Building Audio That Survives Production: A FIFA Heroes Audio Retrospective
A persistent misconception in game audio is that the assets are the product. A sound effect, a piece of music or a middleware event has no real production value until it has been proven inside the game itself. Under the shifting pressures and expectations of production, even a seemingly simple asset can expose the distance between making audio and making audio that actually functions.
I joined FIFA Heroes in an audio design capacity. As the project developed, the work moved beyond asset creation and into the practical leadership of the audio pipeline: making audio coherent, testable and maintainable across design, programming and production. Two weeks into the project, my role had expanded into Audio Lead.
What follows is a collection of lessons about what happens around the assets themselves: implementation, ownership, review, visibility and the systems required to make audio survive contact with a live game project.
Extracting the Audio Brief from the Game
The first phase began without a conventional audio brief, instead relying on gameplay footage. I was given the main menu and a full gameplay match. This meant the early requirements had to be inferred from the loop itself: what the player needed to hear, what the game needed to communicate and where the absence of sound would make the experience feel unfinished.
Moving into production, the initial focus was the core language of play: from ball contact and physical impact to match-state feedback. This is where documentation becomes part of the audio work itself. Each batch of sound effects needed usable variation, though it also needed a place inside an FMOD structure that programming could understand and act upon. A sound with no clear trigger, playback behaviour or in-game intention is only half delivered, regardless of how finished it may seem inside the session. The objective was therefore to give the programming team enough context to close the loop. The work was only complete once the game could call the event reliably in context.
Where no conventional audio brief exists, the requirements inferred from gameplay should be documented and reviewed before too much production work is built around them. Gameplay can provide the initial direction but assumptions around triggers, behaviours and implementation requirements need to be made explicit before asset work is treated as complete.
Implementation Is a Loop
Once the first FMOD structures and implementation notes were in place, the work became iterative. I would prepare sounds, events and implementation requirements and review the result once it entered the game. I would then identify behaviours that were not working as intended, document the issue and clarify the target. Where necessary, I provided reference footage so that an implementation goal could be seen rather than inferred from a written description.
This is where intention has to answer to reality. Assets, middleware organisation and documentation prepare the ground. The system earns its place once the game can use those events reliably enough for the team to judge them in context.
That process also exposed an important distinction between audio production and audible progress. A substantial amount of work can exist upstream of the build: assets may be complete, with their FMOD events prepared. Expected behaviours can be documented and implementation requirements defined, though none of that guarantees that the current playable build will immediately reflect the same level of progress.
For that reason, audio status is more useful when divided into actual production states:
Asset creation: does the sound exist?
Middleware setup: is it structured correctly?
Hook availability: can the game call it?
Behaviour: does it trigger and behave correctly?
QA: has it been tested in context?
Iteration: has it been revised after gameplay review?
Collapsing all six into a vague notion of “audio progress” obscures the live status of audio in a pipeline. One must track audio by its own production state, not simply by whether it can be "heard" yet.
When Audio Design Becomes Audio Leadership
The formal role I entered the project with did not fully describe the function the production eventually required. The work began with assets, FMOD structures and implementation notes. Daily responsibilities soon spanned further, into production.
I was reviewing audio in build, diagnosing failed behaviours and clarifying implementation requirements for the development team. As more direct programming support became available, I began helping define the audio implementation roadmap, prioritise audio tasks, review implemented work and report back to game direction on audio as a coherent production function.
Much of the work involved in leading audio is difficult to see from the finished assets alone. Sound effects can be tallied, a piece of music can be played, though the coordination required to make those elements behave reliably across implementation, testing and multiple disciplines is considerably less visible, unless explicitly communicated.
As the project became increasingly dependent on implementation planning, feature ownership and cross-team coordination, the role expanded naturally into audio leadership.
The final Audio Lead credit reflected the function the production had come to require.
Build review, implementation planning, task prioritisation, cross-team coordination and reporting are not incidental extras. Once audio responsibility expands beyond asset delivery, the role needs to account for the production system surrounding those assets.
Visibility Is Not Approval
Another useful distinction is between making work visible and having that work explicitly reviewed. Contemporary game development produces no shortage of ways to demonstrate progress: sprint reviews, build videos, task trackers, milestone reports and internal demonstrations. All of those are useful, but none of them necessarily constitutes approval.
For audio, this distinction is vital, because decisions compound. A direction that remains provisional for several iterations can gradually acquire dependencies elsewhere in the project. If meaningful feedback arrives later, what might once have been a straightforward adjustment can become a considerably larger revision. The solution is fairly straightforward: review status should be explicit.
Teams need a shared distinction between:
Work that has been shown;
Work that remains provisional;
Work awaiting review;
Work that has received clear approval.
“No news is good news” is a poor production mechanism. Someone needs to own the review, respond to the work and make its status explicit. Visibility and approval should be treated as separate production states. A progress update can demonstrate where the work currently stands. It cannot replace a defined review owner, review cadence and sign-off path.
Reporting Should Serve Production
Audio leadership also involves keeping progress legible to people who may not be involved in the daily implementation process. That can be useful, though it can also become expensive if reporting is disconnected from decision-making.
For audio, progress often moves through several layers before the result becomes fully audible in the build. Reporting therefore works best when it answers a production question:
What is being assessed?
Who has authority to respond?
What decision is the update intended to facilitate?
Without those answers, reporting risks becoming proof-of-work administration rather than a mechanism for alignment.
A reporting cadence should have a defined production function. Its value lies in helping the right people understand the state of the work and make the decisions required to move it forward.
Integration Changes the Meaning of “Done”
Game audio rarely exists in isolation from the rest of the build. An event may behave correctly inside FMOD. A system may work inside a controlled implementation environment, or a feature may appear complete inside one development stream.
The proof is in whether it continues to work once integrated into the environment in which the game is actually being made. This makes integration a meaningful production milestone in its own right. Audio developed outside the mainline build should remain provisional until it has survived integration and regular in-game QA. Otherwise, a task can look complete on a tracker while the behaviour remains unproven in the only context that actually <redacted> matters.
Integration can expose changes in hooks, dependencies, timing and feature logic that were perfectly functional when the audio work was first prepared. That does not invalidate prior progress, though it does mean that “done” has to include survival inside the current game.
Audio should only be treated as fully proven once it has survived the live production environment and regular in-game review.
Audio Hooks Need Feature Ownership
As FIFA Heroes developed, audio reached beyond obvious gameplay actions and into the wider feature layer. Interface movement, progression feedback, cinematics and gameplay systems all required reliable hooks.
An FMOD event does not make a behaviour dependable by itself. Each sound needs an implementation path, a stable trigger and enough review context to function consistently inside the build. That becomes particularly important when features are revised: a menu can have working audio in one iteration and lose part of that behaviour when the underlying feature changes. From the audio side, nothing may have been deliberately removed - the conditions that allowed the event to fire have simply changed.
If that dependency is not considered during the feature revision, audio can become a cleanup task for somebody else to discover later. A useful definition of “done” for a feature should therefore include its audio behaviour.
When a feature changes, the audio attached to it should be preserved, updated or explicitly flagged as part of the same work. Audio ownership needs to follow the feature.
Redistributing Audio Ownership
This eventually informed a broader workflow principle. A central audio function can define standards, build assets, maintain middleware structures, establish behaviours, as well as evaluate results. It should not, however, become solely responsible for rediscovering every audio dependency elsewhere in the game.
Gameplay systems may sensibly remain close to dedicated audio and programming support. Feature-specific audio is often better maintained alongside the teams already changing those features. The workflow therefore became more targeted and distributed: when a team required audio for a feature, the requirement could be tracked explicitly. The necessary assets were subsequently supplied, with the intended behaviour documented and the relevant audio structure maintained. The team responsible for the feature could then account for the associated implementation, as part of that feature's development. This made the work more visible, reducing the likelihood of audio appearing late as an overlooked requirement.
A central Audio Lead can define the system, provide the assets, maintain the middleware structure and review the result. The teams changing individual features still need to preserve the audio behaviour attached to those features.
Conclusion
Game audio cannot be treated simply as a content layer. It has to exist inside the production system early enough for ownership, review, implementation and visibility to become part of the work itself. The assets are only the beginning; their value is proven by what surrounds them. The hooks that call them, the systems that control them, the teams that maintain them, the review process that approves them and ultimately, the build they have to survive contact with.
That was the largest shift in my own role on FIFA Heroes. I entered the project making audio.
I finished it helping to define how audio moved through the production. The value of an Audio Lead lies in making sure the audio survives the conditions under which the game is actually made.
Comments