| |
|
|
||||
![]() |
||||||
| |
|
|||||
|
Your Audio Design Document: Important Items to Consider in Audio Design, Production, and Support
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. OK,
but I don't have a lot of money to spend on talent or resources. What
am I supposed to do? When
should I start looking for talent, if I don't already have them in-house? O.K.
then. So what should an audio design document look like? __________________________________________________ |
|
|