Entity component system
Entity-component-system (ECS) is a software architecture pattern that separates the functionality into individual components that are mostly independent of one another. Composition is used instead of inheritance. The entity is a general purpose object. Usually, it only consists of a unique id and a container. The component consists of a minimal set of data needed for a specific purpose. Systems are single purpose functions that take a set of entities which have a specific component (or set of components) and update them.
A typical application of ECS is in games design when there are many type of objects with many type of attributes. Instead of using a complex inheritance hierarchy of object types, entities are used with components.
An example of a game engine using the ECS pattern is Unity3D[1].
Game example
Suppose there is a drawing function. This would be a "System" that iterates through all entities that have both a physical and a visible component, and draw them. The visible component could typically have some information about how a thing should look like (e.g. human, monster, sparks flying around, flying arrow), and use the physical component to know where to draw it.
Another system could be a collision detection. It would iterate through all entities that have a physical component, as it wouldn't care how the entity is drawn. This system would then detect arrows that collide with monsters, and generate an event when that happens. It shouldn't need to understand what an arrow is, and what it means when another object is hit by an arrow.
Yet another component could be health data, and a system that manages health. Health components would be attached to the human and monster entities, but not to arrow entities. The health management system would subscribe to the event generated from collisions and update health accordingly. This system could also now and then iterate through all entities with the health component, and regenerate health.
Using events isn't part of the original ECS pattern, is convenient and will decouple dependencies.
Design of an entity
An entity only consists of an id and a container of components. The idea is to have no game methods embedded in the entity. The container doesn't have to be located physically together with the entity, but should be easy to find and access.
It is a common practice to use a unique id for each entity. This is not a requirement, but have several advantages:
- The entity can be referred using the id instead of a pointer. This is more robust, as it would allow for the entity to be destroyed without leaving dangling pointers.
- It helps for saving state externally. When the state is loaded again, there is no need for pointers to be reconstructed.
- Data can be shuffled around in memory as needed.
- Entity ids can be used when communicating over a network to uniquely identify the entity.
Some of these advantages can also be achieved from using smart pointers.
Analogy as a key
The entity can be seen as a key, where the teeth of the key are the components [2]. This key is then used to unlock systems.
See also
- Model-view-controller
- Observer pattern, can be used for sending events between systems.
- Strategy pattern, which is kind of a base for the ECS pattern.