Why Procedural Audio Never Took Over Games
Short answer: Sound made live by rules is how the first game machines worked, because they had no room for recordings. Once storage got cheap, recordings won. A recording sounds right the first time, and the sound designer controls every detail of it. Making sound live needs tools, skills and processor time that most game teams don't get. For a small ambient app, the sums come out the other way.
What the term means
Andy Farnell wrote a book called Designing Sound. In an interview he defines procedural audio as "a philosophy about sound being a process and not data".
A recording is data. It is stored and then played back. A process is a set of rules that makes the sound at the moment it's needed.
It used to be the only way
Early home computers and consoles had sound chips. Wikipedia describes one kind, the programmable sound generator, as a "sound chip that generates (or synthesizes) audio wave signals built from one or more basic waveforms, and often some kind of noise". The Commodore 64 and the Nintendo Entertainment System both worked like this.
So every jump, beep and explosion was made on the spot from a few simple wave shapes and noise. Nobody chose that. There was no room for anything else.
Why recordings won
I went looking for people who work in game audio explaining this. Two pieces on the site Designing Sound helped.
Martin Roth, writing in 2014, lists what holds procedural audio back:
- Few places to learn it. He describes "a lack of resources to learn how to make procedural audio, including standards for judging its merits".
- Tools. "Unless the designer can run the sounds on the target platform, the tools are not helpful except as a part of the creative process."
- Speed. Even when you get your work into the game, "chances are that performance will be poor".
Farnell adds a reason that has little to do with technology. He calls it "the internal politics of resources". Sound is treated as something added at the end, so audio teams get a small share of the processor.
My own reading, as a beginner: a recording of a door slamming sounds like a door on day one. A set of rules that makes a door slam is a research project. If the game has to ship, the recording wins.
Where it did get used
- Spore (2008). Wikipedia says "Brian Eno together with Peter Chilvers created the generative music heard while editing planets", and that all of the game's audio was built with a modified version of a sound-programming tool called Pure Data.
- No Man's Sky. Wikipedia says its audio "uses procedural generation methods from base samples". That detail is worth noticing. Even here the system starts from recordings and rearranges them.
- GTA V. Roth mentions its bicycles as a good example.
So it shows up for particular jobs where variety matters, next to recordings and not in place of them.
Why my app goes the other way
- Nothing to match. Game sound has to match what's on screen: a real door, a real engine. My sounds only have to be pleasant. Nobody can tell me my ocean is wrong.
- Nothing to download. Farnell says procedural content "occupies 4kb and plays for six hours". My app has no audio files at all.
- Not repeating is the point. A recording loops. Rules don't have to. That's in ambient sound that never repeats.
I pay for it in two ways. The app uses the processor the whole time it plays, which I looked at in what synthesis costs compared to streaming. And every sound took many tries by ear before it was bearable.
Sources
- Procedural Audio: Interview with Andy Farnell, Designing Sound
- What's the Deal with Procedural Game Audio?, Martin Roth, Designing Sound
- Programmable sound generator, Wikipedia
- Spore (2008 video game), Wikipedia
- No Man's Sky, Wikipedia
Try it: Open Ambient Sound Online and let Ocean run. It's free. Every sound you hear is being made as it plays.
Open Ocean, free