Entity component system

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Entity-component-system (ECS) is a software architecture pattern that implements concepts from Composition over inheritance using a database-like structure. Common ECS approaches are highly compatible with Data-driven programming techniques, and the two approaches are often combined.

History[edit]

The 2002 game Dungeon Siege has one of the first recognizable ECS implementations, as documented in Scott Bilas's talk at GDC the same year.[1]

Bilas's talk explicitly mentions the now-standard concepts of: database for composition, "data-driv[ing]" the schema not just the properties, components as "self-contained" items, etc.

In 2007, the team working on Operation Flashpoint: Dragon Rising experimented with ECS designs, including ones inspired by Bilas/Dungeon Siege, and Adam Martin later wrote a detailed account of ECS design,[2] including definitions of core terminology and concepts.[3] In particular, Martin's work popularized the ideas of "Systems" as a first-class element, "Entities as ID's", "Components as raw Data", and "Code stored in Systems, not in Components or Entities".

With the launch of the iPhone, the Unity game engine grew hugely in popularity from 2008-2010, making their different use of Entities and Components become well-known and widely-used. However, Unity has not formally described their approach, and "ECS" as a term is usually assumed to mean the 2002 Bilas approach instead, unless specified.

Terminology[edit]

Martin's terminology,[4] in wide use today:

  • Entity: The entity is a general purpose object. Usually, it only consists of a unique id. They "tag every coarse gameobject as a separate item". Implementations typically use a plain integer for this.[5]
  • Component: the raw data for one aspect of the object, and how it interacts with the world. "Labels the Entity as possessing this particular aspect". Implementations typically use Structs, Classes, or Associative Arrays.[6]
  • System: "Each System runs continuously (as though each System had its own private thread) and performs global actions on every Entity that possesses a Component of the same aspect as that System."

Game example[edit]

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 draws them. The visible component could typically have some information about how an entity should look (e.g. human, monster, sparks flying around, flying arrow), and use the physical component to know where to draw it.

Another system could be collision detection. It would iterate through all entities that have a physical component, as it would not care how the entity is drawn. This system would then, for instance, detect arrows that collide with monsters, and generate an event when that happens. It should not 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.

Design of an entity[edit]

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.

Drawbacks[edit]

There are a couple of problems with the ECS design.

Inter system communication[edit]

The normal way to send data between systems is to store the data in components. For example, the position of an object can be updated regularly. This position is then used by other systems.

If there are a lot of different infrequent events, a lot of flags will be needed in one or more components. Systems will then have to monitor these flags every iteration, which can become inefficient. A solution could be to use the observer pattern. All systems that depend on an event subscribe to it. The action from the event will thus only be executed once, when it happens, and no polling is needed.

Cost of iterating through entities[edit]

The basic idea is to have one big list for all entities. Every system then iterates through the complete list, and selects only those entities that are needed. If the number of systems grows, and the number of entities is large, the total iteration cost for all systems may be too big.

One solution to this can be to create subsets of entity lists. A typical example is collision detection. If all objects are tested against all other objects, the cost will grow quadratically. This cost can be dramatically reduced with spatial partitioning and separation in different types.

If this separation is taken to an extreme, with one list for each entity type, then it may be that the entity-component-system pattern does not fit well with the problem.

Managing dependencies[edit]

(What happens when specific component/system requires another one to operate)

Composability[edit]

(How to implement functionality that is effectively a combination of several existing systems/components)

See also[edit]

References[edit]

  1. ^ Bilas, Scott. "A Data-Driven Game Object System". Retrieved 25 December 2013. 
  2. ^ Martin, Adam. "Entity Systems are the Future of MMOG Development". Retrieved 25 December 2013. 
  3. ^ Martin, Adam. "Entity Systems are the Future of MMOG Development Part 2". Retrieved 25 December 2013. 
  4. ^ Martin, Adam. "Entity Systems are the Future of MMOG Development Part 2". Retrieved 25 December 2013. 
  5. ^ "Entity Systems Wiki". Retrieved 9 February 2014. 
  6. ^ "Entity Systems Wiki". Retrieved 9 February 2014. 

External links[edit]