Sound Architecture: Date Issued: Filing Path Document Title: Authors: Keywords: Revision History

Sound Architecture
Date Issued: October 10, 2001 Filing Path: SV040:1676/depot/docs/TechDesign

Document Title: Dark Angel Sound Architecture
Authors: Adam King and Brad Reimer
Keywords: Sound, Architecture
Revision History
Issue Date Person Reason - include problem #, ECN #, etc.
0.1 Oct 5, 2001 Adam King Initial version of document.
0.2 Oct 10, 2001 Adam King Revisions based on feedback from Bert Sandie
 Radical Entertainment. All rights reserved. No part of this publication, or any software included with it may be reproduced, stored in a retrieval
system, or transmitted in any form or by any means, including photocopying, electronic, mechanical, recording or otherwise, without prior written
permission of the copyright holder.
This document contains proprietary information of Radical Entertainment. The contents are confidential and any disclosure to persons other than
the officers, employees, agents, or subcontractors of the owner or licensee of this document, without prior written consent of Radical
Entertainment is strictly prohibited.
Radical Entertainment
DA Content Pipelines 18-Oct-02
1. INTRODUCTION
This document deals with the architecture of the DA sound system.
1.1 Scope
All aspects of the DA sound system are covered in this document including there interaction
with other subsystems.
1.2 Objectives
The objective of this document is to discuss the organization of the sound architecture and how
the required functionality will be accomplished.
1.3 Intended Audience
The intended audience of the document is the DA technical director, the sound programmers,
and anyone else who has interactions with the sound system.
1.4 References
Issue: 0.1 Page 2 of 22

This Document contains Confidential Information of Radical Entertainment.
2. SOUNDMANAGER AND THE INTERMEDIATE CLASSES
The sound system is based on two components that are responsible for the handling of sounds
and the interaction with the rest of the game the: SoundManager and intermediate classes.
The SoundManager class is responsible for the loading, playing, stopping, and unloading of the
sound resources at the lower level. The SoundManager will maintain clip, stream, and dialog
players for all of the possible sounds since the players are extremely small compared to the
resources that they will be playing. The SoundManager will have a callback that it can access
for all of the intermediate classes so that if a load fails the associated class can be informed and
if a low priority resource needs to be unloaded so that a higher priority resource can be loaded
the callback will be called to inform the appropriate class that its resource has been unloaded.
The intermediate classes provide an interface between the main game and the SoundManager.
The various intermediate classes observe for sound events and based on the events that they
receive they will call the appropriate SoundManager functions.
All of the loading that is done by the SoundManager will go through the Central Loader. The
SoundManager will make sure, prior to loading, that the resource has not been previously
loaded.
The subsystems that will gain access to the sound system via the intermediate classes and the
events dispatched. The subsystems that will be dispatching the events observed by the
intermediate classes are:
- UIManager
- NISManager
- MissionController
- Director
- CharacterManager
- Collision System
One aspect of the overall sound system that needs to be explored in more detail is the
coordination between the sound and the NISs. The NISs will be synched to the sound, which
means that the NIS will be running off of the clock made available by the sound system. This
has been previously tried in snowboarding and Tim will be consulted on how to create this
system since he created the system for snowboarding. We will also have to look into the NIS
system to see how this will affect the existing code.

DA Sound Design
IDASoundCharacter
IDASoundAmbient IDASoundDialog IDASoundCharacterEffects IDASoundCollision IDASoundNIS IDASoundGeneralObjects IDASoundMenu IDASoundDebug IDASoundSettings IDASoundMusic
IDASoundDialogManager IDASoundDebugManager IDASoundTuner

Interactive
Music
IDASoundManager
IDASoundPlayerManager
Class Name: IDAPlayerManager

Responsibilities: Collaborators:
+ Store all of the clip players FTech radsound libraries…
+ Store all of the stream players + IRadSoundClipPlayer
+ Play sounds + IRadSoundStreamPlayer
+ Provide access to the players for setting + radscript system

volume and positional information?
o Help with fader and multiplier setup

so that settings may be applied
elsewhere.
Class Name: IDASoundManager

+ Allow other systems to capture and + IDAPlayerManager

release the sound resources.

+ (Blindly) inform callers of what we are + Various faders, knobs, randomizers,

doning. Tell them when resources are etc.
ready or finished.
+ A sound resource manager, sound event
+ Manage the sound hierarchies for manager, and sound system
knobs, faders, etc. (multipliers, etc.) manager.
Class Name: IDASoundTuner

+ Present tunable features to composers + IDASoundManager

through scripts and radtuner.
+ Control global sound settings

(especially volumes).
+ Present a master interface for stopping,

pausing, and otherwise managing the
sound system on a utility level.
Class Name: IDADebugManager

+ Get stats on the sound system. + IDASoundManager
+ Give readable sound information.
+ Track sound allocations resources and

other odds and ends for better leak
management
+ Present a breakpoint-based interface for

adjusting settings on the fly.
+ Gather useful DEBUG ONLY

functionality in one easy to use (and

easy to hide) system.
Class Name: IDADialogManager

+ Take various pieces of dialog, sections + IDASoundManager

of conversations, interjections, and
more and feed them into the sound
system.
+ Track an overview of the dialog and

make sure that characters are not
violating any “rules” that may come up.
(The character dialog instances must
manage characters repeating
themselves, overlapping with
themselves, etc.)
+ Extract “conversations” into sound

“resources”.
Class Name: IDASoundAmbient

+ Receives events from TriggerManager + IDASoundManager

and WorldObjectManager about
changes in the environment and
volumes that have been entered.
+ Based on information received in

events IDASoundAmbient will manage
a list of resources and tell the
SoundManager to load, play, stop, and
unload resources.

Class Name: IDASoundDialog

+ Receives information from + IDASoundDialogManager

IDASoundCharacter based on events
from the CharacterManager related to
character dialog.
+ Based on the information that it

receives IDASoundDialog will pass on
information to
IDASoundDialogManager about what
to play.
Class Name: IDASoundCharacterEffects

+ Receives information from + IDASoundManager

IDASoundCharacter based on events
from the CharacterManager related to
general character effects.
+ Based on information that it receives

IDASoundCharacterEffects will
manage a list of resources and tell the
unload resources.
Class Name: IDASoundCharacter

+ Receives events from + IDASoundDialog

CharacterManager about the creation,
updating, or changing of characters and + IDASoundCharacterEffects
their related information.

IDASoundCharacter will pass on

information to IDASoundDialog and
IDASoundCharacterEffects.
Class Name: IDASoundCollision

+ Receives events containing collision + IDASoundManager

information from the collision system.
The collision information will include
the surfaces involved in the collision
and the entity information.

IDASoundCollision will manage a list
of resources and tell the SoundManager
to load, play, stop, and unload
resources.
Class Name: IDASoundNIS

+ Receives events containing information + IDASoundManager

about the playing of NISs and passes
back information via a callback that
allows for the synchronization of the
sound and the NIS.

IDASoundNIS will manage a list of
resources and tell the SoundManager to
load, play, stop, and unload resources.
Class Name: IDASoundMusic

+ The responsibilities of this system are + Interactive Music System

not clearly defined yet due to the fact

that the interactive music system has
yet to be completely defined, but this
will either be a filter/mediation level or
it could be a detailed ai level. This
definition will be made clear in the
coming weeks.
Class Name: IDASoundSettings

+ IDASoundSettings receives events + IDASoundTuner

from any of the outside systems in
relation to changes in volume, pitch, or
reverb.

IDASoundSettings passes the new
settings onto IDASoundTuner.
Class Name: IDASoundMenu

+ Receives events from the UIManager + IDASoundManager

informing it of what the user has done
inside the interface and the transitions
that have occurred.

IDASoundMenu will manage a list of
resources and tell the SoundManager to
load, play, stop, and unload resources.
Class Name: IDASoundGeneralObjects

+ Receives events containing information + IDASoundManager

on changes in the position, velocity,

and status of general world objects
from the WorldObjectManager.

IDASoundGeneralObjects will manage
a list of resources and tell the
unload resources.
Class Name: IDASoundDebug

+ Receives events from all of the systems + IDASoundDebugManager

that the sound system observes and
passes the data culled from these events
to the IDASoundDebugManager for
accumulation and decimination.

3. EVENTS AND RESOURCES
There will be a main SoundEvent class and from this we will have the following more specific
types of events:
- SoundEvent
This basic sound event allows you to load, play, stop, and unload sounds.
o Identifier based on enumeration of what should be done
Load
Play
Stop
Unload
Stop All
o Name of the Resource
o Description
The description will allow the various intermediate classes to see

whether or not they are interested in the information that is contained
within the sound event.
Sample descriptions would include:
• CHARACTER
• AMBIENT
• MENU
• NIS
There will be in most cases a one-to-one correspondence between the

description and the intermediate class but there will be cases where
more than one system is interested in the information (i.e. interactive
music).
- SoundSettingsEvent
This settings event allows the overall sound settings to be manipulated.

o Volume
o Pitch
o Reverb
o Master Volume
o FX Volume
- SoundObjectEvent
This object event allows you to create or update a sound object as the
corresponding ai object is created or updated.
o Name
o Position
o Velocity
o Orientation
- SoundCollisionEvent
This collision event will be passed from the collision system to the
IDACollisionSystem.
o Collision Data Structure
Pointer to character information
• Character name, etc.
Surface Data for both objects involved in the collision
The IDASoundResource class will contain a name (filename or identifier (for dialog)), the player
identifier, alternate resource information (allows for grouping of resources), and a number
identifying the last resource to be played in the group if there is more than one resource in the
group.

4. SOUND SCENARIOS
4.1 Max walks from street into a room
FLOW OF EVENTS:
1. Initially, there are ambient sounds ordinarily found on a street.
2. The room has an appropriate sound trigger volume that will pass an event to the
IDASoundAmbient intermediate class, which will tell the SoundManager to unload the
street ambient sounds and load the sounds and appropriate settings for the room.
a. What will be passed to the intermediate class for ambient sounds to tell it whether
the new sound is replacing an old sound or playing in conjunction with an old
one?
b. What information needs to be stored in the trigger volume?
3. The sound system should perform a smooth transition between the ambient sounds for the
two environments. This will partial be handled by the interactive music system and
partially by trying to avoid jarring starting and stopping of sounds.
INFORMATION NEEDED FROM GAME
1. IDASoundAmbient will need to know when a sound trigger volume is entered.
2. IDASoundAmbient will also need to know when it should stop an ambient sound and
replace it with a different ambient sound.
4.2 Max walks from asphalt sidewalk onto dirt road
FLOW OF SOUND EVENTS:
1. Each of Max’s footsteps will cause an “asphalt” walking sound
2. Max crosses over to dirt road. The new resulting collisions of the feet with the ground
will return a new surface type for the collision that will result in the different sound effect
being used.
a. The ideal situation would be for all the surface sounds that can be accessed in the
environment to be loaded upon entry into the environment. Will this be possible?
What are the sizes of these files likely to be?

1. The collision system will pass a SoundCollisionEvent into the intermediate
IDASoundCollision class that will contain the surfaces involved in the collision.
4.3 Max starts walking (idle to walk)
FLOW OF EVENTS
1. Every time that one of Max’s feet touches the ground there will be a collision, which will
send the collision information to the IDASoundCollision intermediate class.
2. The collision system will provide the surface information to IDASoundCollision, which
will allow for the appropriate collision sound to be played for the surface type.
INFORMATION NEEDED FROM THE GAME
1. An event indicating a collision between a foot and the ground or an event signaling a
change in animation state (idle, walk, or run).
2. IDASoundCollision will need the surface information, which will be made available in
the event from the collision system.
4.4 Max runs into a wall
FLOW OF SOUND EVENTS
1. The collision system will pass an event to IDASoundCollision telling it the surfaces that
were involved in the collision as well as the position of the sound in 3D space.
2. Character information is available from the collision data. Is it necessary to have

character specific collision sounds? Should IDASoundCollision be pulled back inside
IDACharacterInstance?
1. The IDASoundCollision class needs to receive a SoundCollisionEvent from the collision

event.
a. What character hit the wall? This information is available in the collision data
that is sent to IDASoundCollision.
2. What is the nature of the collision? Did she punch or kick the wall? Did she run into it?
a. Is this important data? If this is necessary then it will be necessary to pull the
collision data back inside the character because we will need to maintain the state
of the character’s animation.
3. What type of material is the wall?

a. This information is available in the collision data sent to IDASoundCollision.
4. How hard is the collision?
a. This information is available in the collision data sent to IDASoundCollision.
4.5 A soldier sneezes
1. The character manager will send the IDACharacterManager a sound event saying what
ambient sound to play.
a. These ambient sounds will take place off screen and therefore will not require any
synchronization.
1. The character manager will send the IDACharacterManager the ambient sound that needs
to be played and the location of it.
4.6 Playing a non-interactive sequence (NIS)
1. The NIS sound class receives an event telling it to prepare a certain NIS.
2. The NIS sound classes find the correct sound resource for the NIS.
3. The sound manager is asked to load and prepare the appropriate sound resource.
4. When the sound is ready, the NIS sound class is made aware by a callback.
5. The NIS sound class makes its caller aware and eventually receives an event telling it to
start playing.
6. As the NIS plays, the NIS sound classes may query the sound manager for the number of
milliseconds that have elapsed according to the sound clock. The animation must make
use of this information to properly synchronize itself with sound.
4.7 Max meets a new character (interactive music)
FLOW OF EVENTS
1. If not already created at the start of the game, a sound character instance classes is
created for the new character.

2. The character sound class will ask the sound manager to load some standard sound
resources for the character (such as footstep sounds, common collision sounds, etc.).
3. As the character instance receives events relating to its particular character, it tells the
sound manager to play the appropriate sound.
4.8 Max fights a character
1. Interactive music
a. The music class receives an event stating that a fight is about to ensue.
b. The interactive music system is told of the possible state change, and the music
will react accordingly.
2. Character sound instance for Max
a. When the character class is aware that Max is about to enter a fight, it loads any
sound resources that are fight specific (such as extra grunts, oofs, and collision
sounds).
b. As the fight gets underway, the usual collision and reaction sounds play.
4.9 Max turns the corner from a pleasant looking (and sounding) street to a
dangerous environment (interactive music)
a. The music class receives is triggered as to a change in the location of Max.
b. Based on the old and new location of Max, the music class determines that the
game mood is changing from pleasant to suspenseful.
c. The interactive music system is informed of the new state and it reacts
accordingly.
4.10 Max turns the corner to find an idling car (obstructions)
1. The idling car will be represented by an instance of the sound general objects class.
2. When the listener is close enough to the idling car, the car’s sounds are prepared to play.

3. The car sound object determines an appropriate obstruction factor based on its location in
the world and the location of the listener.
a. Even an estimation of this may involve a large amount of processing. Obstruction

calculations should only be done when they are important to the game (like
building suspense by not fully hearing things around the corner).
4. The sound player for the car idling sound is fetched from the sound player.
5. The obstruction factor for the car idling sound is updated.
4.11 The player enters into pause mode
1. The sound menu class receives an event informing of the transition from the game to the
pause mode.
2. The sound menu class tells the sound manger to stop all currently playing effects, music
and dialog.
3. The sound menu class tells the sound manager to play an appropriate sound for the
transition from pause mode to the main game. This should have already been loaded.
4. The sound menu class tells the sound manager to load a set of sound clips appropriate for
the menu. These would include sounds for “accept”, “move”, “error”, “back”, etc.
5. When the sounds are finished loading, the transition to the pause mode is complete.
6. Based on the users menu choices, the sound menu class will receive event telling it to
play certain sounds.
7. When the game leaves pause mode, the menu specific sounds are released and the
original sounds clips are loaded back in.
4.12 A random piece of ambient dialog is interrupted by a more important

piece of dialog
A piece of dialog of a certain priority is played
1. The dialog instance owned by a character instance must be aware of what dialog its
character is playing. Therefore, it knows that the character is already playing dialog.
2. The dialog manager is told to load the new dialog.

a. The dialog manager interprets the dialog or conversation as actual sound
resources and asks the sound manger to load them.
3. When it is ready the dialog manger informs the characters dialog class instance that it can
play the new dialog.
4. The dialog class determines that the new dialog must interrupt the current dialog. This is
done by a priority calculation using the type of dialog playing and the type of dialog
pending.
5. The character’s dialog class then choose an interjection (a sound such as wha?, a fade
out, or a simple stop). It then tells the dialog manager to cancel the current dialog using
the interjection.
6. Finally, the dialog class tells the dialog manger to start playing the new dialog.
4.13 The game ends
1. Stinger
a. The sound stinger class receives an event telling it that the end of game has
occurred.
b. The sound effects, dialog, etc. are faded out.
c. The end of game stinger sound is loaded. (The sound manager is told to load the
sound resource holding the stinger sound).
d. The end of game stinger is played (The sound manger is told to play the sound
resource holding the stinger sound).
e. When the stinger is done, the game is allowed to move on from the end of game
state.
2. Interactive music
a. The music class also receives the game over state change.
b. The music class tells the interactive music to move to an end of game state.
c. The interactive music reacts accordingly.

5. PIPELINE
The sound pipeline will consist of the following sections:
- Wav to Rsd conversion
- Script creation
o This script will either be the final radscript that is loaded into the game or can be
tweaked through editing values to get the final script
o The script will consist of a correlation between filenames, in-game id values, and
settings for the given resource.
- Copying of files into the proper cd directory structure
Another aspect of the pipeline that will need to be considered is the use of the file cementer to
combine all of the sound files into a single file that register and unregistered by the game. This
section of the pipeline will need to be further explored before more can be said about it. It will,
however, be located in the last stage of the pipeline and will be relatively easy to insert when the
tool that will perform the task is complete.
5.1 Directory Structure and File Naming Conventions
An important point to remember for everything below is to keep the names all in lowercase. It is
okay if some filenames have uppercase letters, but all directory names must be lowercase.

5.1.1 Directory Structure

sounds\
environ\
cityhub
mccenter
saship
tritech
train
ihq
sewer
general
char\
male (generic directory holding male sounds)
female (generic directory holding female sounds)
lowercase character names for directories
general (will contain grunts, oofs, and other similar
sounds)
taunt
ingamefe (contains pause menu and hud sounds)
fe
collision\
punch
kick
grab
swishes
bodyfall
dialogue\
lowercase character names for directories (same as for char)
music\
fe
ingamefe
soundfx
5.1.2 File Naming Convention
- Filenames can have a maximum of eight characters before the dot which is followed
by a three letter extension
All files located in the character directories should be prefaced with the corresponding
abbreviation.
Characters Abbreviation
1. Max max
2. Logan log
3. Brin brn
4. Y-5 (Brin look-alike) y5
5. Madame X mad
6. Original Cindy cin
7. Stretch str
8. Herbal hbl

9. Normal nor
10. Beka (Max look-alike- but larger) bek
11. Zeke zek
12. Y-5 Bear ybr
13. Y-5 Monkey ymk
14. Y-5 Alligator yag
15. Y-5 Fish yfi
16. Y-5 Insect yin
17. Y-5 pregnant mother ypm
18. Sector Police spo
19. Manticore Guard mgu
20. Manticore Sergeant (Multiple Textures) msg
21. Female Scientist fsc
22. Male Scientist msc
After the character dependent abbreviation will be a descriptive word about the file. This
descriptive word may have to be shortened depending on its length.
E.g. grunt, oof
If there are multiple files that correspond to the descriptive word then an additional letter will
have to be used to represent the differentiating feature. An example of this would be walking on
different surfaces. A different letter, as laid out below, will represent all of the different surfaces
that are available in DA.
Pavement p
Concrete c
Dirt d
Water w
Grass g
Metal m

The surface abbreviations will also be used with respect to the collision sounds. The collision
sounds will start of with an abbreviation representing the type of collision (punch, kick, bodyfall)
that will be followed by one of the surface abbreviations from above.


Sound Architecture: Date Issued: Filing Path Document Title: Authors: Keywords: Revision History

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Sound Architecture: Date Issued: Filing Path Document Title: Authors: Keywords: Revision History

Загружено:

Авторское право:

Доступные форматы

Sound Architecture

Date Issued: October 10, 2001 Filing Path: SV040:1676/depot/docs/TechDesign

0.1 Oct 5, 2001 Adam King Initial version of document.

This document deals with the architecture of the DA sound system.

1.3 Intended Audience

Issue: 0.1 Page 2 of 22

2. SOUNDMANAGER AND THE INTERMEDIATE CLASSES

Issue: 0.1 Page 3 of 22

IDASoundDialogManager IDASoundDebugManager IDASoundTuner

Class Name: IDAPlayerManager

+ Store all of the clip players FTech radsound libraries…

+ Store all of the stream players + IRadSoundClipPlayer

+ Play sounds + IRadSoundStreamPlayer

+ Provide access to the players for setting + radscript system

o Help with fader and multiplier setup

Class Name: IDASoundManager

+ Allow other systems to capture and + IDAPlayerManager

Issue: 0.1 Page 4 of 22

+ (Blindly) inform callers of what we are + Various faders, knobs, randomizers,

Class Name: IDASoundTuner

+ Present tunable features to composers + IDASoundManager

+ Control global sound settings

+ Present a master interface for stopping,

Class Name: IDADebugManager

+ Get stats on the sound system. + IDASoundManager

+ Give readable sound information.

+ Track sound allocations resources and

+ Present a breakpoint-based interface for

+ Gather useful DEBUG ONLY

Issue: 0.1 Page 5 of 22

Class Name: IDADialogManager

+ Take various pieces of dialog, sections + IDASoundManager

+ Track an overview of the dialog and

+ Extract “conversations” into sound

Class Name: IDASoundAmbient

+ Receives events from TriggerManager + IDASoundManager

+ Based on information received in

Issue: 0.1 Page 6 of 22

Class Name: IDASoundDialog

+ Receives information from + IDASoundDialogManager

+ Based on the information that it

Class Name: IDASoundCharacterEffects

+ Receives information from + IDASoundManager

+ Based on information that it receives

Class Name: IDASoundCharacter

+ Receives events from + IDASoundDialog

+ Based on information that it receives

Issue: 0.1 Page 7 of 22

Class Name: IDASoundCollision

+ Receives events containing collision + IDASoundManager

+ Based on information that it receives

Class Name: IDASoundNIS

+ Receives events containing information + IDASoundManager

+ Based on information that it receives

Class Name: IDASoundMusic

+ The responsibilities of this system are + Interactive Music System

Issue: 0.1 Page 8 of 22

Class Name: IDASoundSettings

+ IDASoundSettings receives events + IDASoundTuner

+ Based on information that it receives

Class Name: IDASoundMenu

+ Receives events from the UIManager + IDASoundManager

+ Based on information that it receives