|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Designing Interactive Audio Content To-Picture
Adaptive Sound Design: Take The Problem And Square It Nowhere is the current lack of a real-time link between in-game events and game sound design environments more painful than in adaptive sound design. "Adaptive" sound effects are those that must be altered on the fly in response to changing game conditions. The archetypical example of adaptive audio is the sound of a car engine in a racing game - when the user steps on the gas, the effect must change to reflect the engine's changing RPM. This type of sound adds a unique extra dimension to the challenge of game sound design. Whereas an engine sound for a linear AV medium only has to fit with two contexts (the visuals and the mix), an adaptive engine sound must also respond dynamically to pseudo-random user input events. Creating car engine samples as a sound designer on Pseudo Interactive's first project, I was struck by how much the effect depended on the playback system. Since the sounds were meant to be frequency shifted in-game as RPM changed, the samples themselves could not contain any frequency modulation. This meant that in my sample editing software, the samples didn't sound much like a car engine. In fact, they didn't sound much like anything. And, typically, my sound design environment was isolated from the context of the game car engine playback system that was supposed to make the samples sound like a car engine. So, out of context, my sample edits didn't sound like much of anything either. Really evaluating the effect of any sample tweaks involved saving the sound out in the game format resolution, rebuilding the game's run-time file, loading up a level, and starting the simulation. The length of this feedback cycle made fine-tuning a near impossibility. Iterations of the effect were simply so separated in time that gauging the progress of the sample's development was extremely difficult. ("Was that a good change or a bad change? How good / bad? I forget what it sounded like before…") Properly monitoring any little sample edit involved several minutes of setup. Keep in mind that even a 10 second delay is a big deal when it comes to the brain's ability to make detailed audio comparisons! Not being able to edit adaptive sounds in their unique context makes their design an exercise in frustration. A Partial Solution: Faking the Context I quickly realized that I was working blind trying to edit car engine samples without being able to listen to them being dynamically pitch shifted. Luckily, I happened to have a piece of gear in my studio that A) could frequency shift samples in real-time as they played back and B) incorporated a fair amount of on-board sample editing functions. This device was my sampler. A "sampler" is a musical instrument designed to play back and automatically transpose samples based on the key that is being pressed on a music keyboard. The user can load any sound into it (a flute, an oboe, a piano, a cat meowing) and then play it as though it were a piano. This makes the sampler a very flexible instrument indeed! In this case, I loaded my work-in-progress engine samples into the sampler. When I pressed middle C on my music keyboard, the sounds now began looped playback. This would not have been particularly useful without another standard sampler feature: pitch bending. A sampler will smoothly shift the frequency of a sample's playback in real time in response to movements of a music keyboard's pitch bend wheel. It also allows the user to configure the overall range of the pitch bend, so I specified a range roughly corresponding to the frequency shift range of the game's playback system. To hear the samples being played by a reasonable approximation of the game's car engine sound playback system, all I had to do was move my music keyboard's pitch bend wheel around. And now, I was able to listen to this playback in a sample editing environment. As with most high-end samplers, mine has a lot of sound editing capabilities built right into it. In addition to the standard simple transposition, filters, loop point editing, gain envelopes (fades), and layering (mixing samples), I had immediate access to advanced sample edit functions such as compression, non-transposing time stretch, effects, &c - just about everything a sound designer could ask for. Needless to say, editing the samples in this context was much more effective than my previous attempts had been! Still, none of the playback parameters were coming from the real final playback context of the sound (i.e. the car in the game). I was faking this data myself. And though this offered an effective partial solution, the accuracy of my simulation was suspect, and I still wasn't working to-picture. My sound design environment remained isolated from the game AV context and from the actual car engine sample playback system. ________________________________________________________ |
|
|
Features
