Hybrid ECS vs Standard Monobehavior
June 11, 2018 | Go Back
I am new to ECS and thought I would give it a bash, using the hybrid approach. In this article, note that I have not touched on the Pure ECS approach.
So I built two scenes in my project sharing prefabs and materials where possible. One scene named standard, the other called hybrid.
Each scene contains a player controlled sphere and a game object that spawns enemy spheres that will chase the player sphere.
All spheres have rigidbodies and colliders, when the enemy sphere collides with the player sphere it will change colour based on its health (The player cannot be hurt). The player may also force push the enemy spheres back when using the left mouse button.
In the attempt to reduce render draws I implemented meshes with LODs that have a low vert count, in the attempt that unity will batch the render draw calls - this appears to have been implemented correctly when viewing the statistics window during the play mode (Saved by batching).
I added component systems to handle the enemy spheres chase direction and movement, then another component system handles the enemies colour changing based on health (this will reduce the batching of the render draw calls, due to us changing the colour of a shared material - making an instance of the material).
While all spheres are idle (or cannot move), the CPU usage graph in the profiler indicates that the Hybrid approach ever so slightly better. Standard was averaging around 14ms (71,2 FPS) and Hybrid was averaging around the same. You can see on the graph that the scripts and rendering usage is about 20% less, but Physics is still eating away at our usage - regardless of hybrid approach or not.
I would suggest not using physics on your objects if you are generating a lot of them (rather use your own scripts to simulate basic physics or movement), thus you will lose out on the cool features that physics gives us, but at the same time giving us the sheer numbers of objects without crippling your games performance.