Part II: The Asset List

Before we open up our DAW of choice (Digital Audio Workstation – for those who are really new that’s: Pro Tools, Cubase, Ableton, Reaper, etc.), before we start loading instruments, or trawling sound libraries for sounds; we need to know:

“What do I need to do?”

This question seems simple enough but, as we discovered in the last post, creating sounds for a game isn’t as simple as it first seems.

In the last post, we identified the process of perceptually placing yourself in the game and trying to imagine what we should hear if it was real life. The Asset List should start as a basic list of those findings, usually in a spreadsheet (everyone loves spreadsheets, right?). Eventually, you will have a template Asset List with categories and a nice structure, so you don’t have to design it from scratch every time.

For the first time however, a good place to start is to literally list each sound you might expect to hear one after the other. Before you know it, you’ve probably got over a hundred lines in your spreadsheet. Once you’ve got as many as you can think of, it’s worth splitting these sounds into useful categories.

Some suggestions are:

·         UI (User Interface: menu navigation sounds)

·         Gameplay (typically ‘non-diegetic’ sounds; we’ll explain this in a second)

·         Combat (weapons or combat-related sounds)

·         Environment/Ambient (sounds made by or within the environment to increase immersion)

·         Footsteps/Movement (can also include sounds made by clothing, or servos for robots, etc.)

·         Player (similar to movement sounds, but specifically relating to the player avatar)

·         Enemy (any sounds the enemies in the game make: grunts, death screams, movements, etc.)

Quick note on ‘diegetic’ and ‘non-diegetic’ sounds

In the film world, these terms are used to differentiate between sounds whose source is implied to be ‘within the film’s world’. So: footsteps, explosions, car crashes, dialog, music from a radio in the scene; these are classed as diegetic sounds. Anything else is classed as non-diegetic. The film score therefore is typically non-diegetic, as is a voice-over. In the case of our ‘Gameplay’ category above, examples might include: notification sounds for collecting an item, unlocking a feature or achievement, or results screen audio. It may be argued that these could be classed as UI sounds, but I like to split them off into a new category as they’re typically more in depth than the simple menu navigation sounds.

Now that we’ve split our sounds into categories, we can see a bit more clearly what needs to be done. At this stage, it’s helpful to add a column to tell us exactly that: “Is the sound done?” (a simple Yes or No normally suffices, but there may be additional states of completion you need to factor in). This, after all, is the purpose of our Asset List: to keep track of what sounds we need, and whether we’ve created them or not. Useful not only for ourselves as sound designers, but everyone else involved in the development of the game.

By now we’ve got a very basic Asset List that tells us:

·         What sounds we need

·         What category they fall under

·         Whether they are done or not

The complexity of the Asset List depends on your own preference, but some additional columns that I’ve found useful to add are:

·         Variations – how many variations of the sound do I need? If you have only footstep sound in the entire game, it’s going to be very repetitive after about 4 footsteps.

·         Description – try to describe the nature of the sound. This may be provided for you in the brief or create your own description to help with the creative process. Does the shotgun sound ‘like the one from Doom’, or a bit less beefy? Make this as useful to you as possible.

·         Loop? – Loops are typically a bit more involved than just one-shot sounds as you need to get them to loop seamlessly, so it’s useful to highlight how many loops you need to create and afford some extra time for creating them.

·         Priority – In game development you’ll often run into priority levels. Usually a ‘P1’ or ‘Priority 1’ is critical level (I’ve even seen ‘P0’, which is basically “drop everything and do this right now”), all the way down to ‘P5’ or even lower which might even mean “does this if you can be bothered, but don’t stress yourself”. Helpful to track how important each sound is though based on how quickly the developer needs them implemented.

·         Due Date – it’s good to set due dates even if you’re not given one. Personally, if I don’t have deadline, it’s not getting done. So, set yourself even a ‘fake’ deadline to motivate yourself.

·         Implemented? – This column along with the ‘Done?’ column can turn into a long line of columns depending on the pipeline (e.g. ‘Reviewed?’, ‘Feedback Received?’, ‘Signed-off?’, etc.). If you are only responsible for creating the sounds, you don’t really need to know this, but if you’re also adding the sounds to the game engine yourself, it’s good to keep track of every task you need to complete.

There’s an endless list of other columns you could add, but this will come with experience of what information you need for each project.

Naming Conventions

Ah yes, the ever-controversial Naming Convention.

When we’re dealing with thousands of individual assets, we’re going to need some standardised way of naming the files otherwise you’ll get confused, the programmer will hate you, bugs will be harder to fix; basically, it’ll be a nightmare if you’ve got files called:

shotgun.wav

Or even worse:

untitled_new_fixed_01_remasteredversion_001.wav

We’ve all been lazy naming our files and projects; how many ‘New Folder’ files exist on your computer? Go on, be honest!

The naming convention may be something the developer already has. This is highly likely if they’ve made one or more games before, but if it’s a new indie developer you’re working with, you may have to set this yourself.

The first thing to consider is, try to keep it as brief but as informative as possible. For example:

the_sound_for_the_door_opening_when_you_start_the_game.wav

Not a good naming convention.

I tend to start with an abbreviation of the game title or working title. So, if it’s called ‘Robot Smash Fest’ and it’s the Proceed sound for the menu, it will look like this:

RSF_SFX_UI_Proceed.wav

In this example, I have the game title, what the asset is (SFX or Music usually), what the category is, and the action or function of the sound. If there’s more than one variation, use at least three numbers starting with zero (001, 002, 003, 004) as you don’t know how many you might need in the future. 

(Note: these days, upper and lowercase isn’t as big an issue as it used to be, but some devs might have a preference. They may prefer all lowercase, all uppercase, capitalised first letter after the underscore, or something else. I prefer the capitalised first letter as it’s a bit clearer to read at a glance.)

The naming convention is something you’ll just get used to and refine as you gain more experience, but it’s very important you define what it is at the very start of the project.

Lastly, familiarise yourself with Excel or whatever spreadsheet program you end up using. Colour-coding, borders, conditional formatting, filters, sorting, and a range of other functions will save you hours in the long run if you just do a few tutorials.

Next time we’ll look at creating an actual sound for the game!

Hope this was useful, comments and feedback are welcome, and I’ll see you next time!