21.2ConstructingaSoundMap 357
Sound emitters are typically points within 3D space representing the posi-
tions from which a sound will play. As well as having a position, an emitter also
contains a reference to a sound event. A sound event is a collection of data dictat-
ing which audio file or files to play, along with information on how to control
how these audio files are played. For example, a sound event would typically
store information on playback volume, pitch shifts, and any fade-in or fade-out
durations.
Sound designers typically populate the game world with sound emitters in
order to build up a game’s soundscape. Sound emitters may be scripted directly
by the sound designer or may be automatically generated by other game objects.
For example, an animating door may automatically generate
wooden_door_
open
and wooden_door_close sound emitters.
Once all the sound emitters have been placed within the game world, we can
begin our data collection. This process should be done offline as part of the pro-
cess for building a game’s level or world data.
Each sound event has an audible range defined by its sound event data. This
audible range is used to calculate both the volume of the sound and whether the
sound is within audible range by comparing against the listener’s position. The
listener is the logical representation of the player’s ear in the world—it’s typical-
ly the same as the game’s camera position. We use the audible range property of
sound emitters to see which sound emitters are overlapping.
We construct a sound map to store an entry for each sound emitter found
within the level data. The sound map can be thought of as a three-dimensional
space representing the game world. The sound map contains only the sound emit-
ters we’ve found when processing the level data. Each sound emitter is stored in
the sound map as a sphere, with the sphere’s radius being the audible distance of
the sound emitter’s event data.
Once the sound map is generated, we can construct an event table containing
an entry for each type of sound event found in the level. For each entry in the
table, we must mark how many instances of that sound event there are within the
sound map, which other sound events overlap with them (including other in-
stances of the same sound event), and the number of instances in which those
events overlap. For example, if a single
Bird_Chirp sound emitter overlaps with
two other sound emitters playing the
Crickets sound event, then that would be
recorded as a single occurrence of an overlap between
Bird_Chirp and Crick-
ets
for the Bird_Chirp entry. For the Crickets entry, it would be recorded as
two instances of an overlap. An example table generated for a sample sound map
is shown in Table 21.1. From this data, we can begin constructing our sound
packs.