Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
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?
A pure Entity - Component - System architecture means that:
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).
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.
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.)
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.
