The 3 Levels of Game Audio Programming: Brian Schmidt
An Implementation programmer is someone who becomes skilled/fluent in programming sounds into a game, either directly or (more likely these days) using an engie like FMod, WWise, etc. That tends to be a fairly basic-level job; the joke amongst us game audio folks is that it ends up that the intern gets the job of audio implementation and is also tasked with things like “menu screen” programming. Implementation programmers for things like iPhone, Android will probably a bit more down and dirty (unless you’re using a high-level audio engine on those platforms)
An engine programmer is someone who creates high-level “audio engines”— fancy ways of sequencing audio, creating data-driven tools for content people to use, etc. That can require some pretty deep knowledge about overall system programming—knowing how asynchronous disk I/O works, some simple real-time programming, etc.
Signal Processing Programmer
Signal processing programmers get down and dirty—they write code that operates directly on the audio samples themselves, either writing mixing engines, filters, reverbs, etc. Since this code needs to run FAST, the best programmers do it in assembly language. So signal processing programmers need to know not only audio signal processing theory, but also be great at writing tight, fast code.
That’s just a rough rule of thumb of course; for example engine programmers and signal processing programmers are sometimes one and the same. Both are low-level system programmers. As a result, the code these people write has a direct impact not only on audio, but on other aspects of the game as well. The very last thing a game developer wants is to have their visuals stutter because the code that does the audio streaming isn’t very good! For this reason, audio engine and signal processing programmers should be pretty well versed in the overall game engine’s architecture and function, since they will be sharing resources (CPU, Memory, hard drive, optical disk, network, etc.) with the rest of the game…
If you’re looking to get a gig as a game audio programmer, creating a small game/app is a great way to go. Make sure you have professional sounding sounds, though. Your demo app will be judged on the whole package. Make it do something interesting/unique, or with a ‘twist’ over just playing some waves in response to events…
Make sure you know the basics of good coding in general. You’ll probably be asked “white board” programming questions in an interview—something like “reverse a string in place” or “Implement an ordered insert routine into a doubly linked list.” If you’re going to be mucking around in the code of their game, they want to make sure you know what you’re doing!
Brian Schmidt is one of the true pioneers of the game audio industry. He has been creating game music, sounds and cutting edge technology since 1987 and was recently awarded the Game Audio Network Guild’s Lifetime Achievement Award. With a credit list of over 130 games and a client list including Sony, Electronic Arts, Capcom, Sega, Microsoft, Data East, Namco and many others Brian has used his combined expertise and experience in music composition, sound design and his deep technical knowledge to further the state of the art in game audio. He is also the founder of the Game Sound Conference