Five essential things to listen out for in game audio

Audio in games is essential. Just as important as beautiful graphics, engaging gameplay or engrossing writing. When you think about early iconic games like Pac-Man, Donkey Kong and Space Invaders, you think about the sounds they made, and when other media such as film and television reference video games, the shorthand used is often that of some audio cue like the uncanny chirping of an Atari 2600.

Audio might do more than any other aspect of a game in immersing the player in the world. Just close your eyes and imagine an exciting firefight. What you're hearing in your mind's ear is the clatter of shots through air, the whizz of bullets going by a little too close, and the ping and pops of them driving into the car you're taking cover behind. The firing might suddenly cease, leaving you alone in the cold tone of a dimly lit and deserted street. Even the absence of sound is essential.

Audio in games tells the stories, and sucks you into the world. Despite all of this, audio in the daily schedule of games development is often an afterthought

Audio in games tells the stories, sets the mood, gives feedback from game mechanics, and sucks you into the world. Despite all of this, audio in the daily schedule of games development is often an afterthought. Many audio teams are absent of programmers, QA, or production and have to beg, borrow, and steal from other departments, usually on a limited schedule.

Of course, this isn't true everywhere, but it's true more often than it should be. I'm an audio programmer at Rev Rooms, a dedicated games audio co-development studio based in Brighton. This studio was borne out of the many years we had collectively worked in game audio, the things we learned along the way and the conclusions we came to regarding how to solve the issues of modern audio development in games most effectively.

In this article, I will outline five things I've learned over my years working as a programmer in game audio.

1. A good audio programmer needs to be a good programmer dedicated to audio

Code resources are often stretched during game development, and dedicated audio coders are typically uncommon outside large teams. Therefore, it is an unfortunately common occurrence wherein programmers are begrudgingly let out on loan to the audio team to add in whatever audio hooks have been requested, often on a short-term basis and with little time to develop anything beyond rudimentary systems or to iterate on solutions.

This then leaves the design team out in the cold, trying to come up with ad-hoc solutions because a hook wasn't quite implemented correctly, or because of knock-on bugs, or because they've simply discovered that their needs have changed slightly from what was initially expected.

Imagine this same situation in other departments: a graphics programmer with no interest in graphics and no real passion for the fruits of their labour, or a game designer with precisely one shot at getting a new mechanic right, with no chance to iterate or improve on it. Without dedicated audio programmers, this is the reality of audio development in many games. All of this conspires to severely hamper the creative process of what I'm sure we agree now is one of the essential elements of games as an art form. Plus, it slows the entire process down, pushing back schedules and costing money.

The best option will always be to make sure you have at the very least one dedicated audio programmer working with an audio team. A good audio programmer should be able to speak the language of both audio and code, as they act as the effective interface between the audio team and the code team at large. They need to have a good understanding of how audio systems are engineered in middleware, what the optimal interfaces between these middleware systems and code should be, and how to marry aesthetics with performant behaviour. There really is no substitute.

2. Audio coders should be good generalists

Audio is a vast system in any game and must interface with a vast swathe of different parts of the codebase. Anything you can see will invariably require audio, and game mechanics will almost always need supporting audio to help or provide feedback to the player. There are cinematics to consider and environments that need populating with an ambience to provide mood and immerse the player in the virtual worlds we are endeavouring to flesh out.

A good audio programmer must be adept at sifting slippery fingers through diverse areas of code. They need to have a light touch, integrating audio hooks and systems into other complicated codebases they may never have interacted with before. The audio code needs to be robust and be able to cope and sustain its functionality while the surrounding system evolves. Therefore, it is best for audio systems to remain as self-contained as is reasonable, requiring the absolute minimum of maintenance. An good audio programmer should consider systems and architecture as much as audio and be flexible to the methods other programmers have utilised in implementing their work.

An good audio programmer should consider systems and architecture as much as audio

Fundamentally this means that an audio coder needs to be a good generalist, as they never can be quite sure what sort of fresh genius or madness they're going to come across when integrating into other game systems. Additionally, bearing in mind the sheer scope of audio's presence in games, performance and optimisation should always be at the forefront of their consideration, even while still in early development.

For all these reasons, a good audio programmer needs to be in easy and frequent communication with the larger programming team. It doesn't take much to break complex systems when messing around in areas you don't have a complete overview or understanding of. Therefore the best solution to know what to do at times can be to ask, not least because it's also best not to step on other programmers' toes! For these reasons, it is best to ensure that an audio programmer is embedded in the main development team as well as the audio team in such a way as to make this communication both expedient and easy.

3. Close collaboration is a crucial component

There are two aspects to the technical implementation of audio into games: within the middleware being used (such as FMOD or Wwise) and the systems in the game code itself. It's this dynamic that makes close collaboration between audio code and design so critical. The chemistry of a technically savvy audio designer bouncing ideas back and forth with an audio conscious programmer can be immeasurably valuable and productive. At its best, it can become a hybrid of a strange sort of pair programming alongside a brainstorming of what might be creatively possible in games audio.

At the most fundamental level, we always want to minimise the amount of grunt work any team member has to engage in. That is greatly benefited by audio code and designer having a good mutual understanding of each other's workflows and requirements. Clever technical implementations within middleware mean programmers can devise systems in-game that are both data-driven and engineered in such a way as to minimise the amount of actual data entry required. This frees up time for the designer to spend more creatively and for the coder to further machinate more ingenious systems and optimisations.

This is only possible with close collaboration within the audio team. This is another motivation to ensure the audio team is furnished with at least one dedicated and embedded audio programmer, preferably more!

4. Pay attention to the production line

Agile is a widespread production methodology used these days, but often it flows a little counter to how audio development naturally wants to happen. Designers find it challenging to author audio satisfactorily in isolation from the game, as ideally, the work needs to be heard in context. However, this can't happen until the relevant features come online and the supporting audio code is implemented.

So too often, designers find themselves waiting in earnest, noodling within assets in suboptimal circumstances. Basically, audio almost invariably finds itself at the end of the development pipeline and, therefore, sometimes has more of a waterfall style arrangement with many dependencies.

A dirty secret of audio in game development is that on a day-to-day basis, most of your team won't be working with the game audio on

Visual guides and video mock-ups greatly benefit designers to help them get first pass or placeholder audio closer to final earlier in development. That said, the best way to get the production line running efficiently is obviously... production. Even in an agile environment, we can have stacks of tasks linked with relevant dependencies assigned to unlock in a waterfall-like manner. Clever use of automation here can reduce manual production oversight and overhead and inform interested parties the moment a task has become unlocked.

Additionally, in a well-functioning audio team, code and design are so closely aligned that their scheduling is largely inseparable from one another. Generally speaking, we should lean on the design schedule to inform how we should assemble the code schedule. For example, if you're working in sprints, you want code to be one sprint ahead of design so that the features are online and designers can work with assets live in-game. The exact scheduling pattern should also be maintained for iteration: in a sort of one-on one-off manner, alternately allowing design to give feedback and code to integrate this feedback, but also with time taken into account on the code schedule for minor emergent and designer supporting tasks.

5. People don't test with the audio on

A dirty secret of audio in game development is that on a day-to-day basis, most of your team won't be working with the game audio on. They'll be checking out Only Cans Twitch streams or bopping along to the latest Cannibal Corpse release. This is understandable, and for many people, it's a vital part of their working process, so I would never condemn anyone for it. However, this does come with the unfortunate side effect that often, non-audio coders don't test their changes with audio on, and they break stuff.

Sometimes audio breaks because the audio programmer did something stupid, but just as often, it breaks as a knock-on of other issues being introduced to the codebase. Either way, it's usually obvious enough to spot that often it's the first issue to get logged (provided the QA member is wearing their headphones!), so the bug will be assigned to the audio code team. This is another situation where a good audio programmer's skill of being comfortable digging around in unfamiliar code comes into its own, allowing them to identify, fix or reassign the issue appropriately.

This is something of a best-case scenario, however. I've certainly found it true in the past that with big QA teams, not everyone is constantly testing the game with the audio on, and issues can get missed for long periods, making the cause more difficult to narrow down. This leads us to the other core member of any good audio team: a talented and dedicated audio tester.

Good audio testers need to be very technically minded. They should be fully embedded in the audio team, be able to talk tech with programmers, profile with middleware and have enough audio savvy to hear things like glitchy or peaking audio and imperfect loops. A good audio tester will be able to write up their bugs much more precisely than general QA and even use profiling to narrow down issues, saving a lot of bug fixing time for the rest of the audio team. They're also able to provide regular sweeps of the game with audio issues specifically in mind, something that otherwise often gets missed or forgotten about by more general QA testing.

Finally, they provide another great set of ears, almost certainly hearing things in the full context of the game more than any other member of the audio team, and therefore providing a wealth of beneficial creative feedback.