DOCTOR AUDIO / TALK / AUDIO PRODUCTION
Developing an Anti-Crunch Audio Pipeline
Why audio crunch keeps coming back, why it is usually a visibility problem rather than a capacity problem, and a three-question routine audio leads can use to see work before it becomes an emergency.
Audio crunch rarely begins with someone announcing crunch time. It starts with a look at the calendar two days before content lock, and a feature that had been in development for weeks suddenly becomes a weekend. The work was not a surprise. Audio was surprised by it.
This publication is adapted from a conference talk. Across teams of different sizes, countries, engines and pipelines, the same pattern returned, and the question it raises is not how to survive crunch but why audio keeps arriving there.
The answer proposed here is that most audio crunch is a visibility problem before it is a capacity problem. Two maps and a three-question routine turn that idea into something an audio lead, even a department of one, can run every week.
TL;DR
- Crunch is a late discovery, not a surprise. The feature was in development for weeks. The systems did not appear overnight. Audio found out three days before the deadline.
- Visibility is cheaper than capacity. Capacity costs people, outsourcing and hours. Visibility costs attention and gives time to change how the work arrives.
- Two maps show where work comes from. One locates the project in the development cycle. The other maps each department to what audio will need from it and the signal that shows it coming.
- Three questions, on a cadence. Where is the game? What are they building? What will audio need next? Asked weekly, they turn the audio backlog into a prediction instead of a reaction.
What audio crunch looks like
Audio crunch rarely begins with someone announcing crunch time. It starts with an innocent look at the calendar and the realization that content lock is two days away. Somewhere, a decision was made that a broken build could go out for stakeholder review in a few days. A normal weekend turns into a survival game.
In that moment everything feels like it happened at once. Looking back, the feature had been in development for weeks. The systems did not appear out of nowhere. The work was not a surprise. Audio was surprised by it.
This pattern repeats across very different teams. The IGDA Developer Satisfaction Survey documents crunch as a broader industry issue. Over the last few years Flutu has worked with productions of different sizes, in different countries, engines and pipelines, and the same situation keeps returning. The question this paper tries to answer is not how to survive crunch but why audio teams keep arriving there, and what changes that.
There is a second layer to the problem. Audio is still looked down on in parts of game development. Sometimes it is a joke, sometimes a comment, and over time it becomes an attitude of undervaluing the work. This paper does not argue that sound, music and voice matter in games; that discussion is settled. But an undervalued discipline becomes one that absorbs pressure, unrealistic deadlines and stress, and keeps doing it out of passion.
Two readers are addressed. Producers: how to get better audio with less waste, better use of budget and a healthier production process. Audio professionals: how to use leadership and visibility to become part of the creative and production leadership of a project, even as a department of one.
The approach: think upstream
Audio in game development collaborates with almost every other discipline. Game design creates mechanics that need feedback. Programming creates the systems and hooks that let audio make noise at all. Level design creates spaces that need ambience. Narrative creates characters that need voices. Animation creates actions that need sound.
Illustrative diagram. Most of audio's future workload is created in these departments before it reaches audio.
Audio sits in the middle of that map. When something changes anywhere on it, there is a good chance something eventually changes for audio too. A large part of audio's future workload is not created inside the audio department. It is being created right now, somewhere else in the studio.
Traditionally audio is seen as a downstream discipline, and there is a reason: much of the work depends on other departments releasing work in progress. The approach in this paper reverses the direction of attention. Audio needs to see and predict the work being developed before that work reaches it. Seeing the work coming is what makes preparation possible.
An example. If the animation team is developing a set of animations, audio can talk to them now, understand what is being built, discuss details and start preparing the systems that will complement that work. When the animations arrive, audio is ready. Without that preparation, audio may still have the same five days to finish, but those five days feel completely different.
Thinking upstream means using what other departments are doing today to understand what audio will need tomorrow. That change of perspective is the core of the method. Everything else in this paper is a way to make it routine.
What stays with the game team: the information itself. Audio does not take over production planning. It reads production planning and prepares.
Visibility: capacity, maps and signals
Forecasting audio work means distinguishing genuine capacity limits from late discovery, mapping dependencies across the project and watching the signals already present in production.
Capacity versus visibility
The question is not only how much work audio can handle, but how early audio can see that work coming. These are two different problems with two different costs.
| Capacity | Visibility | |
|---|---|---|
| What it answers | How much work can audio absorb? | How early can audio see the work? |
| What it gives | A way to deal with the workload | Time to change how the workload arrives |
| What it usually costs | Money: more people, outsourcing, hours, and often more pressure on the team | Attention: routine, conversations, reading other departments' work |
| Effect on the project | Handles the emergency | Prevents the emergency; makes the project more predictable and cheaper |
| When it is unavoidable | When the volume of work genuinely exceeds the team | Never a substitute for capacity when volume is the real issue |
When audio can see the work coming, it can plan for it: distribute it across the schedule, make better technical decisions earlier, and avoid turning normal production into an emergency. Capacity problems are different. Sometimes there is no way around them and the team really does need more people. But bringing audio in early, with the same visibility other departments have, prevents a share of the situations that get solved with capacity today.
The shift is from being efficient at emergencies to being slightly better at seeing them coming. Two maps make that practical.
The two maps
The first map locates audio inside the development timeline. The second breaks down how audio relates to each discipline. Crossed, they tell audio not only what it needs today but what it will probably be doing next.
Map 1: audio across the development cycle
Audio's role changes throughout development, so the phase the project is in tells audio who to talk to, what those conversations should be about, and what to expect next.
| Phase | What audio is doing | Who to talk to | What to expect next |
|---|---|---|---|
| Pre-production | Sonic identity, core systems, pipelines | Creative direction, lead programmer, producers | Systems decided here define the asset work in production |
| Production | Asset creation, cinematics, level building | Level design, animation, narrative, cinematics | Volume rises; each department's output becomes audio tasks |
| Content lock and polish | Finishing, fixing, validation | Production, QA | The moment crunch usually surfaces if the earlier phases were not read |
This is a working map, not a universal model. Phase names and boundaries vary by studio. The point is that knowing where the project is gives audio a much better idea of where to look, and that broader perspective is what starts producing predictability.
Map 2: audio and each department
Once the relationships between audio and each discipline are explicit, useful predictions follow.
| Department | What they build | What audio will need from it | Signal to watch for |
|---|---|---|---|
| Game design | Mechanics | Feedback sounds for player actions and system states | New mechanic in the design docs or backlog |
| Programming | Systems and hooks | Implementation points, events, parameters | New system in the commit history or sprint |
| Level design | Spaces | Ambiences, reverb zones, spatial setup | New area blocked out |
| Narrative | Characters | Voice production: casting, recording, implementation | New character in the narrative docs |
| Animation | Sets of actions | Sound for each action, synced to animation events | New animation set in progress |
If level design is building a new area, that space will eventually need ambience. If narrative is developing a new character, voice production is coming. If animation is working on a new set of actions, those actions will probably need sound. Understanding what each department is building lets audio predict what it will need from it.
Crossing the two maps
Crossing the development cycle with the department map changes how the audio team thinks. The team stops sitting in its corner waiting to be told what to do and starts paying attention to what is happening around it.
If audio has downtime, development has not stopped. Somewhere in the studio someone is building a system, a mechanic, a level or a character that will become audio work soon. A broader view of development tells audio not only what it needs today, but what it will probably be doing next.
Having many tasks is not the problem. Discovering all of them three days before the deadline is.
Your backlog should predict work
How does audio actually see the work before it becomes work? By being proactive, and by reading the clues that already exist in the project. Not all information arrives on audio's desk directly, but it is usually available somewhere.
| Source | What it tells audio | When it is most useful |
|---|---|---|
| Main project documentation | What was planned during pre-production | Any time, especially when joining a project already in progress |
| Backlog and task boards | What other teams are building now and next | Production |
| Commit history | What has actually been changing in the project | Production, when documentation lags behind the build |
| Daily meetings | Day-to-day shifts in priority | Throughout |
| Milestones | What must exist by when, and therefore what audio must have ready | Throughout |
| Design documents | How a mechanic, level or character is meant to work | Pre-production and early production |
| Feature discussions | Decisions before they reach the backlog | Throughout |
The point is not to add a new tool. It is that audio needs to be part of the development process, with this information on its desk, so that the audio backlog is built from what other departments are building rather than from requests that arrive late.
The anti-crunch audio pipeline: three questions
The anti-crunch pipeline is not an expensive plugin added to the project. It is a way of looking with a broader view, and it comes down to three questions asked as a routine. Each answer feeds the next.
Locates the project in the development cycle (Map 1) and surfaces what happened before audio got there.
Gives visibility outside the audio department: what each discipline is working on this milestone (Map 2 and the signal sources).
Turns that visibility into a plan: tasks, systems and preparation scheduled before the work arrives.
Once this becomes routine, the team feels more supported by audio. Production gains confidence because it can see audio thinking ahead instead of waiting for the next ticket. Audio starts behaving less like a department waiting for work and more like a discipline that is part of development.
What the evidence establishes
This paper is a method drawn from practice. None of its claims rest on a measured study, and the table says so for each one.
- Observed pattern
- Something seen repeatedly across projects by the author. Real, but not counted.
- Design argument
- A structural description or cost comparison. It follows from how production works, not from a measurement.
- Heuristic
- A planning rule of thumb the author uses. Useful for estimation, not a result to quote.
- Pending validation
- Effects reported qualitatively that could be measured on a future project.
| Claim | Supporting evidence | Category | What it establishes | Limit |
|---|---|---|---|---|
| Audio crunch recurs across very different productions | Author's experience across projects of different sizes, countries, engines and pipelines | Observed pattern | A recurring pattern observed by one audio director | Not a survey; no count of projects |
| Most audio workload originates in other departments | Dependency map: game design, programming, level design, narrative, animation | Design argument | A structural description of where audio tasks come from | Descriptive; the share of workload is not measured |
| Visibility is cheaper than capacity | Comparison of what each requires (attention versus hiring, outsourcing, hours) | Design argument | A cost-structure argument | No cost figures; some situations still require capacity |
| An hour in pre-production saves five in production | Rule of thumb used by the author | Heuristic | A planning heuristic | Not a measured ratio; should not be quoted as a result |
| The three-question routine improves predictability and team confidence | Author's observation on projects where it was applied | Observed pattern; pending validation | An observed effect on team dynamics | Qualitative; not measured |
Trade-offs and limits
It cannot predict every problem
Some work really does appear late, and some projects really do need more capacity. The method reduces the share of surprises; it does not remove them.
It costs attention
Reading backlogs, commit history and design docs, and attending the right meetings, takes time away from asset work. On a department of one this is a real trade and needs to be scheduled, not squeezed in.
It depends on access
If audio is not in the meetings, not on the task boards and not reading the repository, the signals are invisible. Access is a production decision, not an audio one.
It is a practice, not a tool
Nothing here is a plugin, a template or a product. It is a routine that has to be kept up through the whole project.
Applying this to your project
A sequence for an audio lead or producer setting this up on a live project. The steps are in order: each one depends on the previous.
01 · Locate the project
Where is the game?
Write down which phase it is in and what was decided before audio joined. Read the main documentation first.
02 · Draw the department map for this team
What are they building?
List each discipline, what it is building this milestone, and what audio will need from it. Use the Map 2 table as a starting point and replace the rows with the real departments.
03 · Get access to the signals
Can audio see the information?
Backlog, task boards, commit history, design docs, dailies and milestone reviews. If any of these are closed to audio, raise it with production as a planning risk.
04 · Build the audio backlog from the department map
What will audio need next?
Not from incoming requests. Every item another department is building becomes a predicted audio item with a rough date.
05 · Prepare systems before assets arrive
What can be set up now?
Use the gap between seeing a feature and receiving it to set up the implementation structure, naming, events and parameters.
06 · Ask the three questions on a fixed cadence
How often?
Where is the game, what are they building, what will audio need next. Weekly works for most productions; align it to the sprint.
07 · Review the surprises
Which signal was missed?
When something still arrives late, trace which signal was missed and add it to the map.
Why this matters beyond the schedule
Audio still gets pushed toward the end of the development timeline far too often, and that naturally creates crunch. When everything becomes urgent the team is not only stressed. It becomes less creative. It stops experimenting, stops trying the weird idea, and chooses whatever can be finished before Friday.
When there is time to prepare, there is space to experiment, take risks, make mistakes and actually enjoy making the game. For anyone leading an audio team, creating that space is part of the job. That is what an anti-crunch pipeline is about.
In the end, we are making games. It should still be fun.
Questions We Can Answer
Why does Flutu publish technical whitepapers?
Around 99% of our projects are covered by strict non-disclosure agreements. That limits how much we can share through named case studies, project footage or internal production material.
Whitepapers give us a way to document how we have helped AA and AAA teams develop working methods, implementation standards and validation workflows, while respecting those confidentiality commitments. We focus on the methods, technical reasoning and evidence we can share without exposing protected project details.
This gives prospective partners a clearer basis for technical evaluation and due diligence: how we investigate systems, structure production work and check results. Each paper distinguishes what was implemented, what was observed and what remains unverified.
Does this work for a one-person audio department?
It is written for that case. The method costs attention rather than headcount, and the two maps and three questions can be kept by one person. The constraint is access: a department of one needs to be in the meetings and on the task boards, which is a production decision to request early.
Does this replace hiring or outsourcing when the team is overloaded?
No. Capacity problems are real and sometimes the only answer is more people. The method reduces the share of overload that comes from late discovery, so that capacity is spent on genuine volume rather than on emergencies that could have been planned.
Is there a tool or template for the maps?
Not a product. The two tables in this paper are the starting point. Most teams keep them in whatever already holds the backlog, so that the audio backlog and the department map live next to each other and get reviewed in the same meeting.