Game Development Reference
In-Depth Information
These tools can be developed to work with either a third-party sound engine or
an in-house sound engine. They are designed so that they sit above the playback
layer, making their addition to your code base as simple as possible. A discussion
of each tool along with any implementation notes is presented.
11.2.1 Sound Event Snapshot
Sound events are the high-level objects processed by your audio engine and are
used to describe how a sound will be played by the sound engine. Typically they
will have a name to identify them: playback settings, such as volume and pitch and
one or more associated audio files. As well as their individual settings, they will
typically belong to one or more category groups, such as player sounds or music.
These sound categories are ways of grouping sounds together and applying modifiers
to them, such as volume. Sound events may also have a chain of DSP effects which
need to be applied to them while they play. DSP chains may also be dynamically
applied to a sound while the game is being played. For example, if a loud sound is
being played behind a door of an adjoining large room, then you may have an echo
reverb and a low-pass filter applied to the sound.
The sound designer will often want to break down the game's current sound-
scape into its atomic parts. This is so that they can see which sound events are
being played and what their playback settings are. They will also want to control
which sounds are allowed to play while the game is running. Examples of com-
mon problems which may occur are individual sounds dominating the soundscape,
rogue sounds playing out of place, or a sound playing in an odd way, such as at the
wrong pitch or volume. The sound designer will need some methods to help them
investigate these sounds.
What the tool must provide.
For each playing sound event, the tool displays the
following information: the name of the sound event, the name of the audio file being
played,andthecurrentvolumeandpitchsettings.
Figure11.1
showsanexample
of how the tool may look.
When an event is selected by the sound designer for further inspection, the tool
should display the names and settings of any sound categories the event belongs
to and the identity of any controlling game object that owns the instance of this
sound event being played. It should show which DSP effects are being applied, if
any. If your audio engine supports in-game variables directly affecting a sound's
playback, then those variable names and their values should be shown. An example
of binding an in-game variable to a sound event would be binding the RPM of the
player's car engine to control the pitch and audio file to play for a car engine sound
event.
The sound designer must also be able to enable or disable one or more categories
of sounds, such as music, within the tool. This allows them to focus on the other
sounds being played to make up the soundscape.
