I’ve spent the last few months on contract break / forced sabbatical from my time at Microsoft. And through the professional void, it’s been personally fruitful. Thanks to living like an antisocial monk for most of 2013, I’d put away enough to take a long trip into Southeast Asia and wander about for a month.
(That deserves its own post–which it may or may not get–but you can view my efforts at photojournaling the whole thing over on my Instagram. It starts here, and I wish there were an easier way to reverse-chronologically browse this thing.)
Travel led into more travel: I got to take a trip to the Italian homeland with my dad and brother for a week’s skiing, eating and pacing around downtown Rome. Then GDC. Then, a few weeks later, the annual VALVE Hawaii trip, which I’d been invited along to as a guest. I’m really blessed to have been able to live out this downtime as I have.
But amidst all the vacationing, the overactive brain wanders. You gotta feed it or it dies.
I’ve thought for a while that a real safe heading for game audio is the career path of the audio programmer. In my last year’s experience on Spark, I can tell you that their time is an incredibly precious commodity. If you, the intrepid Sound Designer and Implementer, are the dreamer of big things, they are the ones that turn those dreams into executable reality. I don’t care how good you are with Wwise or Unity or whatever, on any game of sufficient scope, and if you’re trying to do anything that’d stand out against the forward-rushing edge of game audio, you will need a programmer’s help. Sometimes, though, you won’t get it.
What do you do then?
As preparation for a hopeful and glorious return to pay-stubbed game audio–and because I have a little game I’d like to make someday–I’ll endeavor to decode some of this low-level magic that these guys do. And, jointly because I want to keep myself on rails and give you all something to read about, I’ll be documenting what I find, showing my work, demystifying everything I can.
The simplest of sandboxes seems like a ready-made project where I can poke into some Wwise-Unity integration and figure out exactly what’s going on. I know Wwise well enough and there’s documentation on that particular spot where the middleware hits the engine.
Here’s a mission statement of sorts:
I want to hook a Wwise project directly to a game engine, preferably Unity. This means taking a Wwise project with in-built RTPCs, Switches etc. and creating brand new hooks to them within the game code, compiling and experiencing the audio moving about.
Starter questions:
- Can I do this via an already built Unity game simply integrating a Wwise project into it?
- What languages would I need to learn to do it?
I really don’t know anything about programming beyond some basic batch scripting stuff and a well-rusted primer on Python, courtesty of my time at VFS. So, expect a lot of frustration, doing things without really understanding how they’re working and, hopefully, lightbulbs coming on.
Step 1’s checking out the Wwise-Unity integration package and seeing what the deal with it is.