The short definition
An Entity Component System, usually shortened to ECS, is an architecture with three roles. Entities identify items, components hold state, and systems process entities selected by component queries.
A player can contain Position, Velocity, and
Health. A movement system only needs the first two. A damage
system can work on Health without depending on the player type.
The three parts
Entities identify state
An entity is a handle owned by the world. It does not contain behavior. Its current component set describes what data is associated with it.
Components hold data
A component represents one aspect of state: position, health, visibility, ownership, or any domain-specific value. Components can be added, removed, and updated independently.
Systems process matching data
A system describes the data it reads and writes, then applies a callback to every matching entity. The query is the boundary between state and behavior.
Composition describes the current role
Composition lets one runtime represent many kinds of entities without a
fixed inheritance tree. Adding Selected changes state. Adding
Velocity makes an entity eligible for movement. Removing
Health changes which systems can process it.
This is useful when the set of things in a world changes during play, simulation, or application execution.
Queries connect data to behavior
A query can require a component, exclude one, make a term optional, and describe whether the callback reads or writes the data.
ecs::query()
.require<Visible>()
.exclude<Disabled>()
.each([](Position &position, const Velocity &velocity) {
position.x += velocity.x;
position.y += velocity.y;
});The query expresses the system's contract. It is also a useful place to review the data dependencies of a feature before writing the callback.
Storage turns composition into a data layout
ECS implementations use different storage models. An archetype ECS groups entities with the same component set into one table and stores each data component in its own column.
A sparse-set ECS stores each component type in its own pool and joins the pools during a view. Both models support the ECS architecture, but they expose different paths for iteration and structural changes.
Read the archetype ECS guide for the table model used by SIECS.
Where the model is useful
ECS is a strong fit for applications with many entities, repeated passes over related data, independent features, changing composition, and tools that need to inspect runtime state.
Games are a common use case, but the same separation works for simulations, visual tools, editors, servers, and other data-oriented applications.
How SIECS applies the model
SIECS provides C and C++ interfaces. It extends the core ECS model with scheduled systems, resources, observers, relations, inheritance, modules, reflection, JSON, and an optional REST explorer.
Continue with the C API, C++ API, or game development guide.