Article by Anne-Sophie Mongeau
Edited by Sam Hughes
My role as a Game Audio Engineer in DIGIT Game Studios has been very insightful, and has helped me gain a broadened perspective on game audio and, even more generally, the overall game development process. While being in a position I consider equivalent to a ‘one-person’ audio department, I realised just how many responsibilities fall into my hands, and how the entire process can be both very challenging and immensely rewarding. I wish to share some of my experience here in the hope that it can be of help to game audio designers who are in a similar position as myself, to freelancers who often take responsibility for the entire audio content of a game, or to sound designers interested in knowing more about the game audio workflow.
I am in charge of the entire audio content for a AAA mobile game title, from start to finish. What does that mean? In this article, I’m going to go through the tasks you’ll need to accomplish, and the skills you’ll be expected to possess and/or develop. I’ll also give you an overview of the main challenges you’ll possibly encounter, as well as the rewards you’re certain to experience in relation to this considerable achievement.
THE WORK & RESPONSIBILITIES
First, responsibilities. What are you actually meant to do? Where do you start? How do your tasks change over time throughout the development of the project? Some tasks will certainly be continuous throughout, some spontaneous. There are no really step-by-step instructions that will lead you to a successfully finished product, but I find that the overall workload can be divided in a few distinctive areas over time. Kind of like this:
Concepting/preparing/planning
The first phase will be one of preparation, organisation, concepting and prototyping. Depending on when you are brought on board the project, you may have more or less time to do so. Hopefully, you’ve been included from an early stage and can contribute to the development of an audio vision along with the artistic and technical ones.
You may have been provided with a prototype of the game, storyboards, or equivalent documentation which will allow you to get a sense of the audio requirements.
1. The first step is about very neatly writing all of those requirements down, in an Audio Design Document (to know more about the redaction of such a document, you can take a look at my article on Game Audio Asset Naming and Organisation). Put simply, this document consists of a massive list of all the audio events needed in the game. It will be constantly evolving, but the first pass is about setting up the basic requirements so that you are ready to collaborate with a programmer to implement some sounds in the game. This step is also the first time you’ll reflect on the sonic identity of the game. It will be a work in progress for most of the development process, but at this stage you should already develop some ideas about the audio vision, and start doing some prototype sound design.
2. The second step is putting some sounds in. Your company and yourself will have chosen an Audio Engine (to know more about selecting the appropriate game audio engine, read my blog post on Audio Middleware Comparison), and you will start working closely with one or more programmers to make this work in the game engine. This is a critical period where the first efforts towards an audio implementation pipeline are being made, and I strongly recommend you try to do it right from the start. What I mean by that is this : during our prototyping stage, we put in some sounds by any means necessary. Some were kind of hacked in, most were hard coded, leaving me no control over them whatsoever. It worked, for a while, then it was messy. Some prototype leftovers have haunted my work for months after that, and I wished we had started doing it right (meaning using the audio middleware) from the beginning.
3. The last step of this first stage is kind of mentioned above : the development of an audio implementation pipeline. Note that this comes from working in a relatively small studio where no previous pipeline was established, and we just had to figure it all out. Needless to say, we’re still figuring it out. This will be an ongoing process if you are in a similar position as me, where not only the audio pipeline, but the entire development pipeline is constantly evolving and adapting to the game and the company’s needs. You simply need to make sure that audio is regarded as being part of the development process from the start, rather than being kept for last.
Production
The production phase is very much one that will be an ongoing process from start to finish. It includes:
- Sound design/editing/processing
- Audio Integration
- Mixing
Although the list is short, this is the meaty part. This is what you are here to do : give a sonic identity to the game, enhance its quality, make the holistic gameplay experience a better one through the means of sound, make every action feel rewarding, make every environment unique, give every object a soul.
You’ll start with some design, which will then be integrated using the Audio Engine, and hopefully your support pipeline is efficient enough so you can quickly hear your work in the context of the game. Once you have some material in, you can proceed with reviewing, testing and getting feedback. Some changes will need to be made, so go back to your DAW, replace the sounds in game with your latest version, then repeat the process. Repeat. Repeat again. And again. It’s normal to make lots of changes, this is why you want to be brought on the project at an early stage. It takes time to develop an artistic vision and yours will develop alongside the game’s development. In addition, the more time you have to get familiar with the game’s features and mechanics, the more you’re allowed to get creative with the sound design and implementation.
This production phase is also one that, despite appearances, will require a lot of teamwork. This is when your capacity to receive feedback will be tested, while most of the work your colleagues will hear is a work in progress. You’ll also need to collaborate closely with the programmers to implement your work, and share resources with many other colleagues.
Management
Similarly to the production phase, the management one is also going to be very constant throughout the development process, probably even more so. Being in charge of hundreds of assets as well as being the only one who has a clue about the audio requirements and workflow, means you need to be highly organised and proactive.
1. You’ll need to be a great communicator and very team-oriented. You are part of many teams : the audio team (if there are more than one of you/ if there is any outsourced material), the art team (working closely with the art director, VFX artist(s) and concept artist(s)), the production team (collaboration with front end developers for audio implementation), the QA team (reviewing the work only yourself know about, and receiving feedback), the company (there is a general dynamic of which you need to be part of, the Leads need to know your progress and requirements), the whole thing (you’ll be in touch with your publisher – if any – regarding audio requirements, since nobody else has a clue).
2. You’ll need to develop a detailed, clear and exhaustive system to keep track of the audio progress, as well as manage both asset creation and storage. As mentioned above, the Audio Design Document will be a vital part of this system, but your storage and backup strategies will need to be flawless and safe too. Documentation for every part of the process will be greatly appreciated, not only by your co-workers and managers, but also by your future self, when you need to revisit something you worked on months ago. To give you an idea of some documentation that was made during the development process of my current project (so far), here are a few examples :
- Audio Design Document
- Audio Roadmap
- Audio Bugs
- Game Features specific audio requirements
- Music Design Document
- Environment Audio Design Document
- Audio Reviews
- Game Audio Dialogue Document
- Audio Tools Documentation
- Audio Support Tasks
- Etc, etc, etc, etc.
3. You’ll need to be comfortable with version control software like Perforce, Sourcetree, GitHub, etc. The process of project sharing can be a bit painful at times, but it is of vital importance that you familiarise yourself with it : you are working within a complex software environment where code and assets live together, and which is being constantly modified by dozens of people (if not more). Not knowing what you are doing there can seriously compromise the the entire project (at worst), or waste a lot of someone else’s precious time to clean up your mess (at best).
4. If there is any outsourced material (for example music, or additional sound effects), you’ll be driving these interactions, including :
- Communication of expectations
- Contract sorting
- Budget sorting
- Software Licences
- Reviewing
- Tech support
- Progress report
- Etc, etc, etc, etc.
5. Finally, think ahead of schedule. You need to anticipate the audio needs, whatever their nature, and communicate them as soon as possible, in written form, to whomever is concerned. Be proactive, do more than what is expected, because what is expected is not enough : nobody other than you knows what you are doing, so nobody can possibly expect enough.
Review
The review phase progresses hand in hand with the production one, but will also undoubtedly take greater importance towards the end of the development process. As mentioned above, since you are the only person truly aware of the progress of audio, you’re the best person to QA test it. You’ll know what is meant to be working and what is not, and where to dedicate your attention at a certain point in time.
For instance, during the development process, you may be testing for :
- Bugs & glitches
- Making sure previously/recently implemented features are (still) functioning
- The mix (overall and of specific elements)
- The general ‘feel’ (is your work contributing to the artistic vision? Do you hear sonic coherence and identity? Is your sound design helping the player focus on the right thing at the right time? Is your sound design contributing to the rewarding experience of playing the game? Etc, etc)
Towards the end, you’ll need to pay special attention to technical details:
- Compression artifacts (make sure your compression settings on various devices don’t generate unwanted artifacts and the audio quality is not compromised)
- Loudness & metering (to know more, take a look at my article on Loudness and metering in game audio)
- More bugs & glitches (play the game throughout and look for clics, bad loops, repetition, missing buttons, exception scenarios where something stops working sometimes, 3D settings from every angle, etc).
Finally, the closer you get to release (hopefully this means the closer you get to a finished, releasable quality product), the closer you’ll need to work with the QA team : your stuff should be working now, so they’ll be as useful as you in finding bugs. And in terms of quality review, you’ll be receiving comments and feedback from everyone in the studio. You’ll need to be able to receive this feedback and make the most of it. You may even consider sharing a document around for this purpose. Be humble, everyone wants to make a good game.
Tech
There is a considerable technical aspect to the game audio workload. The obvious points include audio design and integration, which require you to be comfortable with adapting technology, prove your problem solving skills and think outside the box.
The less obvious points concern optimisation. You’ll need to keep constant track of :
- Asset file size
- Memory & CPU usage
- Compression settings with variants (for different devices)
- Loading system
- Etc, etc
You’ll undoubtedly be working closely with a programmer to tackle these tech issues, but it still falls into your responsibilities to make sure that a) this process is being done and b) it is done well and the results are within your target devices’ technical limitations.
CHALLENGES
Such great and diverse a task inevitably comes with a few challenges, some more significant than others. Note that the ones I faced are directly related to the type of studio environment I have been working in, aka a relatively small and young studio which was in the process of rapid growth. You may encounter very different challenges if working in an environment distinct to mine in those respects.
1. You may not have a dedicated audio programmer. This means that either the code support for audio implementation is spread across multiple people depending on the feature, or that there is an audio programmer who does not only do audio, and hence is very busy, all the time. This means you have to double the effort in organisation, and voice in advance as many support tasks as you can possibly predict, so that they are put in the work schedule. However, a lot of the audio code support is about bug fixing or adding to an already functional feature, so it is actually highly unlikely that you will be able to predict everything. Considering that, it is going to be a constant negotiation to be provided with the support you need, within a reasonable time scale.
2. You will have to deal with limited resources. If you are working as a ‘one-person’ department, your allocated resources may be bound to some other department, such as the art department, which knows nothing of the audio requirements in terms of equipment, workload, support, etc. You’ll have to make those clear as soon as possible : you need hardware, software, budget for outsourced material, code support, and also quiet, which people surprisingly don’t always seem to realise.
3. As discussed briefly earlier, the work pipeline may be changing. Not only the audio one, but the entire development process. If the team is expanding and the project is of a larger scale than the company has previously known, there will be adjustments made in the general workflow from the start until release. This means you have to make yourself fit within these changes, adapt quickly and make sure you are not being forgotten.
REWARDS
There is no doubt however, that all those efforts will bear fruit. To every challenge there is a reward and you are certain to find great satisfaction in your accomplishment.
1. Being a ‘one-person’ department means you have full ownership of your work. You are setting the quality bar, and you are the one delivering this quality. Your own vision is in the work you do and you decide what to prioritise and push forward. When you play the game, every single sound you hear is the result of your own work, and you know that you actively contributed to making this game a better one. This is highly gratifying.
2. Your tasks are varied, you work with many different people, and your routine is constantly changing. It’s pretty hard to get bored in this context and the opportunities to learn are all over the place. As opposed to a specialist’s job, your work doesn’t get repetitive, but rather progresses over time as you witness the game itself coming to life.
3. You have an overview of the project and its progress. This is not to be underestimated. I have worked on projects before where I had no clue what the developers were working on, and what was going to be the next feature to be implemented. Obviously I wasn’t responsible for the entire audio content then, so I didn’t need to know. But being in a position where you have this overview will make you feel much more secure in your own progress, as well as remind you how important your role is within the team.
4. Your position in the team will allow you to gain extremely valuable knowledge on the overall game development process. This knowledge will make you a better audio designer by making you aware of the various steps and stages of game development, and which ones concern you. You’ll become a better of judge of dependencies, workload, and delivery estimates. These skills are certain to come in handy, whatever game audio position you are in.
In conclusion, I hope this knowledge I have acquired and shared can contribute to form a rough guide to the responsibilities surrounding game audio. Ideally it can be helpful whether you are in a ‘one-person’ department scenario such as described, a small-ish department or even a freelancer. Keep in mind that these points are extracted directly from my own experience and may very well differ according to your own, but hopefully this insight can be helpful in better preparing yourself for an upcoming role. Good luck!
Anne-Sophie is a sound designer currently working at DIGIT Game Studios in Dublin, Ireland. Anne-Sophie also writes her own blog on the topic of game audio on her site.
You can find her blog and Anne-Sophie on Twitter at the following links:
We hope you enjoyed the interview, feel free to check out more of these at the Interviews page. Also, don’t forget to sign up to our Monthly Newsletter to make sure you don’t miss anything!
If you’re feeling generous there’s also our Patreon page and we appreciate all the support!
The Sound Architect
