Is it useful to distinguish between two different kinds of events?

Question

i have thought about this for a long time and i think i just going in circles. I need someone to tell me if im just simply overthinking it.

So, first of all im coming from a 'classical' ECS approach: You got entities that are basically just Ids, Components to these IDs in different colors (PosComponent, 2dGraphicComponent, etc.) and your systems working on those components. Im still working on an game engine, so none of these components are fix.

Now i have an event manager that accepts events. Currently these events are like MouseButtonClicked, KeyPressed, WindowResized etc. These are events, certain systems have to react to these events immediately and can't wait to be resolved in the next game loop. So the polling for these events is at the beginning of the loop. Since the event manager does not know, that system handles this event, every system needs to be called in order, until one system handles the event and gives a positiv feedback. So for example if you click on the gui, you don't want to shoot a bullet.

Then there are events, that always have some context attached to it. Like an event onCollision, where a sound should be played and the player takes damage. In this case this event would need to be handled by two different systems and in context of the collided object. Bumping spikes might actually kill you, while colliding with an enemy may just hurt you. And of course the sounds are different.
Additionally, you may have events that are delayed to trigger. Faraway sounds like gunshots only move with the speed of sound, so delay it in regards to the distance. Or Buffs and Debuffs that run out. So these events should have a connection to a component or entity (id) and some sort of time to dispatch.

These two event types seem so distinct that i can't even think of realizing both as one class, or at least not the all the assumptions i made.

Maybe this is a stupid question, but should i create two different event types and thus eventManager? In my internet searches i have not found anything about this problem, but maybe my Google Fu is a bit rusted.

Answer 1

A common solution to free systems from having to process every single event is by using a subscription architecture. Individual systems can subscribe to specific types of events. The event dispatcher manages these subscriptions and dispatches events to only those systems which subscribed to them.

You can then further enhance the architecture by allowing conditional subscriptions. Like only receiving events for specific entities or only events which happen in a specific area. Just make sure that the event dispatcher is actually in a better position to filter events than the subscribers themselves and can make the decision for multiple subscribers at the same time. Otherwise there is not much gain from moving the logic for discarding events from the subscribers to the dispatcher.

Delayed actions like running out buffs is something I would not try to handle in the event system. There are just too many edge-cases which would require to cancel such an event prematurely. For example, what happens with the already scheduled buff end events when an entity is destroyed before its buffs run out? I would rather handle such timing problems in the systems themselves which would then create a "buff end" event when it actually happens.