Improbable Icon

1-Day-In Feedback

v10-1-0

#1

Started looking at the SpatialOS architecture in Unity yesterday. I love the concept, but I have a few things that I’d like to state…

  • There are a completely gratuitous number of namespaces; makes writing code nearly improbable. There should be ~5 namespaces total, and only 1 that you need to perform common tasks.
  • Turns out “EntityTemplates” are just normal classes with a static convenience function for generating entities. Could have just said so!

May make an “EntityTemplate” alternative that just loops through the generated monobehaviours on the entity prefab to generate the entity.

  • Connections to Generated Monobehaviours won’t survive being pulled through git; need to add the meta files for the generated scripts to the .gitignore
  • Not obvious what spawns prefabs at the beginning of the game and sets up the scene’s state. Actually, I still don’t know what does it.
  • Hello World is precisely the opposite of what a Hello World should be: gratuitously complex with indecipherable layers of optimizations and pooling on top of the already confusing game/netcode.

It SHOULD just be the Blank Project: walking you through how to spawn minimal player prefabs that users can control, rigorously laying out what it means to create an entity (and what the best practices are for doing so for players, entities in the beginning, and entities in the middle of the game), basic component updating (and update handling), and handling players leaving. There should be no specific improbable related code there that the user didn’t write/import during the codegen process! Ideally it would also use the new Generated Monobehaviours, since these can fit rather nicely into Unity’s own Entity/Component model.

.

If you want us to do advanced techniques like pooling, world origin movement, and dynamically loading/unloading areas, those systems should be packaged into reusable components, not tightly integrated into a monolithic “Hello World” project.

  • There are no examples on using the generated monobehaviours. I understand these are relatively new, but even a hyper minimal (emphasis on “hyper minimal”) example project would clear things up.

I look forward to mastering the workflow and watching the system and its community grow and mature


#2

Glad I’m not the only one who suffers from namespace overload. :wink:


#3

Hey @zalo, thanks for the feedback. Just thought I’d give some reply to couple points:

  • Namespaces: Yep, totally agreed. We have plans to audit and do some cleanup (hopefully in a painless way for people already using them.)
  • Generated MonoBehaviours have stable GUIDs generated for them based on their assigned component ID. You can .gitignore them and regenerate them and references will still be properly maintained.
  • Overall the new MonoBehaviours are pretty basic, so any feedback you have on them is greatly appreciated!