Sound Call Models
15 game audio implementation patterns with explicit triggers, ownership and stop behavior.
Audio implementation becomes difficult when similar sounds are triggered through unrelated code paths. A world loop, an animation cue and a UI click need different behavior, but every call still needs a clear event source, playback owner and exit path.
At Flutu, we organize those decisions into 15 Sound Call Models across five groups. Each model defines its trigger, event recipe, lifecycle and integration boundary. This gives sound designers and programmers a shared contract to inspect before another call path is added to the game.
The catalog sits above the game's existing audio API and registry. It standardizes decisions without taking ownership away from gameplay, animation, VFX or dedicated ambience systems.
TL;DR
- 01
15 defined patterns. Five groups cover documented scene, animation, VFX, code, UI and voice use cases.
- 02
A traceable event source. Each model specifies where reviewers find the assigned event, from component to registry.
- 03
Stopping is part of the call. Loops define who owns completion, release and interruption cleanup.
- 04
A bounded integration surface. Green, Yellow and Client code identify how far an audio team can act without changing gameplay ownership.
When playback patterns drift
A loop can start from an emitter, gameplay code or a proximity trigger. All three paths may work, yet each can assign the event somewhere else and clean up playback differently.
For a new implementer, the central question becomes “Which model applies?” instead of “Which old script should I copy?”
The model contract
A sound-call model is a named implementation pattern that defines who triggers playback, where the event is assigned, which event configuration is valid and how the instance ends. The game's registry, playback API and gameplay logic remain in place; the model provides a consistent contract above them.
We select the model by trigger ownership and lifetime before choosing a component. Two identical looping sounds can require different patterns if one follows an effect's lifetime and the other is stopped by gameplay logic. The distinction matters during interruption, scene unloading and debugging.
Event recipe checks
Check the event family prefix (sx_, mx_, amb_, vo_), spatial mode, one-shot or looping behavior, permitted output bus, 3D distance and model-specific parameters. Rules apply only to models that need them: a UI one-shot should not inherit the distance requirements of a world-space loop.
Prefix checks catch naming mistakes; routing checks protect expected mix controls, and duration and release checks prevent a short cue from behaving like a persistent voice. Recipe validation happens before creation. Lifecycle validation still belongs in a running game.
Where the grammar has exceptions
SxCodeOneShot and SxCodeLoop do not declare 2D or 3D in their names, so the caller must specify spatial behavior. Amb2DSceneBed is an entry point into a dedicated ambience system, not a general-purpose loop implementation.
The 15-model catalog
Each entry answers three practical questions: what behavior it covers, where its event is assigned, and who owns the change. The five groups define model names, uses, event sources and integration ownership.
Scene
6 models · original model table| Model | Use it for | Event comes from | Care |
|---|---|---|---|
| Sx3DLoop | A loop on a world object, such as a machine, water feature or insects. | Project sound registry | Yellow |
| Sx2DStingerOneShot | A stinger on entry, optionally using a playlist that advances with progress. | Component | Green |
| Sx3DPassThroughOneShot | Playback as the player moves through foliage or a soft object; trigger size derived from object meshes. | Component | Green |
| Mx2DAreaLoop | A music zone. | Project sound registry | Yellow |
| Mx2DGateLoop | Music started by crossing a passage one way and stopped by crossing back. | Component | Green |
| Amb2DSceneBed | The ambience bed for a scene or region. | State of the shared ambience event | Client code |
Animation
2 models · original model table| Model | Use it for | Event comes from | Care |
|---|---|---|---|
| Sx3DAnimationOneShot | A sound on an animation frame, such as a step, wing movement or door opening. | Cue asset placed in the animation | Green |
| Sx3DAnimationLoop | A loop started and stopped by animation events, with a release tail. | Component | Green |
VFX
2 models · original model table| Model | Use it for | Event comes from | Care |
|---|---|---|---|
| Sx3DVfxOneShot | The moment an effect spawns particles, such as a burst or pulse. | Component | Yellow |
| Sx3DVfxLoop | Playback for the duration of an effect, such as a glow or aura. | Component | Green |
Code
2 models · original model table| Model | Use it for | Event comes from | Care |
|---|---|---|---|
| SxCodeOneShot | A gameplay action, such as a pickup, impact or puzzle step. | Project sound registry | Client code |
| SxCodeLoop | A loop owned by gameplay logic. | Project sound registry | Client code |
UI and voice
3 models · original model table| Model | Use it for | Event comes from | Care |
|---|---|---|---|
| Sx2DUIOneShot | Hover, press or click on a UI element. Plain buttons in the described setup already have default playback. | Component | Green |
| Vo2DOneShot | Non-spatial voice, such as narration. One event per line. | Component | Client code |
| Vo3DOneShot | A character's voice in the world. One event per line. | Component | Client code |
Tables retain their own horizontal scroll on smaller screens.
Spline-shaped sources and the full ambience system use dedicated tooling; this catalog defines only their relevant interface.
Playback lifecycle and choosing a model
For a loop, the critical design decision is what stops it when its owner disappears. Animation, VFX, trigger volumes and gameplay logic have different lifetimes. Each pattern needs a normal stop path, interruption cleanup and a release strategy that follows its real owner.
We inspect repeated starts, overlapping triggers, cancellation, object disable and scene transitions separately. A loop that plays correctly once can still leak an instance or restart repeatedly at a boundary.
Choosing by trigger and duration
Placed world loops: Sx3DLoop. Area/gate music: Mx2DAreaLoop or Mx2DGateLoop. Animation: Sx3DAnimationOneShot or Sx3DAnimationLoop. VFX: Sx3DVfxOneShot or Sx3DVfxLoop. Code: choose the corresponding one-shot or loop, then specify spatial behavior. UI, voice and scene ambience use their catalog-defined patterns.
Where stops actually come from
Area loops stop on exit; gate loops stop on the reverse crossing; animation loops receive paired start/stop cues with a release parameter; VFX loops stop on completion/cancel/disable; code loops require explicit gameplay stop and disable cleanup. The ambience bed delegates transitions to its dedicated system.
Choose stop delays and restart cooldowns against actual movement and trigger behavior. Validate repeated crossings, cancellation, disable and scene transitions in the target build, including the final voice and instance state.
Integration boundaries and tooling
Integration boundaries are explicit because an external audio team works inside a host studio's codebase. Green models stay within supported audio-owned objects and components. Yellow models require a small host-file change reviewed before application. Client code models require a gameplay-programmer handoff.
This classification controls who makes a change, who reviews it and where a bug is traced later. Even audio-owned changes need checks for duplicate calls, event compatibility and cleanup; a reviewed code handoff needs the same playback contract as a created component.
What tooling can do
Use the catalog to suggest models based on an event and target object, check recipes, then create supported components or prepare exact host-file changes for review. Client-owned gameplay changes generate instructions rather than direct edits to gameplay code.
Keep one source of truth
Maintain the model definitions in one versioned catalog for validators, creation tools and written documentation. Review the catalog whenever a project adds an uncovered playback behavior instead of inventing a local call path.
Validate the contract in the running game
A consistent model name is useful only when its event configuration and runtime behavior agree. We evaluate each pattern at four boundaries: event compatibility, playback lifecycle, ownership of integration changes and the result the player actually hears.
Event compatibility
Check the selected event against its recipe before creating components: family prefix, spatial mode, duration, output bus, distance and required parameters. A successful name match is never the entire contract.
Playback lifecycle
Trigger the sound normally, repeat the trigger and interrupt its owner. Inspect start/stop pairing, release tails, boundary oscillation and surviving voices after effect cancellation, object disable or a scene change.
Integration ownership
Review Green component creation, Yellow host-file edits and Client code handoffs against the owning team's responsibilities. Trace duplicate playback to its event source and verify that the expected system performs cleanup.
Runtime and player review
Use profiler sessions to inspect active instances and lingering voices while listening for incorrect attenuation, abrupt release, unexpected routing and inconsistent playback through real transitions.
Acceptance principle: the implementer should be able to identify an event's source, expected behavior, owner and exit path without reverse-engineering several unrelated call sites.
For a closer look at inspecting live playback and identifiable sources in Unity and FMOD, read Scene Audio Debugger.
Maintaining and extending the catalog
A shared catalog works when its definitions have an owner and its scope stays controlled. We keep specialized systems separate, review uncovered behaviors before adding a model and avoid migrating stable legacy code without a production reason.
Standardize new work first
Apply the models to new audio calls. Migrate existing scripts when a bug, feature change or maintenance task provides a concrete reason, rather than creating risky churn.
Keep dedicated systems dedicated
Spline-based rivers and coastlines need specialized placement tooling. The full ambience system has its own lifecycle; Amb2DSceneBed is its catalog interface.
Give the catalog an owner
New combinations need review, recipes need maintenance, and creators must be kept compatible with changes in the studio's registry and audio API.
Building a catalog for your project
Begin with the paths already shipping. The goal is a system that explains who starts and stops a sound, not a naming convention that looks organized in a spreadsheet.
- Inventory. Find event assignments, call sites, ownership and stop behavior in existing components, code, animation and VFX.
- Define. Group supported patterns by family, space, trigger and duration; document exceptions explicitly.
- Validate. Add recipe rules for event naming, spatialization, duration, routing, distance and parameters.
- Assign ownership. Separate safe audio-owned creation, reviewed host edits and gameplay-code handoffs.
- Test before extending. Exercise playback completion, repeated triggers, disable, interruption and scene transitions. Retain the captures needed for later evidence.
Make the new-work path consistent first. Expand the catalog when a real use case cannot be expressed by an existing contract.
Questions We Can Answer
Why does Flutu publish technical whitepapers?
To make our technical decisions inspectable. Doctor Audio explains the contracts, trade-offs and validation workflows we use to reason about game audio systems, while keeping client code and project assets confidential.
What is a Sound Call Model?
A named pattern that defines a sound's trigger, event source, recipe, spatial behavior where relevant and stop or release responsibility.
Who stops a loop?
It depends on the model. Animation, VFX, area/gate and code loops have distinct owners and interruption paths. Stop and release must be validated in the host project.
What do Green, Yellow and Client code mean?
Green is audio-owned component creation, Yellow requires a reviewed host-file change, and Client code delegates gameplay changes to the studio's programmers.
What does the validator check?
Applicable rules for event prefix, 2D/3D behavior, duration, routing, distance and required parameters. Passing these checks does not replace gameplay testing.