 | This articleis written like apersonal reflection, personal essay, or argumentative essay that states a Wikipedia editor's personal feelings or presents an original argument about a topic. Pleasehelp improve it by rewriting it in anencyclopedic style.(October 2013) (Learn how and when to remove this message) |
Entity component system (ECS) is asoftware architectural pattern. An ECS consists of entities composed of data components, along with systems that operate on those components. It is most associated withvideo game development for the representation of game world objects.
ECS prioritizescomposition over inheritance. Every entity is defined not by a type hierarchy, but by the components associated with it. Systems act globally over all entities that have the required components. For example, a food system might iterate through every entity with a relevant component tracking hunger, and act on them to push them a little away from satiation at time intervals. Entities lacking the component like terrain or items would be naturally ignored by the food system.
Due to an ambiguity in the English language, an interpretation of the name is that an ECS is a system comprisingentities and components. In the 2002 talk at GDC,[1][2] Scott Bilas compared a C++ object system and his new custom component system. This is consistent with a traditional use ofsystem terms in generalsystems engineering withCommon Lisp Object System andtype system as examples.
Although mostly found invideo game development, the ECS can be useful in other domains,[3] such as inrobotics simulators like Gazebo.[4][example needed]
ECS combines orthogonal, well-established ideas in generalcomputer science andprogramming language theory. For example, components can be seen as amixin idiom in variousprogramming languages. Components are a specialized case under the generaldelegation approach andmeta-object protocol. That is, any complete component object system can be expressed with thetemplates andempathy model within The Orlando Treaty[5] vision ofobject-oriented programming.
The behavior of an entity can be changed at runtime by systems that add, remove or modify components. This eliminates the ambiguity problems of deep and wideinheritance hierarchies often found inobject-oriented programming techniques that are difficult to understand, maintain, and extend. Common ECS approaches are highly compatible with, and are often combined with,data-oriented design techniques. Data for all instances of a component are contiguously stored together in physical memory, enabling efficient memory access for systems that operate over many entities.
In 1963,Ivan Sutherland'sSketchpad stored the visual elements of a drawing using an early form of an ECS. Instead of encapsulating points in different objects (e.g. lines, circles, rectangles) points were stored in aring buffer, and visual elements were only referencing them. When moving a point, this allowed updating all the shapes and constraints using it.[7]
In 1998,Thief: The Dark Project pioneered an ECS.[8] The engine was later used for its sequel, as well asSystem Shock 2.
In 2002, Scott Bilas of Gas Powered Games (Dungeon Siege) gave a seminal talk on ECS.[1] This inspired numerous later well-known implementations.
In early January 2007,Mick West who worked on the Tony Hawk series, shared his experiences on the process of ECS adoption at Neversoft.[9]
Also in 2007, the team working onOperation Flashpoint: Dragon Rising experimented with ECS designs, including those inspired by Bilas/Dungeon Siege, and Adam Martin later wrote a detailed account of ECS design,[10] including definitions of core terminology and concepts.[11] In particular, Martin's work popularized the ideas of systems as a first-class element, entities as identifiers, components as raw data, and code stored in systems, not in components or entities.
In 2015,Apple Inc. introducedGameplayKit, anAPI framework foriOS,macOS andtvOS game development that includes an implementation of ECS.[12]
In October 2018[13] the companyUnity released its megacity demo that utilized a tech stack built on an ECS. Unity's ECS runs on a powerful optimized architecture known as DOTS, which "empowers creators to scale processing in a highly performant manner".
The data layout of different ECS's can differ as well as the definition of components, how they relate to entities, and how systems access entities' components.
Adam Martin defines in his blog series what he considers an Entity–Component–System.[11]
An entity only consists of an ID for accessing components. It is a common practice to use a unique ID for each entity. This is not a requirement, but it has several advantages:
Some of these advantages can also be achieved usingsmart pointers.
Components have no game code (behavior) inside of them. The components don't have to be located physically together with the entity, but should be easy to find and access using the entity.
"Each System runs continuously (as though each System had its own private thread) and performs global actions on every Entity that possesses a Component or Components that match that System's query."
Unity's layout has tables, each with columns of components. In this system an entitytype is based on the components it holds. For every entitytype there is a table (called anarchetype) holding columns of components that match the components used in the entity. To access a particular entity one must find the correct archetype (table) and index into each column to get each corresponding component for that entity.
The normal way to transmit data between systems is to store the data in components, and then have each system access the component sequentially. 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 theobserver 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.
The ECS has no trouble with dependency problems commonly found inobject-oriented programming since components are simple data buckets, they have no dependencies. Each system will typically query the set of components an entity must have for the system to operate on it. For example, a render system might register the model, transformations, and drawable components. When it runs, the system will perform its logic on any entity that has all of those components. Other entities are simply skipped, with no need for complex dependency trees. However, this can be a place for bugs to hide, since propagating values from one system to another through components may be hard to debug. ECS may be used where uncoupled data needs to be bound to a given lifetime.
The ECS uses composition, rather thaninheritance trees. An entity will be typically made up of an ID and a list of components that are attached to it. Any game object can be created by adding the correct components to an entity. This allows the developer to easily add features to an entity, without any dependency issues. For example, a player entity could have abullet component added to it, which would then meet the requirements to be manipulated by somebulletHandler system, which then could result in that bullet doing damage to other objects by running into them.
The merits of using ECS for storing the game state have been proclaimed by many game developers like Adam Martin. One good example is the blog posts by Richard Lord, where he discusses the merits and why ECS-designed game data storage systems are so useful.[14]