A while ago a` twitter thread had me thinking again about devs not listening to a game while in development. Now I know the main people that will read this will be audio people. I know I’m preaching to the choir in a large respect. Now I have a few theories/ideas about how our dev culture helps reinforce muting the game. Now these are just my thoughts. I don’t have any actual data to back them up. Just observations from my work. I will say there is no promised land.  We’re still all wandering the desert on this. But maybe some of my observations and tips will help communicate this stuff better with your devs.

The first is I feel open office lay outs are a bad starting point to getting people to listen to games. No one can fire up any speakers with out bothering anyone else. Which means you have to wear headphones. And lots of people do not like to wear headphones for 8 hours a day. Communicating with your team members is harder with headphones on. Or you’re using them, with your own music, to drown out the rest of the office and focus. It also means its hard to share and comment with another person about the audio. I don’t know about you but I rarely see headphone splitters at lots of peoples desks. This is what I consider the first step in unintentionally creating a culture of muting the game you’re working on.

I also think that the culture of “first thing I do is mute the game” leads to two things. Devs become abnormally used to the game with no sound. With everything always being muted that becomes the unconscious default. And secondarily, I think it subtly and mostly unintentionally shows a devaluing of audio.

This is aimed at game devs. Not you people really.  So, game devs who mute cause it “drives them nuts.” and playing the same level over and over doesn’t? Walking down the same hallway 1K times doesn’t? Everything about playing a game during dev will drive you nuts. That’s part of the job. We’re not playing finished games. And that “mute first thing” mentality, while I can understand the need to take breaks shows how much you de-value audio. It’s not part of the experience for you.  Also, if it can drive you that nuts it shows just how valuable and important it is. Something with the power to drive you nuts will really hurt or improve your game.  By being part of the “mute first” culture you’re showing both how important audio really is (cause it has the power to drive you nuts) and that how much you don’t value audio as part of the whole experience.

No those aren’t the only reasons dev’s shut down audio right away. I’m sure people have more reasons than just what I’ve said. But what do we do about it?

Possibly a shock to the audio people, but I’m not saying all dev’s should be listening to the game all the time. There are times to be taking breaks. There are times when you really need to focus on one thing jumping in and out of the game and audio can be a distraction. There are times to turn off the audio. But the majority of the time we should all be listening. We should all be contributing to each others game areas. How many times has a designer or programmer spotted an art bug? Especially with audio usually being the smallest staffed area on a team, the more ears on during play the better off you’ll be.

Getting people to listen more is problem you need both the carrot and the stick for I feel. You’ve got to lay down the law but also be encouraging about it. One step is being more visible. If you’ve got an open office go actually sit with your team as much as you can. Maybe it means you’re out there working on headphones part of the time. Work on your leads to understand how much you need more than just the audio team ears on the game. Getting them on board can trickle down to the rest of the team. Work on getting those key people on board. And in some cases you may need to get into some “No, you have to listen to the game.” with some people. But overall it’s not accusing people of not listening/caring, it’s about showing you want their input. And for that input to happen and matter they need to be listening to the game more often than not.

This of course is not the definitive write up on this. There are more reasons why dev’s don’t listen or mute first. There are more ways to get devs to listen more consistently to the games. Let me know you’r thoughts.

There are times. When you make a really great sound. You’ve got dense subtext to what makes up that sound. It’s so deep in what it says. You get it in the game and play it for someone. And their reaction is “What’s with that sound I just hear?”. To which you respond “Oh well I was trying… (blah blah blah deep explanation)”. And right there you failed.

The reason you failed is you don’t ship with the game. Any sound that you put in the game needs to do it’s job with out anyone standing next to the player explaining it’s intent.  Our sounds need to stand on their own. That said, it’s not that you can’t have deeper meaning to your sounds that aren’t grokked right away. A truly deep sound that works on many levels and shows deep meaning and connection can be the best. But it always needs to do it’s primary job first. Which would usually be to inform the player of something. If that information isn’t understood first by the player it doesn’t matter how deep things might actually go.

An example I relate first is some of the computer sound in Invisible Inc. Now everything in the computer hacking/Incognita mode had bit crushing and ring modulation as part of it’s sound. That was my way of building that part of the world to be unique to the “real” world. Now some of the programs you’d run in that mode were analogs of actions you also did in the real world of the game. For those, I took the sounds from the reality actions and processed them with the plugins I used on all the computer sounds. Some worked right away with just a small amount of processing. Some required major reworks to still convey what you were doing while still relating them to the other game actions. Now I couldn’t describe to every player those sort of connections. I had to make sure they worked standing on their own. And hopefully have left enough crumbs for really observant players to follow back to the source.

Another is a time I made a great sound. For Invisible Inc again. It had some depth to it. Related back to another set of sounds in the game. I put it in the game and a designer came and said “what’s up with this sound? it doesn’t sound good.”  I fired up the game and played that section. Yup it sucked. Now I didn’t try to explain the intent of what it was trying to do. If I had I probably could have convinced the designer that they sound worked cause blah blah blah. But I’d never get that chance with anyone else playing the game. So back to the drawing board with that sound.

We have to be very aware of how close we are to our sounds, the intent behind them and how we’re trying to link them to a larger auditory world. We, almost always, have chances to create deeper meaning to just about any sound we make. We can link simple click sounds back to other important in world player actions. We can give a history of a world through varies in world sounds. We can show evolution and passages of time and all kinds of deeper world building things. But we have to be sure that it all works with out being inside our heads. That things work for the game. Because hopefully you’ll sell enough copies that it would be impossible to ship with your game and explain all your little intents.

I thinking this might be a shorter one but a little more concrete. But I do tend to go one once I get rolling. What I want to talk about this time around is working from two kinds of pools. A sound pool. What I mean by a pool is a curated set of sounds that all your subsequent game sounds will come from. And a plugin pool. Which would a similarly curated set of plugins for a project.

So first the sound pool, the most concrete area I do this is for HUD and UI sounds. I can really spend to much time over thinking my HUD/UI feel for a project. I always want something uniform that all flows together and feels of the world in question. One of the ways I’ve found to help me in this is to spend time before I create anything to create or curate a bunch of sounds that will be the basis of all my HUD/UI for the project. I’ll record some synth stuff. Record some real world items, switches, rattles, small hits. I’ll source from my libraries sounds I can’t record that feel will fit. The whole time thinking about the world of the project and what I want to say with the end HUD/UI sounds. Once I’ve got that pool of curated library sounds and custom recordings, any HUD/UI sounds I make for the project come only from that source. That sets the baseline commonality for all the sounds in this area. Now of course you can do some severe processing and get pretty far from the source as needed but it still creates a link. Possibly a subtle one in the end but all those subtle decisions along the project still all add or take away from the overall vision.

The other pool I’ll set myself to work from is plugins. The same way I’ll curate my samples to work from, I’ll curate a plugin list for certain areas of a game. Some times it’s an inclusion pool, only use these plugins, and sometimes it’s exclusionary, use anything but these plugins. I’ll usually setup these in and out plugin sets for different areas of a project. Sometimes these define each other in conjunction. While working on Invisible, Inc we came up with the idea of Mainframe Mode which was where the hacking parts of the game happened. I decided that the sounds in this mode should be related to counter part actions in the real world but need to feel “in the computer”. The idea I went with was everything in Mainframe Mode would be processed with bit crushers and ring modulators. And as well I wouldn’t use those two effects in any other part of the game. I still allowed my self to use any other plugins as well but the sounds always had a least a little of those two effects as well. And was unique to that part of the game.

Those are two “pool” ideas that I use to help unify areas of my sound design. Hopefully you can use them as a starting point for your own workflows.

I had a very specific idea that this post was first titled with but I’ve realized I could broaden it. So the idea today is to focus your project by limiting yourself. The more of these I write the more apparent it will be how much I love limitations and working with in them. The epic expanse of all possibility is a scary place and it can be really good to put some walls up and box off a smaller area to work in.

So lets start with what I was first going to write about. Limiters. The dynamic audio kind. Not the artificial creative ones or game dependency related ones. For every project I choose one limiter that all the assets will be mastered through. How much limiting is of course a sound by sound issue. Sometimes there isn’t any at all. But that same limiter is on the master channel of every sound. It’s of course a very subtle thing but it helps bring all the sounds in the game together in a related way. At the beginning of the project I make a gut call of from what limiters I have available what goes best with that game. I’m not going to go into why I have picked the ones I have because it’s been a complete personal opinion that hasn’t really gone on any hard facts. I pick what I think its right and run with it. You’ll have to make your own call on what limiter or master chain goes with your game/project.

Ok so that was a cool idea. Now lets broaden that out. Other than limiting our limiters what else can we limit? Well really anything that have multiple creative options can be limited. Maybe you want to only use a certain synth for a song. Maybe it’s only a certain collection of libraries for your sfx. Maybe it’s excluding lion sounds from any of your creature creation. You can make up any kind of limiting rule for yourself. And they can even be different for different areas of your project. I feel it’s always best to stick to these things but of course if push comes to shove you can always drop them if needed. None of this is written in stone.

Some times I like to limit myself to certain plugins or libraries I know I haven’t used much. We’ve probably all got great tools we’re not using to their full potential. And to get out of our regular ruts that we know work. We’re creatures of habit. Now restricting yourself to the newest tool in the shed will probably be the most likely time you’ll want to throw that rule to the side. But if you stick with it you could get the biggest pay offs. This could be how you find your new signature trick. Or the great new unifying sound your project needed.

Now maybe you’re asking what the benefits of this might be. For me it’s two main things. The first is you can speed your self up by removing “endless options” and replacing that with “several options”. You don’t have to worry about exhausting every available way of making a gun shot. You just have to work through the tools you’ve limited yourself too and come up with the best with in that. Now of course, you may have created a rule set that comes up bad sounds in which case you might have to change things up. Finding what works and what doesn’t just takes experimentation.

The second main reason I do this is to bring some uniformity to a project. Not to the point of sounding boring but just a little so the project sounds cohesive. Finding ways to fit everything together into one vision is how we can help create living breathing worlds that subscribe to their own internal logic. And not just a collection of cool sounds.

Some posts are longer than others. (Say that to the melody of The Smiths’s Some Girls Are Bigger Than Others.) I don’t have a set minimum length for these things just an idea I want to get across in each post. Some ideas are going to be long and some are going to be short. Still all ideas worth thinking about.

This time I want to talk about one part of getting motivation to do what you want/need to do more creatively. One of the biggest things I think about in this regard is Lowering The Bar Of Entry. Pretty much anything you want to do is going to take several steps to do. And a lot of the time the more creative it is the more steps it’s going to take. And each one of those steps is an opportunity for you to back out and take possibly an easier, less creative route. Now, there’s nothing wrong with taking the easy route sometimes. There’s lots of times where it’s the right thing to do. Nothing like a looming deadline to make the easy quick way to create a sound the right thing to do.

But if we can start to eliminate steps, or at least streamline them, the easier we can make it to use our possibly more complex methods in any situation. For anything we want to do there’s a bar we have to jump over to do it. And each step raises that bar. So eliminate the steps, lower the bar to jump over. Now we’ve got the metaphor if we didn’t before.

So what’s some of the things we can do to eliminate/streamline steps and lower our bar.

First one for me is to make recording sounds easier. Recording generally has a bunch of steps to it that can really quickly kill motivation. At my home studio I always have a mic plugged in on a stand next to my desk. There’s no setup if I have a quick voice idea to record. It’s ready to go. At work, the recording room computer is always also with a mic on a stand at all times. There’s even generally a DAW open as well so you can walk by throwing it into record and walk into the booth and do stuff. Ok usually you’ll have to test out levels as well but you get the idea. The quicker you can get from your recording idea to having a file of that idea the more likely you are to do it.

Very related to that is DAW templates. Lots of us have similar starting points for lots of things we do. Maybe it’s how we record or build UI sounds. So templates are a great way speed up your starting of a given area. For me the key is to make my templates as sort of vague and flexible as I can get away with. I want the bare minimum of boring stuff I know I’m going to do every time but not enough to trap me into the exact same flow each time. I don’t want my templates make me lazy and possibly make things sound the same across projects. But I sure know I’m going to have a master fader in PT with usual metering plugins on it. And who wants to go through putting that together each time.

In a more physical sense having things like you’re foley objects organized can really help your desire to use them. (I’m using that in the broad term of any objects you’ve got to make sounds with even if it’s not actual for true foley sounds. Just didn’t know a better short hand for that.) At work, we have a bookcase of items to make sounds with that I’m way more likely to us than my collection of junk at home that’s stuffed in a closet. Having things out in the open and within view inspires me way more to grab them than to dig through milk crates stuffed in a closet.

So in general this is about prepping your workplace and workflows so you’re more likely to use the most creative solution and not just the fastest one. Most of all I think of this not about technical aspects cause for sure most of my library sounds are better recorded than I can do it. It’s about getting your passion and creativity into the project. And I feel the more hands on you are will all the parts and steps of a song, project, or even individual sound the more you’re going to be excited by it. And the more excited you are by your work the better the end result will be. So look at how you do things. Look at what you might do repeatedly and how you could speed that up. Or what ideas you constantly talk yourself out of and how you can make getting to those ideas quicker with less boring steps in the way. Sometimes a little pre-prep can go along way to lowering the bars and get you into doing things more creatively.

So what’s some of things you do to lower the bar of entry on your work?

Something I talk a lot, other than “Did you use Decapitator on that?”, is my world view of the game audio for a game. I feel it’s really good to have a bedrock of some simple rules that you build all your game’s audio on. A philosophy of why the sounds that are playing are playing. Now of course this will change from game to game since possibly the most major rule is Serve The Game (that might be another post). And each game is going to determine a different way it needs to be served by audio. But I have 2 things that I always think about for every sound.

For me it’s the idea that on the highest level all your games audio should be doing one of two things. Building The World or Informing The Player. Two fairly simple things to keep in mind. So what does that mean? Well it’s the idea that you don’t want any fluff in your game soundscape. And that if you give yourself some flag posts to guide by up front you’ll have an easier time hitting your mark. It helps make sure everything has a purpose. We build up this big full worlds for our players and are constantly throwing a wall of sound at them. Well almost. Of course there’s games that don’t but just play along with me.

So if we’ve got this wall of ever changing sound being thrown at a player what are we trying to do with it? And for me this is where my two categories come in. I’ll usually start thinking about these before I start designing anything. When I’m planning out what’s needed. They can also be relevant later on when mixing and testing with players but will get you the most milage right up front.

For me the first usually is Informing The Player. There are times when these will swap order of importance on a given game but working on a lot of design heavy games this is generally the first I think about. I’ll probably start out with some rough gameplay either in the game, talking to designers, or in a doc. See what all the actions are/might be and start making lists of all the possible sounds. Of course I’m sure lots of you do that. Then I’ll start applying my Informing The Player filter. Do these actions inform the player of something? I fired a gun. Yes that sound informs the player the gun has been fired. Not only have you spent a bullet but you’ve possibly hurt someone. A shell casing has hit to floor from that shoot. Here’s an opportunity to inform the player of the type of floor they’re standing on. Is it wood? Dirt? Cement? Having the right impact sound on the shell tells the player something. I think a lot of people only think of HUD and UI sounds as Informing The Player but it applies to a much wider set of sounds with in our game world.

So the next filter I’ll apply to my sounds is Building The World. Largely it’s the stuff if you just sit and don’t do anything they make you feel like you’re in the space you’re looking at. What’s going on in the ambiences? How are they making you feel? Is that inline with the setting and story your game is trying to tell. Are you helping and adding to the tone of things? This can be in the small details too not just broad ambiences. In a post apocalyptic world does everything sound dirty and rusty? Or does it sound fresh and brand new and well oiled. Maybe that grenade pin pull needs some grit on it.

Of course there’s a lot of cross over with these as well. A reverb both Informs The Player of where they are and Builds The World as this is a proper space everything is in. Rattling the objects in the world when you shoot your gun but Informs The Player of the space they are in so they can tell where they are in a multiplayer map. And Builds The World that this is a real space and that’s how things act when a gun is shot next to them.

Ok so we’ve got these two filters we’re applying to everything going into our game. We’re thinking about it when first making lists. We’re revisiting once a game is rolling to make sure they still apply to a sound when designs change. So what might not fit? And what to do if it doesn’t? Second is easy, dump it if it doesn’t fit. By not hitting one or both of those filters it’s cluttering up your soundscape and either breaking your emersion or confusing the player. First one can actually be a bit tricker. It can easy to convince yourself that it does fit if you like it, think it’s cool or are otherwise invested in it. For me it’s usually the “cool” ideas I’ve had that I want to try out and I’m trying to force it in because I’m more invested in the process then what the event is actually doing in the game. Sometimes the depth of a certain subsytem might not actually fit. A crazy indepth foley system might really get you excited as a sound person but might not actual add to the player’s world or information they need to know.

These two ideas are what I start building my game’s audio off of. They give me a bedrock to make my decisions on for just about every sound I’m going to consider. Try thinking about them the next time you’re planning or evaluating the sounds in your game. Or find a different set of rules/filters to work from. Just be consistent in your application so your bedrock is firm.