Event queue: tell or ask?

Question

I'm working my way through a lot of game development resources, coming from a completely different field of software development, I'm interested in learning what patterns are frequently used in game development, and which aren't.

During my research, I wanted to know if/how event queues are handled in games, and came across Game Programming Patterns' post about Event Queues. _{^{(as an aside, what an awesome resource that book is!)}}

In it, Bob Nystrom gives an example of a "play audio" queue, where one part of the system can produce/enqueue the playing of an audio fragment, and the audio handler/consumer can act on that request whenever it can.

I like this pattern a lot, but the end-result still feels like it results in domains being crossed, because the sender (in this example the part of the system that deals with a unit dying) has to ask the audio system to play the "deathSoundID" sound using playSound(deathSoundID) (which, in this case, then enqueues that request for the audio engine to pick up as soon as it can).

What I expected to be proposed is that the sender in this case tells the audio engine that an event occurred (by having the audio engine listen for events from this specific game system), at which point the audio engine can then determine if/how it wants to act on that specific event.

Now, admittedly, there's still crossing of domains here, as in my example, the audio engine now has to have some kind of (huge) case statement that couples any game event to an audio-related action, but you no longer have to litter unrelated functions with calls to playSound, and it also forces you to be a good citizen, and allow other systems to act on whatever action you just took, be it the audio engine in this case, or the "gamepad rumbler" engine that wants to rumble your gamepad because you've just slain a large enemy.

Another downside to this is that you need many more queues for all your systems (if you want to avoid some kind of global event queue, which I think you should), which might not be practical/performant enough to do, so perhaps that's the reason why it wasn't chosen here.

Either way, as a newcomer to game development, I'm interested to hear why one would be preferable over the other, and in what situations that would be the case.

Answer 1

Telling the audio system that an event occurred (versus demanding that the audio system play this sound right now) is generally preferable because it lets the audio system make the final determination about whether or not/how to play the sound. Whether that looks like "posting a request" or "posting an event" is largely a semantic issue. The important part, as you note, is that the audio system gets to decide the specifics.

Audio engineers typically have limitations to work with that are both technical and physical. Technically, the engine may only support playing N sounds simultaneously, and physically a player may only want to hear M sounds at the same time (otherwise it sounds like noise). Similar restrictions exist for background music tracks.

Gameplay code that triggers a character death probably isn't aware of what else is going on in the world, audio-wise, and so by telling the audio system "a death sound should play," the audio system can look up the priority assigned to death sounds and decide if that sound gets to override any other sounds currently playing, or if it needs to reduce the volume on the background music track, or if it needs to mix that sound in with some other enqueued sounds to reduce the total number of audio buffers being streamed to fit some technical constraint.

All of those priorities and mixes and overrides are usually defined in data controlled by the audio engineers who oversee that domain; it's better to have that data (and it is data, in a production-scale system, not "one big case statement," although the concept is basically the same) localized in one spot there, for them (via tools like Wwise) than to scatter it around a bunch of areas in the gameplay code.

For similar reasons, game code will often want to say "play a death sound" rather than "play screaming_burning_on_fire_omg.wav because it will let audio engineers control sound variations, randomness, pitch shifting based on other audio events and queues, from within their data rather than having to poke around in a bunch of different areas in code or data.

For games with smaller, perhaps one-person teams, this kind of organization is maybe less useful. But for any larger-scale project where there is a dedicated team working on the audio, that team will likely prefer the approach where they get to actually make the decisions about how the audio works.

Answer 2

There's a lot to balance in practical game development.

Generic event system vs domain-specific:

One doesn't preclude the other.

You can use a generic queue system:

audioQueue.SendEvent("PlaySound", deathSoundID);

And wrap it in a convenient function:

void playSound(ID_TYPE soundID) {
    audioQueue.SendEvent("PlaySound", soundID);
}

//...

playSound(deathSoundID);

By wrapping a generic message system into domain-specific API calls we get the advantage of a tested and debugged generic message system while keeping the code very readable at-a-glance and easily refactor-able.

Decision making

It can be up to the sender, the receiver, or both. We can even add a 3rd layer in between the two ends to add for example a context-aware filter.

eg: Turn playSound() from global function to a local member function of actor object that can make more decisions, and then call the global playSound() function.

The receiver (audio system) can decide to ignore the message or alter its interpretation.

The message parameter soundID can be either a specific sound or a class of sound, it's really up to the receiver.

The message can be an order to play a sound or a request to play a sound, again it's up to the receiver.

Redirection

Nothing prevents the audio system from sending rumble commands as part of the sound effect processing.

In fact, the rumble motor is just a very low-frequency sound generator and some advanced haptic-feedback use low-frequency weighted solenoids (essentially a "speaker" without a diaphragm).

So we're not even breaking out the audio concept nor functionality.

If you feel things would be more manageable with one more abstraction you can create an "effect" system that then sends events to other sub-systems.

But too many abstraction layers can make it very difficult to know what's happening and why.

Domain-Crossing

"Perfect is the enemy of good."

You'll always have domain-crossing: Things have to talk to one another.

The best practice is to keep it to a minimum, not to eliminate it completely which is not possible.

Separation of Concerns

The important part here is to keep game-specific logic out of the lower generic/reusable engine code.

You can add callback-functions and/or data-driven masks, remapping tables, and settings if game-specific context-sensitive decisions/tweaks are needed so the engine-level code remains game-agnostic.

ie: If one level needs a particular sound remapped, a remapping table feature can be added to the audio engine. The audio engine doesn't "know" it's on the "Fire Level" it just knows it has to remap the sound. It's up to something inside that level on the game-side to enable/disable the remapping.