Orcs vs. Martians audio

RTS audio, beta

Lately I've been doing audio work in Orcs vs. Martians. I thought I'd blog a bit about how the audio has turned out, or rather is turning out, both in terms of the content and the coding. Plus mention some thoughts on future work (environmental sounds, yeah!), and also give a mention that a beta isn't too far down the road.

Content

On the content side, I've been adding more sounds to OVM, trying to construct a richer audio environment. The game now has about 170 sound files, and I expect that'll still grow some more before release.

The way OVM has turned out, nearly all its sounds are associated with game events like:

attacks
- like shooting an arrow or firing a laser.

attack impacts
- when an attack hits a target. the sound is a function of both the type of attack (arrow or laser), and the type of the target (flesh, wood, metal, etc.).

pain
- played if the target groans in some way, in response to being hurt. used mainly for targets that are living creatures.

death
- self-explanatory.

terrain impacts
- a catch-all category for footsteps, debris, or even corpses, hitting the ground.

water splashes
- same as above, but for footsteps/debris/corpses hitting the water.

worker actions
- all the traditional RTS worker actions (chopping, hammering, mining, etc.).

The "terrain impact" sounds have turned out to be a lot of work. OVM models five terrain types: earth, sand, gravel, rock, and snow. So I've given each of those terrain types its own set of impact sounds.

Also, every type of game events supports multiple sounds. Each time an event occurs, OVM randomly picks one sound out of the set. The idea there, of course, is to add more audio variety. I've found that this feature is almost a necessity for an RTS--without it, hearing your units emit the same pain sound ("uh!" "uh!" "uh!") every time they get hit, gets pretty repetitive!

Coding

I've also been working on the coding side, both in OVM's own code, and in Torque's alx audio layer.

I ran into a couple of issues that I thought were kind of interesting.

One issue was that the "pain" sounds really need to be singletons in time for each RTS unit. That is, if a swordsman gets hit by three arrows in rapid succession, you don't want the swordsman saying three "Uh-Uh-Uh!", sounds that play concurrently. That doesn't sound natural--the guy only has one set of vocal cords! Plus, it adds unnecessary load to the sound card. So I had to add code to detect and prevent that case--if the unit is already emitting a pain sound, new pain "events" are ignored until the current sound finishes playing.

On the other hand, it is ok to simultaneously play three attack impact sounds concurrently -- "whap-whap-whap" -- of the arrows hitting the swordsman. That sounds perfectly natural. So the different sound types have needed different code that handles them slightly differently.

Another interesting issue has been (and maybe this wasn't 100% necessary to address, but I did anyway) that sometimes, the more "important" game sounds got drowned out by "less important" sounds. By "important" I mean some sounds are more important to hear, gameplay-wise, than others. The player really wants to hear when his units die or his buildings get destroyed, more than he wants to hear when they get damaged. And he wants to hear when they get damaged, more than he wants to hear even less-important sounds, like terrain impacts (footsteps, debris hitting the ground, etc.)

The problem was, Torque's "alx" sound layer prioritizes sounds strictly based on volume, as perceived by the listener. So depending on where events occur, bootsteps can drown out pain sounds, and pain sounds can drown out death sounds. Now don't get me wrong, prioritizing based on volume is surely the most correct and realistic way to do it, but for an RTS I felt like this was a problem. Every once in a while, I wouldn't hear a building blow up, just because a bunch of debris was thudding against the ground in the foreground, while the building was a little farther back in the background. I didn't like that.

So to addresss that issue, I added an "importance" field to the AudioDescription structure. So now the alx layer combines importance and volume together, to come up with a final priority weighting. Volume alone no longer determines priority. This approach seems to have fixed the issue: during intense battles, when there are more sound events than the sound card can handle, the death and pain sounds seem to come through clearly and reliably. w00t!

Future plans

Next on my audio to-do list: adding environmental sounds.

I think I'm going to enjoy implementing this. Environmental sounds are just fun. So far, I've thinking of adding sounds for:

• birds chirping, where trees are dense
• leaves rustling, where trees are in windy places
• waves lapping, along shores
• deep-water sounds (whatever that sounds like!), in centers of lakes
• frogs croaking, along shores
• insects buzzing, in grassy plains
• coyotes howling, in desert plains
• howling wind, near canyons with steep walls
• jetstream wind, when the camera is at the highest altitude

One challenge with implementing environmental sounds in OVM will be that all of OVM's maps are randomly generated. There are no pre-made, hand-made maps. So the game will have to analyze the map at run-time and programmatically add the environment sounds in (hopefully) appropriate places.

Finally, I'm working towards releasing another public beta of the game. I'm hoping to get this audio work in first, plus of course the usual bug fixes and optimizations. I'm thinking the beta will be ready in about another month or so.