Game Development Reference
In-Depth Information
seen over and over again, the history of games is a movement from
simple to more complex systems, and audio system development in
games is no exception to this phenomenon.
THE OLD SCHOOL
Back in the day, a sound designer made noises and delivered those noises to a programmer in some i le
format or another, and that programmer put them in the game in some way or another, and then they
both (if they liked each other) went out and had lunch. Since this was a one-to-one relationship, it was
usually a pretty ei cient, not to mention tasty, system.
As games got more complex and people were not always close to each other, it became standard
practice to make those noises and deliver them to a programmer, maybe over the Internet, along with
a text document with i le names and instructions about where these sounds were supposed to go and
what they were supposed to do. This process is still in use today. But, over time, software has emerged
that handles an increasingly larger amount of the heavy lifting between the game engine and the
programmer, and sound designer. This software is called
middleware
.
Middleware Emerges
Audio middleware is another type of engine that works along with the core game engine and sits in a
sense in between the sound designer and the programmer. Its main job is to allow the designer, who
may not be a programmer, to have more control over how, when and where their sounds are triggered in
a game.
The 'old' method of audio implementation.
1: The audio designer communicates with the
programmer; 2: The designer sends the asset
list plus the sound i les; 3: The programmer puts
these into the game and coni gures everything to
trigger and sound correctly; 4: Upon success, the
two have lunch!
Credit:
Images from Corinne Yu (Flickr).
