What is a "pure" ECS? What makes an ECS pure or not?

Although the term appears to have come up since as early as 2013 in this community, it appears that often, a user asking a question feels the need to explain it. Is there a common, globally accepted definition of what a pure ECS is, so that we would not need to explain it every time?

  • \$\begingroup\$ Can we assume that the reader already knows what an ECS architecture is in general so we don't have to explain it from the beginning and can only focus on what makes one "pure"? \$\endgroup\$ – Philipp Jan 8 '20 at 15:31
  • \$\begingroup\$ @Philipp Yes, we can assume that. \$\endgroup\$ – Vaillancourt Jan 8 '20 at 15:59
  • 1
    \$\begingroup\$ In case you or anyone else missed this, it gives an excellent description of ECS: gamedev.stackexchange.com/a/31491/41345 \$\endgroup\$ – Evorlor Apr 22 at 21:04

A pure Entity - Component - System architecture means that:

  • Every object in your game is an Entity. However, an entity itself has neither any data nor any code. It is an abstract concept not represented by any data structure. It is just an ID number. There is no "class Entity".
  • All the data about the entities in your game is in Components. A component is a "dumb" data container without any executable functions. Each component is assigned to an entity (However, some ECS architectures do allow multiple entities to share a component and/or singleton components which do not belong to any particular entity)
  • All your executable game logic code is in the Systems. A system might hold data which is relevant to the system itself, but no data about the entities it processes. All entity-specific data belongs into components.

However, keep in mind that seeking pureness just as an end in itself can become counter-productive. Architectural patterns are guidelines, not religious dogmas. Sometimes it can make sense to add a small utility method to a component in order to avoid code duplication between systems. Sometimes a system maintaining internal entity-aware data structures can make sense. And almost every game will have at least some code which isn't in a system or part of managing systems.


Here's an article explaining it quite clearly: https://www.gamedev.net/articles/programming/general-and-gameplay-programming/understanding-component-entity-systems-r3013/.

A component can be likened to a C struct. It has no methods and is only capable of storing data, not acting upon it.

An entity is something that exists in your game world. Again, an entity is little more than a list of components. Because they are so simple, most implementations won't define an entity as a concrete piece of data. Instead, an entity is a unique ID, and all components that make up an entity will be tagged with that ID.

Notice that I've neglected to mention any form of game logic. This is the job of the systems. A system operates on related groups of components, i.e. components that belong to the same entity. For example, the character movement system might operate on a Position, a Velocity, a Collider, and an Input. Each system will be updated once per frame in a logical order.

Note that unlike, for example, Unity, in "pure" ECS the behavior and state are kept strictly separate (no behavior in components, no state in systems).

  • 1
    \$\begingroup\$ In the last sentence you call Unity not a "pure ECS". Are you referring to the classic Unity pattern with MonoBehaviours or the new Unity ECS system for the data-oriented tech stack with systems and components? If you are talking about classic Unity, then I fully agree. If you are talking about the new ECS, then I think you should elaborate a bit on what aspects of that architecture are not pure ECS. \$\endgroup\$ – Philipp Mar 6 '20 at 12:44

Pure ECS can also describe one of thw two ways that Unity allows developers to create projects using their--as of 2020, still in development/in preview--ECS development workflow: Hybrid or Pure.

Pure ECS

In a project that is written with Pure ECS, each game object is built purely with Entities, Components, and Systems. GameObjects and Components/Monobehaviors are predominantly not used. (This is not always true as there are still certain types of objects that are unavailable in an ECS form and may still need to be created as traditional Unity GameObjects. I imagine by the first release of ECS there will be ECS form of everything needed to build most games.)

Hybrid ECS

Alternatively, Hybrid ECS is being offered as a go-between the classic GameObject/Monobehavior pattern and the ECS pattern. In this, the developer can use GameObjects and attach a special form of Monobehavior that converts GameObjects into Entities and certain Monobehaviors into Components.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.