In order to make the best chocolate bar in the universe, everyone knows you have to start with caramel.
Milton Hersey, whose last name you’ll probably recognize, started just this way in 1876. After starting and shuttering multiple candy shops, Hershey got fed up moved to Colorado where he studied and mastered the art of caramel making. A decade later after becoming a caramel whisperer, he returned home to Pennsylvania and began the wildly successful Lancaster Caramel Company.
But this wasn’t enough to satisfy Hershey – instead, he always wanted to find ways to make his candy offerings better. He found his next step to do this in 1893 when he was introduced to the delectable invention of German chocolate. He quickly bought his own machines to better his already popular caramels by smothering them in chocolate. This twist caught on so well that just one year later he decided the only way he could better the caramels again was by removing the caramel altogether – thus both the Hershey’s Chocolate Company and Hershey’s chocolate bar were born.
Most of us share this “bettering” trait with Hershey – we always want to make ourselves and our skills better in order to be more hirable. One way to do that with game audio is by learning how to implement sounds with code. Let’s look at three reasons you might want to think about taking the plunge and become better with programming:
- You’ll be better at interactive audio
- You’ll be better at cross-team communication
- You’ll be better at solving impossible problems
Interactive audio is different than linear audio.
This sounds obvious, but to those who haven’t had the experience to work on games or to “plug in” their own sounds, it’s incredibly difficult to understand the complexities and frustrations that arise working on software.
Everyone in audio has the experience of working in a DAW, and the experience of working in video editing software isn’t incredibly different. We’re used to sticking something on a timeline, hitting play, and mixing the resulting output.
In interactive media, you’re completely reliant on user interaction and your developer teammates. With software, it’s never a case of if something will break, but when will it break? For example users can, and will, play your game in unexpected ways, causing your music and sounds to play back incorrectly. Sometimes your tools won’t work as expected, and your audio won’t sound like you intended. Sometimes it’s even your coworkers, who plug your sounds into the game differently than you expected!
Learning how to implement your own sounds in the games you contribute to with code, it will give you a much better appreciation and understanding of how interactive software works. This knowledge will cause you to build and mix your sounds differently, so they trigger in specific ways for an interactive environment. Most of all, it will give you two other unexpected skills…
You’ll be able to speak the language of your teammates.
Have you ever described a mix as “muddy”? Maybe you’ve described a sound as “harsh”, “tinny”, of “boxy”. If you’ve worked on audio for any length of time – you know exactly what these words mean in mix terms. But what happens if you tell her mom that her TV sounds “tinny”? She’ll look at you like you’re crazy, that’s what she’ll do!
(She’s not wrong, either – you chose audio!)
This is exactly what it sounds like when you talk audio to software developers, artists, producers, and HR people. You know exactly the look they’ll give you when you’re super excited about the sound or mix you just made – that “I have no idea what you’re talking about but I’m going to smile and nod at you to validate your enthusiasm” look.
Believe it or not – you do this too! If I start talking to you about memory management, structs vs classes, templates, how many bytes are in a float, smart pointers vs unique pointers, etc. well… I’ve probably lost most of you at this point, right?
A key component to empathy is being able to understand the person you’re communicating with. The single biggest failure I see from audio professionals in gaming is the complaint that people don’t understand how audio works. The constant refrain is “nobody cares about audio” – it’s a complaint that never ends.
Well, it’s hard to empathize with a complainer who only seems to want their way, is it not? The way I’ve solved this personally is through curiosity, questions, and learning. The more I’m curious about what another team does and how they could help me, ask them questions, and learn – the better off our communication becomes and the more we collaborate on awesome things.
When you learn even a bit of programming, you take this leaps further. You’ll surprise engineers when you’re able to provide them a large context of information, work through the basics of problems with them, and start to understand why the code isn’t working the way you all intended. They’ll also be your biggest fans when it does, and when you can take something off of their plate!
And that leads us to another big win…
The impossible problems won’t be impossible anymore.
If you’ve worked in games, inevitably you’ll be involved in a conversation where you’re explaining to an engineer about how the audio or your tools should work. As frustrating as these conversations are – what’s more frustrating is that you have no idea how the system actually works.
Eventually, you’ll throw your hands up and say “I don’t know how to do this, but I just need it to sound/work like X.” It’s often embarrassing to not be able to convey your desires and be helpless to do anything about it. You’d be surprised at how understanding just a bit about programming completely inverts these moments.
With a small amount of programming knowledge, you’ll be able to start doing things like building your own scripted tools and feature prototypes. Even the act of automating how your build syncs or your imports to Wwise can absolutely blow the minds of your fellow sound designers. Imagine as well, not having to say “it should sound like this and play back when the user does X – no, not like that, like this!” but instead programming a poor prototype to visualize what you’re talking about.
Those are the kinds of things, once you begin to learn languages like Lua, Python, and C# that you’ll be able to unlock for yourself.
Sometimes, you’ll even be able to save tremendous amount of labor for your team. I once automated an effects processing pipeline that previously took a human 3-4 days of running batch jobs in Sound Forge, simply because I didn’t want to endure the tedium. I’ve also built a simple XML parser that read and modified every single Wwise work unit in a game to make sure every sound shipped with the correct settings. Both of these problems were costing people tremendous amounts of time and money, but I freed them up to work on more important things.
Believe me, the trust and appreciation your team will share for you after something like that is amazing.
And before you think I’m special – I’m by no means am I an expert software developer – I’ve never been employed as such full time. I’m just enthusastic about both software development and audio. I promise, this skill is not out of reach for you.
“But Adam,” you say “programming is like pulling teeth for me! I just want to design sounds!”
Good news, my friend, that’s 100% perfectly acceptable. Most sound designers feel that way, in fact. Very few sound designers I know are truly interested in programming enough to actually take the time to go through even some simple tutorials. The regular refrain I hear from these folks is “I really should learn some code…”
More often than not, that means “but I won’t because [reason]” and that’s okay. You’re not required to, at all, and you won’t be a horrible sound designer if you don’t. I give you permission to let yourself off the hook, tell programming that you think it sucks, and ignore it forever!
But, you should dive into programming if…
- You want to be better at interactive audio
- You want to be better at cross-team communication
- You want to be better at solving impossible problems
It’s all about better.
Remember, Milton Hershey was already really successful with his Lancaster Caramel Company, but he just had a drive to make it even better and turned to chocolate. Your audio skills may be good or great, and if you want to make them even better, you can turn to implementing audio with programming.
But where do you start?
Most online programming tutorials suck for audio people. None of us want to write up code with generic tutorials that doesn’t really do anything functional or cool with audio.
That’s the very reason I created C# Implementation with Wwise and Unity, and I’m going to put it back onsale the week of September 28th.
If you’re looking to start out your programming and implementation journey and work with tools you’re already used to like Wwise and Unity – I made this just for you.
The course is going to be limited in its availability, so take a few weeks and consider diving in. If you’ve got any questions about, all you have to do is reply to this or email me@adamtcroft.com.
Copyright 2016-2021, NIR LLC, all rights reserved.