A bit about GameObjects
A bit about GameObjects.
I nearly have none of them.
Thanks for coming to my TEDx talk.
No, but for real... My first Unity games consisted, obviously, of GameObjects, each with its own script. Creating a new NPC was a controller initializing a new GameObject from a saved prefab, the prefab held the code associated with that GO, and that's how stuff moves across the screen, explodes, dies, finds paths, etc.
Quite soon, however, I learned that this isn't the most ideal way of writing largish/complexish games: It's quick if you want to shoot toothpaste at sugary sweets to prevent tooth decay (a game concept I once worked on), but as soon as you want more complex characters, maybe with their own preferences and statistics, it all becomes a bit more difficult.
So like many programmers, I tried to decouple my code by using the Model-View-Controller (MVC) pattern: My model ruled the world, it was able to save & load, it held all the logic and decisions, and the View and Controllers were mere 'followers': The Controllers could pass commands to the model, and the view registered itself with the model to get updates about moving entities, etc.
However, the View still instantiated a GameObject per entity, and even though GOs produce little overhead, they produce more overhead than no GOs, so I tried to reduce them even further.
Dutch Delta
For an unrelated game I'm working on, Dutch Delta, I wrote my own shader. It's a simulation able to simulate waterflow over ~1.5m 'tiles' with no GameObjects per tile. I have one GO, "the view".
Using the Unity Jobs & Burst system allows me to do the calculations for the waterflow multithreaded and extremely fast. One ViewGameObject receives the changes, updates its local data, and sends the bare data off to the shader. The shader, using GPU instanced meshes, draws the tiles and water at the correct height.
Everybody who has ever worked in a Unity project knows 1.5m GameObjects would grind the sim to a screeching halt, but with this Burst+Jobs->GameObject->Shader setup, I am able to run the sim at ~60fps.
Having seen the possibilities of working without GameObjects, I wondered: Would this work in Starship CEO?
Yes. Yes it would.
It's not entirely fair to say I don't have GameObjects or prefabs in Starship CEO. I've got 23 GameObjects in my Game scene: A GameController, a CameraController, a DebugController, even a controller that just builds the menu at the start of the game. The thing is: No more GameObjects are added, no matter how big your ship gets. It stays 23. Well... 23*
I also use prefabs. Extensively. All my objects are bought from the Unity Asset Store, so most arrive as prefabs. I just don't use them as prefabs. When an entity of a new type is instantiated, a script reads the prefab, completely strips them to their individual meshes and materials, and creates a GPU instanced mesh per entity type. Every entity you see in the game is just one more rendered copy of the same mesh and materials. Every one? No! One small band of indomitable GameObjects still holds out against the optimizations. And it won't surprise any programmer that, once more, it's one type that ruins it for the rest of the entities: People.
For static objects, GameObjects are completely pointless overhead. A wall, a crate or a machine doesn't need a transform hierarchy or Unity's scene graph overhead just to sit there - rendering them via GPU instances means zero extra performance hit no matter how big the ship gets. So instantiating a full GO for static geometry is just unnecessarily degrading performance.
Of course, with all their movements, helmets, animations, stances, activities, dying, hair color, preferences and whatnot, moving people fully to the GPU hasn't been successful. Yet. Recently I found out how I can, at least in theory, do the animations fully on the GPU, without having to create separate meshes per person... The goal eventually is to do it all without any GO 'per entity'. Until then, people are the only ones cluttering my scene and degrading performance unnecessarily.