I am studying the Entity-Component-System architecture philosophy. As I have read about it, a typical entity system has:

1) Entities - which are merely ID tags which have a number of components

2) Components - which contain data on various aspects of an enity that the component is responsible for

3) Systems - which update relevant components of every entity. Say, a rendering system updates the rendering component, or simply saying, draws a picture that is stored in the data of that component. A positional and movement system handles position and movement of each entity who has a corresponding component.

These statements follow from this article which in my opition tries to be the most clear and pure in it's statements -

But the author did not explain how the interaction between systems should be realized. For example, the rendering system must know the data from the positional component of an entity in order to draw it in a correct position. And so on.

So the question is - how should I implement the interaction between the various systems?

  • 1
    And what is the question?
    – Karlson
    Commented Feb 3, 2012 at 18:15
  • 1
    @Karlson the question is in the last paragraph - how should I organize interaction between two components of an entity, say, how a rendering component should take data from a spatial component in order to render a thing in it's place... I can think of a number of ways but I am not sure how they align with ES concept in general.. so I am interested in knowing how is it done traditionally.
    – noncom
    Commented Feb 6, 2012 at 8:40
  • Instead of putting it in the comment you should put this in the original question. Because your last paragraph is a statement and not a question.
    – Karlson
    Commented Feb 6, 2012 at 14:07

3 Answers 3


So the question is - how should I implement the interaction between the various systems?

Ideally they don't interact, not in any direct sense. The systems in an ECS all have access to the central ECS database where they can fetch entities and components attached to them. They don't talk to each other directly. They talk to the database and all run independently of each other.

enter image description here

Dependencies Flow Towards Raw Data, Not Abstractions

The dependencies in an ECS do not flow towards functions, not even abstract functionality. They all flow towards raw data which might sound like an epic violation of many accepted software engineering principles, and in my opinion it is, but yields something easier to maintain for some cases. Maybe some software engineering principles are wrong or at least not applicable for all scenarios. There are many situations where it's easier to achieve data stability than interface/design stability. As a basic example, it's much easier to reason about what data fields a raw matrix component should have once and for all and keep that stable (unchanging) for years to come. It's much harder to figure out all the functions an abstract IMatrix interface should provide once and for all and keep that perfectly stable (unchanging) for years to come without facing temptations, if not outright needs, to add and remove and change functions.

So in appropriate cases, when your dependencies flow towards data instead of abstract functionality, your codebase will find fewer and fewer and fewer reasons to have to face central design changes with cascading effects and potentially big parts having to be rewritten. To direct dependencies towards data in that case is directing them towards stability. It's worth asking yourself as a developer whether the tendency in your system is for developers to add, change, and remove functions or to add, change, and remove data from components. If it's the former case, you might benefit greatly from an ECS engine.

If systems start to depend on each other a lot, that's directing dependencies away from data and towards functionality, and many of the maintenance benefits and the ability to reason about the correctness of your engine and easily keep it stable at the design level will be lost. Of course a pragmatic solution might sometimes call for a system calling a function in another every once in a while, but you should generally seek to keep that to a bare minimum. Instead of talking directly to each other, you can have systems modify and attach components to entities in a way such that other systems can then pick up those changes and react accordingly.

System Interaction

[...] the rendering system must know the data from the positional component of an entity in order to draw it in a correct position. And so on.

That it can grab from the ECS database, looping through entities with renderable and position components, just as the physics system before it might loop through entities with position components and modify their position. Generally each system fits into a basic loop model:

for each entity with the components I'm interested in:
    do something with the components

... and you have to start thinking about doing things in passes, often multiple passes even if the intuitive solution is to do everything in one pass. For example, it might come more intuitively to loop through all your game entities and apply physics and respond to input and process AI and render them all in one go. That can minimize the amount of loops you have and also require less state. However, the ECS tackles this typically with multiple simpler passes and sometimes slightly more intermediary state to use from one pass to the next, but as a trade-off, it leads to a much easier system to maintain and one which is easier to change and potentially parallelize* and vectorize.

  • As yuri mentioned, it could also make things harder to parallelize, at least across systems in an inter-system way, but could make things easier to parallelize in an intra-system way because it's easier to reason about the correctness of a parallel loop without locking if it's, say, making less state changes on the way and the code involved in the pass is much simpler. In my blunt opinion, it's often not worth multithreading the systems themselves so much as the loops they are performing inside for the most performance-critical systems.

Multiple, Simpler Passes

It's somewhat similar to GPU programming since GPUs aren't so good at doing complex things with each iteration, so they often excel instead at doing simple things per iteration that add up to a complex task after repeatedly running through the same data with multiple, simpler passes.

Unlike GPU programming, you can still potentially do much more complex things in a single pass, but each pass will represent like one logical thought: "for each of these components, apply physics", not both physics and rendering. The physics system performs its own pass just as the rendering system, living in its own isolated world, performs its own completely separate and detachable rendering pass. Each system lives in its own little world, seeing only the ECS database and being able to grab components and entities inside. They shouldn't have to bother with what other systems are doing.

In fact, in a well-designed ECS, you can remove any system from the engine and not have the codebase collapse horribly on itself because systems don't depend on each other to function. All they care about is the central database and the components (which are raw data) that they are interested in processing. They all live in their own isolated world. As a result you should be able to remove the physics system from your game, at which point motion components will cease to have physics applied, but everything else should keep on working just as before. It's extremely orthogonal in that respect.

Event-Driven Programming

Event-driven programming can be a bit awkward with ECS, but one straightforward way to solve that is to have event queue components. A system can push events to these queue components for another system to pop and process in a deferred fashion without the first system directly calling functions in the second. Again the bulk of your interactions should not be system->system, but system->ECS, and system->component.


Quick answer to the question that you haven't asked yet: the entity ID tag is like the key to a database row in a table, you query the system(s) using that key and pluck out the info you need.

Yes it is theoretically slower than storing pointers away. No, it is not as slow as you would think because systems can look up that key O(1).

Another quick answer to a question you haven't asked yet: yes, these component systems that everyone loves lately require some infrastructure work to get them working smoothly - they don't exist just as a realignment of where data is stored =) TANSTAAFL

  • Do I understand correctly from your answer that there should basically be two parts of an ES - the storage which is more like a DB and a machine that queries that storage? And that the actual program logic is the one that operates the queries, and really is the third part?
    – noncom
    Commented Feb 6, 2012 at 9:06
  • That's a good summation @noncom of it. More like a smart DB holding the components tied to the data. A component is the low level code to handle a bit of data, say Health for example. A system, which is the program logic, says to the DB give me Health for this ID and then tells Health to -10 itself. Health may then look up other components by ID and tell them to do something or simply update status more likely, or other systems like character's Life can watch for Health to be 0 (depends on your architectural choice, MVC or whatever). It's definitely not OOP but it is very flexible. Commented Feb 6, 2012 at 19:48

Systems and Components are not restricted to 1:1 relationship, though that is a desired trait that allows parallel processing without requiring synchronization. Generally a system can operate on any number of components attached to a entity. For example consider the following typical setup:

  • Components

    • Mass
    • Acceleration
    • Velocity
    • Position
    • BoundingVolume (for collision detection)
    • Model (visual representation)
  • Systems (with components they operate on)

    • Physics: Mass, Acceleration, Velocity, Position, BoundingVolume
    • Rendering: Position, Model

This gives every system access to all the components it requres, without the need for intersystem communication (actually this communication happens implicitly via components), but at the cost of sacrificing parallelization.

  • One of the benefits of ECS is improved CPU cache hits, due to contiguous layout of components during updates. However, if the RenderingSystem has to combine PositionComponent and ModelComponent of an entity from two separate lists, isn't that negating any potential benefit of the design? Commented Jan 7, 2020 at 21:57
  • 1
    @MarkIngram that depends on how exactly you components are laid out, but yes, there are certain trade-offs. Commented Jan 11, 2020 at 15:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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