A Look Behind The Sound: Audio Middleware

Welcome Wastelanders to the first blog post from the audio team! We’ve been quite busy over the past months and want to show you what we’re doing. This first one is going to be about the technology we’re using and how we’re trying to make the best auditory experience for you, the player!

So, if you’re ready, head on down below!

Challenges In Game Audio

Audio in games is very different from producing audio for a static medium (TV, movies, music, etc); we’re not just exporting a piece of audio, sending it to a producer and seeing it get uploaded soon after, No, audio in games is dynamic in nature and has to react to player input. This means that we need to construct quite a bit of clever coding as well as some good sound design from the engineers.

Unity does come with its own built-in solution but limitations in its features and design make it difficult to work with on a large project.

(Similarly, the music team had this same sentiment, spurring on the creation of Sequence Music Engine, the adaptive music system they use in our game. Check their blog post out here: https://theovermare.com/blog/2014/12/ingame-adaptive-music/)

There are two industry standards professional sound designers are expected to work with: Wwise and FMOD. Now, there’s always a debate on which of these is better but, for the Overmare, we’ve chosen FMOD. FMOD has arguably the best UI (that’s quick to learn), an audio engine that’s been powering games for over a decade and a host of other features that make it perfectly suited for our project. For us, it was the obvious choice and meant we could get audio into the game with lightning efficiency.

This may look daunting at first but if you’re familiar with DAWs (digital audio workstation) then this won’t be too different for you.

The Event

An event is like the upgrade to an audio file. Rather than one piece of audio, you can string together multiple audio files and define when they should all be played. Have a look at this image of an ambiance event!

There is a long piece of audio at the top, which is the basic ambiance, but also lots of other ones scattered below, giving further variation. These bits of audio aren’t triggered every time, meaning this loop will sound unique to the player as they explore the space, and won’t break immersion.

At the top of the image, you can see four knobs. These are parameters and allow for more control of the event when being played. This is a huge advantage compared to Unity’s internal mixer, as now you can have the audio react to player input. For instance, this event has a parameter called ‘Day/Night’. As you can guess from the name, when the parameter’s value is changed, the event will transition to a nighttime sound.

This kind of idea can be applied to create an ambiance that transitions between different states of the game (combat, exploration, dialogue), different locations or conditions of the player (health, fatigue, drugs).

But this works for more than just ambiance; every event can do this and means you have a deep toolbox when it comes to shaping and deploying sound.

The Mixer

The FMOD mixer works very similarly to one in a static DAW like ProTools, Logic Pro, Reaper or even Audacity.

The event (or channel in a DAW) gets routed to a group. These can be chained together to make a hierarchy before going to the master bus (the output).

However, when we dig into FMOD’s mixer we see a specific dynamic tool called ‘Snapshots’. Snapshots allow you to save the volume, panning and reverb levels of the mixer and then transition between these levels during gameplay.

This is commonly used to create a technique called ‘Dynamic Mixing’. In music -or any other static media- the person mixing knows what’s coming next and can then make that sound great. In games, however, the person mixing doesn’t know what the player will do so has to make the audio react to all situations, so maybe you set up snapshots for fighting, exploring, listening to the radio or when you’re in dialogue etc.

The Profiler

Something every game developer wants to know is how their game is performing; without this information, you’re just asking for a sloppy game that no one can run.

Luckily, Unity and FMOD have something called the ‘Profiler’. Both of these let you see things like CPU and memory usage, but FMOD’s focuses in on the audio side of things, giving you levels and voices (number of events playing) -among a few other things.

This also ties in with the things we just checked out: we can see what snapshots are active, what the parameters on an event are doing or why -and most importantly- you’ve got a bug.

This feature is also powerful for the fact you can record your gameplay sessions. This can be done so you can look back at changes you’ve made, or check out how the game sounds in different situations.

But the recording doesn’t have to be from the game you’re playing: it can be someone else’s. Let’s say you want your mix to be thoroughly tested; you could ask a person on QA to play the game, connect to their session and then record the audio -getting all the juicy info you need to optimize or improve the mix.

The Sandbox

The last feature is possibly the coolest FMOD has to offer: the sandbox. This is a test environment for all the audio in the project. Normally, you’d have to play the game in order to mix things; with FMOD, that’s not needed and you can mix safely from the app -no being shot at or having to run around trying to trigger a sound.

And this idea -not having to be in the game- is kind of why FMOD -and audio middleware in general- is so useful: you don’t have to touch the game or code before getting the perfect audio.

To give an example, all of the sounds from the game had to be moved over to FMOD, meaning we had to construct a new mix, and the new changes give the chance for bugs to crop up.

If we had just thrown everything into the game, and mixed along the way, the end result could be a horrible mangle of sounds. But having all the audio in its own, dedicated environment, where it can be perfected, means we can mess around with the SFX without ruining the game for everyone else on the team!!

Anyway, we’re going to wrap up this first blog post in the hopes you enjoyed it! The next one will be about the ‘What’ we’re doing, rather than the ‘How’ we’re doing it.