Systems and Events

As mentioned before, all game logic goes into game systems. There might be a physics system that is responsible for moving entities, or a health system that is changing entity health. All of these systems communicate by the means of game events, only.

Let’s take a look at an example: Say there’s a FightSystem that decides (in whichever way) that the entity with the id 337 has been attacked. It creates an EntityAttacked event and sends this event to a dedicated event manager. The event can contain any required data, such as the ids of attacker and defender, or the damage type of the attack. At this point, the FightSystem is done, nothing more to do for it here.

Now, there’s a HealthSystem that has registered for this event, and asks the entity manager for the HealthComponent of the entity with the id 337. After having completed all computations, such as detracting armor or considering the damage type, it reduces the health value of the component by 19. After that, the system creates a DamageTaken event and hands that event over to the event manager.

There might be other systems as well, such as a SoundSystem that is interested in DamageTaken events for playing hit sounds, or an AnimationSystem that has registered for these events for playing hit animations. There is a huge upside to this approach: There is no coupling at all between game systems. You can literally delete the AnimationSystem code file, and the game will be just fine with that.