I realized that I was doing that thing that I always do, which is spend an hour writing different titles for my blog, fantasize about the content, try to define the blog and what its importance was, and not get anywhere. This is one of my curses when it comes to blogging. And it’s silly. So, now I’m just gonna write this thing. Screw it! I’m writing it! And it just going to be a big jumbled blog about all that stuff.

The Volition Audio Hiring Process

I think it all really started with Anne. Anne is the project manager for audio at Volition. She’s an innovator. I’d like to think that I am, too, but I’d rather someone else say it about me than to say it about myself. “I’m an innovator!” Sure ya are, buddy (wink-mouthclick-point). At the very least, I am an early adopter. So, with Anne and I working in the same department, experimentation can sometimes be the path of least resistance. (wink-mouthclick-point-jump-heelclick-belch) I don’t know why I just wrote that.

Anyway, we decided to put the audio hiring process up for discussion and change.

We kept a central person to review all incoming applicants. That would be me. I’d scrap a bunch of incoming applicants because I could tell by reading the cover letter and resume that a person did not have the stuff. I will talk more about that later. If someone piqued my interest, I would pass their cover letter, resume, and demo materials along to the rest of the audio team. I’d get feedback and then decide if we wanted to proceed with the candidate to the next step.

The next step would be some kind of test. Previously, we had sent out a written test that had a bunch of questions on it. Stuff like, what do you consider to be the three most important areas of sounds in an open world game? What do you think would be difficult about working on audio in an open world game? And if you had to design a beam weapon, how would you put it together both creatively and technically? And a bunch of other riddles and puzzles and noodle-ticklers that usually had no specific correct answer but plenty of potential incorrect or awkward answers.

We decided to kill the written test. We had all taken similar written tests and decided that they were annoying and time consuming. Additionally, those are the types of things that we discuss on a daily basis within the group. If someone in the Volition audio team were to say, “I’d design a beam weapon as 330 one-shot sound effects of varying lengths,” then one of us would say, “That seems like an odd approach,” while cleaning up all the barf. Also, we could ask questions like that over the phone or in person and it would allow for some back-and-forth.

Previously, if the applicant had gotten past the written test stage, they would go on to the video test. This is where we would send out a video capture of Red Faction: Guerrilla with the sound stripped out and would ask the applicant to replace the sounds with their own creations. This method is decent for exposing a candidate’s sound design skill. They would need to design some weapons, some impacts, a vehicle engine, ambience… it would give us back a pretty good variety of sounds that would be relevant to their jobs.

But there are some problems with that method. We do some linear work within the Volition audio team, but the vast majority of our work is non-linear. Also, it’s easy to get caught up in the little gotchas, like, did they get every footstep? Did they notice that piece of metal in the distance falling over? Did they notice that the player is low on health in this section? And if we weren’t really careful about it, we might be mentally dinging an otherwise awesome candidate because they missed that little visual cue, which again, would be something that could be addressed in a feedback session if they were working here. We also tended to get a lot of very similar results back. Also, it doesn’t really give the candidate much of a chance to show us if they can get a point across or tell a story with sound, although that was partly because of the footage we would send.

Byron had heard that some other companies were instead sending out a scenario that is written out in text. The candidate is asked to read the scenario and to then send back an audio file. That is, there is no video component to sync the audio to. There are some limitations, like how long they have to do it (two weeks) and the duration of the .wav file that they send back (60-120 seconds), but other than that, it’s really up to the candidate to tell the story with their sounds. Not only does the candidate have more creative liberty, but they also get to completely control the pacing. They can tell a better story this way. So we did it. After getting a couple of these tests back, we decided that we were able to tell a lot more about our candidates than what we were able to tell from the video method.

So, the new process to this point would be to look at the applicant’s materials that they’ve sent, then pass along the good ones to the team for discussion, and then to send out this new test. If we liked their test, we’d schedule a phone interview.

In the past, we had tried a couple different methods for the phone interview. The first method involved getting the entire audio team in a conference room and calling the poor applicant as a team. We would all go around the room asking questions off of a piece of paper. Lots of standard questions like, “Do you have any weaknesses? No? Okay, next question,” and, “What’s a game you think had cool sound? Saints Row? +10 points.” It was too rigid and it didn’t really give us a sense of who this person was.

So, the pendulum swung to the complete other side and we went paperless and very spontaneous. One might say unprepared. But we were all still in the conference room. Like seven or eight people asking all sorts of disconnected questions, like, “What kind of music do you listen to,” followed by, “How would you design a tool to implement ambience,” followed by, “What’s your favorite plug-in?” My opinion was that it was a complete mess, and although we sometimes would get a better sense of who this person was than with the worksheet full of standard interview questions, it was spotty at best.

This time around, the phone interview was two people. I was in all the phone interviews and we rotated the other members of the audio team. We would meet for 15 minutes before the phone interview and toss around a few questions that we’d like to ask. Usually we would each have around five questions that we wanted to ask, and the rest of the time was left open for banter and rambling. Banter and rambling actually means a lot to me. I want to know how this person banters and rambles. In the end, I’d say that it went the best that it has ever gone. There are probably ways to improve the process, but it worked out better than anything before.

At this point, after the application process, the test, and the phone interview, we had a pretty good sense of this person. There was just one last test to go. The on-site interview.

To me, the on-site interview has a primary purpose, which is that I want to see how well this person is going to fit in with the team. I already know that this person is qualified or they wouldn’t get to this point. So, for the on-site, I just want to be able to predict whether or not I want to work with this person day in and day out. But there are lots of other things that we can find out during the on-site.

When the candidate shows up for their on-site, the first thing we do is gather up the audio team and a few other relevant people and listen to the candidate’s test a couple times with the candidate in the room. Then we start the critique.

I find that it’s actually pretty tricky, because the candidate wouldn’t be sitting in a Volition conference room if their test was bad. My favorite question that I heard asked was, “If the tables were turned and you had to critique this test, what criticism would you have?” This was followed by, “Now respond to your own criticism.” We would also pick a section and say, “What would you do to make this section more realistic?” This would be followed by, “Okay, same section, but how would you make it funnier?”

The responses to the questions isn’t really the point to me, anyway. So, it doesn’t really matter what we criticize. We do this because we want to know how the person reacts to feedback. Do they get defensive? Do they struggle with coming up with new approaches? Do they clam up and seem defeated? I personally give the candidate lots of slack, too, since they’re in the hot seat for a job that they presumably want really badly.

After the critique, they get a little face time with me and our audio programmer and we tend to ask more technical questions. I want to get a better sense of whether this person has serious technical chops or if they are more of a content creator. Or maybe both.

This is followed by some show n’ tell of what we’re working on. We take them into one of our offices and just play the game. We talk about what we’re working on, what gets us excited about the project, we play the game in front of them, and we check out their reaction. We usually get some good questions from the candidate at this point in the process. The questions that they ask during the show n’ tell of the game give me an indication of where their head is at, what they’re most interested in, stuff like that.

Then it’s lunch with the audio team. Lunch is important. This is the first chance that we have to see how the candidate behaves with the audio team in a more social setting. We’re not in the office. We’re not sitting in front of a computer. We’re not grilling the person. We continue to ask questions, but they’re social ones. Anne likes to ask questions like, “What would you be leaving behind if you were to move here?” And I tend to ask stuff like, “What kind of music do you listen to?” More personal questions. It tells me a lot about the candidate. It’s also a chance to reset the candidate and get them ready for what’s coming next.

After lunch, we have an interview gauntlet. Three hours of interviews with people from the audio team as well as people from production, studio management, writing, design, and whoever else we think would be able to give us an interesting perspective on this person. This is probably the most stressful part of the on-site. After this, it’s usually around 4:30pm, and the candidate is probably like, “I need a drink.” Which is exactly what we do.

It was Anne’s idea and it has proved to be another great one. We have formalized drinks as the way that we end our on-site interview process. We promptly head out to a local bar and have beers for two hours. I find this to be the most interesting part of the on-site because once you get a beer or two into someone, especially after an extremely stressful day, they tend to open up. To me, this is an essential part of the interview process because we start to see who this person really is.

After that, they go home and we make a decision in the following days. If you’ve read this far, well, I’ve just barely gotten started! Sorry boutcha! I haven’t blogged in a couple months and I have all this crap rattling around in the ol’ fleshy hat rack.

What It Takes To Work With Us

If you’re applying to join Team Audio at Volition, your odds of actually joining us are very low. It doesn’t matter if you’re straight out of school or if you’ve been in the industry for 20 years, the odds are still very low. It doesn’t matter if you’ve never worked on a game before or if you have 20 games under your belt. Still low.

For this round of hiring, we had 64 applicants that made it through HR and landed on the network for me to check out. That’s the lowest that I’ve seen since I’ve been here, and it’s probably because we didn’t post the job to Gamasutra or other job sites. Typically we have well over 100, but for what I’m about to say, let’s go with 64. Out of these 64, we had on-sites for three of them. Of those three, we hired two. So, purely looking at the numbers, without taking anything else into account, if you applied, you had around a 4% chance of getting an on-site interview, and around a 3% chance of getting hired. So, I would call that a pretty small chance. I’m assuming that I did the math right, there. I think I did.

I want to add that the people that we hired didn’t really have experience as in-house game audio designers. We were able to hire senior guys if we wanted to, but we didn’t. And I also want to add that we had senior candidates apply. Lots of them. Full on industry vets that were more than qualified for the job requirements that we posted. But we went with guys that had way less comparable experience. And I’ll also mention that we had that same criteria of experience and shipped titles on our job listing. So, why would we hire guys that didn’t have a ton of experience?

It’s because that stuff isn’t all that matters to us. And I think it matters a lot less to people like me who are in the position to hire other people than many might think. In fact, if you’re out there publicly complaining about the catch-22 of needing experience before getting an entry level job, I think you’re looking at it from the wrong angle. Also, I might see you doing that, and as someone who gives people a chance, that might annoy me. Just sayin’! And believe me, I understand how you could see things this way. I was in your shoes not too long ago. I remember sending my resume and demo materials to over 100 developers before Volition saw my potential and hired me. And I had experience and titles! And even then, they didn’t really know what I was capable of until I had been working there for a while.

And that’s kinda the point. We can research you and check out your previous projects and watch your demo and talk to you on the phone and even meet you in person at the on-site and we really don’t know what we’re getting until you’ve been working here for a while. And I realize this. I’d like to think that most people in my position realize this. Which is why many of us are looking for something that can’t really be articulated very easily. Yes, we want to see an awesome demo reel. Yep, it would be great if you’ve got some experience. But there are things that mean way more to me than that stuff. I’m going to give you three things that I think are more important than all that other stuff.

First of all, I want to see that you have a purpose for wanting this job. Not what you’re doing (e.g. your resume and demo). Not how you’re doing it (e.g. your web site or blogs that show how you do what you do). But why you’re doing it. That’s tougher to show me. I realize this. But people have managed to do it. It’s in the tone of your presence on the Internet and in person. It’s written between the lines in the e-mails that you send me. It’s hidden in something you wrote on Twitter or on a comment on a Gamasutra article. It’s the sound of your voice and the look in your eyes when we’re talking in person. And if you’re starting to think this is unfair because it requires you to be active in some community that I’m a part of, then there’s one glorious place where you’re assured that I will see it no matter what. That is your cover letter. You should see the look on peoples’ faces when I tell them that I often get more out of a cover letter than a resume or a demo. But sometimes I do. That’s your shot at showing me that you have a purpose.

Secondly, I want to see the potential for growth. It doesn’t matter if you’ve been around the block, either. There are as many titans of the game audio industry as there are newbies who realize that this field changes so quickly that you still need to be able to grow and change. If you think you have figured this whole game audio thing out, well, there might still be somewhere out there for you, but it’s not Team Audio at Volition. I see this as going hand-in-hand with some other important qualities, like humility, a good sense of humor about yourself and your work, and the ability to take feedback. I wrap it all up in this thing that I call potential for growth.

And thirdly, I want to see that there’s more to you than audio. Team Audio at Volition tries to look at each other as complete human beings. We can all design and implement audio. But that’s not all there is to it, not by a long shot. There’s so much more to being part of this game development team than being a good audio designer or than knowing how to make things sound right in Wwise. Maybe you have some game design sensibilities. Maybe you’re able to make people laugh. Maybe you play an instrument. Maybe you know how to read a schematic. Maybe you’re good at making a point. Maybe you’re a futurist. Maybe you like to take random online classes. Maybe you like to put together puzzles. It doesn’t matter. I’m not just trying to look at you as an audio designer, I’m trying to look at you as a complete human being. The bigger picture I can see, the most interested I may become.

One Swallow Does Not A Summer Make

After looking at so many audio applicants since being at Volition, even the most recent time, when there is more information about what it takes to get an in-house audio job out there than ever before, it has become apparent that some people still don’t understand the breadth of knowledge and skill that it takes to get an in-house audio gig at Volition.

I see a lot of applicants applying who have experience in some form of broadcast media. This is relevant, don’t get me wrong. There are things that you could learn at these places that might give you some skills that would apply to the work that we do. But if this is all you got, then it’s probable that you will be outgunned even for an entry level position.

I see a lot of applicants applying who emphasize that they are musicians or composers. This is also relevant. But if that’s all you got, you’ll be outgunned.

I see a lot of applicants coming from advertising. Again, relevant. All you got? Outgunned.

Lots of applicants coming from good schools. That’s it? Outgunned.

Theater audio? Outgunned.

Live sound? Outgunned.

Worked on a mod? Outgunned.

Helped engineer at a recording studio? Outgunned.

VO recording and editorial? Outgunned.

However, if you’ve done several of these things… I’m interested. You may or may not have noticed that this person hasn’t shipped a game or held an in-house audio position at a game developer. But what this person at least appears to have done is, well, a lot. They’ve done a lot. Even though they haven’t shipped a game, they’re interesting to me. If their cover letter and demo is good, they’re on the path to an interview. People like this definitely exist and they’re itching to get into game audio.

Now, if someone has shipped a game or two, has a solid demo reel, has some knowledge of how audio works in games, and also has a good cover letter and resume, they are definitely going to give this other person a run for their money. But that doesn’t automatically mean that they’ll get the job. If you read everything else I wrote above, there’s a lot of stuff that means a lot to me other than what someone has done in their past.

The reason I started this section with one swallow does not a summer make is because there are people out there who have dedicated huge amounts of effort to getting a job in game audio. Huge amounts of effort. Can’t understate that. That’s what it takes. And like I said earlier, if you’ve got other skills that make you valuable, like knowing how to script, or knowing how to solve complex problems, or knowing how to build a synthesizer, or knowing how memory and streaming work, or knowing how to build a level in Hammer, or know how to recount something that happened to you in a compelling way, well, that is awesome, because that sounds like someone I might want to work with.

So, be honest about where you’re at and try to keep things in perspective. If you’ve applied to 100 game audio jobs and haven’t found one yet, take some time to think critically about yourself and what you bring to the table. Think about what you could do, what you could learn, who you could learn from, what it might take to make you someone that a company must hire. Then go do that stuff. There are a lot of people out there already doing it. But don’t let that discourage you. None of them are you and they can never be you.

Jerk Move, Potential Employer. Jerk Move.

Okay, this is the last thing I want to write about.

Why are developers being so jerky to their applicants. Do these people not realize or remember what it’s like to be an applicant?

My friend Dave Samuel, a kick ass VFX artist, put it this way, and I’ll never forget. When you’re applying for jobs, a minute is like an hour, an hour is like a day, a day is like a week, a week is like a month, and a month is like ten years. These people are in agony, waiting with baited breath to hear back from you. It’s way better to get a rejection quickly than to be strung along for who-knows-how-long. Stringing people along is lame. I’m guilty of it, too. Nobody’s perfect. But I’m trying to get better. Try to tell your applicants how long it’s really going to take to get them moving to the next step.

If you’re rejecting someone, you can leave the door open. Sometimes your rejection letters can make people think that they will never have another shot at working there again. If that’s the case, well, okay then, I guess. But is it the case? Not as far as I’m concerned. The door is always open to reapply. The door is always open to talk to me. Even after I’ve rejected you. In fact, if I reject someone and they keep in touch, I see that as a good thing. It seems like a mature and smart thing to do.

Also, give you applicants your direct work e-mail address if you can. If you can’t give them that for some dumb reason, give them your home e-mail. Let them contact you. Encourage them to stay in touch. Build that relationship. It might turn into something amazing. Don’t screw up HR, talk to your HR department about it first, but probably you can keep in touch with these people.

Before you hang up the phone from the phone interview, or after the on-site interview, tell the applicants that they should not hesitate to contact you if they want an update or for any reason. Remember, they’re going to be biting their fingernails off and dreaming about your response. They probably have diarrhea from all the stress. Even if they know first hand that this process can take a really long time, it doesn’t make it any less nerve wracking. There’s no reason to leave these people thinking that they’ll botch everything if they ask you what’s going on or if there’s any news. And if they do ask you for an update, be straight up with them. It’s okay to say that there are other applicants and that you can’t decide yet, or that the team has been too busy to make a decision, although if that’s the case, then that’s kind of annoying and you should probably consider addressing that.

Just remember that you’re dealing with a human being. Someone who you could potentially be working with, or someday this person might be looking at your application. Who knows? There are all the reasons in the world to treat these people like you’d like to be treated. If you have the power to make or break someone’s dreams, then wield that power like a kind and honorable king. I believe it’s the right thing to do.

The End

Alright, that’s a bunch of stuff. I feel like I’ve said my piece a few times over. If you actually read all of this, you should leave a comment or send me an e-mail or something. I’m impressed that you, or anyone, would read these ramblings. And that’s just what these are. Ramblings. Try not to take them too seriously. I’m just some schmuck.

On that note, I’d also like to point out that these are my opinions and mine alone. These opinions do not reflect Volition’s official positions, or the Volition audio team’s official positions, or THQ’s official positions, or the FLOTUS’s official opinions, or any other silly ideas that you might get in your head. Honestly they probably won’t even reflect my own opinions in a few months.

Also: no bologna this time. Sorry. Except for that one that I just wrote. And this one: bologna.

I found him hiding behind a giant leaf, wearing a giant leaf. He was pressing binoculars against his eyes, gazing towards a nearby algae-covered pool. I crouched next to him and started asking him questions.

Ariel Gross: So, Damian, what is it that you do? Aside from questing after fabled beasts of yore?

Damian Kastbauer: I’m a technical designer for games, which is a somewhat nebulous term. It’s defined pretty well by Rob Bridgett in this article. Essentially, I try to serve as a bridge between sound content and programming/engine-side integration in order to create systems for sound playback, or just plain getting sounds in the game working and sounding right.

AG: Nice. My opinion is that sound design in games is only as good as its implementation. What do you think about that?

DK: It’s often said that the best sound can end up sounding bad if it’s not implemented properly, so, a lot of the time I’m trying to let the sound do its thang… which is not always easy. Since I don’t create content, and I’m not a programmer by definition, I usually spend a lot of time either building tools, streamlining pipelines, and strategizing audio features with the help of the programming team or working with audio middleware tools to similarly create the smoothest integration possible.

Damian finally released the binoculars, which then fell and dangled around his neck, but kept his hands in place, and continued to look off towards the pool with his hand-noculars. It was an interesting technique that I had never seen used in the field before. He made a refocusing gesture and continued to peer out through his hand holes.

AG: So… do you find yourself being a middle man between Team Audio and Team Programming? That could be challenging, what with all the unrequited love and/or red-hot rage between those two disciplines.

DK: Definitely, I’m helping to bridge the gap between the two worlds. Whenever possible, I like to enable content designers to just “design in the box” all day from the DAW without having to worry about the sometimes-labyrinthine pipeline to get sound into the game. In this way, they can focus on what they’re really into and I can go to town with making sure it all works within the context of the game. It’s a balance that requires human interaction, but I’m pretty keep on that as well.

AG: Wow, you just said labyrinthine. I’m golf clapping right now. In my head. And in my heart. I don’t want to scare off the paisley hippo. You’re welcome. So, have you found any common issues between Team Audio and Team Programming among multiple developers, and do you take measures to help both sides see eye to eye?

DK: I think one of the missing or underdeveloped pieces of some studios is the direct communication between Team Audio and the rest of the teams. It’s common for audio to touch almost every corner of the pipeline and development process.

With Team Audio often sequestered within a sound-proof cave deep within the bowels of a studio, it can be hard to get the kind of happy accident or magic moment that can come from being out in the pit or lined up in a hallway.

AG: This is painfully true.

DK: One of the things that has always seemed right about my involvement with different game studios on-site is the necessity of being “on the floor” with the other disciplines… which has always been a positive in bridging that gap.

When I work remotely, I put a tremendous amount of effort into achieving a high level of communication between the different teams on a project. Whether it’s e-mail, IM, Skype, or occasion on-site visits during development, the communication between people is among the most important aspects of working on a project.

If I am outside the fence, having an on-site advocate for audio is a definite plus, and in most cases, it is key to making my role as a facilitator for sound actually happen.

Some foliage near the murky pool began to shake. Damian dropped his hand-noculars and placed one hand over his mouth to ensure complete silence. He placed his other hand over my mouth, too. I resisted the urge to lick his hand. A rabbit bounced from the foliage. We both sighed deeply.

AG: Miv viff fuhm coffm prbflrm…

Damian removed his hand from my mouth.

AG: Is this a common problem at studios you’ve worked with? That Team Audio doesn’t pop their heads up through the manhole enough to be part of the greater discussion?

DK: Whew, well, I think that as a matter of course it is hard to have visibility across the team in the same way as being out in an open floor plan, when part of your daily work requires you to be locked away in a padded room.

That is, people can’t SEE you and demand your attention by rolling up to your workstation. I mean, there’s a door… you have to turn the knob… like, maybe even knock… and then get blasted in the face by high decibel explosions in order to interface. We know how averse most people are to moving in the first place, let alone opening a door.

I chuckled.

DK: A little dry, mid-west sarcasm for you.

I chuckled more, leading to a whole-body belly laugh, leading to a maniacal, snorting cackle, ending finally with a very feminine giggle. Then we sat motionless for what felt like an eternity.

AG: Sorry. What you say is completely true. Before tracking you down in the Congo, I hadn’t left my seat in four years. Not even to use the restroom. I held it. What you saw at the GDC was my hologram. A hologram with mass. I digress. What is the number one reason why a studio hires a technical sound designer?

DK: The number one reason I am hired is to help ship games. Having shipped my fair share, I would like to say that I know all the tricks in the book, but this is absolutely not true.

What I hope that I bring to a project is an ability to work together with people to get things done, through thick and thin, regardless of the task at hand.

Sometimes I don’t even know what I’m going to be doing until I get involved and assess the situation… this can be true of the studios as well. They’re not sure what exactly needs to be done, but they need someone to help pull it off in the eleventh hour.

AG: You’re basically a hero that is brought in to save the day.

DK: If I can come in and take the burden off of content designers, help design complex playback systems for physics or procedural animations, help wrangle memory budgets or streaming look-ahead times, then that is one less thing for someone, who already has too much on their plate, to worry about.

For remote work, it can be at any time during the project, I work from the home studio connected to a VPN using source control while making local builds from day one.

When I do work on-site for an extended period of time, it’s usually toward the end of a project for a few months.

At this moment, the waters of the pool began to ripple as a large, paisley-patterned mound broke the surface of the water. Then, two paisley ears emerged, followed by blinking eyes. Damian fidgeted with excitement, but stayed put.

AG: You mentioned memory and streaming.  This is something that some people don’t realize. Someone on Team Audio is usually tasked with wrangling memory budgets and streaming bandwidth. It’s really techy work.

This isn’t always expertise that is considered when hiring an audio designer. I’ve found that studios tend to focus more on whether or not an applicant can make rad sounds, with less emphasis on the technical side of things.

There’s usually some requirement that says, “familiarity with middleware tools and implementation,” but I get the sense that the weighting at most companies is 80% creative aptitude and 20% technical prowess. Does that seem accurate to you? Or am I totally wrong? And ugly looking?

DK: I think there are a majority of people who come to studios with a sound design background. Until recently, it has been almost non-existent to have someone come out of school with an education in the technical side of game audio.

It used to be that “audio implementer” was the job that someone new to the industry would take on their way to becoming a sound designer… or even a musician or composer for games… that was really the only way to learn the ropes.

When I got into games, it was clear to me that the technical side was the only thing that I wanted to do. Thankfully, in the past few years, it has become a niche that has benefited from a group of people whose interests are purely in the technical, which has helped to establish legitimacy for the specialization.

AG: We used an in-game editor to place ambient audio emitters on Saints Row 2. Sometimes the frame rate would tank while I was moving an ambient emitter around, and I’d fling the emitter object 100 miles away, sometimes into a different game entirely. I think a few of those emitters landed in Red Faction: Guerrilla.

DK: Hahaha… user interface physics lerping… TOOLS!

AG: Do you ever find yourself caught up in the mystery of missing sounds? Like, the audio team is sure that a sound should be playing, but it’s not. Is that something you run into a lot?

DK: Totally! Someone did a model swap but forgot to bring the audio hooks with it, or moved the entire level geometry across the level away from the audio emitters that were placed on a different layer in the editor… happens ALL the time, and the resources to figure it out are sometimes underestimated.

With all the different ways that people can approach game audio these days: mods, Unity, UDK, FMOD, Wwise, SDK documents, Max/MSP or pd, it’s becoming common to have fresh faces joining the team who already have a good handle on the tasks at hand and are ready for the challenge.

The fabled paisley beast began to slowly emerge from the algae-covered pool. Watching the water cascade off of it’s psychedelic hide was glorious. Swirls of color and waves of sweet smells washed over me. Granted, I had also been munching on some random red berries that I’d found on the ground.

AG: I know plenty of sound designers that don’t want to do the implementation. They look at it as a boring chore. A chore-bore. A borch. Anyway, I could see some Team Audios out there wanting to hire you on full time. Do you ever get this? Have you considered an in-house gig?

DK: I’ve worked remotely on a couple of projects for a longer duration (1-2 years) serving as a conduit for getting content in the game. I’ve worked a ton with Bay Area Sound as an outsource audio solution involving their audio and music content creation in conjunction with my management of the technical side in what has been a perfect solution for smaller developers and teams that need supplemental assistance.

I worked for five years in this capacity on the games for Telltale. I integrated content provided by Bay Area Sound and Harmony Machine into The Saboteur from Pandemic Studios for about a year to help augment their in-house audio team, which included building vehicle systems in Wwise to work with the simulation team who was responsible for the cars driving around in the open world.

Most recently I’ve been working again with Bay Area Sound to integrate content and tool the pipeline for a couple of MMOs using the Hero Engine in conjunction with FMOD.

AG: How about documentation? I have seen with mine own eyes the lack of documentation out there. Do you find yourself having to trudge through undocumented systems a lot? Do you end up documenting them yourself as part of your services?

DK: Documentation is always a tricky one. A lot of developers who have been iterating on in-house engines and tool sets carry with them a ton of institutional knowledge… usually within their brains. There’s usually a pretty intense time of education at the beginning of the project where I do my best to document… for my own sanity as well as anyone who might find themselves in a similar position in the future.

I recently worked with a company and provided an evaluation of their audio middleware integration in addition to recommendations for how to move forward with some key changes. In that case, it was documentation and justification for the different recommendations, as well as education in order to get everyone thinking about the possibilities.

AG: Do you find that most companies that you work with have an audio programmer on stand-by to compliment you? Compliment both in terms of assisting you in a complimentary fashion, and also to tell you that your shirt looks very nice tucked in.

DK: It’s definitely becoming more common for developers to recognize the need for audio programming support throughout the project. While I think it’s becoming, I think there is still a false expectation that you can just throw on the UI programmer for a couple of months and sew everything up.

The need for dedicated audio programmers is definitely growing as we continue to scale in meeting the demands in quality during the current generation.

So, I guess, having an audio programmer is necessary to compliment the technical side of sound design, especially a dedicated professional who is invested in sound. Their ability to bring not just programming, but a knowledge of audio to the table can only mean an increase in the quality of the audio and the quality of life for Team Audio.

That, and yeah… someone to tell me when my dashiki doesn’t match my socks.

AG: Last question, and then you can get back to your quest. What do you think will change from a tech audio standpoint with the next generation of consoles?

DK: I think the industry at large will further close the gap between pre-rendered and in-engine… across all disciplines, a continuation to move forward into real-time.

What this means for audio is building on the sample-based methodology that has firmly taken root in the current generation while using more procedural audio, synthesis, and DSP to modify or accent sample-based content dynamically at runtime.

Additionally, increased transparency and better communication in both directions between the game audio and audio engines will develop, which will in turn necessitate a further push towards enabling this functionality within usable tool sets. This accessibility will reach into every corner of the audio production pipeline, simultaneously exposing the technology while making it easier to adapt it to the interactive needs of the game.

Hopefully the new consoles will also make espresso.

AG: Espresso feature would be cool. I’m hoping that someday I can feed a slice of bologna directly into the console. It would recognize the meat as bologna and procedurally create a game called Bologna Quest, where a young adventurer named Ariel, clad in the finest bologna armour, would climb the mountain of… Damian?

Damian, recognizing that I had started my typical bologna-related sign-off, was already planting a kiss upon the lips of the sleeping paisley hippopotamus. Then, a flash of light, and they both vanished, never to be seen again.

Players have all kinds of crazy crap.

When it comes to audio, players be crazy. Not meant as a dis. Just an observation. One person might have a high fidelity 7.1 surround sound system with discrete speakers placed perfectly according to THX standards. The next person might have the same system, but all of the speakers are stacked on top of each other like a tower in the center of their room. And the next person is listening through their old CRT television’s stock speakers. And the next guy is listening on amazing headphones. And the next person is listening on earbuds that they got from a plastic egg after depositing a nickel in one of those vending machines.

We never really know what the heck our player is doing when it comes to their sound system setup. The Volition offices are a microcosm of this. Some people here use professional speakers (Team Audio). Some people use headphones (Team Design). Some people use cheap PC speakers (Team Production). Some people use earbuds (Team We Hate Team Audio).

Again, not meant as a dis. All of these are, of course, perfectly fine means of getting sounds into ears. However, some issues can crop up as a result.

“I can’t hear Sound X. Turn it up.”

Story time! Also, disclaimer time! This is a dramatization. This didn’t happen here at Volition. But I know it has happened elsewhere, and it’s not some isolated incident. Team Audios world-wide will be more than happy to regale you with some variation of this story while sullenly drinking their whiskey and/or pink-colored bismuth.

Once upon a time there was an Audio Designer. Our dear Audio Designer had made Sound X and had implemented it into the game. Audio Designer was happy.

Two weeks later, Audio Designer is called over to Project Producer’s desk. Audio Designer was scared. Nervous. Vulnerable. Naked. Okay, not naked. No, you know what? Naked. May as well make this story extra weird.

Project Producer was frustrated because they could not hear Sound X very well, and demonstrated this through their cheap PC speakers. Naked Audio Designer responded that the reason that Sound X couldn’t be heard very well was because of the crappy sound system that Project Producer was using.

Project Producer frowned. Project Producer rebutted that perhaps Naked Audio Designer shouldn’t be testing sounds on top tier studio speakers and should instead be testing sounds on crappy PC speakers, or television speakers. And why wasn’t Naked Audio Designer wearing clothes? Well, that’s another story altogether, isn’t it? It is.

Well, Naked Audio Designer immediately went home and wept for two weeks in their crawl space and forgot to drink any water, and therefore died, and was of course eaten by rats.

So, why don’t we just test on TV speakers?

I find that the easiest way to answer that question is to refer to our dear friends in Team Art. While it’s possible that Team Art might have to use whatever monitor is in front of them, they tend to want to work on the highest possible quality, perfectly color calibrated monitor. When they work on these monitors, they can assume that the visual quality will be maintained to all the different types of screens.

We’re in a similar situation in audio. We do our work using high end studio speakers (usually called reference monitors, but I tend to use the word speaker to avoid confusion), sometimes with especially flat frequency responses (meaning the speaker itself isn’t changing the sound), and usually in calibrated listening spaces, because that way it should translate better to all the different kinds of speakers that our players have.

If a colleague from production or studio management wants your Team Audio to work with low quality speakers because that’s what most players will be using, point to this article if you want. Maybe then you’ll be able to scam them into getting you nice equipment. Wait, did I just ruin that strategy? Maybe I did. But I’m too lazy to go back and change the word scam to convince. Moving on.

But testing on TVs… that just seems smart.

You make a good point, Blog Heading.

Testing on TVs still seems like a good idea. I’m not trying to make a case against testing your mix on a ridiculously wide range of audio systems. You should probably still do that. And you should still test your game audio on a system that you’re most familiar with. Test it on the system that you play games on. Then capture some audio from your game, burn it to a disc, and listen to it in your car. Test it in the conference room where you do your show n’ tells. Test it on the Jumbotron in your living room. What, doesn’t everyone have a Jumbotron in their living room? Well, then do your best with what you have, I guess.

In my experience, the most important thing to test on a wider variety of sound systems is your mix. If you are struggling to hear the dialogue in your game on your television where you play most of your games, then that’s something that might be worth looking into. Does the music seem too loud when you listen on the headphones you’re most used to? Data point added! Just be careful. If you’re doing a final mix of the game, then you’re probably pretty close to submission. Choose your battles wisely!

Another trend in audio is to give our players a bunch of audio options. We give them discrete volume options to adjust sound, music, and voice, sometimes even more granular than that. We also occasionally give them overarching presets like Hi-Fi, Television, Headphones, etc, which can do things like control how much compression there is on the master mix or on sub-mixes, among other wizardry. This is awesome, but if we’re being thorough, it can put an increased burden on the audio team as well as audio QA.

No time. Who care about most?

Wow, Blog Heading, the way you wrote yourself is really convincing. You even deliberately left out a couple of words. Nice work.

I think the question that the Blog Heading is trying to ask is, when we’re low on time, which is typical in audio land, then who should we be designing audio for? Should it be for the player with the kick ass high end sound system? Or the player with the crappy earbuds?

Your team may have varying opinions on this. Some people or disciplines will suggest that you need to appease the lowest common denominator. Like when you make your PC game playable on an 80486SX, even though you may need to wait two years to play the same game on max settings. So, if that’s the case, then we need to design for earbuds gamer. Or at least crappy Labtec PC speakers gamer.

Well, my current opinion is the opposite. Go for the gamer with the higher end sound system. Why? That gamer probably gives a crap about the sound in the game.

I know, earbuds gamer might care, too. Maybe earbuds gamer just isn’t able to afford a nice sound system. Well, that’s okay, because fortunately for earbuds gamer, we always do our best to accommodate everyone, right? Right!

But the gamer with the higher end sound system is basically begging you to put that system to good use. Higher end sound system gamer probably wants you to do some serious face melting. Why else would they spend all that money? They probably want an aural experience more similar to the (good sounding) movie theaters.

This might be kind of controversial. I don’t really know. I haven’t tested the waters on this one, yet. I guess I should say that this is only my personal opinion, not that of any company that I work for, and it’s just an opinion, and I’m just a dude whose opinion changes, like, all the time. I’m not running for president, here. And if I was, I’d probably make a law that proclaims bologna as the official meat AND undergarment material of the country. Does the president make laws? I can’t remember, but I don’t think so. I think it’s congress, actually. Anyway, just remember, a vote for me is a vote for bologna.

I had recently hooked Jason up with a little Behringer mixer and some spare M-Audio BX5a speakers. He immediately transformed into the Maxell guy. The one sitting in the chair. Google it. He felt my pain. He had been experiencing the sound in our games in a way that transcended his previous Labtec lifestyle, and he yearned for others to share in that experience.

So, we decided to buy all the designers headphones. Nothing too fancy, just some reliable, closed-ear Sennheiser headphones. There are a lot of designers at Volition, so it wasn’t going to be cheap no matter which way we sliced it. It turned out that it was easy to justify, though. How?

Story time! This is a dramatization, this did not really happen, but it could. It totally could.

It’s down to the eleventh hour. Only two months before submission. An overworked system design hero is hunched over his computer, the outline of his spine practically ripping through the back of his shirt. A bare light bulb dangles over his head, the hot, oppressive light illuminating the beads of sweat on his scalp. A cigarette dangles loosely from his lips as his fingers punch his keyboard to tweak the handling of a motorcycle for the fiftieth time that day. CLAKKETY-CLAK CLICK CLICKETY CLACK. He threads his hands between his glasses and his eyes and grinds more sweat into his corneas. He is numb to the sting. He’s done. It’s time to test. He runs the game, hops on the motorcycle and drives. He drives and drives, far away from this place. He is happy. He checks in his work and falls asleep in his chair, snoring loudly for three hours before he has to wake up again.

Next day, it’s time for a multi-discipline group review of vehicles! Yay! Even the producer is there! Team Audio bounces on their tails into the conference room. One audio hero is particularly excited to hear his new motorcycle audio in action. He had spent a good five hours last week making sure that all the loops were smooth and that each gear sounded more aggressive than the last. He was proud of it. The game is loaded up. The motorcycle is mounted. And then BARRFFFFFF. It sounds awful! It doesn’t sound anything like it did last week. Producer mad! PRODUCER MAD!!! RUN FOR YOUR LIVES. Producer chases audio designer around the building with a chainsaw to the theme from Benny Hill.

So, what happened? I’ll tell you what happened. Vehicle designer changed the handling of the motorcycle but didn’t listen to hear how the handling totally botched the audio, and then he checked it in.

Now, to be fair, audio hero screwed up, too, so to any design heroes reading this, I’m not trying to pick on you. A smart audio hero knows better than to spend five hours tweaking vehicle engine audio when the handling isn’t finished. That’s why I chose this dramatization. Besides, the only thing that’s even remotely realistic in this dramatization is the behavior of the producer. I’m kidding! (I’m not kidding).

So, we bought all the designers headphones. And we didn’t just buy headphones and throw them at the designers’ desks and swagger off, either. I sent numerous messages to the entire design team offering my personal assistance in hooking things up however they wanted. Want to be able to switch between listening to the game and listening to your PC with one convenient swap of a cable without crawling under your desk? I can do that for you. Want to be able to listen to Hey Ash, Watcha Playin’ on your PC and listen to the game at the same time? I gotcha covered. Want to listen to your PC, PS3, 360, PSP, and iPad at the same time? Okay, that’s annoying. Not doing it… Oh, alright, I’ll hook you up.

I’m not going to lie. It’s not like every single designer is listening to the game at all times. That would be amazing, but it would probably drive them insane, especially since audio tends to be in this weird, ramshackle state until about three days after release to manufacturing. And just buying headphones for designers doesn’t replace relentless communication and real rapport. But it helped. It really did. Designers were coming to us with audio issues before the group playtests, and we were able to fix those issues before the producer had even finished marinating his garotte in botulinum toxin.

All we had to do was describe a handful of these scenarios while groveling obsequiously at the feet of our finance hero and boom, headphones for all.

So, to all the Team Audios out there, if you find yourself in a situation where nobody is listening to the game, take some time to make your case to your buddies in studio management and finance. Ask to earmark a little bit of money for some listening pleasure for your colleagues. If you can’t afford it, at the very least you can spend some time informing and educating your colleagues from the other disciplines about how their changes can affect your work. Work with them to coordinate your changes in a way that makes sense. Invite them into your world. Because in the end, it could mean saving a life. I’m looking at you, producers. Wait, who, me? No, no, I wasn’t looking at you. I was, uhm, I was admiring your coffee cup. <nervous whistle>

I’m not saying we’re the only ones, by the way. I can feel something by looking at a painting. I saw a painting by Delecroix once that chilled me to the bone. And a majestic sunset doesn’t need sounds to make me feel something, but I will say that adding a soft “I love you” in my ear to that sunset will turn my legs into cooked spaghetti. I also don’t need the sound on to feel the exhilaration of speeding down an alley in a muscle car, but when I hear the engine tearing the air around me to shreds, I’m probably gonna crap my pants. Emotionally, that is. An emotional pant-crapping.

Anyway, I fully acknowledge that when we work together across all disciplines, that’s when the magic happens.

Team Audios out there, we are emotion designers, and we can sing this glorious news to everyone. Fortunately, a lot of our colleagues recognize this already and want to exploit it, which takes some of the work off our own shoulders. These are the people that involve us early to talk to us about pacing and tone and emotion. They want to hear what we’re working on, and they provide feedback about how the sounds and music make them feel.

And then there are the ones that haven’t put their finger on it, or they might be completely oblivious to the idea. They’re not bad people, though. Just like people who don’t listen to music a lot aren’t bad people. They’re not! Most of the time these people just need to hear it said plainly, “we’re emotion designers,” and then they have a catharsis, and you have to hold them for hours and hours while they blabber through their tears and snot.

I’m sure there are also those crusty audio vets out there, the ones that have allowed the relentless onslaught of late timing changes and object impacts and mouth noises harden their hearts, and when they read this their smirks become just a little more permanent, and I’m at peace with that. It’s easy to get caught up in the grind, or to be so far from creative sound design on a daily basis that it’s painful. I know what that feels like, and some people let it get the best of them, but I’m trying to stay soft and to remind myself why I care about sound and why I’ve devoted so much of my life towards this line of work. It’s because I like to feel things when playing games, and I like to make other people feel things when they’re playing.

So, I’m just going to keep reminding people that Team Audio is here to make the player feel something, and that we’re good at it, and that we want to talk about it. I’m going to say it to everyone, even strangers walking down the street. I’m going to grab them by their lapels and get two inches from their faces and mutter under my breath, “we are emotion designers.” Because even though we have tons of assets to churn through and meetings to attend and e-mails to read and bugs to fix, I think we should strive to keep our heads above the muck and remember that we have the opportunity to give someone a feeling that can stick with them after they’ve turned off the game. And that’s amazing.

What does this have to do with game development?

I have noticed certainty creeping into our discussions as game developers. This tends to frustrate me at some level, sometimes obviously, and sometimes subconsciously. Certainty can stunt growth and kill new ideas. If we become certain about something, then what can possibly change our minds? Maybe a catastrophe? Squashing certainty from the beginning seems like a better option, and applying E-Prime to the way that we communicate can help.

I believe that the application of E-Prime to our communications in game development has the ability to fundamentally change the way that we work together. It may seem subtle, and I have found it extremely challenging at times, but I’ve also noticed that using E-Prime has the potential to cause less conflict and increase collaboration. More collaboration can lead to more ideas and more innovation. I find myself hard pressed to think of an example where innovation caused a crappy consequence.

How does E-Prime work?

The Wikipedia page that I’ve linked above describes the rules for E-Prime. You might initially gasp at the list of words that you can’t use, but with a little bit of practice, you’ll probably surprise yourself at how it becomes more natural. I’ve found it helpful to see some practical examples, so I’ll give you a few right now.

Not using E-Prime:

“Combat is the most important aspect of our game, therefore we are going to be creating multiple tiers of combat based on distance to the enemy.”

Using E-Prime:

“We believe that our players will value combat above all else, therefore the current plan involves multiple tiers of combat based on distance to the enemy.”

Right out of the gate, I feel the difference between the two. Other may not, so I will break down what makes the feel so different to me.

The first statement declares with certainty that combat is the most important aspect of our game. The phrasing indicates this as an immutable fact. I don’t feel very inclined to propose an alternative. For example, while it seems obvious that players care about combat, perhaps some of our players may care more about the narrative.

By instead saying that we believe that our players will value combat above all else, we can establish a sense of probability instead of a sense of certainty.

The first statement also declares that we are going to be creating multiple tiers of combat. This sounds like a decision to me, like the future has a definite course that can’t change. This statement makes me feel like the gods have determined the future of our game and that I should fall in line and accept this decree without resistance. I might be exaggerating my feelings a bit to make a point here.

Saying instead that the current plan involves multiple tiers of combat creates a sense of malleability. It feels more like I still have a chance to propose new ideas, and that my new ideas may change the way that we approach combat. It feels more collaborative.

I’ll provide another example:

Not using E-Prime:

“You are not giving me the support that I need for this to be as awesome as possible.”

Using E-Prime:

“I need more support from you to make this as awesome as possible.”

The first statement feels very accusatory. It seems like it could accompany a finger pointed right at my face. I wouldn’t want this statement directed at me. It feels like an attack on my character. My natural response to this would probably include defensiveness and resentment, which could cause further arguing and maybe even escalation. Who wants that? I certainly don’t.

The second statement feels like a plea for help, or a request for more collaboration. It feels more like someone asking me for increased involvement. My natural response to this would probably involve asking what additional support I could give to make it more awesome, and I would probably feel inclined to provide more support, because I always want to help fully realize the potential of our games.

I’ll provide one final example.

Not using E-Prime:

“I know this tools is a piece of crap, but there isn’t time to change it.”

Using E-Prime:

“I know this tool needs improvement, but the improvements will have to wait until the next project.”

I’d probably feel disappointment after hearing either one. But I still feel a difference between the two.

The beginning of the first statement defines the tool as a piece of crap. That carries baggage with it. The second statement doesn’t define the tool as anything, but instead expresses an intention to improve it. It makes me think about the potential future of the tool instead of dwelling on my current issues with it. If I had created the tool, I would definitely prefer to hear the second statement. The first one feels like a devaluation of the previous work that went into it.

The latter half of the first statement makes it seem like nothing will ever change. The tool sucks and will always suck. It carries a defeatist tone because it doesn’t imply any possible changes for the better. The second statement might give a shred of hope to someone using the tool. That person using it may agree that the tool sucks now, but they may also infer that changes might make it better in the future.

Do you do this all the time?

I don’t do this all the time, but I try to. E-Prime lurks in the corners of my subconscious every time I write an e-mail, and even when I speak to my colleagues. I do occasionally correct myself mid-sentence to rephrase what I’ve said, which can make me sound like a stammering goofball or seem like I struggle with English for no good reason, but it has become easier as I continue to practice. One of my personal goals involves creating an environment in which people feel more collaborative, because I want to collaborate, and applying E-Prime to my communications seems to help.

At first glance, using E-Prime can seem too difficult to even try, but as an example, this article only took me about an hour to write and the whole thing uses E-Prime. Well, except for the examples, but those don’t count. It don’t think it took me much longer than if I hadn’t used E-Prime. So, I’d say give it a shot. Pay attention to the way that people respond to your newly phrased e-mails and see what comes of it. You may find that people suddenly seem more collaborative, and you may find yourself in fewer conflicts. Seems worth it to me.

The reason I’m phrasing the question this way is because I originally wanted to write up a blog that answers the question, “What is sound design?” But in brainstorming, I realized that it would probably end up being roughly 400 pages, and I don’t have time for that today, so I thought instead I’d ask an easier question. That is, what isn’t sound design?

Why am I even asking this question?

I’m asking and eventually answering this question because it seems like people generally don’t know what sound designers do. I’m mostly referring to other disciplines, but it also applies to many students and even some so-called sound designers (that don’t seem to know what they’re doing).

It’s important, though. It’s important for people to know what sound design is (or isn’t). Sometimes it’s like people think that we wave a magic wand made from bologna and rad sounds start filling the air. To be clear, rad sounds would start filling the air if one were to wave a bologna wand around, but those haven’t been invented. Or, at least, they’re not mainstream (yet).

So, the first answer to the question is this: Sound design is not the result of waving a bologna wand around in the air after someone requests a sound. There isn’t even such a thing as a bologna wand. At least not in the mainstream. We’ve gone over this. Since I’m getting to answering the question already, I’m starting a new heading.

Okay, so what isn’t sound design?

Sound design is not quick work. It doesn’t happen in five minutes. I don’t care what sound I’m making, it could be the sound of a feather landing lightly in a basket of cotton. It doesn’t matter, it’s not going to take me five minutes. It’s probably not going to take me 30 minutes. I might be able to get it done in an hour, but it’s not going to be the best that it can be. Not even close. It’s going to be a rough first pass that may be acceptable to ship if absolutely necessary, but I’ll probably find some time to make it better later. May as well say that it’s going to take at least a couple hours.

Sound design is not simply taking existing sounds and plugging them into the game. Although in many cases this is technically legal to do, depending on the EULA of the sound library or if the sounds are owned outright, it’s still generally unacceptable to Team Audio. Yep, we do tend to have a bunch of sounds lying around, and they may come from sound libraries, or they may be original field recorded sounds, but the buck doesn’t stop there. We want to take those sounds, usually referred to as source assets, and layer who-knows-how-many of them together (could be two, could be 100), tweak them with all kinds of effects, and apply all manners of audio wizardry to them to make them unique and, most importantly, perfect for what they’re being used for.

Sound design is not reserved exclusively for titled sound designers. Just like how I can open paint.net and make an awesome picture, anyone can make a sound, and believe it or not, it can be great. There are so many free tools to make sounds that it would make your head spin. Audacity is a popular choice, and it’s free, so don’t be afraid to dabble. Beyond that, you can use your mouths to make sounds. We encourage this at Volition to help us determine what it is that people want. Just make the sound with your mouth and you’ve given more useful direction than you may realize.

That said, good sound design is not something that is easy. Like any other profession, sound design will take years and years of hardcore practical application to master. It could take a lifetime. It’s highly creative, highly technical, and at times, highly frustrating. To be a professional sound designer, you have to devote your life to it. You have to pour your soul into it. If you have the fortune to be working with good sound designers, take a moment to appreciate their work. Like, go watch them do it if they’re cool with it. You’ll see!

Sound design is not exclusive to sound effects. This one can be tricky and I don’t mean to confuse anyone reading this, but the lines between sound design and music as well as sound design and voice are blurry. Mario picking up a coin is a quick little two-note melody. Is it music? I don’t know. It’s musical, for sure. I think you could call it a tiny little song, or you could call it a sound effect. And when I’m applying a walkie talkie effect to a voice line, it feels suspiciously like sound design. Same goes for zombie voices. Pitch the original line down, apply some distortion, layer in some extra spit and a growling animal… sounds pretty sound designy to me. But it’s still a voice line!

What about the bologna briefs?

You could use the footstep system for that. Take a squishy sound, something nasty, maybe stirring a bowl of mac n’ cheese, and make it staccato with your envelope, basically an immediate attack and a decay of no more than a half a second. I’d probably opt to layer in some subtle farts in a couple of the variations, but that’s just me. Bologna is pretty floppy, so it would be slapping against the thighs, so you may want to put something viscous on your hands and clap them together, maybe maple syrup, since that’s highly viscous and also may not taste too terrible if eaten on bologna. Layer that in there, too. Then, make it play on top of whatever footsteps are already playing using your footstep system. This way you get the sound on every step.

You’ll want some VO lines for NPCs that indicate that there is a meaty, pungent smell emanating from the character that is wearing the briefs.

If you’re from a non-audio discipline and you’re reading this, I’m here to put a caring hand on your shoulder and to tell you that it’s OK. It’s OK to say that you want a sound or a piece of music to be more chocolatey. Or to say that a sound isn’t sharp enough, or yellow enough, or crunchy enough. To say that you want a piece of music to be a breeze on a summer afternoon is perfectly fine. It really is!

Part of an audio designer’s job is to translate what people say into sounds. Not to be confused with making sounds using peoples’ mouths, which we can also do, but rather to take somewhat abstract words or phrases and turn them into sound effects, or to use them to iterate an existing sound effect.

It’s uncommon for people to have an audio lexicon, and that’s OK, too. We don’t expect it. If an audio designer on your team is getting frustrated with you because you aren’t saying “attenuate the 12k to 15k frequencies by 3 dB,” then I’d propose that they are not doing their job, or at least they’re not doing it as well as they could be. Don’t let it deter you. Maybe they haven’t yet learned that this is a major aspect of their job and that it should be expected. But you should know that it’s their problem, not yours, because this is part of their job. You can take it from me, Some Guy On The Internet.

Now I’d like to address my fellow audio pros out there.

This might seem like a silly topic, but I’m finding that it’s more important than it might seem. Team Audio needs for others to provide feedback about our work, and as audio designers, we need to make sure everyone knows that it’s totally acceptable and normal to apply their existing vocabulary towards audio.

When you’re showing your work to your colleagues, encourage them to speak up, and to use whatever words come to mind to describe what they want. Remind them that they don’t need to use technical jargon to get their point across, and don’t be afraid to provide some examples. I’ve listed a couple at the beginning of this post, and more are incoming, and you can feel free to use them.

Also, when you’re soliciting feedback from other disciplines, you can give them something to work with up front by using normal words yourself in your explanation. You could say things like, this explosion is green, so we want the sound to feel green as well, which is why we’ve added the sound of acid corroding a soda can. Or, this creature’s skin looks all cracked, so we wanted its movement to sound brittle and poppy. Starting off like this and avoiding audio jargon can help set the tone of the discussion to be more inviting and fun for them, which can lead to better ideas.

Once someone has expressed themselves in this abstract way, it can also be good to follow up by reiterating what they said and then explaining at least one way by which you plan to fulfill their suggestion. For example, you could say something like, “You say you want this pool of fluid on the ground to sound darker and more gooey, so I think the first think I’ll try is lowering the pitch of what you’ve already heard, and then I’ll add the sound of a really thick soup coming to a boil, kinda quiet in the background. Unless this seems way off from what you meant, I’ll have an iteration for you in a day or two.”

Don’t be surprised if you get it totally wrong. You’ll probably find yourself faced with some pretty abstract concepts, like trying to turn a color into a sound. And honestly it would be silly of me to presume that this will be right for everyone, so maybe this is all a bad idea for you or your project, and that’s OK, too. Generally speaking, though, I’ve found that it serves to open up a meaningful dialogue between you and your colleagues from the other disciplines.

Most importantly, to all of you Team Audios out there, remember to be patient. The idea is to help them feel safe enough to speak up, and to give you more ideas, and for them to feel like they were more involved with the design of the sound. It’s a way to get earlier buy-in from people. Remember that awesome ideas can come from anyone. And who knows, maybe other disciplines will come talk to you more about what they’re doing, and that can be a very good thing.

Lastly, get rid of the turd-sock when you’re done with it.

I’ve noticed a change in myself over the last couple of years. Back in the day, I worked on a lot of casual and indie games. Reviews were fairly scarce for these games in the first place, let alone a thorough one, so when a review had as much as a mention of the audio, it was amazing to me. I would study every word in that review, poring over it like it was a love note or something. I would revel in the praise and torture myself over the criticisms.

More recently, though, I’ve changed inside, and I’m not referring to my languished musculature and sagging organs from sitting in the same chair for three years, although that has also happened. It’s more of a psychological change. It feels like I’ve realized some things about game reviews, both in general and involving the audio aspects. The bottom line is that they matter less to me as a developer these days.

First of all, on the audio tip, I find myself astonished when there’s more than a few sentences about the audio. And beyond that, when there is at least some mention of the audio, a lot of reviewers out there don’t seem to know how to provide a good critique of the sound effects. Some are pretty good at critiquing the dialogue, and some are good at critiquing the music. But when it comes to critiquing the sound effects, the vast majority of reviewers out there just don’t seem to have the lexicon to express their opinion, or maybe they don’t realize how much the sound effects are adding to their experience. So, what we end up with is a couple of sentences mostly about the voice acting, writing, and/or music, and maybe, if we’re lucky, “the explosions were visceral,” or something like that. Many of us internal audio designers are most interested in the reception of the sound effects because often we’ve made them ourselves, and it can be disappointing to have so little said of our work.

Secondly, a review is written by some working schmoe like me. It’s just some other human being out there who is paid money to do their work. They may be qualified from playing lots of games and having some insightful views, maybe they’re good writers, and don’t get me wrong, writing a good review is an art in and of itself, but still… it’s just some goofball who accidentally burps in the middle of their sentences just like I do. Sometimes developers seem to fear reviewers as they affect the almighty metacritic rating, or they put reviewers’ opinions on a pedestal, or they think reviewers are evil, and there are reasons for these things, but really, they’re just some schmoe getting paid money to do work, just like me. They put their pants on two legs at a time using the Pantsinator 3X just like me. Somehow this makes me care less. I don’t know if it makes sense. It’s just how I feel. Lately I’ve been feeling the same way about celebrities and world leaders. We’re all a bunch of schmoes.

And the third and probably most relevant reason is that I’ve discovered that the actual act of doing the work is why I do the work. Of course I love the end results and love to see it all come together. But to me, the journey is more meaningful than the destination. I put my all into the work that I do because I’m on a team and other people are relying on me. I’ve learned more than I could have ever imagined. I’ve made relationships with people that are now very important to me. I’ve discovered things about myself that I didn’t know before, things that I am capable of that I wasn’t so sure about a few years ago. And because of this, it’s less meaningful to me to have someone that I don’t particularly care about critiquing my work. I already know that I’ve done my best.

Ok, so, all of that said, I need to be clear about a few things.

I do value feedback, even from complete strangers, but it’s more relevant to me if it’s feedback during the development process because I can do something about it. Now there is nothing that I can do about it. If a read a review that complains about the audio falling flat, well, I’ll just have to swallow that tough cookie because there’s no changing it at this point.

Also, I mean no disrespect to game reviewers. Reviewers play an important role in educating players about games, and I’ve found that some reviews are very useful and thought-provoking. I particularly enjoy reviews in which it’s obvious that the reviewer isn’t just going along with what the rest of the reviewers are saying and is instead speaking their own mind. I’ve learned things from reviews, and that’s very important to me. And as a gamer, I do occasionally use reviews to influence my purchases.

And finally, I hope that this whole me-being-honest-about-my-feelings thing isn’t coming across as cynical. I’m not summarily distrusting of reviewers, and I don’t hate them, or think that they are evil, or that they’re sheep, or scrubs, or anything like that. They’re people very much like me, and we probably have a lot in common, like languished musculatures, and sagging organs, and many are proud owners of the Pantsinator 3X.

In conclusion, reviews just don’t matter as much to me anymore, but I don’t mean to devalue them. When Saints Row: The Third hits the streets, I will read my fair share. I’m sure I’ll be excited by some and frustrated by some. But in the end, I’m much more interested in my next journey than the previous destination that I’m leaving behind.

People just want to do their thang, though…

We get it. We want you to do your thang. Your thang is what keeps us audio guys relevant. Your thang could be designing missions, it could be creating artwork, it could be making animations, it could be updating pipelines, it could be almost anything, and you may never know that it affects us in the distant, green pastures of audioland. But so often, it does.

And this isn’t your fault. If there’s blame to go around, I believe that it should mostly be shouldered by your friendly audio team. They’re the ones that need to be educating the world of their woes. It’s their responsibility to advocate for themselves, ideally to people who can then advocate for them, and so on. I’m an audio guy, and I’m putting my pants on and marching over to you to educate you on this issue. At least I hope I remembered to put my pants on. Did I? I did. Good.

You weren’t “supposed to know” this information, by the way. In fact, from all accounts that I’ve heard, most of you won’t be taught this information in school. Except for maybe the school of hard knocks. You’re also usually not the one suffering the consequences, so it’s possible that even if you do learn that audio relies on you, it might not stick. But I want to make it stick. I want to make it stick so badly.

Why does Team Audio care about my stuff so much?

As mentioned in my previous ADBAD post titled Team Audio vs. The Milestone, the nature of audio is such that we typically can’t call our work completed until you call your work completed. If you’re making a bombastic explosion, then we can’t call our explosion sound effect completed until we can see your final explosion visual. If you’re designing a system that increases the fire rate on a rifle, then we can’t call our rifle sound effects completed until that fire rate is dialed in. If you’re creating an animation of someone’s eyeball being impaled by a Triscuit, then we can’t call our sound effect completed until the timing of that animation is locked down, and possibly until we see the white goo oozing from the ocular cavity. Just sayin’.

How do we know when Team Audio gives a crap?

So, my pants are on, and it’s time for me to attempt to educate a little bit. Here are a bunch of grossly generalized per-discipline lists of when you should let Team Audio know. This is not comprehensive by any means, but hopefully it is helpful.

Team Animation! We rely on you…

…to let us know if you think there’s a chance that the animation you’re working on will need audio in the first place.

…to let us know if you’re planning on changing an existing animation that already has sound effects, particularly if your change is going to change the timing of the animation.

…to let us know if you’re replacing an animation wholesale, even if we haven’t designed the sounds for it yet.

…to let us know if any animations with related audio triggers change timing (e.g. a footstep trigger).

Team VFX! We rely on you…

…to let us know if you think there’s a chance that the effect that you’re working on will need audio in the first place.

…to let us know if you’re changing the timing, color, shape, size, or motion of your effect.

…to let us know if you’re using tons of miniature effects to comprise what we may think is one big effect.

…to let us know if you’re reusing an effect in more than one way (e.g. this steam effect will be coming out of this dragon’s nostrils, and it will also be used on this chimney).

Team Environment Art! We rely on you…

…to let us know when you’ve locked down an area in the game and it’s ready for some audio love.

…to let us know that you’ve placed some object in the world that has movement associated with it.

…to let us know when you’re relocating some landmark, piece of terrain, or anything else that already has sounds associated with it.

…to let us know the emotional direction of an area (e.g. this graveyard is supposed to be somber, so please don’t put ghostly moans and women shrieking in the background).

Team Prop Art! We rely on you…

…to let us know if your props are going to have moving pieces.

…to let us know what the intended materials of your props are.

…to let us know if your prop is going to end up having VFX attached to it.

…to let us know if the prop you’re designing is static or dynamic.

Team Mission Design! We rely on you…

…to let us know when you’re thinking about adding something new to your mission. Doesn’t matter what it is.

…to let us know when you think a sound for your mission isn’t conveying what it needs to convey, including the emotional goal for that segment of the mission.

…to let us know when parts of your mission are considered final and locked down, but only if they truly are final and locked down and nothing else is going to change.

…to let us know if you’re going to have a meeting about your mission. We’ll probably want to be there.

Team Systems Design! We rely on you…

…to let us know if you’re planning a new system that could even remotely affect audio.

…to let us know if there are changes planned for any system that has an audio component involved.

…to let us know when you’re done tweaking values on any system that could affect audio (e.g. weapon fire rate, vehicle RPM ranges, player reload speeds, etc).

…to let us know if you’re working on a system and you think that there may be a way for audio to piggyback on that system.

Team Writing! We rely on you…

…to let us know your writing schedule, or if your existing schedule is changing, so we can help figure out the recording schedule.

…to let us know when you’re done writing a line and you’d like to get some temporary voice over in-game to give it a test run.

…to let us know if a line isn’t working for your in-game, if it seems out of context, anything like that.

…to let us know, if you know, that a line is going to need processing, like if it’s said over a walkie-talkie.

Team Programming! We rely on you…

…to let us know the second you hear that memory is being freed up. We’d like a chance to make a case for it.

…to let us know if you see an issue with an audio system. The audio programmer doesn’t need to bear this burden alone.

…to let us know when you start to suspect that our seemingly simple request is blossoming into more work than you first realized.

…to let us know if you have any cool audio ideas, or if you have feedback on the game audio. Don’t be shy! Everyone has ears, even you. Unless you don’t. That would be really strange, though.

I’m sure there are lots of people that I’m forgetting. Don’t take it personally. Let me know if I’ve left you out in the comments of this post. I’ll make an effort to include you. Despite appearances, I’m not perfect. I know, I know. It’s true, though.

A note to my colleagues at Volition.

If you’re a Volitionite reading this, I want you to know that all of these things still apply, but that I also salute you for doing such an extraordinary job of communicating with audio. You guys are heroes. Yes, there are still improvements to be made, and we still have a lot of education to go so that we can work together even better, but by and large, you guys get it, and you’ve done more than you probably realize to make our games sound great. So, thank you.

A background of the opponents.

Team Audio is the audio team working on a game. Probably obvious, but one never knows. Team Audio could be a team of a dozen, or Team Audio could be a lone wolf, or any range in between. Team Audio needs to hit deadlines just like all the other disciplines. But where do those deadlines come from? That leads me nicely into The Milestone.

The Milestone is a chunk of time, basically. A chunk of time in which, hopefully, work gets done. At the end of The Milestone, progress is measured, so everyone endeavors to accomplish the things that they set out to accomplish before The Milestone ends. Towards the end of The Milestone, I tend to ask myself all sorts of questions. Did I meet all of my goals? And did I squash all of my bugs? And did I remember to brush my teeth? Because that’s also very important.

The Milestone can vary from developer to Developer, and even from project to project, which I’ll talk about later because it has happened at Volition. So, your experience of The Milestone might be different than my experience, but that doesn’t really matter to the point that I will eventually be making. You’re probably thinking, get to the epic battle (i.e. the point) already! Alright, alright! One last thing, though.

To understand the battle, you should probably first understand where audio fits into the schedule in game development. It’s easy. Most of the time, audio comes last. There’s no sense in designing a glorious explosion sound effect when we haven’t yet seen the explosion. I mean, we’ll make something awesome, but when we find out that the explosion has green flames and a bunch of silverware shooting out from it, we might need to redesign the asset. That is unless we always put silverware clattering in our explosions. (we do)

Anyway, what you need to know is that audio tends to happen last, after the visuals have been completed. Or after the lines have been written. Or after the fire rate on the gun is dialed in pretty close. Or any other number of variables that would make us change how the thing, whatever it is, could sound. Otherwise, we run the risk of wasting time.

The battle begins!

The Milestone has begun and all of the disciplines start grinding away at their work. And it looks like a couple disciplines are going to barely make it! Team Animation and Team Mission Design only have a couple of days to wrap up their work… it’s getting so close, now… and BOOM! Team Animation and Team Mission Design finish their work in the nick of time on the final day of The Milestone! Team Audio can now design and implement the sound effects for those animations and missions. Will Team Audio make it? Nope! I’ve just said that it’s the last day of The Milestone.

Team Audio might do something miraculous and valiant and actually finish their work by the end of the day or over the weekend. It happens all the time, in fact. But even if others can’t tell, Team Audio knows that those sounds are nowhere near the quality that they could have been if they’d had more time. Actually, little secret here, Team Audio will redo those assets later, probably at a much more inconvenient time, like towards the end of the project. It’s not unheard of for Team Audio to not tell anyone that they’re redesigning those sounds, just so that they can redesign those sounds.

Before we get to the potential and possibly obvious solutions, I feel like I should be clear about a couple of things. First of all, Team Audio failing to complete their work by the end of The Milestone is not the fault of Team Animation or Team Mission Design in the above example. In fact, Team Audio will be happy that the other teams got their work done on time. Nor is it the fault of Team Audio, and I hope that fact doesn’t need explaining. Secondly, The Milestone isn’t a bad guy. The Milestone can be very valuable and important, though applied incorrectly in this case, I think.

Is there a better way?

Team Audio might push for other disciplines to complete certain things earlier than others. That’s not a bad solution, really, but it’s not very reliable, either. Team Audio could ask an animator to make the animation of the guy getting punched in the face before making the one of the guy lifting his arm to light his cigarette, because the first one will likely need sound effects while the second one could get by without. Unless of course the guy is whipping that cigarette up to his face super fast. Then you’d want a wicked kung-fu whoosh like a ninja is trying to punch Bruce Lee in the nads. Anyway, this could work, but then Team Audio might be messing up Team Animation’s flow, or Team Animation might forget. But it could work, and I think it’s better than doing nothing.

In my opinion, the better solution is to give The Milestone a little compadre called Audio Milestone. Audio Milestone wraps up a week or two after The Milestone is over. This way, all of the other disciplines can proceed as normal, and then Audio Milestone kicks in, and Team Audio has the chance to give the project the love and quality that it deserves and needs. Added benefit: Team Audio can cut $45 from their monthly Pepcid AC budget!

This is what Volition has done for one (and probably both) of our upcoming projects. On Red Faction: Armageddon and Saints Row: The Third, it was Team Audio vs. The Milestone, and Team Audio became adept at phrasing their goals in such a way that they wouldn’t fail if they couldn’t get their work done due to a late-arriving deliverable. Next projects, though, instead of Team Audio vs. The Milestone, it will be Team Audio <3 Audio Milestone.

And what about the future?

But there is a great nothing on the horizon, a deep and endless murky black, drifting slowly across the lands. It’s inky tendrils, while far away, creep towards Team Audio and leave an eerie hush in their wake. And that vast darkness is named The End of the Project. What happens at The End of the Project? Because, if you think about it, Audio Milestone can’t go on forever, can it? Will Team Audio be given time at The End of the Project to complete their work after everything else has been locked down and truly will not change?

We’ll see. Maybe I’ll be writing about a new and different epic battle sometime in the future. But at least it won’t be “of the ages.”