I wanted to write a short blog this week to talk about some conventions for setting up your audio projects in video games in a way that allows the project to grow while maintaining organization for working with it! When I started out in game audio, I would often implement sounds on the fly without adhering to any rules or practices that I had set for myself. What this left was a project by the end of the development cycle in which files and events had to be hunted for, banks were near impossible to optimize, and the game couldn’t easily grow! So after a few unwieldy games bursting at the seams, I have developed some rules for myself that can keep a project organized and easy to work with, whether it’s a small phone app or a full AAA game. I will be using Wwise for my examples, but you can relate these concepts to whatever audio tools you are using.
Let’s first talk about soundbanks. Though popular game engines don’t use them, some popular audio middlewares take all of the sounds in the audio project and bake them into banks, which the game engine interacts with. The important thing to note when working with soundbanks is that they are generated and loaded into memory as a whole. This means that how you organize your sounds into banks heavily affects your workflow and the game’s performance!
Think about what needs to be loaded into your game, and when it needs to be loaded, and work from there. Do you get a weapon halfway through the game? Put it in its own soundbank so that it’s not being loaded into memory the first half of the game. Is there a boss with its own set of sounds? No reason to load those sounds outside of that level.
This is my organization for a first-person shooter that I’m currently developing (banks are in bold):
- VO (non localized)
- Each weapon
- Each NPC-type
- VO (non localized)
- Each level
- Including scripted events
- Global (sounds that will pretty much always need to be loaded)
- Global environmental
- Global, or per-level, depending on ambience
- Global music
- Most state-based music like combat or tension
- Level-based music
- Music based on events that occur in each level
- Global music
- Each NPC-type’s VO (localized)
- Global localized VO
- Level-based localized VO
- Communications to player
- Diegetic VO
Filenames and locations
By the end of a large project you may have thousands of sounds to sort through, so knowing where they are and how to find them is key to quickly working. Consistent naming schemes for various elements of the audio project will become more and more important as the project scales for both organization and readability. Personally, I use naming components in Pascal case separated by underscores, but you can use whatever you think is most readable. The important part is consistency, so you always know how to find the right file!
I always name my files as such:
I use a batch filenaming software which helps me maintain this called Advanced Renamer.
In this case, [Type] refers to if it’s a sound effect, music, or voice over. [Category] generally correlates with the soundbank in which the sound belongs. [Subcategory] is generally the specific object on which the sound is playing, with a [Description] as its action. And lastly, a [Variation] if there are more than one sound describing this object’s action in a container of some sort. An example that I have in my projects might be: SFX_Physics_CeramicSmall_Break_00, or MX_Combat_Generic_LowIntensity_01.
This also makes knowing the appropriate file location much easier, because you can just have the directory tree match the files:
Objects, Hierarchy, and Events
Now this is where all of the naming conventions in the previous section come together and keep your project organized. Import your files into their proper directories in Wwise, and their associated sound objects now reflect the filenames. The project’s hierarchy can easily mirror the directory tree that you’ve set up (with additions that you need for further organization and mixing), and creating an Event from the right-click menu of a sound object will append its already easily-traceable name with the Event’s primary function:
From here, you can organize the Events in a similar manner as your sound objects. And just as important, I always have my game engine’s Events mirroring that structure:
Note: When dealing with larger teams, it will become necessary to split these groups out into separate Work Units, as this will allow multiple people to work in the project at the same time.
RTPCs can afford to, by their shared and overarching nature, be named more naturally than most other aspects of the game. Since the only thing that an RTPC conveys is a number on a scale, the only thing that needs to be denoted in its name is that it is an RTPC and a description of what its value represents in common terms. Almost all of my RTPCs are normalized on a 0 to 1 scale for ease of working in the game engine (and it will probably make your programmers happy).
Attenuations can get out of hand and disorganized more than just about any other aspect of an audio project if not handled correctly. I usually add quantitative measurements to my Attenuations to keep them organized and reasonable.
[GeneralUse] generally describes the type of object at the source of the sound, with a [Range] of the curve in whatever distance measurement unit your game engine uses. The [SlopeType] describes the falloff curve being used, and at the end I suffix any [SpecificDescriptors] which may be needed to denote this curve from others, like a harder lowpass or its usage for a specific game object.
There are some other conventions that can be used, for different things like switches and states, but you should have enough to go off of to make your own rules for those. The ways that I’ve outlined are not the only way to go about creating a scalable project, but regardless of how you handle it I hope the biggest thing that I’ve impressed is the helpfulness of creating naming and structuring in a deliberate way. Focus on making sure that your files will always be labeled and located in a consistent, but significant way and you should have far fewer instances of “what the hell sound should be playing right here?” six months after working on a sound effect.