If this is your first time here, you can start at the beginning, and then work your way forward though the archive links. -------------------------------------------------------
Monday, May 16, 2005
Hi LCL,
Sorry to jump in on your blog, but I wanted to ask you a question about the example spreadsheet ...
In most of the games I've played I would have expected the duration of the FX files for footsteps to be quite small (e.g. single footsteps) that were repeated so the sound could start and stop according to the on-screen action and input of the player.
The only time I've encountered the need to create long FX sequences is in my work on Film soundtracks when I've had to create ambiences for scenes.
Are the "Human Footsteps" FX listed in the spreadsheet for actual gameplay or are they for cutscenes (just wondering why they're listed as 2 minutes in duration)?
Excellent document btw. I'm sure it will be very useful during production.
Cheers,
Malcolm.
--------------------------------------------------------------------
Response:
5point,
Good catch, it is a mistake kind of, but let me justify it in some way. (other than the oversight)
Originally I had wanted to use a single sound file and randomize the start time of the file when triggered to introduce diversity.
Turns out file start randomization isn't all it's cracked up to be. (currently experimental/ dysfunctional in OpenAL)
So, the 2min sample will be cut down into several single footstep samples for a single intensity level. (Split off into randomized lists of L/R footsteps that will get shuffled together through coding)
The footsteps will then get grouped together by priority and randomly selected to play when an entity is selected and moved. (for this example lets assume a single entity)
Factor in a little volume/pitch randomization and you’ve got a recipe for diversity!
This should cut down on some of the monotony of the sound of stepping.
Can you imagine a world where everyone only has 2 footstep sounds...L + R?
Thanks for looking over my progress...I'm still feeling my way through a lot of this, your extra set of eyes is much appreciated.
LCL
Sorry to jump in on your blog, but I wanted to ask you a question about the example spreadsheet ...
In most of the games I've played I would have expected the duration of the FX files for footsteps to be quite small (e.g. single footsteps) that were repeated so the sound could start and stop according to the on-screen action and input of the player.
The only time I've encountered the need to create long FX sequences is in my work on Film soundtracks when I've had to create ambiences for scenes.
Are the "Human Footsteps" FX listed in the spreadsheet for actual gameplay or are they for cutscenes (just wondering why they're listed as 2 minutes in duration)?
Excellent document btw. I'm sure it will be very useful during production.
Cheers,
Malcolm.
--------------------------------------------------------------------
Response:
5point,
Good catch, it is a mistake kind of, but let me justify it in some way. (other than the oversight)
Originally I had wanted to use a single sound file and randomize the start time of the file when triggered to introduce diversity.
Turns out file start randomization isn't all it's cracked up to be. (currently experimental/ dysfunctional in OpenAL)
So, the 2min sample will be cut down into several single footstep samples for a single intensity level. (Split off into randomized lists of L/R footsteps that will get shuffled together through coding)
The footsteps will then get grouped together by priority and randomly selected to play when an entity is selected and moved. (for this example lets assume a single entity)
Factor in a little volume/pitch randomization and you’ve got a recipe for diversity!
This should cut down on some of the monotony of the sound of stepping.
Can you imagine a world where everyone only has 2 footstep sounds...L + R?
Thanks for looking over my progress...I'm still feeling my way through a lot of this, your extra set of eyes is much appreciated.
LCL
Altogether the pre-dev on this is starting to wrap a bit.
Here's an excerpted example of the spreadsheet currently used to communicate audio file detail and implementation specifics:
0ADSOUNDPRELIMEXAMPLE3.xls
Decisions have been made as to how to handle file randomization, priorities, intensities, and various concepts are being tossed around regarding how to hande the scaling of entites/sources.
Also added is a Folder tree hierarchy that dictates, based on the spreadsheet, where sounds should be placed in the sound folder for the game.
Still on the plate are the integration of EAX effects in non-standard ways, a more comprehensive naming standard, samples & screens to illustrate audio concepts, voice asset round-up, and hiring staff to the audio dept. for sfx creation.
From the audio asset spreadsheet, there are currently over 700 expected unique sound effects for the game.
It's a big list, and will require many talented sound effect wizards to complete...look out for a job posting in the future.
Thanks for following, I'll try to get more meat in the next update.
Damian
LCL
Here's an excerpted example of the spreadsheet currently used to communicate audio file detail and implementation specifics:
0ADSOUNDPRELIMEXAMPLE3.xls
Decisions have been made as to how to handle file randomization, priorities, intensities, and various concepts are being tossed around regarding how to hande the scaling of entites/sources.
Also added is a Folder tree hierarchy that dictates, based on the spreadsheet, where sounds should be placed in the sound folder for the game.
Still on the plate are the integration of EAX effects in non-standard ways, a more comprehensive naming standard, samples & screens to illustrate audio concepts, voice asset round-up, and hiring staff to the audio dept. for sfx creation.
From the audio asset spreadsheet, there are currently over 700 expected unique sound effects for the game.
It's a big list, and will require many talented sound effect wizards to complete...look out for a job posting in the future.
Thanks for following, I'll try to get more meat in the next update.
Damian
LCL
OpenAL Basics:
The OpenAL has three fundamental primitives or objects: Buffers, Sources, and a single Listener. Each object can be changed independently, the setting of one object does not affect the setting of others.
Listener AND Source Attributes:
POSITION specifes the current location of the Object in the world coordinate system.
VELOCITY specifies the current velocity (speed and direction) of the
Object, in the world coordinate system.
GAIN denotes a scalar amplitude multiplier. As a Source attribute, it applies to that particular source only. As a Listener attribute, it effectively applies to all Sources in the current Context. The default 1.0 means that the sound is un-attenuated. A GAIN value of 0.5 is equivalent to an attenuation of 6 dB. The value zero equals silence (no output).
Source Attributes:
SOURCE_RELATIVE set to TRUE indicates that the values specifed by POSITION are to be interpreted relative to the listener position.
LOOPING is a flag that indicates that the Source will not be in STOPPED state once it reaches the end of last buffer in the buffer queue.
MIN_GAIN is a scalar amplitude threshold. It indicates the minimal GAIN which is always guaranteed for this Source.
MAX_GAIN denotes a scalar amplitude threshold. It indicates the maximal GAIN permitted for this Source.
REFERENCE_DISTANCE This is used for distance attenuation calculations based on inverse distance with roll off.
ROLLOFF_FACTOR This is used for distance attenuation calculations based on inverse distance with roll off. For distances smaller than MAX_DISTANCE (and, depending on the distance model, larger than REFERENCE_DISTANCE), this will scale the distance attenuation over the applicable range.
MAX_DISTANCE This is used for distance attenuation calculations based on inverse distance with roll off, if the Inverse Clamped Distance Model is used.
PITCH Desired pitch shift, where 1.0 equals identity. Each reduction by 50 percent equals a pitch shift of -12 semitones (one octave reduction). Zero is not a legal value.
Direction and Cone:
Each Source can be directional, depending on the settings for CONE_INNER_ANGLE and CONE_OUTER_ANGLE.
There are three zones denoted: the inner cone, the outside zone, and the transitional zone in between.
The angle-dependent gain for a directional source is constant inside the inner cone, and changes over the transitional zone to the value specified outside the outer cone.
Source GAIN is applied for the inner cone, with an application selectable
CONE_OUTER_GAIN factor to de ne the gain in the outer zone. In the transitional zone implementation-dependent interpolation between GAIN and GAIN TIME.
CONE_OUTER_GAIN is applied.
The OpenAL has three fundamental primitives or objects: Buffers, Sources, and a single Listener. Each object can be changed independently, the setting of one object does not affect the setting of others.
Listener AND Source Attributes:
POSITION specifes the current location of the Object in the world coordinate system.
VELOCITY specifies the current velocity (speed and direction) of the
Object, in the world coordinate system.
GAIN denotes a scalar amplitude multiplier. As a Source attribute, it applies to that particular source only. As a Listener attribute, it effectively applies to all Sources in the current Context. The default 1.0 means that the sound is un-attenuated. A GAIN value of 0.5 is equivalent to an attenuation of 6 dB. The value zero equals silence (no output).
Source Attributes:
SOURCE_RELATIVE set to TRUE indicates that the values specifed by POSITION are to be interpreted relative to the listener position.
LOOPING is a flag that indicates that the Source will not be in STOPPED state once it reaches the end of last buffer in the buffer queue.
MIN_GAIN is a scalar amplitude threshold. It indicates the minimal GAIN which is always guaranteed for this Source.
MAX_GAIN denotes a scalar amplitude threshold. It indicates the maximal GAIN permitted for this Source.
REFERENCE_DISTANCE This is used for distance attenuation calculations based on inverse distance with roll off.
ROLLOFF_FACTOR This is used for distance attenuation calculations based on inverse distance with roll off. For distances smaller than MAX_DISTANCE (and, depending on the distance model, larger than REFERENCE_DISTANCE), this will scale the distance attenuation over the applicable range.
MAX_DISTANCE This is used for distance attenuation calculations based on inverse distance with roll off, if the Inverse Clamped Distance Model is used.
PITCH Desired pitch shift, where 1.0 equals identity. Each reduction by 50 percent equals a pitch shift of -12 semitones (one octave reduction). Zero is not a legal value.
Direction and Cone:
Each Source can be directional, depending on the settings for CONE_INNER_ANGLE and CONE_OUTER_ANGLE.
There are three zones denoted: the inner cone, the outside zone, and the transitional zone in between.
The angle-dependent gain for a directional source is constant inside the inner cone, and changes over the transitional zone to the value specified outside the outer cone.
Source GAIN is applied for the inner cone, with an application selectable
CONE_OUTER_GAIN factor to de ne the gain in the outer zone. In the transitional zone implementation-dependent interpolation between GAIN and GAIN TIME.
CONE_OUTER_GAIN is applied.