Event handling in Pure Entity Component Systems, is this approach correct?

Question

I want to ask if the following is an effective way to architect event propagation using an ECS?

Here is a hypothetical collision scenario using an ECS.

Components:

class Collider {
    public var rect:Rectangle;
}

and

class Health {
    public var health:Int;
}

Now for the behaviour logic:

We can create entities with Collider and/or Health components.

Some ColliderSystem handles entities (more specifically, nodes) with Collider components. It deals with handling collision logic and determining if two Collider component rectangles overlap.

Moreover, if an entity with a Collider component has a Health component, the Health component's value should decrease.

How would I implement this behaviour?

---

I see three ways to approach it, 2 bad, 1 good.

1. Bad idea 1: We could check for a collision on all ColliderHealthNodes in a HandleCollisionsSystem each frame, but this seems like a waste of computation. The value likely won't be changing every frame.

2. Bad idea 2: Instead of an events system however, we can use the ECS to pass this logic via system registration. Our HandleCollisionsSystem could add a Collided component (really just a tag) to the Collider component's entity. Then our HandleCollisionsSystem would be registered to our ECS with an aspect of <Collider, Health, Collided>.

   Besides this looking like an overuse/abuse of ECS, it also silently couples logic between systems (how do we know that CollisionSystem will add Collided component tags to the entities of the ColliderNodes it processes?) How do we know that our HandleCollisionsSystem needs to have an aspect that includes a Collided tag? CollisionSystem and HandleCollisionsSystem need to know each others inner workings and so become logically, but invisibly, coupled.

3. Good idea (?): The approach that makes the most sense in my mind is to use an event-listener pattern and to have our CollisionSystem broadcast CollisionEvents, while our HandleCollisionsSystem can listen to CollisionEvents. The implementation is described below:

---

We'd create an enum:

enum CollisionEvent {
    BEGIN_COLLISION;
    // ... could have more types
}

And we create our CollisionSystem like so

//aspect:<Collider>
class CollisionSystem {

    // some collision determining logic to determine if a Collider
// is being collided with -> calls the broadcastCollisionEvent function
// on those Colliders that are colliding
    
    function broadcastCollisionEvent(event:CollisionEvent, collider:Collider){
        eventSystem.broadcastEvent(event, collider)
    }
}

We'd then have an interface

interface CollisionEventListener {
    function handleCollisionEvent(event:CollisionEvent, collider:Collider);
}

And our HandleCollisionsSystem would look like

//aspect:<Collider, Health >
class HandleCollisionsSystem implements CollisionEventListener
    
    public function handleCollisionEvent(collisionEvent:CollisionEvent, collider:Collider) {
        colliderHealthNode = findNodeForColliderComponent(collider)
        switch(collisionEvent){
            case BEGIN_COLLISION:
                assocNode.health.health -= X; // some computation
            // other cases
        }
    }

Our HandleCollisionsSystemthen gets registered as a listener for CollisionEvents to the EventSystem. When the CollisionSystem broadcasts a CollisionEvent, the EventSystem will propagate that call to the HandleCollisionsSystem to handle.

Is this the best approach for handling event propagation between systems?

If it isn't: is there a better way?

If it is: how would we implement findNodeForColliderComponent()?:

Would we always register ColliderHealthNodes within a Collider->ColliderHealthNode map within our HandleCollisionsSystem upon registration to be looked up later?

---

Note 1 Specifically referring to a ECS to mean pure ECS: that is, all behaviour would be encompassed by systems and all components are data-only. Systems don't have access to entities directly and only operate on "nodes"- bags of components that match their respective aspect; ie ColliderSystem operates on "nodes" with only a Collider component, and HandleCollisionsSystem operates on "nodes" with both a Collider and Health component.

Note 2 In this simplification, it may look like merging CollisionSystem and HandleCollisionsSystem would make sense, but the separation is there to allow extension to a more complex scenario where we have multiple different HandleCollision systems that care about CollisionEvents and affect different aspects.

Answer 1

Merging systems, such as collision and collision response, is a bad idea. The reason being that there can be many different responses to collisions: Physics based, and game-logic based.

In most game engines I have seen (ECS and non-ECS and all the greys in-between), there is some kind of inter-system communication system, because this is what makes the creation of games possible.

As far as communication goes, you want your engine to handle two basic message types: events, and commands.

Events get queued up, and processed at the beginning of the next frame(synchronously), or handled asynchronously (as soon as they are received). Which you choose is up to you (but I recommend async).

Commands are for something that does not affect the game state, but modifies the engine state (startup/shutdown/change settings/log error).

Both can be routed very similarly, but this distinction is very important: An event is something that occurred in the past, and a command is something that is to occur in the future. What is also very important is whether you let the processing of one event generate other events. If handled incorrectly, you may end up blowing the program stack.

My personal approach, is for the highest level of the engine to have a central event queue, which is emptied at the beginning of the update cycle, and filled up again during the update cycle, as game events occur. Each system has it's own event queue, but the events that end up in there are filtered by each systems responsibilities.

When these events are processed by each system, they can generate additional events which are passed back up to the engine level, and en-queued.

Once this is in place, you can then have multiple collision event handler systems, each of which behaves differently (and could be run off scripted behaviours if you want).

Now, here is where we get to the meat of the question:

How do we handle things like health from say, a bullet hitting the player?

Well, that's simple enough. Both entities should have some kind of GameObjectData component, which, to keep this simple, contains a type (string, enum, whatever). The player has a CharacterData component too.

So, when a collision event is received by our "GameCollisionHandler" system, we can query a couple of things, like so:

GameCollisionHandler::handleCollisionEvent(CollisionEvent& e, Engine& engine){
    //find entities by unique id provided by event


    auto entityA = findEntity(e.first.getID());
    auto entityB = findEntity(e.second.getID());

    //Query if we have a bullet/player match
    if ( entityA->hasComponent<GameObjectData>() ){

        auto data = entityA->getComponent<GameObjectData>();
        if ( data->getType() == "Player"){

            if ( entityB->hasComponent<GameObjectData>() ){

                auto data = entityB->getComponent<GameObjectData>();
                if ( data->getType() == "Bullet"){

                    if (entityA->hasComponent<CharacterData>()){

                        entityA->getComponent<CharacterData>()->decrementHealth(10);
                        // and let the engine know that the bullet is to be removed
                        engine.sendCommand(RemoveEntityCommand(e.second.getID());

                        if ( entityA->getComponent<CharacterData>()->getHealth() <= 0){
                            engine.sendEvent(PlayerDeath(e.first.getID());
                       } 
                   }
                }
            }
        }
    }
}

This is a very crude example, but I think it illustrates the idea reasonably well.

So, to more concisely answer your question:

Is this the best approach? Possibly, there are no silver bullets in programming. I believe so, but could be wrong.

Is there a better way? I don't believe so.

How would we implement findNodeForColliderComponent()? I have no I idea what you mean by that, except that it is some form of search function. Your engine, at this stage, should already have some form of multi-function search ability, so that should cover it.

Answer 2

Your question boils down to

Is it a good idea to use a publisher-subscriber-based GUI and to keep this subsystem distinct from my ECS (while enabling interop between them)?

Yes, keep your UI and your ECS systems totally separate.

Notice what I'm not saying here: I'm not saying you should not have mouse-clickable entities. What I am saying is that it would be ideal to keep your primary UI system totally separate from your clickable entities system. But first... Why is it a good idea to keep them distinct?

• You are obeying the Single Responsibility Principle
• Low coupling brought by pub-sub (event dispatchers and handlers)
• "Silent coupling" that you mentioned is avoided - you never, ever want to think about side effects of what a system is doing. You want systems that do the minimum possible to fulfill their role, whether that is at the function, class, or module level. "Do the job and go home" - see FP.
• You indeed want to avoid polling if you can help it, as it is costly and unnecessary in most cases. Handle things as they happen, this means function call stacks which means your event system.
• Btn components - bad, bad idea. You are smearing (for lack of a better term) one layer of logic into another, embedding an aspect of the UI system into your ECS. It quickly becomes unclear who should be controlling whom, and that's a bad place to be at in a codebase.

So how can you achieve this?

Option A There's the play area, and superimposed over it, the UI. If a click misses everything in UI, it gets delegated down to the play area / game world viewport. At this stage, your entity system takes over entirely, and uses its own custom approaches to handling clicks. Notice that what is shared between these systems (UI and ECS) is fairly trivial - primarily the ability to decide who, if anyone, gets the click. It's generally a lot easier in the game viewport however, because you usually haven't got nested elements to contend with, as in UI. So it's a simple box, circle, and/or pixels based collision check that returns an entity ID. And away you go.

Don't be taken in by that little voice that says, "but... but... I could reuse so much of the architecture if I could only make the entities use the UI system!" It's a seductive lie that never works out. YAGNI. Better to copy some logic from one to the other where needed, and avoid mangled architecture.

Option B Create a simple UI element (button?) with bounds to represent each entity and have these track the entity positions each frame, only for those entities that are in view and thus clickable. In order to do this, your UI system should listen for additions, removals, and positional changes of individual entities as broadcast by the ECS core (preferably not from individual entities themselves). This way as far as the UI system is concerned, it is dealing only with its own known types (UI elements) and not some foreign types (Entities) which it would then have to be re-written to handle (tight coupling).

P.S. I made a joke on another ECS post today that "In order to discuss ECS, you first have to define ECS... in full." That holds true here as well. I am not telling you how ECS is supposed to work. Everyone has a different view of that, and some approaches are considered more "pure" than others. I am giving you the benefit of experience - don't mix the primary subsystems of your game. ECS is a direct submodule of your larger game logic, and game logic should never be dealing with raw input or rendering, which is exactly what UI is. That's why you are advised to have the UI system, as a View (in the MVC sense), subscribe to the ECS system which is a Model (in the same sense) in B, ensuring your core game logic concerns remains clean, vs. being polluted by unrelated concepts.

---

EDIT

Let's look at your proposals again (now that they've been updated via the comments).

• Use an ECS in the pure sense of having supercontrollers make changes to, and read state from, data elements; (consequently) have pure data elements with no functions.
• Not separate your logic between view/render/UI at the ECS components level,
• Yet separate it at the supercontroller level (BtnSystemvs. BtnGraphicSystem where you have your pub-sub).

Focusing on ECS, I suggest that you read Mick West's Evolve Your Hierarchy, the seminal text on pure ECS. Mick does not disallow mixing of view vs logic components; whereas for the record, I do.

On my (deleted) answer you mentioned:

...all behaviour would be encompassed by systems... For an ECS-based GUI, Btn would be a component (data-only). Btn would not have an OnDown function and BtnSystem (which would have a aspect) would handle all entities with Btns behaviour. Thats why the BtnSystem would receive events from an InputMgr and handle logic per Btn. A BtnGraphicSystem would receive events passed from a BtnSystem to apply graphic changes to entities who have both Btn and Graphic components.

You are planning to implement several new classes just to implement this one, tiny, new bit of functionality. That's a code smell. Good engineering primarily centres around one thing: Keep moving parts to a minimum. Every interface between parts is a potential point of failure.

In addition to the above wants, you presumably also need a generalised UI system that will be generic to all sorts of UI elements (menu buttons, inventory etc.), that will in any case replicate some of the functionality of clickable entities. If you already have such a system that amply accommodates UI elements, and/or can be easily extended to accommodate a new sort of UI element while still remaining utterly generic (i.e. no knowledge of Btn* at all), then why would you introduce new classes to do what the UI system can already do? Let the regular UI system handle button state changes, as it would for any other button. For the UI supercontroller to find out about entities, have a proxy, be it your main game loop or a distinct UIEntityProxy controller, subscribe to events dispatched by the ECS supercontroller, which it then routes to your regular UI system (which could be anything from QT to DOM to your own custom but encapsulated OpenGL-based system). That is, the proxy will inform the UI to add remove entities for the current viewable area of the world. The UI system can then act to add clickable elements for each entity, as appropriate, and maintain graphical state for these.

However, I think you are proposing that the graphics are instead handled by the ECS supercontroller. Also, I think entities sound like your primary interest here, and not generic UI systems, so let's ignore the latter. ECS system then handles all clicks, game logic changes and graphics. The pub-sub approach is unnecessary, and I do see a problem with the separation into BtnSystemvs. BtnGraphicSystem; since your entity components may be either view or game logic related, then you may as well conflate this logic in your supercontroller as well, and avoid class proliferation (fewer moving parts). Doing Controller vs. View in once place, yet not in another, just leads to confusion. It can be as simple as the following (pseudocode ahead - interpret rather than taking literally):

ECS.BtnSystem
{
    //register for event from your OS, platform, or library
    Initialise()
    {
        SomeAPI.RegisterMouseDownCallback(OnMouseDown);
    }

    //receive callback from your OS/platform/library indicating that mouse device state has changed
    OnMouseDown(pos)
    {
        entity = GetEntityAtClick(pos);
        entity.UpdateModelState(); //cache game logic state of the entity as caused by mouse interaction
        entity.UpdateGraphicState(); //cache render (or "frame") state induced
    }
}

//main game loop
...
{
    ...
    //by here, OnMouseDown should already have run and stored some state - both logical and graphics - for the following steps to use.
    RunGameLogic(); //use game logic state
    ...
    RenderBackground();
    ECS.RenderEntities(); //use stored graphic state
    ...
}

Why set up event systems when you can just do everything where the device input event comes in?