Take the 2-minute tour ×

I am studying the Entity 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 realize interaction between the various systems?

share|improve this question
And what is the question? –  Karlson Feb 3 '12 at 18:15
@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 Feb 6 '12 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 Feb 6 '12 at 14:07
add comment

2 Answers

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

share|improve this answer
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 Feb 6 '12 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. –  Patrick Hughes Feb 6 '12 at 19:48
add comment

Systems and Components are no 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.

share|improve this answer
add comment

Your Answer


