How would the entity system handle dependent components?

Question

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?

Answer 1

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:

inputSystem.process()
stateSystem.process()
animationSystem.process()
renderSystem.process()

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.

Answer 2

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)