Game Development Reference
In-Depth Information
Okay, let's get back to our three files, car fast, medium and slow.
The sound designer will create these sounds just like before,
except this time they will import them into the middleware
program of choice. Once there, the designer will attach whatever
is needed to the sound files. This might be crossfades or mapping
parameters in the game to the audio. In this case it is quite
common that the game engine will be keeping track of the speed
of the car, probably in miles/km per hour, and the programmer will
create a hook called
car_speed
inside their code and give this hook
to the audio designer. As the car speeds up, this parameter value
will increase.
Great! First, however, we need to create what is often referred to as an
event
. Remember when we referred to being concerned about the
action itself rather than the time it takes place? This is an extension of
that concept embraced by middleware. An event can be tied to anything
in the game, and it can consist of multiple parameters driven by the
game's logic as well. You can think of an event as a container for some
kind of action or state in the game.
So now that we have the hook of car speed we can create a custom
parameter in our middleware editor or GUI that is mapped to the
dif erent engine sounds we have. The value of the parameter will then
control the timing and crossfades as well as the selection and balance of
our low, medium, and high speed car engine sounds. It may even control
the speed/pitch of the sounds—there's a lot of l exibility available here.
It is then a relatively simple matter to export our sound i les along with a
text or coni guration i le, that gets delivered to the programmer. Now, all
the programmer has to do is tie the value of the parameter to the game's
event using lines of code, and voilà! The car's visual speed will now match
its perceived audio intensity.
This is a very generalized example that should give you a decent
overview of how the middleware process works. The details
surrounding the building of complex audio events tied to game states
and parameters can get quite involved. The main point to take away
here, however, is that this is an all-round win-win situation. The sound
designer has more control over their work, coni dent that what they
deliver is actually what they will hear in the game, and the programmer
doesn't have to spend as much time working on and worrying about
the audio in the game. Plus theoretically, they have more time for
lunch.
