Why in-house plug-ins DON’T get developed

If you haven’t followed me on social media or checked out the audio programming resources page you probably haven’t seen a fantastic article by Robert Bantin on why writing Wwise plugins is important to your game and how to get started.

And when I say fantastic – I mean the article is f*#@ing phenomenal. Go read it right now.

Read it yet?

Ok good, now I’m going to rant on a few things in relation to the beginning of it.

First let me slam you across the face with this quote…

Audiokinetic’s own effects suite notwithstanding, either your studio has made the decision to support a certain platform (and that platform vendor is supporting you in some way), or you’re presented with a shelf of after sales parts that might be of use.

Now, I mean this with absolutely no disrespect to those 3rd party vendors, but if we were talking about graphics and your studio was expected to only use built-in or 3rd party shaders, would that be acceptable? Probably not, because as we all witness from time to time, video games need to have their own visual aesthetic in order to differentiate them from the rest and, in practical terms, there are all kinds of performance reasons why bespoke shaders are written for a game.

As a sound designer – exactly how often do you actually consider having in-house tools made to support your aesthetic vision, not just efficiency? Never. Right? Never.

I want to argue a few things here.

As much as I really want to argue otherwise – I have failing hopes in the idea of having a dedicated audio programmer in-house everywhere to do more things than improve process. I’d love to be an in-house Wwise tools builder, and some exist – but Rob accurately points out how difficult it is to get there and even have people look for it.
But why the f**k aren’t you thinking about that? You should! You should have someone who can build you better tools and interesting brushes.
One of the main points of why I’m writing is I wholly agree that this should exist everywhere and I want to enable teams to think about it, people to pursue that, and projects to adopt more audio programmers. I’m betting the future is going to need them.

For you who are interested in being an in-house audio programmer, or are even just considering making plugins, you need to read the following quote…

There are in fact thousands of software engineers out there who are experienced low-level DSP coders. They work in other industries, such as in-car systems, cinema, and music production tools. The reason you don’t see them in the game industry is because the recruitment methods that a lot of studios use to assess a programmer’s ability involve testing for game-play or game-play-related disciplines instead. Therefore, the only audio programmers that get hired in the games industry are usually the ones that have learned how to pass those standardized game-play code tests. A few of them have DSP skills as well.

Every day I live and die by the mantra that things are the way that they actually are – things never are what they “should” be. You might understand this better if I clarify that life is not fair or you have to work hard for what you want.

Rob’s cluing you in on an obvious misstep you’re going to make. You (and I) want to learn audio programming. We’ll spend hours and days obsessing over audio-related programming work. We don’t technically care about anything beyond that right? I’m not researching gameplay programming, not at all.

But you might need to. You might actually need to consider knowing something useful outside of what you actually care about.

This puts you on a common lingual footing with those you want to work with. It will build a bridge of trust from you to them.

I hear you arguing “well shouldn’t it be their job to learn what I do?” – no. It’s your job to learn to communicate to your client in their language and present them solutions.

Ok – I just wanted to share those bits of insane knowledge from early on in Rob’s article with you.

NOW GO READ THE REST! IT’S A TOME OF BRILLIANCE!