Event Based vs Listen Based Interaction

I’ve just been exploring different ways of providing interaction between actors and the player. For example, the player interacts with a switch, which then turns a light on. I know it appears to be a very easy problem to solve on the surface. However once you start diving deeper into it and fleshing out the myriad of interactions that a project requires it starts to get complex quickly. Especially in multiplayer. I just wanted to get some feedback on what others think of using an event based system vs a listen based system, or perhaps there is another approach I’m not thinking of.

Event Based
The invoker connects to the invoked actors. In the above example, the switch would hold a (soft) reference to the light (set at design time). The switch would call an event (via an interface) on the light when the player interacts with the switch. The light would then react accordingly to this event and turn on.

The main advantage of this system is that it is relatively light weight and performant, since it is largely dormant unless an event occurs. The other advantage is that it handles stateless events. For example, a button (unlike a switch that might have an on and off state) can be stateless and therefore only triggers an event when interreacted without actually changing state in any way.

The disadvantage is that it is an exclusively 1…n system, whereby n…1 and n…n relationships (think AND and OR logic for example) are difficult to handle without resorting to messy two-way communication or some sort of middle man.

Listen Based
The invoked connects to the invoker actors. In the above example, the light would hold a (soft) reference to the switch (set at design time). The light would listen for changes to the switch when the player interacts with the switch. The light would then react accordingly to this change and turn on.

The main advantage of this system is that it can handle 1…n, n…1 and n…n interactions with ease.

The disadvantage is that it usually requires some sort of polling in order to “listen” (i.e. a timer for example). This can result in a heavier system with more performance issues as the number of actors and interactions grow. The other disadvantage is that it is harder to handle stateless events. Such as the button example earlier. The button doesn’t change state in anyway when pressed. Therefore the listener has nothing to actually “catch” to determine that a change has occurred and to react.

I just wanted to gather other peoples thoughts on this topic. Is there a particular way you handled interactions in your project? Do you lean towards one way more than the other for some reason, or is there a completely different approach that you’ve taken? Most importantly, have you found any elegant ways of mitigating the disadvantages of either system?

I would say the main thing that dictates which style of interaction you’re going to use, is the current task at hand.

1-1 would be interface

1-n would be event dispatcher

n-n really depends on the problem. Listening can work. Also passing tokens between the actors.

You won’t find the perfect interaction system for all duties.

1 Like

You basically either do direct communication / interfaces, or delegate binding / event dispatchers in UE4. It only really plays a role in which way you do the binding, both of them are event based. The only listen based which updates on the tick that I know of by default in the engine is a widget binding, and even those aren’t recommended to be used.

Is there a particular way you handled interactions in your project?

I use an interface made in C++ with a couple of events, and I handle object highlighting / interaction signals through that. The objects themselves decide what happens once they’ve been interacted with.

I’d bind the other way around IF I had something like a big event, that needs multiple different actors behave in a certain way; like let’s say you have an alarm trigger - then an event dispatcher would handle that signal instead. The alarm sound would play, the lights would blink red, and the guards would change their AI state. It would be easier to handle the bindings that way, i.e. guard enters an area, and once he does, he is bound to the local alarm trigger delegate.

3 Likes