The problem with this is that there is no guarantee that every object with this MonoBehaviour will update after each other so the instructions might be kicked out of the CPU’s instruction cache and then it has to get it from the RAM or slower cache. Getting it from a slower cache or RAM is terrible for performance, we just waste cycles waiting for it. What if instead we could just do all of this logic for everything that needs it at the same time? Then we wouldn’t have to wait and that is what ECS is good for.
The example I am going to show now is a hybrid ECS approach where data is in MonoBehaviours. It does the exact same thing though and will in theory perform much better at higher amounts of objects. Not to mention that ECS in Unity can be run in parallel which means we can use multiple cores to our advantage (In DodgerV2 this would allows us to process both Asteroid and Bullet movement at the same time in 2 threads).
For DodgerV2 I will be using the Hybrid ECS that I showed above approach because I need collision and that isn’t implemented in ECS yet. If that were to be implemented it would be perfect for this project but I am not going to work on that or wait for it.
I will have 2 Entity types:
Because both of those entities only move forward we only need one system for them the ForwardMovementSystem. It will just move the entities forward based on their speed.
For the speed we need a component, we’ll just call this the MovementComponent and all it will just hold a float Speed.
And that is pretty much the whole implementation of ECS I will be using. Pretty simple.
And this was all I wanted to cover in this post. The next post will be the first more journal like one so it might be quite different but it will be talking about market research.
Written 21 Nov 2019 by Grim