LCL

Recently we've been tackling the management of audio file properties and how to adjust specifics so sounds play the WAY they shoul, WHEN they should. This isn't too big a deal when you're dealing with simple call and response triggered events with around 30-60 files, but can swiftly get out of control when you're dealing with scripted actions and multiple animations triggering multiple sound events using a library of over 700 sounds.

Thankfully there are standards in place to handle all the strangeness, in this case we're going to use XML to quickly manage the changes to properties.

Quote:

Extensible Markup Language, abbreviated XML, describes a class of data objects called XML documents and partially describes the behavior of computer programs which process them.

Basically a text file that stores definitions for various things that can be referenced easily using "Tags" or short names that might reference a group of files and parameters associated with them.

In our examples; a sound file or several sound files are assigned default parameters in what we are calling audio_class.xml. This is where we keep the base level OpenAL properties for each sound files.

Quick recap of OpenAL Properties we'll be using:


Hierarchy of Audio xml's will be:
audio_class.xml = default
audio_group.xml = soundfile(s) and adjustment properties

Initially sound files will be grouped based on their top level association in the following categories within the audio_class.xml :
Category Examples:

interface
human
resource
attack
soundscapes
fauna

These initial categories (or classes) will have the same attributes with relation to how sound will be played back by OpenAL.

Defaults properties for these classes could include:

GAIN: 1.0
LOOPING: N
PITCH: 1.0
MIN_GAIN: 0
MAX_GAIN: 1.0
CONE_OUTER_GAIN: 1.0
CONE_INNER_ANGLE: 360
CONE_OUTER_ANGLE: 360
PRIORITY: 60
BUFFER: buffer_X
VELOCITY: (For Doppler Effects*)
DIRECTION: ?
SOURCE_RELATIVE: Y

*Which I am very excited to try out, at least in some instances...although probably not many

Once defaults have been defined for sound files of a certain class, groups can then be created at any time to include any sound file or files that need properties outside the default in the audio_group.xml.

I threw together a couple of quickies that might illustrate the proposed XML scheme:

Code looks first to determine defaults from audio_class.xml for a human entity walking on grass:

human_footstep_class

GAIN: 0.5
LOOPING: N
PITCH: 1.0
MIN_GAIN: 0.0
MAX_GAIN: 0.5
CONE_OUTER_GAIN: 1.0
CONE_INNER_ANGLE: 360
CONE_OUTER_ANGLE: 360
PRIORITY: 60
BUFFER: buffer_01
VELOCITY: (For Doppler Effects*)
DIRECTION: ?
SOURCE_RELATIVE: Y

Then it looks to audio_group.xml for soundfile(s) and adjustment properties, which in this case include adjustments for file, gain, and pitch randomization within specified ranges.

human_footstep_grass

class=human_footstep_class
{
footstep_01.ogg
footstep_02.ogg
footstep_03.ogg
footstep_04.ogg
footstep_05.ogg
footstep_06.ogg
footstep_07.ogg
footstep_08.ogg
footstep_09.ogg
footstep_10.ogg
footstep_11.ogg
footstep_12.ogg
}
RANDOMIZE FILES IN GROUP: Y
GAIN RANGE UPPER: 0.5
GAIN RANGE LOWER: 0.4
RANDOMIZE GAIN: Y
PITCH RANGE UPPER: 1.2
PITCH RANGE LOWER: 0.8
RANOMIZE PITCH: Y

human_unit actor then calls for:

walk on grass: use human_footstep_grass from audio_group.xml

This is another example where a cow might use the same footsteps, albeit pitched/ slowed down (as reflected by the pitch range:

cow_footstep_grass

class=human_footstep_class
{
footstep_01
footstep_02
footstep_03
footstep_04
footstep_05
footstep_06
footstep_07
footstep_08
footstep_09
footstep_10
footstep_11
footstep_12
}
RANDOMIZE FILES IN GROUP: Y
GAIN RANGE UPPER: 0.5
GAIN RANGE LOWER: 0.4
RANDOMIZE GAIN: Y
PITCH RANGE UPPER: 0.6
PITCH RANGE LOWER: 0.4
RANOMIZE PITCH: Y

animal_cow actor says:

walk on grass: use cow_footstep_grass from audio_group.xml

Same class (default parmaters), same foot steps (different parameters) = resource sharing and diversity built in, all enabled by subtle tweaks in the audio_group.xml.

And with a little deeper implantation showing the action for lumbering resource:

audio_class.xml

human_lumbering_class

GAIN: 1.0
LOOPING: N
PITCH: 1.0
MIN_GAIN: 0.0
MAX_GAIN: 1.0
CONE_OUTER_GAIN: 1.0
CONE_INNER_ANGLE: 360
CONE_OUTER_ANGLE: 360
PRIORITY: 60
BUFFER: buffer_*
VELOCITY: (For Doppler Effects*)
DIRECTION: ?
SOURCE_RELATIVE: Y

audio_group.xml

human_lumbering

class=human_lumbering_class
{
chop_01
chop_02
chop_03
chop_04
chop_05
chop_06
chop_07
chop_08
}
RANDOMIZE FILES IN GROUP: Y
PITCH RANGE UPPER: 1.2
PITCH RANGE LOWER: 0.8
RANOMIZE PITCH: Y
{
falling_01
falling_02
falling_03
falling_04
falling_05
}
RANDOMIZE FILES IN GROUP: Y
GAIN RANGE UPPER: 1.0
GAIN RANGE LOWER: 0.5
RANDOMIZE GAIN: Y
PITCH RANGE UPPER: 1.0
PITCH RANGE LOWER: 0.8
RANOMIZE PITCH: Y
INTERMITTENCY: Randomly once every 30-60 seconds

human_unit actor says:

resource gather lumber: use human_lumbering from audio_group.xml

This hopefully closes the case for now on how the assignment of sounds and the changing of parameters will cascade from all entities/actors and scripted actions.
I encourage you to call me to task on clarifying any discrepancies or questions about the process you might have. Any chance I get to further develop the concept and communicate that through this log is, hopefully, helpful for all involved.

We will be actively seeking Sound Designers/ Sound Effects Specialists beginning next week. If anyone is interested check back here for the posting and head over to the 0.A.D. website and apply.

Next time I'll be talking about tool creation to help implement and attach audio within the game and hopefully some preliminary testing with the currently implemented audio engine and system.

Stay good noise makers!
Damian
LCL