Currently, I am learning about entity-component-systems, and I have a question concerning the components. How would the systems handle dependent components?

For example, In a 2D game, I have a game object entity that has the following components:

  • RenderComponent - contains current character sprite

  • AnimationComponent - contains set of sprites and frame index

  • CharacterStateComponent - tells what the character is actually doing

Given player input, such as "move_forward", I am not sure which of the following procedures should happen:

  1. System Polling:

    1. Input notifies StateSystem.

    2. StateSystem updates CharacterStateComponent.

    3. AnimationSystem reads CharacterStateComponent changes.

    4. AnimationSystem updates AnimationComponent.

    5. RenderSystem reads AnimationComponent changes.

    6. RenderSystem updates RenderComponent.

    7. RenderSystem draws RenderComponent normally.

  2. All-in-one Updates:

    1. Input notifies CharacterSystem.

    2. CharacterSystem updates CharacterStateComponent, AnimationComponent and RenderComponent.

    3. AnimationSystemiterates AnimationSystem normally.

    4. RenderSystemdraws RenderComponent normally.

I am not quite sure how the engine would respond to a change in one component that is suppose to update other components, as well. I believe there will be performance issue, when it comes to each system having to poll its prerequisite component changes (as shown in System Polling).

How would the entity system handle dependent components?

  • 4
    \$\begingroup\$ This has been asked many times already. Check the right side for clues and be open to different naming since everyone hits this problem somewhat differently. \$\endgroup\$
    – snake5
    Commented Jan 30, 2013 at 12:07
  • 1
    \$\begingroup\$ Here's an answer of mine from another question, that is also relevant here: gamedev.stackexchange.com/questions/23755/… \$\endgroup\$
    – Paul Manta
    Commented Jan 30, 2013 at 16:21
  • 2
    \$\begingroup\$ I've found this to be an excellent answer. \$\endgroup\$ Commented Jan 30, 2013 at 16:35
  • 1
    \$\begingroup\$ @NoobsArePeople2 That answer is "OK" for learning about how systems work, but it doesn't really address the ordering for system processing. I guess the author wasn't complete enough. \$\endgroup\$
    – House
    Commented Jan 30, 2013 at 18:07

2 Answers 2


I wouldn't suggest having your systems be triggered by input. The systems should run in your update loop and should poll input when they start. You can solve that by having an input component and system. That also means that only entities controlled by the keyboard have an inputComponent, so they're the only ones that get updated on keyboard input. Pressed keys should be queued in the inputSystem when they happens. Then the inputSystem will process the input when it's time to run. Similar to your first scenario, they would run in order:


Just make sure to order your systems so that you're not a frame behind. At the moment there's no cyclic dependencies in your systems, so you have no problems.


Components should be independent, and Systems should communicate via some indirection such as a message bus/event aggregator. Your input system can publish an event to the message bus, and any other interested systems can opt to subscribe to the event, thus decoupling the two systems in this way:

InputSystem --> MessageBus.Publish(MoveForwardEvent)

MovementSystem --> MessageBus.Subscribe(MoveForwardEvent, MovementSystem.MovePlayerForward)


You must log in to answer this question.

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