Thanks so much to noio, Jonas and Peter for the excellent discussion above!! I just migrated our project to the GDK for Unity and wanted to add my observations to help others going through the same process.
- SendCreatePlayerRequestSystem assumes that the spawner entity will have the hardcoded ID of 1. If you don’t put the spawner in your snapshot first, you won’t be able to create players.
- In the WorkerConnector classes, I needed to add: GameObjectRepresentationHelper.AddSystems(Worker.World) before GameObjectCreationHelper.EnableStandardGameObjectCreation(Worker.World), otherwise none of the Monobehaviours were enabled. This is mentioned in the troubleshooting documentation, but does not appear in the section describing: SpatialOS entities: How to link SpatialOS entities with GameObjects which was my guide for this process.
- When representing a worker as a GameObject as discussed here, the monobehaviours on the GameObject are enabled as soon as the scene runs: Before the GameObject is actually connected to the Worker and before any included _[Require]_d CommandSenders, etc are set. This means that these [Require] elements cannot be referenced inside OnEnable(). It is necessary to write code that checks to make sure the values were injected before using them.
- As far as I can tell, while most of the EntityQuery workflow is supported, there is still no way to actually generate the IConstraints that define the EntityQuery. Note that ComponentInterest.QueryConstraints exist, but do not implement the IConstraint interface.
- It is no longer straightforward to work with component data in Entity objects (the CInterop version) and EntityTemplates hide entity and component data altogether. Our issue with this was that in building an “initial conditions” snapshot, if entities have any kind of interdependence, it is useful to get all the initial data into the entity objects in a large list, then iterate through that initial data and make adjustments based on inter-dependencies. Without a way to work with these “intermediate Entity objects,” we end up needing to create our own intermediate classes to hold all the initial data, operate on those and then build the entity templates afterward. This feels somewhat silly considering that the Schema system is already building classes to store all of this data and put them into Entities anyway. I got around this in a roundabout way by using a sort of loophole to get access to the Entities from the EntityTemplate, then getting their data by using the built-in component serialize functions, but this method is patchy and will presumably break in future GDK code iterations. Direct methods for altering component data in Entity objects and providing a way to access them through the EntityTemplate would be helpful.
- Currently, the MonoBehaviour workflow seems to load all prefabs in a single frame. In the Unity SDK there was an option to load only a certain number of entities per frame, but I don’t see that in the GDK. This can cause the client to miss too many heartbeats while loading and disconnect.
Those were the main issues that I encountered. All in all we are very excited about the Unity GDK!! The extra performance from the ECS system will be great, the automated component updating system is much cleaner, and the ability to debug both client and worker in the same Unity project makes a big difference. Thanks!!