Came in at v10 without prior experience with spatial. I’m using the experimental MonoBehaviours pretty much exclusively because it matches how we were doing networked entities in our previous implementation (Bolt, a more traditional client/server stack). That being said I haven’t formed a super strong opinion either way yet.
The way I’m currently using these is to have something like a PlayerBehaviour that requires both a SpatialOsWorldTransformComponent and a SpatialOsPlayerComponent, and then I will read and write to various parts of the entity during the update loops. We’re trying to keep our data separated into separate (SpatialOS) components where appropriate and so we can split authority between client and server, but retain most of the code in a single (Unity) component. We’re finding this seems to serve fairly well for being able to reason about all the logic in one place, rather than worrying about how different components are interacting with each other. It’s maybe a bit against the grain of how Unity is set up by default, but so far it’s helping our team.
Agree with @draconigra in terms of not deriving from the generated classes - as well as trying to avoid inheritance, I find it helpful to keep it clear what is network-synced state and what is local-only state.
- Events and commands seem slightly easier to send
- I know that I’m managing whether or not the component is enabled.
- Also not crazy about seeing the updates directly in the editor as an always-on thing. Personally I would prefer being able to enable logging of all message coming in and going out of the network (maybe this is available and I haven’t found it yet?)
- I believe OnComponentReady fires before authority has been granted? It looks like even on a component that has authority, I get HasAuthority as false in the Ready callback. There have been a couple cases where I’d like to use this to set up different behaviour based on whether I’m authoritative or not.
- Access to the client id of the client sending a command. Using the regular command callbacks with a write I believe I could read that out of the request, it would be good to have that exposed on the new CommandResponseHandle handlers.