Today I want to tell you a little story…
I was chatting to a sound designer friend of mine, Cai over a video call. He wanted me to help him out with a game he was doing some sound design on.
Challenge Extended…
Using FMOD, he needed to write some code that would play music for each level of this game, and then stop the music once the level had ended.
Challenge Accepted!
After we took some time for us both to understand the code that had been written by the programmers, we eventually got the music playing exactly as he wanted. Awesome!
However once we had finished, I noticed something about his FMOD project and the events he had created…
His Master Bank looked a little bit like this. FILLED TO THE BRIM with all of his audio events. THAT’S A BIG NO NO!
Now this is a bit of a problem and is something that needs fixing. Before we can understand why it needs fixing, we need to know the purpose of our SoundBanks and how to use them properly.
What’s A SoundBank?
A SoundBank is a file created by FMOD (Wwise has them too), that contains all our audio files we’re using inside our project, as well as all of the data surrounding the events we tell them to play in (parameters, loops, effects, etc).
Whenever we select “Build..” inside of our FMOD project, we’re telling FMOD to build new and up-to-date bank files containing all of our hard work.
These Banks are then read by our game engine (Unity or Unreal), allowing it to play our FMOD events during runtime of our game.
FMOD gives you the option of creating multiple SoundBanks, allowing you to separate your events into SoundBanks dedicated for specific purposes. This is a very common practice when it comes to audio implementation. The reason why we do this is to save space inside the RAM of the device that our players will run their game on.
RAM space (or Memory) is a limited and scarce resource that we must cherish. We cannot waste it.
Why Is Memory So Precious?
In case you don’t know the process a computer goes through when loading data, here’s a brief explanation:
All of the data that makes up our game (art, code, animations, audio, etc) starts inside our PC’s Storage Device System such as a hard drive. When our game is first booting up or is at a loading screen, data from that storage device is being pulled into the PC’s RAM. Think of RAM as a temporary place of storage. Whilst the game is running and our player is moving through a level, data from the RAM can be quickly retrieved as needed, saving the game time as retrieving data straight from the storage device would take significantly longer.
Image playing an FPS, but every time you fire your gun, you have to wait a couple of seconds to hear the BANG! That's what would happen if your game tried top pull the SFX straight from the storage device as it was needed, as appose to pre-loading it into the RAM before the level started.
Now you might be thinking “Well why don’t we pre-load all of the games data into RAM to save people having to sit through loads of loading screens?”
The reason why is because the amount of data that RAM can hold isn’t very big, in fact it’s pretty tiny compared to our storage device. It’s quick, but not very big.
So because there’s not much room inside the RAM, we need to make sure that we ONLY LOAD WHAT’S ABSOLUTELY NECESSARY into it at any given moment.
And that includes our Sound Banks.
How Can SoundBanks Save Memory Space?
Take another look at this picture again. In it, all of our audio is being stored inside one bank file, despite the fact that most of it won’t be heard until our player spends a couple of hours playing our game.
Now do you think this is the most efficient way to manage our limited amount of Memory? By loading our entire soundscape into memory?
HECK NO G.I.JOE!
So instead, we need to create multiple bank files, and then organize our audio for specific purposes or moments in our game. That way, we can load and unload those Bank files in and out of the game as needed, freeing up space inside the RAM for other assets.
Something like this is more like what we want to do with our events and our banks. As you can see, here the audio files have been arranged into separate banks.
They’ve been organised into categories such as “Environment”, “Level1” and “Music” to then be loaded into our game separately. There may be moments when we need our “Environment” sounds, but not our “Music” for example.
How you arrange your audio will entirely depend on the context of the game you’re working on. You may separate them by level, by purpose (music, ui, SFX, ect) or in your own way to fit your game. The goal is to do it in a way that fit’s the design of the game you’re working on so that the banks they’re assigned to can be loaded in only when necessary.
But How Do I Do Any Of This Stuff?
Well the answer to that question will have to come in the next post. For now, I just wanted to make it clear how important Banks are, as they tend to get over looked quite a bit by composers and sound designers (myself included). I’ll be talking more about the specifics of loading FMOD banks in the next email.
Preserving Memory and RAM space is also something that video game developers and programmers have to consider CONSTANTLY! So think about how much they’re going to absolutely love you if you turn around to them in the middle of a project and say…
“Oh don’t worry about my audio taking up too much memory, me and my SoundBanks have got it covered!” …
I’m telling you mate, they’re going to be kissing your feet!