The short definition
An entity component system, usually shortened to ECS, is a software architecture built from three roles. Entities identify things, components store their state, and systems run logic over matching component sets.
Composition defines what an entity contains. An entity with
Position and Velocity is selected by a movement
system, while an entity with Position and Mesh
can be selected by a rendering system.
The component set is the entity's runtime shape. Systems select that shape through queries instead of depending on a fixed object hierarchy.
Entities, components, and systems
Entities are identifiers
An entity is a compact handle with a component set. It can represent a player, particle, camera, scene node, request, or any other item managed by the world.
Components are plain data
A component describes one aspect of an entity. Position,
Health, Visible, and ChildOf are
examples. Adding or removing a component changes the entity's composition.
Systems run behavior
A system combines a query with a callback. A movement system can request
writable Position data and read-only Velocity
data, then apply the callback to every matching batch.
How an archetype ECS stores data
The ECS architecture can use different storage strategies. An archetype ECS organizes storage around the exact component set of each entity.
An archetype ECS groups entities by their exact component
set. Every entity with Position and Velocity
shares one table. Entities with Position,
Velocity, and Player belong to another.
Each data component occupies a contiguous column inside the table. Queries visit compatible tables and expose those columns as arrays, which gives systems a direct batch iteration path.
Entity composition
The component set describes the data attached to an entity and selects the archetype table that stores it.
Table storage
Entities with the same component set share contiguous component columns that systems process together.
Queries connect data to behavior
A query describes the components a system reads, writes, requires, or excludes. These terms determine which archetype tables match and which component columns the iterator exposes.
ecs::query()
.require<Visible>()
.exclude<Disabled>()
.each([](Position &position, const Velocity &velocity) {
position.x += velocity.x;
position.y += velocity.y;
});A persistent query caches its matching table set. Repeated execution starts from those tables and iterates their component batches.
Structural changes move entities between tables
Adding or removing a component produces a new component set. The runtime transfers the entity to the archetype table that represents that set and preserves the component values shared by both tables.
Updating an existing component writes to its current column. This separates value updates from structural operations and gives both operations a clear execution model.
Where ECS is effective
ECS provides a strong model for applications with:
- Many entities assembled from changing component sets.
- Repeated processing over large groups with the same data shape.
- Independent systems that share data through explicit access.
- Runtime tools that inspect entities, components, and systems.
The composition model describes what each entity contains, while queries provide a direct path from required data to executable behavior.
How SIECS approaches ECS
SIECS implements this model with a C23 runtime and a type-safe C++ API. The world stores entities in archetype tables and keeps queries, systems, resources, relations, modules, and metadata available at runtime.
Queries cache compatible tables and iterators expose component columns as batches. Systems schedule persistent queries, observers connect events to callbacks, and reflection makes component schemas available to JSON and editor tooling.