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
    Commented Jan 8, 2020 at 15:31
  • \$\begingroup\$ @Philipp Yes, we can assume that. \$\endgroup\$
    – Vaillancourt
    Commented Jan 8, 2020 at 15:59
  • 1
    \$\begingroup\$ In case you or anyone else missed this, it gives an excellent description of ECS: What is the role of "systems" in a component-based entity architecture?. \$\endgroup\$
    – Evorlor
    Commented Apr 22, 2021 at 21:04

4 Answers 4


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
    Commented Mar 6, 2020 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.


“What makes a ECS pure.” Short version In it core, the strict splitting data from code and entity strict a ID or key or handle. Component is strict pure data, POD.
Often there is not 1 component but many. Thus a container of that type component. The data accessed through the container interface.

In my opinion getter en setters on component is not pure, but that debatable. You set and get component using the container. You prepare for batch processing of that container. Manage or do Sort all alive component at beginning

Pseudo code: Parallel foreach in alive range of that container do update. That where the multithread friendliness of pure ecs and DOD comes in.

  • 1
    \$\begingroup\$ Please consider using spelling and grammar checking software, especially if posting in a language that is not your first. It's harder to attract upvotes when posts contain glaring errors. \$\endgroup\$
    – DMGregory
    Commented Aug 4, 2023 at 20:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .