A game can have beautifully designed footsteps, weapons, dialogue, music, and ambience and still sound confusing when they all play together. One common cause is not the individual assets; it is the way the project routes and controls them. A useful audio mix hierarchy makes it possible to lower music without touching dialogue, apply a shared effect to a family of sounds, reduce background activity during a spoken line, and find the source of a mix problem without opening every event.
The goal is not to build the deepest possible tree. It is to create a small number of meaningful control points that match how the game needs to behave. This guide uses engine-neutral examples, with notes for Unity Audio Mixer, FMOD Studio, and Wwise where their terminology differs.
What should the hierarchy let you control?
Before creating buses or mixer groups, list the decisions the game needs to make at runtime and the adjustments an audio designer needs to make during a mix pass. These are related, but they are not the same thing.
- Player settings: music, sound effects, dialogue, and possibly ambience should have clear user-facing volume controls.
- Mix changes: conversations may need less music and combat noise; a pause menu may need the world to become quieter; a cave may need shared spatial processing.
- Asset-wide tuning: all weapon reports might need a small level adjustment, while footsteps need a different treatment.
- Debugging: when a sound is too loud, too wet, or missing, the signal path should make it possible to narrow down the cause.
- Growth: new enemy types or environment layers should fit the existing organization without requiring a new top-level bus for every asset.
These needs suggest a practical rule: organize the routing tree around groups that should be mixed or processed together, then create separate controls for sounds that need to be adjusted together even when they live in different branches. The distinction matters because a routing bus and a volume-control object are not always the same thing.
A starter hierarchy for a small or mid-sized game
Begin with a readable tree and add branches only when they provide a real mixing decision. For a typical action or adventure game, this is a sensible starting point:
Master
├── Music
│ ├── Music_Main
│ └── Music_Stingers
├── Dialogue
│ ├── Dialogue_Player
│ ├── Dialogue_NPC
│ └── Dialogue_VO_Radio
├── SFX
│ ├── Player
│ │ ├── Movement
│ │ ├── Combat
│ │ └── Interaction
│ ├── Enemies
│ │ ├── Combat
│ │ └── Vocalizations
│ ├── Weapons
│ ├── Impacts
│ ├── UI
│ └── Foley
├── Ambience
│ ├── Beds
│ ├── Local_Emitters
│ └── Weather
└── CinematicsTreat this as an example, not a required standard. If the game has no voiced dialogue, the dialogue branch may be unnecessary. If weather is always part of the ambient bed, it may not need its own child bus. A mobile puzzle game may need only Master, Music, SFX, and UI. A large RPG may need separate dialogue, creature, weapon, cinematic, and environmental branches because those groups have different mixing and debugging needs.
Keep the first level aligned with the largest decisions: what players can change in settings, what the mix needs to duck or mute, and what the team regularly balances as a group. The second level can reflect gameplay ownership or sound family. Avoid making every asset its own branch; individual events and objects already provide a place to adjust individual sounds.
Routing hierarchy, asset folders, and volume controls are different jobs
One of the easiest ways to make a project hard to maintain is to assume that the asset browser, the signal-routing tree, and the player’s volume settings must have identical structures. They answer different questions.
| Structure or control | Question it answers | Example |
|---|---|---|
| Asset organization | Where does the team find and maintain content? | Weapons / Rifle / Fire, Reload, Tail |
| Routing hierarchy | Which signals are combined and processed together? | Weapon fire routes through SFX / Weapons |
| Player-facing volume control | What can the player turn up or down? | SFX volume controls several effect buses |
| Snapshot or mix state | What should change temporarily in a gameplay situation? | Dialogue state lowers selected competing groups |
| Per-event or per-object parameter | What needs individual runtime behavior? | A distant explosion loses high-frequency detail |
In Unity, Audio Mixer Groups form a routing hierarchy; audio sources route into groups, where effects and other processing can be applied. Snapshots capture parameter settings and can transition during gameplay. Unity’s documentation also distinguishes the audio mixer structure from the scene graph, which is useful when deciding where audio should be controlled. See the official Unity Audio Mixer overview for the current concepts and workflow.
FMOD Studio uses group buses for routing and return buses for shared effects. Its VCAs can control the levels of multiple buses or events that do not share the same routing path; a VCA is a control layer, not a bus through which the audio signal passes. This is useful for a global SFX slider that needs to affect several separate branches. The FMOD Studio mixing documentation explains group buses, returns, VCAs, and snapshots.
In Wwise, the Master-Mixer Hierarchy defines bus routing and processing, while the Actor-Mixer Hierarchy organizes sound objects and containers. Keeping those roles clear helps prevent a content folder from becoming a substitute for a mix plan. Audiokinetic describes these hierarchies in its Wwise Audio tab documentation.
Decide what belongs on a parent bus
A parent bus is most useful when its children genuinely need a shared adjustment or processing stage. For example, a Weapons bus can provide a single place to balance all weapon families. A broader SFX bus can then adjust the overall effects balance without changing music or dialogue. But a parent should not become a dumping ground for unrelated sounds simply because they are all “game audio.”
Ask three questions before adding a branch:
- Will these sounds often need the same change? If all UI clicks should be quieter than gameplay effects, a dedicated UI group gives you a meaningful control point.
- Do they need the same processing? A shared reverb send may make sense for several indoor emitters, but a dry menu click should not inherit the same treatment merely because it is also an SFX.
- Will someone need to inspect or mute this group during debugging? A distinct Dialogue or Enemy Vocalization bus can help isolate a problem quickly.
Do not add a bus just to mirror a noun in the game design document. “Boss,” “forest,” or “rare loot” may be useful gameplay labels, but they only belong in the routing tree if the audio for that category needs a shared mix operation. Otherwise, use event naming, switches, parameters, states, or asset organization to represent the distinction.
Build volume controls without creating routing knots
Player settings are easiest to reason about when their names correspond to what the player expects. A basic settings screen might expose Music, SFX, Dialogue, and UI. Decide explicitly whether UI belongs under SFX or has its own slider; either choice can work, but the menu label and actual routing must agree.
If the audio middleware supports a separate control layer—such as an FMOD VCA—use it when one setting needs to affect multiple branches that do not share a parent bus. If your engine uses exposed mixer parameters, map each setting to the intended group or parameter and document the mapping. Avoid connecting one slider to both a parent and its child, which can apply the same adjustment twice.
Use a simple mapping table during implementation:
| Settings control | Controls | Check before shipping |
|---|---|---|
| Music | Music bus or its dedicated control | Gameplay music and menu music both respond as intended |
| SFX | Gameplay effects, impacts, foley, and other agreed categories | Dialogue and music do not change accidentally |
| Dialogue | Player and NPC dialogue, including radio VO if desired | Subtitle and accessibility settings remain independent |
| UI | Menu navigation, confirmation, alerts, and interface feedback | UI remains audible when gameplay effects are reduced |
Test each control at its minimum, middle, and maximum values. Also test the combinations players can actually create: SFX at zero with UI audible, dialogue reduced while music remains unchanged, and music muted during a cinematic. If a category is meant to be included in two controls, define that intentionally rather than letting it happen as a side effect of the hierarchy.
Use snapshots and shared effects for situations, not permanent categories
A routing tree describes the persistent signal path. Gameplay situations often need temporary changes across several branches, and that is where snapshots, mixer states, or equivalent runtime controls become useful. A dialogue moment might lower music and selected ambience; a pause menu might attenuate the game world but leave interface sounds untouched; an underwater state might change filtering and sends without moving every sound to a new bus.
Scope each state to the properties it should change. If a dialogue snapshot modifies Music, Ambience, and selected Combat groups, it should not also rewrite unrelated UI levels or the master output. Small, purposeful snapshots are easier to combine and debug than one enormous “everything changes” preset. Unity’s snapshots capture mixer parameter settings, while FMOD snapshots can target specific bus and effect properties; consult the relevant engine documentation before relying on exact transition behavior.
Shared processing also benefits from clear routing. If several environmental emitters need the same reverb character, route or send them to a common return where supported instead of inserting a duplicate heavy effect on every event. Keep dry and wet balance intentional: too much shared reverb can blur transients and make spaces feel less distinct. For spatial systems, the routing design should complement—not replace—distance, occlusion, and per-emitter positioning. The guide to audio occlusion and obstruction covers the separate problem of how geometry affects a sound’s path to the listener.
How can you tell whether the hierarchy is working?
A tidy-looking tree is not proof of a useful mix. Validate it with specific tasks that an audio designer or player must be able to perform. Start with a representative gameplay scene containing dialogue, movement, combat, ambience, UI, and music; then run the following checks.
- Solo and mute test: each major branch should be possible to isolate without unexpectedly removing unrelated sounds.
- Settings test: move every player volume slider independently and verify that only the documented categories change.
- Dialogue test: trigger a spoken line during busy gameplay and check whether the mix change protects intelligibility without making the world disappear.
- Shared-effect test: bypass or adjust a return effect and confirm that only the intended sources change.
- Transition test: enter and exit pause, dialogue, underwater, and combat states rapidly. Check for stuck snapshots, abrupt level jumps, or parameters that fail to return to baseline.
- Growth test: add one new sound category. If it requires several unrelated routing exceptions, revisit the hierarchy rather than adding patches indefinitely.
Keep a short routing map alongside the project. For each top-level group, write down its purpose, who owns it, whether it has a player-facing volume control, and which runtime states can modify it. This small piece of documentation helps programmers avoid routing new events directly to Master and helps sound designers understand where a shared adjustment should happen.
If your project already has a large library, do not rebuild the whole mix tree in one risky pass. Pick one category, reroute it, test it in a representative scene, and compare the result before moving on. The same incremental approach works when refining source assets: use the game sound effects workflow guide for individual effects, then make sure those effects behave correctly once they enter the wider mix. For projects with changing combat intensity, the dynamic combat audio system in Wwise shows how event logic and mix priorities can sit on top of a deliberate routing design.
The best hierarchy is the smallest one that gives the team the control it actually needs. Start with a few obvious branches, verify the player settings and gameplay transitions, and add complexity only when a real mix or implementation problem exposes a missing control point.