LCL

Well, time marches on!
Progress on the Design spec for the sound effects on this project are humming along well.

Have a peep at the updated one here.

Still to be determined are some of the expected uses and parameters for various in-game effects.
Setting a naming standard that is good for everyone involved, not too long, somewhat descriptive, easy to grok...still weighing in on what's best.

More details to follow soon!
LCL

Good ideas from the team that came out of this discussion include:

Naming Convention:
Agreed. There are no spaces in the path and everything is in fixed format lowercase and easy to interpret programmatically.

Pitchshifting:
Sounds like a good way to increase the # of unique sounds. I will have to mark sounds that will be pitch shifted and specify a range with which they can be shifted within.
The engine will handle this natively, I'm told.

Panning/Placement:
From what I've gathered so far with regards to stereo sound (and potentially 3Dsound) is that by tying the sound to an position/ entity on the map the engine sorts out panning and positioning depending on your speaker/soundcard configuration. If I'm right then, it would handle the sound placement in a stereo, surround, or "virtual surround” environment.

Sound Overload:
*Limiting # of Sounds on Playback*
Comment:
With respect to the sound overload comment, again I think this could be balanced based on different situations with some sort of priority system to limit the # of sounds at a time. (i.e. play up to X instances of resources and X instances of natural ambience at a time...not sure how this will work...but this is where I would like to get to. variables to balance the distribution of sound situationaly)

Comment:
The game sound code should be responsible for making sure we don't emit too many sounds of one type (a fixed budget for several classes as you suggest sounds good), while the low-level code makes sure that everything fits into the number of sound channels we have (which varies with sound card capabilities). This is because snd.cpp knows about the sound hardware, but not anything about the game itself.
OpenAL promises us at least 16-1 'sources'. High-end sound cards and software mixers typically have 64. A good ballpark figure seems to be 24, but we must be able to get along with 16.

Low-Level Audio Code already envisages 'application priority' to make sure voiceovers aren't dropped in favor of seagulls. If the game sound code were to automatically detect sound clusters, that would help a lot with reducing the number of active sources. In that case, it might be enough to assign a base priority by sound type (battle > chopping) and let the distance sorting (and fading - you don't hear stuff that's too far away) do the rest.

Comment:
1. Think about the idea of "automatically detecting sound clusters" more...keep a dialog going about whether this scheme continues to make sense.
2. Think about what the range of "base priority" would/should/could be, and I will work to apply it to the clips in the spreadsheet at some point. (If it's a go)

The idea was brought up that once the # of entites on screen goes over X, we could play different audio clips for the sounds of larger scale action.

Open questions on the table:

1.Who decides if 4 lumberjacks are to be combined, and how?
-Must decide on inclusion cut-offs and scope of workload. Start small and work our way upwards in intensity as necessary.

2.When updating all entities, I guess they would issue play requests every few seconds. After all are issued, we could look over the list, detect that >= 4 came in one area, and combine those.
-Do the entities issue sounds for the next 2 seconds all at once (all with a random start delay, so that we fill the 2 seconds)? In that case, the above might work.
-What about if the villagers stop chopping?
-The sounds would still be queued, how is this normally done?

3.Are there 'must hear' events that occur on the other end of the map and wouldn't normally be heard (because it's too far away)? How do we handle that?
OpenAL provides for 'minimum' gain (= volume), I guess that would effectively disable attenuation by distance.
- 1st thought is that yes there may be 'global' events (alarms) that you would want to use to notify the player of something that happened on the other side of the world. We will need to roll that around the rest of the team for input.

I continue to build more and more potential parameters onto each sample, that will hopefully make it easier to implement when the time come to start dropping the sounds in.

It is due to the highly responsive and knowledgeable team involved on this project that I've been able to navigate the heady waters of this project thus far, and just want to acknowledge all of their valuable comments.

Moving right along!
Until Next Time
LCL

This is a roundup of some of the preliminary thinking that I had been doing with regards to pulling the audio side of this project together.

The initial challenge was laying the foundation for managing the audio assets, and charting a straight path to audio implementation for the programming department.
(I say challenge with a smile, as I head deep into the recesses of my organizational mind...mwuahahahaa!!!)

First off I talked with the audio programmer about some of the work he had done with regards to the OPENAL audio engine. He helped nail down some of the basic specs and requirements as well as the flexibilities. His insight into the deep levels of the audio code will prove to be invaluable in the future, and I look forward to working with him more to sort out the details.

Next I needed to start with a naming standard to work with, so I probed the Programming Dept. Head for a quick tip on how they like it down in code world. What came out of that was an attempt to give everything a name comprised of a [xxx_xxx_##] designation for each sound clip reference. At the very least this gives me a chance to organize things in the spreadsheet in the short term, but hopefully we will nail down the macro level of the naming standard that will carry through to the coding.

The other cool thing that came out of that talk was the idea of 'play lists' that could be randomized.
Ahh, sweet randomness how you will solve all of my woes of overworked audio and often heard audio cues.
I'm hoping to randomize a fair share of things to keep the sounds fresh and spry in a world so full of life, and I see this as an easy win.

The potential for sharing various sounds across multiple sound groups has become desirable, and I'll try to illustrate what I might be thinking with an example:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
One of the actions in the game is to collect resources for building houses and weapons in order to build your empire.

Foresting is used to collect wood to build houses and ships, a worker is assigned to a plot that has tree's on it and goes to town de-foresting until all the tree's are gone.

Instead of having a single loop that starts with the action, I'm proposing:
1. Random loop selected from the [tree_chop__##] "play list" that would play immediately.
2. Random loop selected from the [tree_creak_##] "play list" that would play after a random pause from the start of action of betweeen 5-10 seconds.
3. Randomly play sounds from [group_lumbering_##] "playlist" that would include any other sounds in a defined "lumbering" group, potentially: [fire_crackling_##], [gather_leaves_##], etc. to help fill in ambience of the event.(occasional blacksmithing sound, or vocal asset tied to the action of Foresting)

The furthering of this idea may be to have EACH foresting location emanating these sounds, panned in relation to their locations on the map.

If you can imagine the cacophony of a dozen foresters hacking away at a forest with randomized sounds emanating from each of their locations across the map.
Merzbow would likely be proud. (hmmm...I should also think about a way to limit it to X # of entities on screen at a time)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Something that has been thrown around a bit is the idea of randomizing the pitch of the sound clip to give even more variability to the sound.
This sounds like it would work in some applications within certain ranges, and as long as those parameters are specifiable we should be able to play with that a bit.
(i.e. randomizing the pitch on each instance of wood chopping would sound great in the above mentioned scenario as long as it wasn’t pitched too high/low)

Sharing sounds will be an important factor, along with pitch shift, frequency and bit rate conversion all in an attempt to try and keep the total audio size budget on track. (re: small)

Needless to say it involves a multiple tabbed Excel spreadsheet (draft example) with a maddening amount of variables in order to communicate effectively to the programmers, as well as the future team of audio specialists, what we are trying to accomplish.
I envision looking to the spreadsheet to get a grip on who is working on what, what sounds are finished, what sounds are implemented by programming, etc. (I'm also hoping to use it to cook rotisserie chicken!)

That said, the concepts aren't fully realized, and will require much discussion to sort out the further details.

Next time, we'll look at some of the good discussion that came out of these initial ideas.

I signed on as Sound Designer for this Historical RTS currently in production at WildFireGames called 0 A.D. ("zero ay-dee") in March of 2005.
This freeware project is made up of a dedicated staff of volunteer individuals who have been working on the project for sometime, and involves every aspect of game development.

The scope of the project is massive in comparison to the smaller titles I have worked on and completed, so it has opened my eyes to some new ways of looking at the process of Asset Management and Audio Implementation.
It is my hope that through my process there is something to be learned if you are just starting down the path of interactive game audio, and that through the painful process of cataloging my experiences and discovery you too can make an attempt at sorting out the black-art of implementation and push the audio boundaries into the future.

When I first joined the project there was a huge pile of well defined information to sort through with regards to the gameplay and the work that had gone on already.

The previous sound designer had done a good job pulling together the preliminary Sound Doc outlining the different sounds that were expected to be needed based on (what was then) current concepts of the features expected to be included. I like to refer to this document as the 'Fuzzy Sound DesignDoc', in that it is imbued with pure emotion and conveys the basic arc of what is expected in plain English.

But that is as far as it had gone.
There was no strategy in place as to how to manage the Audio Assets, Naming Standards, or Audio Implementation.

The preliminary audio programmer on the team had made great strides in implementing the OpenAL framework, as well as some low level sound code, and was off and running with the basics for what it will take to get the audio off the ground. But there had been very little discussion on the needs of the Audio department, but this was due more to the lack of a proper sound team than anything else.

The journey begins!

I'll try to outline some of the thinking's that I have gone through in the process of wrapping my arms around the scope of the audio side of this massive project.
As this is a work in progress, I encourage anyone with ideas to pipe in and join in the rich learning experience that this has been. and will continue to be.

Hopefully this will shed some light on the deeper thinking that goes on with regards to audio pre-production.
(as well as revealing some of the stumbling blocks along the way in my learning process)

Stay Tuned True Believers!
LCL