Contents

Ask Yourself Components Checklist

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 styleand 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:

1. "General" music played when mundane activity is going on
,

2. "Action" music played when in combat,


3. "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.

__________________________________________________

Checklist