Hacker News Reader

Comment by gurkendoktor | Hacker News Reader

> Physics, AI, animation, etc.

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).

View on HN

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.

Reply on news.ycombinator.com