When Orcs Attack! Audio Post-Mortem

All of you probably saw Jon Frisby's (Mr. Joy, Inc.) post-mortem regarding his new game When Orcs Attack!

If not, you can read about it here:
garagegames.com/blogs/48969/13597

Before reading, I would highly suggest you download and play the demo as well -- as you will get much more out of this if you understand what I'm referring to! Download it here:

mrjoy.com/games/6

As the audio designer for the game, there were several interesting things that happened during the development for this game that I thought others might find interesting and perhaps applicable to their current situations. For Torque users, however, your mileage may vary as WoA was developed on the Unity3D platform, so some of these "solutions" that we came up with may or may not exist for you and some additional ones may be available as well! In case you are wondering, I also did the two tracks of music in the game, but most of my post-mortem will be focusing on the sound design elements of the game.

What went right

1) (Pretty) Clear scope In all sound design projects for games that I work on, this can be a big issue. Knowing exactly WHEN to incorporate the sound designer at a stage where the scope is pretty well nailed down is key. Most sound designers are working on "per sound effect" price point as opposed to a "retainer format" (unless you are very rich and can offer health and dental plans...), so for the sound designer to produce extra sounds that you won't actually use can become quite costly. This project, however, was well scoped and I was shown the project pretty late in development, so most of the major features were there and could be seen -- so any additional sounds were figured out pretty quickly.

2) Good Source Sound design falls into two black and white areas; purchased source or self-made source. There is a lot of "grey" in there as well which makes up the huge amount of blend that you often do between self-made and purchased... but in general, when I see an animation and description of something I typically quickly sort my source needs into one of these two categories. A lot of beginning indie programmers I've met, however, have this completely bogus notion that you can just go buy all the sound fx you need and don't really need to do anything original, so you really DON'T need a sound designer. I can tell you honestly that if that's what you do, your sound will be extremely rough and amateur sounding. Every sound that you buy almost certainly needs to be cropped, level-balanced, EQ'd, possibly "placed" (reverb balanced) and converted to the appropriate file format, bit-rate and channel setting (mono/stereo/surround). Multiple that process time about 30-60 sounds for the average casual game, and it becomes a reasonable feat of effort that you are best letting someone experienced in these matters handle.



At any rate, you need to find good source. Sometimes, it simply is not available or is extremely difficult to produce. Fortunately, for this game, there was plenty of arrows whizzing, fireballs and other needed fx for me to chop up, recombine, enhance, double and otherwise mold into what was needed for this project.

3) Successful execution of "levels" In game audio design, a common request is to make a sound, for example, a turret shooting and arrow, and then make four more of them, variations so to speak, on the original. This is tricky as you need make sure its not TOO different that it doesn't sound like an arrow-shooting turret, but not too much the same as to defeat the purpose. Additionally, as it was with this game, another common request is to make the same kinda sound, but variations (5) that purposefully sound BIGGER. Like, "level 2 tower", "level 3 tower" etc. The animation/graphics show the tower getting bigger and tougher, so the sound needs to reflect that. The effect can be achieved through various techniques using additional source and layering (try to preserve at least one common "element" in all the sounds"), EQ (things with more low-end sound "bigger"), reverb (more reverb sounds bigger), short delay (enhances bigness to have a short delay) and other FX. Overall, I think this effect works well in this game.

3) Good trust I was fortunate that this was my second collaboration with Jon, so we had already developed a trust relationship that helped in working on this title. He trusted that I knew what I was doing and I trusted him likewise and this allowed us to go out on a limb in some places rather blindly and trust that certain things would work. This often becomes an issue when a sound designer basically is requesting custom audio "programming". (Note to all soon-to-be-professional-programmers. I was at AGDC last month and many, many folks are looking for real, dedicated audio programmers. So if you are one, or want to be one -- you seem to be in demand!)

Sometimes, your audio designer may request something that doesn't even make sense to you why it would be useful. Try to trust them if possible -- they usually know what they are talking about. :) Granted, they should also listen to you as you know what the game engine limitations are, etc.

What went wrong

1) Polyphony! Polyphony! Polyphony! This was easily the most frustrating part of this project. This game features a lot of projectiles and all of these projectiles have sounds attached to them. At a certain point (of which we could only estimate, but not pin down) Unity would cap the polyphony and sounds simply would drop out -- offering an extremely awkward playing experience. Several strategies had to then be utilized to try to minimize this having to do with firing behaviors of towers, when certain orc damage (i.e. "ugh!") sounds would be heard and so on. Additionally, several sounds needed to be retooled to be shorter so as to free up as many resources as fast as we could to make the game run smoothly. Finally, some sounds did need to go unused to simply keep the numbers down.

2) Lack of studio-side development license Because I don't own Unity3D, every time I made a change, I needed to wait for Jon to build a version with my new sounds in it so that I could hear the end product. This was tedious at best for Jon and for me. Additionally, apparently version control is difficult with Unity, making it difficult to keep a synced source even if I had a copy of Unity.

3) Variations In all sound design projects, you want to avoid what is known in the trade as the "machine gun effect". This refers to two audio samples being rapidly repeated and sounding too much alike so as to distort whatever their actual source content is, and if played fast enough, everything sounds eventually like a "machine gun". Clearly, not what you want in a game where there is supposed to be towers of arrows firing!

To avoid this, you *could* produce lots of alternate sources, which is a good idea, in general. However, for us, we wanted to keep the file size as small as possible, so that wasn't much of an option. The other thing you can do is use some random pitch shifting. Not a lot, but even a little will make thing sound different, yet the same, and will avoid the machine gun effect.

Try this: clap your hands several times. Listen closely and you'll notice that the apparent pitch changes slightly. This is essentially the same thing that is accomplished. If you just recorded one hand clap and played it back instead of multiple ones, you would understand the machine gun problem. This often, in games comes up with things like footsteps and other repetitive actions that often go overlooked.

Fortunately, Unity, like most other modern game engines, have this variation function built into them, so with a little tweaking of parameters, we found a setting that worked and used them on many of the repetitive sounds to make it seem like there are more sound than there are.

----

All in all, it was a great project and I hope you check it out.

Cheers!

-John
Composer/Sound Designer
www.seguinsound.com