LCL

Today we're looking at a few different tools that might be of help to us here on the audio team, with regards to the management of audio parameters in relation to 5 different areas where sound properties need to be adjusted.

I'm gonna shoot from the hip with what I've been able to discern through conversations with educated team members, design document information and discussions.

By no means do I have a complete picture of what is involved with the deeper programming issues that may be implied by my suggestions, nor am I experienced enough to know whether there is a better way to handle some of the concepts I'll be throwing out.

This could get lengthy, but I've mocked up some visual aid's that hopefully will make it less bookish. B)

This is my attempt to round up and define a strategy for managing the audio code to allow for maximum audio flexibility, taking into account the brilliant work that has already been done and harnessing the hard work of others effectively.

My proposal is for the ability to manage sound file parameters and assignments within .xml documents related to 5 different area’s of game play interaction.

audio.xml - Defines base parameters for all sound files
audio_group.xml - Defines sound file group affiliation for referencing
entity.xml - Expand to define audio behavior for an entity.
action/event.xml - Expand to define audio behavior for a specific action, in relation to the entity involved.
actor.xml - Expand to define audio behavior and trigger points, in relation to the specific actor/animation.

audio.xml

audio.xml should be used to define base OpenAL properties for each sound file in OAD.
The list of adjustable parameters includes: GAIN, LOOPING, PITCH, MIN_GAIN, MAX_GAIN, CONE_OUTER_GAIN, CONE_INNER_ANGLE, CONE_OUTER_ANGLE, PRIORITY, and BUFFER.



See 0ADSOUNDPRELIMEXAMPLE4.xls for additional descriptions of OpenAL properties. (New OAL Tab on the bottom)

After seeing Phillip's beautifully implemented and simple design actor editor, I created a mock up of a possible iteration of what an editor for OAL parameters would looks like.



Knowing very little about how such a thing is built, it may not be based in reality. The key is to be able to adjust values for 1 or multiple selected sound files at a time, where 1 sound file's parameters are adjustable using the table view (similar to the actor editor), and multiple selected sound file parameters would be adjustable using the various input fields along the top of the window. The benefit to this is that it makes adjustment of similar file types quickly, and the changes can be viewed in the window in real time.

audio_group.xml

audio_group.xml should be used to associate files that will be used when a specific group is called, instead of a single sound file or /folder. Groups should be treated much like a “virtual” folder that holds sound files.
A sound file may belong to more than one group.

A group tag should be assignable in any location where a single sound file is also welcome.

Manageable in much the same way a GUI for viewing sound files attached to a group, adding new groups, and adding files to groups could look like this.



entity.xml

entity.xml is already being used to define the underlying behavior of a unit. The applicable extension of this on the audio side is to be able to attach a sound to an entity that is not an Action/Event or Actor/Animation.
An example would be: once a Resource Center is built, the ambient sounds of the Resource Center could be heard coming from it within a certain radius.

Adjustable parameters at this level could include: Looping, Random (from Group or /Folder), Intermittency, and Pitch range & Randomization.
(Sound properties should call first to audio.xml for parameters and replace only variances within current .xml)

action/event.xml

action/event.xml should be used to attach sounds to specific actions/events or sequences of actions/events.

Adjustable parameters at this level could include: Looping, Random (from Group or /Folder), Intermittency, and Pitch range & Randomization.
(Sound properties should call first to audio.xml for parameters and replace only variances within current .xml)

actor.xml

actor.xml is already being used to define various visual specifications wrt the static appearance of a unit or entity, and in the case of animations, should be expanded to include various sound properties as well. Sound files should be attachable to various points during an animation with control over sound file properties at each instance. (the degree to which this last part is necessary remains to be seen)

Adjustable parameters at this level could include: Looping, Random (from Group or /Folder), Intermittency, and Pitch range & Randomization.
(Sound properties should call first to audio.xml for parameters and replace only variances within current .xml)

In discussions with Phillip regarding his Actor Editor, it seemed like these additional fields would be addable to the current actor editor framework.

That's what I've got so far, hopefully some of it makes sense.

Thanks again, to the greatest team on the planet!
Damian
LCL