Your Audio Design Document: Important Items to Consider in Audio Design, Production, and Support

Gama Network Presents:

Your Audio Design Document: Important Items to Consider in Audio Design, Production, and Support
By Keith Zizza
Gamasutra
July 26, 2000
URL: http://www.gamasutra.com/features/20000726/zizza_01.htm

When customers put down their money for a game, of course they expect the best gameplay, AI, and graphics. Why, then, does the audio component always seem to be less on par with the rest of the product, as if it were an afterthought? Consumers are becoming increasingly aware of the potential for audio in games, and in the near future (if not already), excellence in this area cannot continue to be put aside due to the production demands of other in-game components.

It's possible that when it has been put aside, the audio design -- the design and implementation of music, sound effects, and dialogue -- may have been too casually put together, or oversimplified. It may have been presented, say, as a list of files on a spreadsheet; where only some of those files, along with their implementation, were most likely coded in for testing. The rest is left incomplete until the closing stages of the development cycle, possibly as nothing more complex than triggering a sound-for-an-object on the screen.

If graphics are so closely linked to game design, why shouldn't the audio be as well? Granted, in terms of the other project components, the complexities of audio design (and its time line) may be smaller, but audio considerations in general should have just as equal importance. "Equal importance" shouldn't necessarily have to mean "expensive," however. Some careful thought and attention to audio design early in the development cycle will pay off many times over later on.

In recent years, developments in audio technologies, such as MPEG and DirectMusic among others, have opened up and inspired all kinds of exciting possibilities in audio design. Occasionally, attention is given to one specific technology in a game, sometimes features are even marketed on the front of the game's box. Still, it is the rare game that assesses all of these available technologies, chooses the most effective one(s), and harnesses them to their maximum potential.

But there is a good chance that your studio may not have the time and resources to implement potentially complex audio specifications. Or that the game's audio design doesn't really require much detail. Having a bunch of MP3 tunes to cycle through and a basic set of sound effects for in-game sprites is probably "just fine" for some games, you might think, so why bother taking it any further than that?

Well the fact is, whether the audio design is simple or complex, it's not enough simply to provide a list of content. In determining the best audio solution for a game, an audio design document should be created, in order to define the content, technology, and top-level design and implementation used. The latter element is really the formal definition of an "audio environment," defining the parameters and boundaries of the sonic world living in your game. How will you define this? And how will you test and maintain this design?

The audio design document would not only be of benefit to the audio team. Designers will want to absorb it, programmers will demand it, and producers, along with just about anyone else who is involved on the project, will want to at least skim it. Whether it's one page or one hundred, it should be as descriptive as it needs to be for you and your development team. The end result, hopefully, is a harmonious one -- working with and enhancing graphics, writing, game design, and the overall gaming experience.

Before we get into the actual audio design document, here are some answers to questions you may already be asking yourself:

Why bother with an audio design document? We hardly even have time to think about the audio.
Having great music, sound, and voice (and implementing it properly) can only be of benefit to your game, enhancing the total experience for the consumer (and yourself, the developer). If it's really good, you might even receive some acclaim, garnishing a nice review or award. And this, in turn, may improve your sales, even if only by a slight margin. That alone should be reason for increased interest and awareness in effective audio design.

OK, but I don't have a lot of money to spend on talent or resources. What am I supposed to do?
If you have the budget to commission the best crew of audio engineers, sound designers, musicians, and voice talent in the world, by all means go for it! But for the other 95 percent of us, a small handful of audio personnel, or even programmers doubling as sound designers, is all most of us have time or money to commission. The thought of spending big money on audio (upwards of six figures) is simply out of reach for many game developers, or not part of the strategy. There's usually only so much money to go around on a project, and more attention often has to be focused on graphics, marketing, or design; and there may be valid reasons for this. The fact is, you're going to have to do some legwork and find some talent, and spend a modest amount of money (or resources, if the audio team is in-house). Much of the time, it's going to be about balancing the financial resources you can offer versus the quality of talent you need. Go through online resumes. Post ads. Ask through word-of-mouth, starting with the creative departments in your company. Creatives are sure to know other creatives of varied disciplines.

When should I start looking for talent, if I don't already have them in-house?
You really must focus on this a bit later in the process. Design an audio spec first; see what resources you need and then go for the best talent you can find. The most talented audio designer's work may still fall short of the mark because of flawed or weak audio design. In the end, with careful planning and creative know-how, anything is possible. You may find that your best talent works for far less money and offers faster turnaround. After a few projects, you'll probably have built up a library of contacts, specializing in all audio-related disciplines, from which you can always draw.

O.K. then. So what should an audio design document look like?
Good question. Read on for the components of an effective audio design document.

I. OUTLINE/OBJECTIVES

This is your overview. It should contain a statement or two describing the goals and purpose of the audio for the game. It should also describe the audio's proposed style and execution, as compared to the setting of the game. A good idea if you have time is to expand this entire section into a brief synopsis of your entire document, keeping to about a page or so. This mainly serves as a quick reference for those who wish to skim the design without having to wade through all the details.

Think of this entire section to be only as detailed as one could figure out by observation, as if they were to be playing the game and discovering these things independently.

1. OVERVIEW (setting in game)
Overall style of audio, purpose, what is trying to be conveyed as compared to the setting of the game.

(2-[n] optional, or as part of OVERVIEW if 2-[n] can be quickly and easily described)

1. MUSIC
brief statement about how this should work, outlined in very simple terms.

2. SOUND
(same approach as above)

3. DIALOGUE
(same approach as above)

4. MISC.: animations, promos, and so on
(same approach as above)

[n.] [component]
(same approach as above)

II. RESEARCH

This section can prove to be valuable in looking back at past experiments on the project. Unless it's noted somewhere, it's easy to forget the details on research that never made it into implementation. Where research does turn into implementation, it's essential that you note it in this section, even if it's described in simple terms.

Items that can be included in this section can be file formats tested and used, in-game audio experiments, and especially any proprietary audio research.

III. IMPLEMENTATION

Define a set of rules: permutations, and boundaries (limits) as to how the audio works on a more detailed level. This section can be somewhat more technical if you prefer. So long as it's not looking like C++ , you're on the right track. The goal here is to clearly describe how your audio world is defined. As mentioned earlier, you can also think of this as your "audio environment".

The subsections of this section should include at least A. Sound and B. Music Implementation. If you have speech files for characters, narration, and so on, then you must include a subsection for C. Dialogue as well. Here's an example:

A. SOUND EFFECTS ENGINE
The sound effects engine for Space Hamsters will have more complexity than the music engine, bringing the focus to the rich, sonic variety of creatures met in space.

There should never be more than (8) unique sound effects playing at once, not including dialogue or music. Music Implementation is described in B and Dialogue in C.

1. Hamster sound effects sub-engine:
The actual Space Hamsters have their own audio layer. As they travel across the screen, each has a total of 3-6 distinct hamster sound effects they can play individually. The sounds will not loop, they will be played as one-shot .WAV files. The only unique case is when the Hamster Captain appears, who has a looping snare drum sound effect playing over its "normal" sound effects (see Space_Hamster_Sound_List, on [disk/server]).

2. Non-hamster (alien) sound effects sub-engine:
(similar to above)

[n.] [component]
(similar to above)

and the same style for B, C, and so on, as needed.

You may only need a small amount of detail, or several pages to describe your implementation. You'll have to revise and update your document often, as the game design changes, or you may find new problems you were unaware of in getting your design to become reality.

Below, I have provided a real-world example of the audio implementation (III. A, B, and C above) for Impressions' upcoming title Zeus: Master of Olympus. Of course, in the actual document, the implementation is described on a highly detailed level -- but here I tried to just sum up each component in a line or two, just to give a sense of the possible complexity of audio design needed in a game (this particular design can probably be thought of as "intermediate" in complexity). This audio engine harnesses up to six distinct layers of sound, with some layers playing simultaneously and others on their own. Here is an abstract outline of the environment:

Layer 0
An ambient sound effect layer. As the player passes over certain terrain types on the map, that terrain type's ambient sound loop begins to play. As the player passes over a second terrain type, the first ambient track gently fades out while the second fades in. There can be no more than two ambient sound effects cross-fading into one another at a time.

Layer 1
A 3D sound engine, where monaural sounds can travel through a four-speaker system, complete with a parameter list defining each sound's path, traveling speed, special effects, and so on. The goal here is not to have in-game dependent sounds, as the game itself is isometric, not 3D; but rather, to provide "enhancement" to the gaming experience, further immersing the player in an ancient, mythological setting.

Layer 2
Ambient sounds generated from terrain and buildings, which play only occasionally, and are randomly selected. Terrain played here is separate from the terrain played in Layer 0, which is a more of a "global" sound. Here, the sound played is more specific and complementary to the ambient terrain track being played in Layer 0.

Layer 3
Civilian, animal, monster, and all combat-related sounds are played here, including disaster sounds, user interface sounds, and so on.

Layer 4
Interactive music categories based on game events:

"General" music played when mundane activity is going on

"Action" music played when in combat,

"Special" music played during various important events in the game.

All of this music segues from one category to next as needed.

Layer 5
All narration and in-game dialogue for all characters. Narration is provided at the beginning and end of campaigns and/or missions; in-game dialogue is heard by moving the mouse over an on-screen character and right-clicking on it.

In all, there are more than 1,200 files to manage in Zeus. About 800 of them are speech files -- and this is before localization!

Again, in the real document, there has to be far greater detail provided. In the example above, there are several things missing: how the different layers work together, some actual design that needs to be implemented in certain layers (aside from just "playing" the sound file), and various other special cases with certain elements, permutations, and the like.

Don't be afraid to push the envelope a bit here. Remember, if you can find the extra time, provide as much detail as possible to "fill in the cracks" of your implementation, trying not to be too vague in describing any area. Ask yourself, "how would I explain this to the designer? The programmer?" and so on. Strive for a universal but detailed description.

Of course, how your implementation is decided upon and how you wish to detail it is entirely up to you and/or your team. Don't over-describe every little thing: this document shouldn't become your life's work! But the more you stick to it and the more detail you can provide, the less chance for ambiguity in the end product -- and the greater chance to detect bugs or weaknesses in your audio design.

IV. CONTENT LIST
Reference a separate list of all audio content for the game, including those for demos, marketing, your web site, and so on. If you like having everything in one document, and the content list is on the small side, it's probably fine to include the master list here. In any case, it's good idea to include a general outline of content, well before there is enough detail to have an actual, formal list. Here is a generic example, where I give more detail in the first section, defining a pattern to follow for the rest of the list:

A. SOUND DESIGN
   1. Action sounds
      a. Explosions: 5-10, varying from small to large
      b. Weapons: unknown, will know before 4/20/01 -- possibly 30-50 unique sounds for 15-25 weapons
      c. Characters
         i. human -- military: 5 unit types, 3-5 sounds each
         ii. human -- civilian: unknown
         iii. alien -- misc.: unknown
         [n].

[n].

2. User interface
[n].

[n].

B. MUSIC
   1. Setup mode
   2. Mission panel
   3. In-game music
   4. win/lose music
   [n].

C. DIALOGUE
   1. in-game characters
   2. narration
   [n].

D. ADDITIONAL AUDIO-FOR-VIDEO CONTENT (marketing promotions, in-game animations)
   [n].

[n].

A basic sketch of content, such as the one shown above, can certainly help you plan your attack in terms of scheduling audio production time, helping to decide who will be creating and programming what.

If you have more than a few sound files -- and chances are you do -- a better approach is to reference the formal, working audio content list in another document. If your list ends up in the hundreds of items or more, it may be awkward to include it in your design document, especially if others need access to it. For example, what if you're sharing the list with a writer who needs to update lines of speech to be recorded on a regular basis? And what if that list is buried on page 24 in your document? And you brought a copy of the document home to work on over the weekend -- while the writer is updating the list in the office? There's always the temptation for local copies to be made when documents are shared, so avoid redundancy and confusion at all costs. It's essential to keep a single audio content list, especially if multiple people reference or make contributions to it.

V. SCHEDULE
As in IV, you can outline a rough schedule here, perhaps updating it every month. You'll want to set some basic milestones, such as "all music done by [date]" or "75 percent of sound engine implemented by [date]." And by some method, even if it is the barest outline, you should indicate who is working on what, with some sort of timeline provided.

So now you have the design and implementation where you want it, and everything is under way. But you realize as your document comes to life, that it is opening up more and more complex questions that need answers. Support all the way through the project is crucial; with that, somewhere within the document there should also be the following considerations, taken as notes, mental or written:

DESIGN DOC PRODUCTION CHECKLIST

Aesthetic Continuity/Quality
- If using more than one composer or sound designer, do their styles blend well with one another?
- Have these people ever worked together before? Does anyone need additional training on your internal production process, game background, software, or hardware?
- Should there be additional up-front time for creative research if it's a more challenging style or genre to define?
Technical Continuity/Quality
- Is there proper level balancing for all files?
- Do certain sounds have odd qualities, such as strange EQ or other unusual DSP aspects when compared? Is this intended?
- Have all files been checked to ensure their correct file format? Bit depth? Sample or playback rate?
- Are all file names spelled correctly?
- Any odd characters being used that a CD Data Mastering Specification cannot handle?
- Are you confident of the "real estate impact" your audio will have in memory/on your CD/DVD/Server/other?
- Are you using an audio technology to your advantage? Are you getting what you need from it for this game?
- Have you cleaned up any noise/maximized your S/N(signal-to-noise) ratio for all files?
- Are you getting enough of the frequency spectrum you want (especially for music) in your files? Is it worth taking another pass at certain files to remaster/remix/re-EQ?
- Does your audio sound good on a wide range of speaker systems? Have you decided upon an "optimum" sound card and speaker configuration?
- Do your files have clean starts and finishes (especially voice clips)? Any unnoticed dead space before or after any files? Any unnatural rhythm patterns on voice files, especially those that were constructed from multiple takes?
Miscellaneous Production Considerations
- Are you going to be within budget?
- Is the schedule reasonable? Will you need more people, or need to put in more hours?
- Do you have the production tools/equipment you need? If not, can you make due with what you have? What areas can you cut corners in?
- What can be done earlier or later in the production cycle? What is not time-dependent within that cycle?
- Is extra time allowed for additional content or redos? Any "outside" influences that may break up/accelerate your schedule: multiple title/version production, web site needs, marketing materials, E3, magazine demos?
- Do you have access to the most up-to-date, correct information (design documents, schedules, content lists/requirements)?
- If someone cannot complete their tasks for any reason (becomes ill, quits, and so on), is their a contingency plan? Can some content be "let go" or reduced in scope due to time constraints?
Overall testing
- What the main areas of the audio design that need testing? Can anyone else help define this list with you, on a more objective level?
CPU performance testing
- If your game's performance is sluggish, could it be due to too many audio files playing simultaneously? Is it just a matter of finding a more suitable audio file format or specification? A more suitable technology? Can the code in question be further optimized in this area?
Limits testing
- Can you work on your own or with your QA group to help test the limits of the audio design? How many sound files can play simultaneously? What if the same sound is played by multiple sources simultaneously? What if someone toggles the music off, then turns it on again? Does it pick up where it left off or start over from the top? Is that the desired effect? And so on.
Relevancy
- Which areas are more important to focus on from a programming perspective? Will all of this coding even make an aesthetic or qualitative difference for gameplay? Or will the efforts go unnoticed? Can the programmers' resources be better spent elsewhere?
Technology trade-offs
- WAVs vs. MP3s vs. DirectMusic, for example. Can these or other technologies be used to their (and your) advantage?

Ultimately, your game's audio design should translate into a rewarding, interactive experience, one that blends effortlessly into the gameplay, graphics, and other components of the product. The real trick of course, is how you specify it in your audio design document.

Your document should be able to answer most questions about the audio design and implementation, or at the least point other team members in the right direction to go for more information (references to another document, a manual, a web site, or another contact). As mentioned earlier, how detailed or concise you need to be in writing it is up to you and/or your team, provided it meets your needs and, where applicable, can be generally understood by the people who need to make use of it.

Hopefully this article has demonstrated some effective, practical methods in designing and supporting audio for games. I have found the these ideas and techniques useful for my particular environment; of course they may not necessarily reflect your studio's needs. But I hope that for those reading this, it has at least provided further inspiration to strive for excellence in the quest to create great audio for games.

Keith Zizza is the Audio Director for Impressions Games, a division of Sierra Studios (Havas Interactive).