A Guide to Game Audio Task Planning – by Jaime Cross

 

 

Howdy.

Are you an audio person that’s suffered from the terrible and generic “Audio Pass” Jira ticket with no details? Are you a producer trying to work out how long an audio task actually takes so that you can avoid bottlenecks and hit deadlines without your sound designers cracking under the pressure of only having 2 days to actually do the work? Or are you another random person that some slight hyperbole around game audio work might apply to?

Well, here’s something for you. I wrote a guide to help folk when it comes to drafting audio tasks, with a target of ensuring collective accountability and knowledge of what is required to complete them across the board.

It’s a bit long, and the standard caveats of “this is non-exhaustive and there will be scenarios I have not covered” and “please look at your own project’s scope, needs, and team” apply, but hopefully it will help get your own pipelines off the ground or tightened up a bit!

Some parts may seem self explainatory to certain people or disciplines, but not to others, so please bear that in mind. Game development a team effort after all :).

 

The User Story/Feature Kickoff

When thinking about audio needs and requirements, you need to start at the very start. When writing a User Story or Feature the first questions asked should be:

• Does this need audio?
• Does this affect audio?

If either is “yes” or “maybe”, then you need an audio person involved!

When thinking about audio tasks that are attached to a Story/Feature, the main things to consider are:

• How does audio tie into the wider Story/Feature goals?

• How should tasks be broken do to accurately reflect the work involved?
  • As an example: Consider audio creation, implementation, and mixing as 3 separate audio tasks. This allows for a more accurate reflection of where audio in relation to the Story/Feature, and properly define what is expected or needed to complete each part (especially in relations to dependencies).

• What other disciplines involved in the Story/Feature might affect audio?
  • This will likely be all of them to some degree, but knowing key people to contact is critical.

↑ back to overview
 

Writing The Tasks

So you should now know if you need audio or not for your user story, feature, or epic. Next it’s time to break it down: what are the audio tasks in relation to the User Story or Feature?

Tasks need to be usable and not just “yeah work needs done”. We should aim for audio tasks to be:

• Readable – The task and outcomes are easy to understand
• Trackable – Progress on tasks can be followed
• With Purpose – Have an explicit goal, even if the outcome is not direct asset creation
• Accountable – Have defined dependencies + sign offs

Instead of having one generic “audio for thing” Jira Ticket like “we need sounds for [x] enemy”, consider breaking that into its component tasks or sub-tasks with a short write up on what each involves and/or references, so that people know what is happening with each and that it matches an overall goal. For example:

• Create audio for [x] enemy’s Fireball ability – Overall description of what happens, when/where audio is triggered, how long it should take to complete the task, any dependencies, expected end result, approval conditions + sign offs.
  • Audio Design for ability + related animations – What audio is needed for what actions? Are there any additional anims like build ups, follow throughs, or interrupts? Are any variations needed?
  • Implement Audio for ability + anims in Wwise – Event set up in Wwise. Set up any parameters as needed. Mixing etc.
  • Implement Audio for ability + anims in Unreal – Attach to anim events/BPs/wherever it’s triggered. Make sure parameters and variables driving them are set up correctly.
  • Testing and Signoff – Does it work locally/in-engine? Does it work in build? Has this been validated? Does it mean any additional creative/aesthetic criteria?

This may seem a bit like overkill (I can hear the screams of “no that’s too much info to track it’s NOT AGILE ENOUGH!”), but understanding the steps involved from “we need a sound” to getting it into a game is important, and not everything is going to require the same amount of work. If you’re fortunate enough to have a team with multiple audio disciplines then you’ll want these tasks separated out so that people know what work is actually assigned to them (ie: a generalist audio person creating assets while a tech audio person is doing the implementation work for a feature).

Breakdowns also allow us to track any potential bottlenecks or issues people are having, in case they need additional support or if there are repeated instances of certain tasks taking longer than estimated. It might be more data, but it also means you have more knowledge about your process and how to patch up any issues if they arise!

↑ back to overview

 

Time Scales and Dependencies

Time Scales are straight forward – how long will each task take?

This should be estimated by the audio people on the team and/or the audio lead for the project, depending on how you run your sessions. Having tasks written out and broken down will help both the audio team and others understand the scope of work that will be involved. Sometimes a task might seem smaller than it actually is when all that exists is a single Jira ticket!

Dependencies have a few requirements that can vary depending on the nature of the Story/Feature. Any dependencies should be linked to tasks they affect.

The most critical of these are:

• When will the required work for audio to start be finished?
• What tasks directly affect audio?

For example: if a User Story involved creating an implementing a new playable human character, audio may need to know (but not be limited to) the following:

• Abilities: This is general design work on how the character should function. It will need to be known in advance of the task being written up.
  • ie: What does this character do? How do they move? What attacks or special powers do they have?

• States: Again, this is design work that will tie into audio system and implementation as well as asset creation.
  • ie: What gameplay states can this character enter? Will audio reflect these? Do different states need different audio assets or processing?

• Aesthetics: Mostly visual related. These only need to be at the concept level rather than in game.
  • ie: Is there any visual style to stick to? What does the character look like? What is the character wearing? What are their clothes made of? Do they have any additional gear that needs audio sweeteners?

• Animations: These should be almost final or locked for any audio related tasks, and will always be a key dependency in those instances. Pre-final anim passes are useful for getting audio assets made and rough timings, but audio related tasks cannot be fully completed until they are done. Any animation change is a potential audio change. Any timing changes MUST be communicated to the audio team.
  • This comes from experience. Trust me on this one.

• VFX: Are there any visual effects or tie ins that need audio sweetening? These can be done as a separate follow up task if the VFX pass is going to be some time out from everything else.

• Barks + VO: This one is fairly obvious, but any VO tasks can’t begin until there’s a script in place. The script needs to be as final as possible when it comes to getting recordings done, as additional sessions and pick ups cost time and money. You can and should use robo voice where possible to test things and set up dialogue hooks in advance of the performed lines being delivered.
  • ie: What is the voice spec? Has someone been cast in the role? Do we have a cue sheet and/or script covering everything?

Obviously, a whole character is iterative and not all of this can be known at certain stages, but it’s important that it is available for any relevant audio tasks!

You may also have to consider Additional Support Needs, which relate to any non-audio work which may also be required to complete audio tasks.

This should be considered a bit differently to dependencies, which are needed before the task starts. For example, an implementation task may require some code support to complete, but is depending on audio work having started. Just because it’s an “audio task” doesn’t eman it’s entirely on the audio team to complete!

Please remember: Audio often relies on other work being finished. If that work isn’t going to be available until the end of a sprint, then there will be no time for audio to complete their tasks.

↑ back to overview

---

Popular on A Sound Effect right now - article continues below:

---

 

Expected Outcomes + Deliverables

This is what the deliverables of the task should be in relation to the Story/Feature, and how they can be checked by a third party.

Generally these should be straight forward, such as:

• finished audio assets
• assets hooked up to any actions or animations
• written proposals

and so on.

The checks for sign offs should have some frame of reference to do so. For assets and implementation, this can be in the form of a video from the audio designer showing what sounds should be playing when, along with repro steps (including relevant asset, variable, and/or state names) which can then be checked by others in a build to confirm. For proposals: these will generally be written documents, slides, or something like Miro boards.

↑ back to overview
 

Task Tagging

Audio Tasks should have a master audio related tag (eg: Audio in Dept) that can be used to filter out any audio work on the project. This does not need to be the only audio tag, as different projects and studios will have different ways of working.

This should be attached to tasks that are unassigned to anyone as well, to ensure that all work is accounted for at any given point. Don’t let things go missing in your backlog or bug reports!

↑ back to overview
 

Agreement Sign Off

This is a general sign off by involved parties to make sure that the time scales, dependencies and deliverables for the tasks are all correct and agreed to. This should include anyone that will be signing off on task completion/acceptance criteria that is covered below. They should agree that the:

• Task description and work requested are accurate and reflective of Story/Feature needs.

• Task timescale is achievable.

• Task dependencies are recorded.

• Task outcomes + deliverables are correct.
  • This is the end output of the task. What should be done once this has finished?

• Task acceptance criteria are correct
  • ie: What is needed to meet the above outcomes? What quality bar needs to be reached?
  • This should include what expected results for QA will be, most likely a video reference + scenario conditions.

• People signing off on acceptance are the correct ones
  • For example, VO tasks would need agreement from whoever is managing narrative, but weapon sounds would not.
  • Cinematic or trailer work may need sign off from a cinematics or publishing team.
  • This might be the same person on a project (like a project lead), but it’s good to know WHY they are signing off so they know what perspective to take!

Again, when sprint planning it is CRUCIAL to remember that audio will likely be at the end of most content creation Stories/Features. It cannot reasonably be expected to start and finish during the last week of a sprint or milestone. A general recommendation would be to have audio be a sprint behind on any Stories/Features that are dependency heavy.

↑ back to overview

 

Completing Tasks

How do we know that a task is complete, and what if the process for any iterations and bug reporting? Some of these are self evident. For example, have/has the:

• Targets or Outcomes of task have been met?
  • Can you look at the main task title and say “Yes, this is done”?

• Wider User Story/Feature targets been met?
  • Does the work meet the wider goals it is attached too?
  • With reference to the above, someone could “correctly” complete a task, but be at odds with the context of what is going on around their work. Best to be safe.

• Deliverables been provided?
  • Have the assets or systems that were requested in the task been completed or implemented?

• Task been completed on time?
  • Especially in relation to any other work that depends on it. Audio has a lot of dependancies but that doesn’t mean others aren’t waiting on us!

• Test Cases/Expected Result been confirmed?
  • Has QA ensured that things are producing the expected result provided?
  • Does this new system produce any critical or high-level bugs that need to be fixed?

• Quality bar been hit?
  • Is it at a level we are happy with in game on expected hardware?
  • Also consider any playback formats here. Has it been checked in headphones and other speaker arrangements? If it’s in VR has it been checked using their built in headphones?

Outside of completion on time, these should be considered the main failure points for any task and must all be met before being considered “complete”. Other tasks may have additional points that must be met before sign off by the people agreed upon during the planning.

↑ back to overview
 

Feedback Process

It is also expected that iterations of work will be needed, either during the task or as part of the sign off process. This work should remain subject to the review process defined in the task.

Having somewhere for the audio team to share WIP passes informally, especially within a wider audio team, is always great to have. Building an environment where people are encouraged to do so and provide (USEFUL!) feedback results in both a better end result and better sound designers. It’s also great to share them with people doing related tasks, like animators or VFX artists. Games can and should have circular feedback processes where people can work off of what other disciplines are doing, and generally share knowledge about what each does and requires. Show and tells are generally great for this.

I also recommend wider audio health checks at the tail end of major milestones to ensure things are at the quality level they should be and that the audio work for the project remains realistic and achievable. This should involve the audio lead on the project, a producer/project manager, and a project stakeholder (like a game director). Things happen, plans change, so be sure to adapt correctly to what the project needs and make sure everyone agrees!

For other feedback, it’s useful for this to be:

• Relative and relevant to the task/Story/Feature at hand.

• Informative. Don’t just say “I don’t like it”. Why not? What issues do you have? What do you think is missing?
  • You don’t need to use audio terminology here either, the main thing is making sure both sides understand what is or isn’t working.

• Non-contradictory. Don’t say “I want it to sound like Tron, but not futuristic”. That doesn’t make sense!
  • If you’re not sure how to phrase things you should give references + examples. There might be specific elements from Tron you want/don’t want, but don’t know how to get that across. That’s fine! But people can only work to what they’re told.

How this feedback is delivered is also important!

Ideally this should be somewhere that’s visible as well as trackable or referenceable, such as in emails, on Jira tasks, or on Miro boards. Mainly so that it doesn’t get lost, but also so that others can see it too. Having a dedicated audio feedback channel on Teams or Slack with the relevant project stakeholders might be useful too, depending on how big your team is.

If you’re working with clients then their feedback should be delivered as quickly as possible, using the above rules. Where possible, an audio person should be looped into these conversations to ensure that information is being clarified with the person giving it and not through multiple filters.

Finally, one main thing for having a somewhat more formal and visible feedback process is to make sure that actions don’t go into feature/scope creep with additions on top of the original task. Other work can come out of tasks, but those should be separate things with separate timescales and requirements.

↑ back to overview
 

Maintenance and Documentation

For larger scale audio systems, or audio systems that will likely have people outside of the audio team interact with them, there should be some time given for the audio designer on the task to write up how they works and make it publicly available to the rest of the team on the likes of Confluence, Notion, or whatever tool you use. This is to ensure that people can investigate and work with systems with some degree of knowledge without having to completely rely on the audio person that made that system for information.

The audio team should also be creating and maintaining their own asset lists for tracking purposes. Do not neglect these!

Additionally, it is expected that over a project’s lifetime audio content and systems will need maintenance and updates. This should happen naturally as new user stories and features are planned out, however some issues may be raised during milestone audits or by the audio designer themselves.

---

Phew.

I apprciate that is a lot of info to read through, but hopefully there’s parts of it that make sense and you’ll want to integrate into your working practices. Again, it is quite granular but the main point is to get across what needs to be considered when it comes to making audio happen in games! Audio people can sometimes squirrel away in their own little fiefdoms, so if this helps someone bridge a gap in understanding their needs then that’s a win!

I’ve also not spoken about mixing at all there but I would consider it good practice to have some time set aside for it each milestone at the very least, especially later in the dev cycle when things are more content complete. People will do passes as they implement their work, but the game as a whole also needs time and care. There’s no point in all of their hard work going to waste if the game sounds bad!

But yeah, I hope this helps someone. Good luck!

 

Please share this:

 

---