Quick & early iteration for game audio

When your job is creative and open ended sometimes is hard to feels things are finished. Even if you design, export and implement a particular SFX on your project, is hard to be sure things are done. Art is not finished, is abandoned. This sometimes produces a kind of “paralysis by analysis” situation where if you try to really make sure everything is perfect you would never finish in time.

That’s why I’m advocating for a diffferent approach on this post: Quick and early iteration. Don’t worry about things being perfect, not even “finished”, just put ideas together and throw them into the real world as fast as possible. There are a few advantages to this approach.

Context

For the most part, audio is never going to be heard in isolation so why bother making a SFX super detailed and interesting if its context is never going to allow it to shine? This is analogous to the mixing engineer trying to make the kick drum sound awesone for hours, only to realize that it doesn’t work in the context of the song.

You don’t always know how much spectral space do you have. You don’t always know how much time you have. If you try to get these things perfect you will probably be too slow on a project with hundreds of sounds.

Instead, make your best guess, put some audio together and get it into the game. As more and more audio gets in, you will start to get a sense of how the sounds work together. Later on, is when you can start thinking about teaking: with context.

Implementation

Getting audio into the game quick also lets you know sooner rather than later how an audio event should work functionally. This is important because it can affect how it should be designed. Should it be a loop? Use a speed parameter? Should you bake many different sound into a single file or have many small sounds played from a scattered instrument?

If you actually implement it, you will be faced with these decisions in a real way that will always be better than just planning. Don’t get me wrong, you should plan your work of course but that is never going to tell you if things are going to actually work. For that, you need to get your hands dirty.

On the code side of things, an early simple implementation will give you insights about your current audio tech. You will know if your audio scripts are sufficient or if you need to add new functionallities or ask a programmer to help you out. In terms of project planning, knowing this soon is a big advantage and producers will appreciate it.

Lastly, somehing nice about early implementation is that once you get feedback on the audio, you just need to swap or tweak the assets and future iteration will be quick and painless.

Focused Priorities

It would be tricky to know what is important if you don’t have a clear idea of what is going to be there. Throwing audio to the game soon gives you a more clear idea of what you need to focus on. Your time is not infinite so you need to pick your battles and add detail and love to the content that most will benefit from it.

Once a respectable amount of audio is implemented, it will be easier to decide what is best to focus on and you will get a better sense of what is important.

Earlier Unknowns

Game development is usually about solving problems and these problems are often hard to predict. You can sit all day and plan how you are going to do things but it would be impossible to take some of these future issues into account. The next best thing is to know about them as early as possible.

That way, you can tackle them with more time and have a better chance getting the resources you need.

Optimization

Something to also consider is how efficient you are in terms of memory and CPU. This is hard to determine in the earlier phases of the project and if you go too slow on the first stages of the game development, it may be too late to have enough time to react.

Building the audio earlier would give more information about how things perform and you will be able to make better strategic decisions on how to do things. In turn, this will also influence how audio is built and designed.

80% is enough

Quick iteration has an additional advantage: if anything goes wrong or new time constrains come, you know you will be 80% of the way there and that could be enough to save the day.

This is something that goes against all our instintcs as creative, detail-oriented people. We always strive for more emotive, interesting and inspiring audio but that can only happen if we have the time to do it and sometimes we just don’t. If worst comes to worst, at least we know things are functional and all the main aural information is already conveyed to the player. Maybe is not pretty but it works and sometimes, in an emergency, that could be just enough.

Iteration

So that’s pretty much the idea. As you get more and more audio in place, always trying to be fast rather than perfect, you will get a better idea of what to spend more time on and that’s when iteration comes into focus. As a project reaches maturity, you will find yourself working less on new content and more on iteration.

You will be surprised to see that most things will just need tweaking while only a few will need to be re-done from scratch. On the long run, I think you save time working this way and the result will be better. Another nice advantage is the peace of mind that comes from knowing that most things are in place and now is just a question of iteration and refinement.

Lastly, as you get more experience working this way, you will find that your initial quick, dirty work gets closer and closer to be good enough quality sometimes even high quality as you sharpen your instincts and workflows.