Data-oriented ECS: ownership and iteration before architecture labels

Start from the work

An entity-component-system architecture is useful when it makes the game's data and processing easier to organize. The label alone promises neither speed nor simplicity. Begin with a frequently executed operation: identify the fields it reads, the fields it writes, and the entities that actually need that operation.

Identity, data, and systems

Entities provide identity, components associate data with entities, and systems operate on selected component combinations. Flecs documents these roles and query-driven systems. [1] Archetype storage groups matching component sets; Unity Entities stores such data in chunks, with structural changes potentially moving entities between groups. [2] Other ECS storage strategies make different tradeoffs.

Worked example

Consider an illustrative update for 20000 moving sparks. Each requires a three-component position and velocity, each component represented by a 4-byte float. The movement payload is 20000 × 6 × 4 = 480000 bytes.

A hypothetical monolithic record of 128 bytes per spark would occupy 2560000 bytes, including unrelated fields. These payload calculations do not establish actual cache traffic or a speedup: alignment, padding, chunk occupancy, and access patterns still matter. They motivate testing whether the hot loop can traverse compact Position and Velocity arrays without following per-object pointers.

Define the integration system to read Velocity and write Position. A lifetime system owns expiry. Queue removals for a documented structural-change boundary rather than invalidating the active traversal. Rendering can read the resulting positions after the required dependency completes.

Practical workflow

Map systems' reads and writes before scheduling parallel work. Two systems that write the same component require ordering or a safe partition. Stable entity handles should outlive storage movement; cached component addresses may not. Specify when queries and references must be refreshed.

Keep high-frequency fields close to the operation that uses them, and separate bulky infrequent data where measurement supports it. Examine archetype count, chunk occupancy, structural-change cost, and random lookups. An entity relationship that repeatedly jumps to unrelated storage can dominate an otherwise linear update.

Tradeoffs and validation

Adding and removing components is not free in every ECS. Many tiny component combinations can fragment the workload, while a giant component can make unrelated systems touch excess data. Choose granularity from ownership and measured access, not a rule that every scalar deserves a component.

Compare representative scenes with identical behavior and include creation, destruction, and transitions. Inspect total frame cost and memory, not only the best inner loop. A small game with highly individual objects may reasonably use conventional objects alongside ECS-managed bulk simulation.

Sources

[1] Flecs quickstart — Sander Mertens and Flecs contributors.

[2] Archetype concepts — Unity Entities documentation.