A question regarding how to respond to 'events'

Question

What is the best practice to use when events happen in a game? For example:

1. You have a sensor. When a particular game actor is near that sensor, a sound must be played and a door must be closed.
2. When a collision between characters A with animation i and character B with animation j happens, a special graphical effect, a sound effect and a decrease of life points of A and B should come into effect. Furthermore, A and B must be forced to return to some specific animation.
3. The user presses the left-key, so actor A must be moved.

What I would like to know is: do you play sound, move the player, close the door (calling the relevant methods, like PlaySound(..), CloseDoor() or MovePlayerLeft()) directly in the event handler or do you use some sort of message based system, so that when the actor manager code is called, it sees that the player must be moved to the left and moves it to the left. Also, when the sound manager code is called, it sees that a particular sound must be played and plays it and so on...

Ps. I would really be happy to see some reference to books/papers/articles to read something related.

Answer 1

There's no best practice really. It would depend a lot on the engine you're using, the complexity of the game, etc. If I was writing a small Flash game then I'd write the PlaySound call right into the sensor check for the player. If I was writing a bigger game using Unity or equivalent I would do the same, except the PlaySound call might well be implemented as a message (since you wouldn't want every object to know about all the possible systems that can result from all events).

Personally I wouldn't add a messaging system just for the sake of decoupling code - you obscure the flow of control for very little gain. But if you find your code is too tightly coupled, then sure, add a messaging system.

I would also stick to active changes ("when this happens, move the player to the left") rather than passive changes( "so that when the actor manager code is called, it sees that the player must be moved to the left and moves it to the left"). If you make things too passive then the flow of control becomes too awkward to follow and you can't easily track what has caused a change in an object's state. If you're sending messages, send them immediately (if possible) and act on them immediately (if possible).

Answer 2

gamedev.net link 1

gamedev.net link 2

The code in these articles is badly structured, just download the source and study it as you're reading.

Ad. 1: The sensor could act as an NPC that has a proximity list and sends apropriate messages to the elements on the proximity list or sends a message to the sound engine, etc.

Ad. 2: Animation is not a part of game logic. You can implement a messaging system where you send a message to the object B that reads "i'm enemy A and i just attacked you for 10 damage" and then the function handling this message could send a message to the graphics engine and tell it "i've made an attack, please display an attack animation for me". The fact that there's an animation playing along side of the event of dealing damage is a separate thing.

Ad. 3: Again, you send message to object A that says "change position" or "move 3 to right". The event of pressing a button is a part of reading input, not game logic. If you need information about how to read input, that's a whole different story.

The message handling function for a particular object could send messages to the sound and graphics engines, it depends on how you structure your game. You should be fine as long as there's no actual displaying or sound logic within the player or NPC class.

Answer 3

I agree with Kylotan's answer about "keep it simple, straight forward and avoid too many indirections".

But I want to add one exception:

When handling object deletion or "remove from scene" events, I found it very helpful to not immediately handle these messages (or events) by deleting objects right now. Instead, just set a flag "toBeRemoved" and shedule the actual deletion at some specified point in your main loop grouped together.

Also, try to minimize dependencies when destroying objects (small destructors / Dispose() functions / DeInit() / whatever). Or consider writing a separate "OnRemoved" function which gets called and where it is guaranteed that other referenced objects in the current frame are still exist (but whose OnRemoved may already have been called).

The reason are that you just will make mistakes and errors. And when it comes to deleting objects, errors very often end in null pointer access, AlreadyDisposedException or whatever is the equivalent in your language ;).

Its very easy to make mistakes where you accidently destroy objects that aren't there anymore while destroying that very same object. Or another common example, where you change a list (e.g. an event listener list) from a destructors while iterating over the very same list.

Just handling the actual removal later isn't a perfect solution. But many times, it turns crashes into glitches.