|Page (1) of 7 - 06/15/04||email article||print page|
Introduction to Interactive Game AudioAn excerpt from the book ''Audio Programming for Interactive Games''
|This article has been excerpted from the book "Audio Programming for Interactive Games" by Martin Wilde, published by Focal Press. To learn more about this book, go here.|
To buy this book, click here.
Copyright 2004, Martin D. Wilde. All rights reserved.
Thing 1 and thing 2
To avoid this, our first goal is to design and build an interactive audio system that allows the audio artist to construct a compelling soundtrack that will adapt and change in response to the player’s actions in real-time and in an appropriate manner for the current game situation.They should also have to author that content only once for all the platforms on which the game will run. Therefore, our second goal is to separate the desired operation and behaviors of an interactive audio system from its platform-specific implementation.
This is a pretty tall order. From a programming perspective, how do we accomplish this?
The simple, yet powerful, answer is to first approach the problem from an artistic, not a technical, perspective.We turn the conventional thinking about a game audio system on its head by considering “what” we want to do before we delve into the “how” of making it happen.We must define and then support the fundamental actions necessary to afford a composer or sound designer the flexibility they desire when constructing an interactive soundtrack. On the most basic level, our audio software system has to play, stop, pause and resume whatever content we throw at it. It also has to loop, unloop, mute and unmute sounds, set their volume and pan positions, and fade sounds in or out. Most, if not all, of these operations are supported to some degree in the APIs we examined in the previous chapter. But we want to do it all, and without having to use a different syntax on every platform.
Beyond these basic operations, however, the composer needs the ability to assemble play lists of different audio material. Using these constructs, composers can specify and direct the flow of the audio from one piece to the next. They must have the facility to create, add, remove or clear these lists and have the means to jump or segue to any piece of audio content within them. They should be able to directly address and manipulate any subcomponents or tracks of the audio content, and have some signaling or callback mechanism to keep track of the sounds while they’re playing and when they finish. There is precious little in the audio APIs we looked at in the previous chapter that offers this kind of functionality “out of the box.” One has to build these behaviors on top of what they provide. One could argue that many game developers have done this before, so this is not new. I would agree with this assertion, but only to a point. The higher-level musical systems that use these underlying APIs have not been sufficiently disseminated to the game community at large, but rather reside in the proprietary hands and libraries of many different individual companies. The Soundtrack Manager is an attempt to bring the ideas and details of one interactive audio system into the light of day for everyone’s use and discussion.
Audio supports visual media in a primal and visceral way. In a game, the coordinated stimulation of the aural and visual senses creates a synergy that makes a game more engrossing, enveloping and interesting. But to do this well, the audio in a game must respond logically and gracefully to current game conditions. It should draw you into the game and suspend your disbelief in what you’re seeing and hearing. It should “sound natural,” and not violate your aural expectations of the scene or surrounding environment. We should be able to associate sounds with specific characters or objects in a game, and those sounds should be synchronized with the visual rendering of that object. All of this requires well-defined lines of communication between the sound engine and the game application itself. And no matter what the underlying audio resource, these behaviors must be addressed and work the same across all platforms.
Finally, a record of what audio is currently playing in the game should be preserved so it can be restarted across different sessions. Therefore, we must also provide commands to pause, resume, reset, save and reload a game’s audio configuration.
Related Keywords:game composer, soundtrack, interactive audio. programming
To Comment on This Article, Click HERE
Most Recent Reader Comments:
Click Here To Read All Posts
Must be Registered to Respond (Free Registration!!!, CLICK HERE)