Entity Component System

So you want to use an Entity Component System

I spent three weeks rebuilding a combat system because every entity class needed "invincible," "invisible," and "can't move but shoots," and the inheritance tree had become something I was genuinely afraid to touch. An Entity Component System isn't a magic fix for that, but it is the thing that actually lets you solve it without making things worse. Here's how it works, how to set one up, and where it will bite you.

What an Entity Component System actually is

Three things, nothing more: The reason people get confused is that tutorials describe it like a library architecture when it's really just a discipline. You could implement it in fifty lines if you don't care about performance. You won't, because the whole point is performance and decoupling. Let's skip the framework debate and just build something workable. I've used raw C++ with custom storage layouts, Unity's DOTS, Flecs, and even my own homegrown mess. Starting simple beats starting complex.

This is the part nobody tells you until they've profiled their game and the CPU cache misses are eating 60 percent of your frame time. The naive approach stores components as objects inside a map keyed by entity ID: When System iterates over all entities that have both position and velocity, it looks up each entity in two separate hash maps. That's two pointer chases per component per entity per frame. In a game with a thousand moving objects, that's two million random memory accesses. The CPU cache can't keep up. The fix is a Structure of Arrays, sometimes called a chunked or dense storage layout:

struct PositionComponent { float x, y, z; };
struct VelocityComponent { float dx, dy, dz; };

vector<PositionComponent> positions;
vector<VelocityComponent> velocities;

Entity IDs are now just integer indices into these contiguous vectors. When System iterates, it walks through memory linearly. The hardware prefetcher does its job. This is usually a 10x to 50x improvement on iteration-heavy systems depending on your component count and structure size. You need a way for systems to request "give me all entities with Position and Velocity." A type-erased registry handles this. Each component type gets a unique integer ID assigned at compile time or startup. The registry holds a vector of component handles, and each entity stores a bitmask or a small array of component IDs it owns. For bitmask lookups to work efficiently, you want no more than about 64 distinct component types per world unless you switch to a sparse set or chunkedbitset approach. I hit that ceiling once on a project with 89 component types and had to rework the archetype query system. Going over 64 with a simple bitmask means your query compiler breaks or you do something clever with multiple words per entity.

Writing a system

A system looks like this: That's all there is. Query, iterate, mutate. No virtual dispatch inside the loop if you can avoid it. The query returns indices, not references to objects, which keeps the iteration tight. I was building a pathfinding system that modified component states during iteration. Specifically, I had a System that gave units temporary speed boosts, and another System that checked whether units had reached their destination and removed the boost component. The problem was the removal happened mid-iteration of the movement system, which invalidated the entity index the loop was using.

The fix was straightforward once I understood what was happening: defer all component removals and additions until after the query finishes. I kept a small "pending changes" list per tick and applied it between system runs. This is called the command buffer pattern in ECS circles, and almost every production framework implements it this way. If your framework doesn't, you'll hit this exact issue and waste half a day debugging it.

When to use it and when not to

Entity Component System shines when you have many similar objects that need different combinations of behavior. A tower defense game with fifty unit types, twenty tower types, and various status effects is exactly the right use case. The query system lets you express "all enemies with Slow debuff and Speed component" in one line. It's a bad fit for games with very few unique entity types where inheritance actually makes the code clearer. A first-person shooter with twelve enemy variants and a player character? Traditional OOP will be faster to write and easier for a new programmer to understand. The performance gains from ECS only materialize at scale — usually hundreds or thousands of entities running the same systems every frame. Also, debugging an ECS is genuinely harder than debugging OOP. You can't set a breakpoint on a component's method because the component has no methods. You have to inspect the raw data arrays and figure out which entity index corresponds to the thing you're looking at. I keep a debug overlay that dumps entity-component snapshots to screen during development. Takes an afternoon to build and saves hours every week after that.

Framework recommendations

If you want something ready to use, here are the ones I've actually shipped products with: Don't spend more than two days evaluating frameworks. Pick one, build your first system, and move on. The second you start writing your own ECS from scratch you'll realize you've just reinvented whatever you were going to install, except less tested. More components doesn't always mean worse performance. A system that queries for five components out of a total of fifty registered component types will run roughly the same speed as one querying for two components out of ten. What matters is how many entities match the query, not how many component types exist in the registry. The registry lookup is O(1) after initialization. The iteration is proportional to matching entities, not total component types.

This catches people off guard. They think adding thirty more component types to their project will slow everything down. It won't. Only adding more entities that match a system's query will slow that system down.

Bottom line

An Entity Component System is a way to organize game code around data composition rather than inheritance hierarchies. It gives you cache-friendly iteration, easy new behavior combinations, and decoupled systems. It costs you debuggability, a steeper initial learning curve, and a data layout decision that's hard to undo once you've committed to it. Build the registry with contiguous arrays from day one. Defer all structural changes until after queries finish. Don't reach for it unless you actually need the flexibility.