> With this setup I can now add 5 to each object's X position really efficiently. But what's the use case for that? Particle systems, and what else?
Physics, AI, animation, etc.
A player controller is not a good candidate for that type of optimization because they tend to have very complicated logic that needs to interact with many different game systems. Also, you don't usually need to have more than one or a few.
That class you linked to is a mess because it seems like all state is mashed together into a single class. One way to clean this up is to implement an object-oriented state machine, so that state variables and logic are organized into classes instead of being a conditional soup in a giant update function. Here's a good article on that: https://gameprogrammingpatterns.com/state.html
But that game shipped and it worked, and that's really all that matters.
That sounds good, but how would this look like in practice? For the sake of simplicity, let's assume I write a 2D game with classic spritesheets for animation frames. With an ECS, I can pool the animation state of each object into the animation system, and basically execute "anim_frame = (anim_frame + 1) % num_frames" for all objects in one speedy loop.
But game object animations are tied to game logic, and as soon as an object depends on its anim_frame in logic that is outside of the animation system, the cache benefits are moot.
Maybe I'm not thinking big enough in terms of how many "dumb" objects are in the game in proportion to the ones that have lots of logic (like the player).
If you have beefy objects representing, say, characters, and you only care about their position, you'll use 16 bytes of a 64 byte cache line. So for the "move everything to the right" use case you're wasting 75% of the bandwidth if you go with simple composition or inheritance. If you move from arrays of objects to objects of arrays, your cache utilization improves fourfold. This doesn't matter for your character of, IDK, 20 platforms moving on the screen, but it does matter a lot for entities that are counted in hundreds or thousands. There are only that many cache lines available and memory bandwidth is also limited. If it's your bottleneck, ECS is going to potentially solve some problems. If you're doing something simpler it may not matter at all.
The player can be just one component, until you split things to reuse them.
But imagine a simple 2d game: whag are you reusing on a lot of entities?
- collision size
- sprite to render and render properties
- position on grid
- maybe also a velocity, maybe an acceleration
With ECS it becomes trivial to make a system that iterates over all entities with a sprite and a position, and draws them. Another system can adjust the position with the velocity.
Notice how we can create non-moving entities by not having the velocity component at all. Also notice how we can easily add a rendered sprite to any entity without changing any code.
I know this scales well as it gets more and more popular also for larger games.
Bonus: This data is all located together so iterating over Sprite+Position is very cache friendly. And if a system only reads and writes data to the entity jt can also be parallelized.
Physics, AI, animation, etc.
A player controller is not a good candidate for that type of optimization because they tend to have very complicated logic that needs to interact with many different game systems. Also, you don't usually need to have more than one or a few.
That class you linked to is a mess because it seems like all state is mashed together into a single class. One way to clean this up is to implement an object-oriented state machine, so that state variables and logic are organized into classes instead of being a conditional soup in a giant update function. Here's a good article on that: https://gameprogrammingpatterns.com/state.html
But that game shipped and it worked, and that's really all that matters.