Good way to play a sound when something happens? How does this sound?

Question

So I was thinking about how monolithic my classes get a lot of the time. For example, in the Character class's Jump method, one may have a reference to a sound effect object and play that. By itself that is fine but when physics, animation, collision, etc. are taken in to account the Jump method gets huge and the Character class has a lot of dependencies to many different things. Still, this may be fine. However, what if we no longer want a sound to play when the character jumps? Now, we have to find that specific line of code in the jumbled mess of the Jump code and comment it out or whatever.

So.. I was thinking..

What if, instead, there was some sort of AudioSystem class and all it did was subscribe to random events it's interested in in other classes. For example, the Character class may have a Jumped event (static too, I suppose) that is raised within the Character class in the method. Then, the Character class would know nothing about the little sound effect that is played when the character jumps. The AudioSystem would just be a huge class that the programmer could retreat to to hook up sound effects with certain events that happen in the game through the use of static events. Then, if it got too big it could be separated in to subclasses like EffectsAudioSystem, BackgroundAudioSystem, AmbientAudioSystem, et cetera.

Then, in the options for the game, one could have a checkbox to enable or disable these sorts of sounds and all that would need to be done is just to disable that one system with a simple and single Boolean flag. This idea of systems could also be extended in to things like physics, animations, etc. to the point where most of the game responses resulting from player actions are hooked up through these elaborate and decoupled systems.

Okay, so my question may be a little vague, but how does this sort of thing sound? I haven't really ever heard of much kind of talk about this sort of system. This is all up in my head right now without any coding done so far so perhaps it's one of those "good in theory but not in practice" kind of deals. Would this kind of system work with a larger game or would it eventually break down and become even more of a spaghetti mess than the original system?

Answer 1

Messages are a hell to debug and maintain. It sounds good in theory, but once put in practice it gets messy with lots of duplicated data sending around. The jump-sound-effect will need a lot more data at the end, for instance the position, velocity, material the character is on, you name it, the list will be long at the end.

So either you will need to collect this data and send it to the AudioManager via a very specific event/message with the data copied in it or you will send a reference to the character in the message, so the AudioManager can access the data, both ways end up messy, and now the audio-manager has to choose a sound for the material-underground etc.

So at the end the specific event (which is a very specific class for only this message) will couple those classes very deep again. Not much won and at the end you will have a messy big list of very specific events/classes which only serve the purpose of sending data around, which exists already, and may be out of date and will suffer from all other problems of duplicated data.

So there will be a huge list of unnecessary classes to maintain which introduce a deep coupling between the character and the AudioManager, except now it is scattered all over the source-code. Not only in the Character- and AudioManager-classes.

Still a good idea to decouple your code, but Messages are really just another way of deep couplings. Some code just has to be coupled, use the most direct way to couple them, don't over-engineer.

Answer 2

I don't think a message passing system is over engineering at all. In fact it can make it dramatically easier to get things done in the polish phase. You're doing it right!

What you described is exactly what I threw together for our Global Game Jam game last year. I was responsible for creating and editing the SFX, and integrating music that myself and another composer wrote into the game in a way that didn't suck.

What's great about this approach from an audio perspective is that it allows you to do so many more interesting things with your sound. If you think a sound effect in a game is merely a sound file, volume, and panning, then you're doing it wrong.

Example

For our game you were a dinosaur flying a spaceship running into planets to score points. We were working in Flash, so a data driven infrastructure wasn't needed. The AudioManager was a class consisting of a bunch of static methods whose sole purpose was to control what sounds happened in response to a game event.

If I were to write it in C++, then it would have taken a bit more time to abstract all the possible behaviors sounds could have. The requirements for a message notifying the system an action had taken place wouldn't be too complicated. It would just need the message type, the object of origin or object being affected, access to some kind of game state context, and not much else. The protocol could grow as the game's needs grow. Naturally, if you do all of this in implementation in code (like our shoddy GGJ code), you have a worse monolithic class problem. But that's easily mitigated by making a data-driven system.

Anyway, here's how our game audio system reacted to various messages:

• Player collides with planet: This would trigger a planet explosion sound, basic enough. then immediately after it would query the running combo counter. If it was high enough it would schedule a sound effect to be played half a second or so later of the dinosaur doing a victory roar. Also in the background a random planet population value was calculated (something like 600 to 3000--I have no idea why that range was chosen, it was some abandoned gameplay mechanic and still lying around for me to use to make the audio interesting), and so I used that to scale the volume of the distant sound of screams (planetary citizens meeting an untimely fate).

• Player holds spacebar for acceleration: Upon receiving this a little "whoosh" thruster sound was played, but also simultaneously a low looped engine roar ramped up over 1.5 seconds. The particle system also used this to fire an emitter IIRC

• Player lets go of spacebar for deceleration: Now that the player had let go of the spacebar, the audio system knew it had to ramp the engine loop back down. If I had more time I would have liked to layer another sound over it that was a sort of whining pitching down type of sound.

• Player collides with evil space mine: Space mines are bad, so not only is there a metallic impact sound combined with an explosion (that's just baked into one sound), but there's also a randomly selected dinosaur dismay sound that plays. It's more likely to choose more "crying" like sounds as the player's health gets lower.

An already fun game becomes a delight to play when its soundtrack is active and dynamic, even with just little simple behaviors like I described above. Yes there are some logistics to work out with making sure the correct data gets passed. But hey, BFD. It will be far from the most complicated thing you have to write in the larger scope of the game code.

In fact, FMOD and Wwise work like this. They don't have a central message dispatcher, but you effectively post events to their central systems and they react by playing a sound effect that was pre-designed by an audio implementor in an authoring tool. Think of it like giving your game a live DJ. He sits and watches what's going on, and triggers sound clips at the right times to keep things interesting, mixing them so they fit well into the preexisting audio environment.

[EDIT] Also, I see you've tagged this C#. Is this XNA, and if so are you using XACT? If you are using XNA you should be using XACT.

Answer 3

I agree with Maik Semder, that a message passing system may be over-engineering (for now anyway).

From what I understand, your class currently looks like the Bjorn "monolithic class" as can be seen in "A monolithic class" here.

I suggest you read that article, and, although a full component system would be overkill for now, if you read to "Splitting out the rest", that should give you a good way to abstract your behaviors and eventually maybe move to a more complex solution. It will give you a good base to start from anyway.