I recently did a talk at the Breakfast Game Audio Club, a monthly game audio event here in Toronto, about documentation and organization. Since the attendees really liked it, I’m sharing the content so everyone can access it 🙂

In this post, you’ll find how improving your organizational skills and documenting your work can help you:

• Make better use of your time
• Keep up-to-date with your teammates
• Handoff a project to another sound professional easily
• Charge appropriately for your services
• Set expectations with your clients
• Avoid multiple revisions
• Lead a happy and healthy work life 😎

I learned a lot about documentation and organization working at Tapps Games. When you’re part of a team and deliver audio for up to 15 small games every month, it is extremely important to document everything. Doing so, your teammates are aware of what you’re currently doing and can build on what you have already done. I found the lessons I learned there are also very useful as a freelance professional, and of increasing importance the bigger your projects get.

So let’s look at some good practices regarding organization and documentation when working with game projects (most of them can be applied to other types of audio and programming work as well).

But before we start, it’s important to note that, when it comes to organization, the best practices are the ones that work for you. Experiment and adapt these concepts so that they become useful to you, and not a hindrance to your work.

And remember, these things take some time to become habits – but, when they do, that’s when they start showing benefits.

Organization

Calendar

Maintaining a calendar is the first step in keeping your work hours tidy. It is the “macro” view of your work days and weeks.

Keeping a calendar helps planning your hours ahead, so you don’t:

• spend more time than you should on a project
• crunch (or remember when you crunched, and for how long)
• lose yourself on one task and forget other important stuff, such as
  • eating
  • sleeping

I also find that colour-coding my calendar and letting it remind me when it’s time to shift projects/tasks helps a lot for me.

This is an example of what a week would look like for me on Google Calendar:

Task tracking

If the calendar works for me to look at the bigger hour clusters in my day/week, a task tracking software such as JIRA, Asana or Trello goes into each individual task I need to perform. It also shows the status of each of these tasks and lets my team know what:

• I’m working on
• I need feedback on before proceeding
• is ready for someone to pick up where I left off

Depending on the task tracking service you use, you can also generate reports to evaluate how many hours you’ve spent on each task. That is very useful for a bunch of payment-related planning, as we’ll see in the next topic.

In this generic JIRA Kanban board example, notice how the columns show the status for each task:

• Backlog groups tasks that will need to be done, but can’t be started yet;
• Selected for Development (or To Do) is for things you can start working on;
• In Progress is what you’re currently working on;
• Done is for what you’ve finished (there’s a great feeling of accomplishment in moving a complicated task from In Progress to Done!)

I also like to use a Waiting for Feedback (or Paused) column between In Progress and Done. This helps me quickly visualize tasks I’m waiting for feedback from the client, and therefore can’t move ahead until they do.

You can also colour-code task cards and create a hierarchy among them (e.g. the full project is an Epic, the next delivery package is a Story, each macro task such as Music or SFX has its own Issue card, and those are subdivided into Subtasks such as Menu Music, Game Over Music, etc). This example is loosely based on the Agile methodology, for which JIRA is primarily focused on, but I’m not concerned with being “correct” here – again, what works best for you and your team is what you should use.

Timer

The purpose of a timer is pretty straightforward: it tracks the time you spend on any given task.

After completing a few projects, tracking the time you spend on each task and labelling them correctly allows you to know how long you normally take to complete recurring tasks. This is important for you to know:

• how much to charge for a project
• if you’re earning the per-hour rate you set for yourself

The logic is simple: if you know that you take, say, 6 hours to create 1 minute of electronic music (because you’ve tracked your time doing this over a few projects), and you charge $ [insert you per-hour rate], you should charge 6x you hourly rate plus how long you usually spend on revisions (or charge for revisions separately).

Of course, if you simply charge per hour, a timer is of utmost importance for you to invoice your client by the end of your billing cycle. Most clients I’ve worked with prefer to have a flat rate, though, so they can budget accordingly. But this is a topic for another post.

I like to use Clockify for time tracking, and I know a bunch of people that use Toggl. Again: whatever works best for you, as long as you know your typical turnaround time for your recurring tasks.

Version management

This is usually extremely important for game development (and general software development as well). If your team uses a version management tool such as BitBucket or GitHub, you can:

• Upload audio assets directly to the game’s repository (where every game file is grouped together)
• Edit code (if you feel confident!) and change audio triggers directly in the game’s scripts
• If you (or someone else) messes things up, files can be reverted back to a previous version (that works for different versions of the same audio file as well, provided they are named the same)

For smaller teams, it is pretty common to use Google Drive / Dropbox / OneDrive to upload audio files. While those can get the job done, they are not version management tools, so you have to be more careful with changes (or always keep a copy of each version so you can go back if needed).

To push your files to a repository, you’ll need software such as SourceTree, GitKraken, or any other similar Git GUI. Talk to your team and decide which one to use!

Documentation

I like using Google Docs and Sheets for documentation because they are easy for collaborative work and you can revert to previous versions if needed. But you can use whatever text and spreadsheet editor you prefer.

Sound List

One of the most important documents in game audio! This list, preferably set up in a spreadsheet, allows sound professionals and programmers to be on the same page regarding sound assets.

It also allows tracking the status for each asset: what is done, what needs to be done, what needs external resources to be made (e.g. a video to create a sound asset synchronized to animation), and so on.

When you work on similar projects, a previous sound list can provide a template so you don’t have to assess the new project’s audio needs from zero.

If you’re using middleware (such as FMOD or Wwise), the sound list can also track which assets are part of which events, what parameters the programmer needs to call in the code to execute certain sound behaviours, what parameter values correspond to what game situation, and so on.

On top of it all, the sound list can also be used as a quoting tool. You can set your minimum Quoting Unit (the “cheapest” asset type for you, like a variation for an SFX for example) and multiply that accordingly for each type of asset you offer. So, for example, if you charge $X for each SFX variation, 1 QU = $X. An original SFX can cost 2 QU, 30 seconds of music can cost 30 QU, voiceover files can cost 10 QU, etc.

Check my two sound list templates (one focused on quotes and one focused on middleware audio events), and feel free to copy them and adapt your copies for your needs!

Sound Briefing

A detailed briefing is ESSENTIAL for aligning expectations between you and your client. It avoids frustration on both parts, avoids multiple redos, and is highly recommended to establish a proper work relationship.

The sound briefing must be provided by the client (even if you, the sound professional, ask the questions and write them down yourself). It should contain, at least:

• A basic explanation of the client’s needs (what they’re hiring you to do);
• References (music / SFX / voice examples, game benchmarks, etc.)
• Due date(s)
• Game art, when available
• A link for a game build, when available
  • Even a prototype with “programmer art” is good
  • A sound designer needs to see the game “in action” to assess its audio needs
  • Many times a video with the full gameplay can be as useful as a build (though not as fun 😉 )

Game Audio Document

The Game Audio Document (or Sound Design Document) is an often forgotten, albeit extremely important, piece of documentation in game development. It gathers all audio-related information in the same place (references, ideas, concepts, technical information, and so on), letting every current and future team member into the specifics of the audio design.

It is especially important when:

• multiple sound professionals are working (or could eventually work) on the same project
• you are working on multiple projects (so you can refer back to the document to refresh your memory and put yourself in the project’s mindset)
• You’re working on a large project (it’s easy to drift off from the original project focus when you work on the same thing for a long time)

Some smaller/simpler projects can have a rough game audio document embedded on the same spreadsheet that contains the sound list.

Here is my Game Audio Document template – once again, feel free to copy it and adapt it to your style and your projects’ needs!

I hope this was useful to you! If you have considerations regarding the tools and practices I mentioned here, suggestions, or concerns, let me know!

If you’re interested in more content like this, subscribe to my mailing list (I promise not to bother you with neverending emails!)