Sound Call Models
Game audio implementation patterns for triggering sound in games
A looping object, an animation cue and a UI click need different playback behavior. They still need a shared way to describe who starts the sound, where its event is assigned and who stops it.
Flutu Sound Call Models is a catalog of 15 implementation patterns built around those decisions. The models sit above a project's existing audio API and registry. For a concrete middleware integration reference, see the FMOD for Unity documentation. This paper explains their naming grammar, event requirements, lifecycle rules and integration boundaries.
TL;DR
- The catalog defines 15 models across five groups. Each identifies a playback pattern, an event source and an integration care level.
- Names describe family, spatial behavior, trigger and duration where those fields apply. Three catalog names use exceptions explained below.
- Event recipes check compatibility before creation. They cover prefixes, spatialization, duration, routing, distance and parameters.
- Stop behavior is part of the model contract. Gameplay and dedicated audio systems retain their own responsibilities.
- The source reports qualitative production observations. It supplies no timing benchmarks, defect counts or retained profiler captures for independent comparison.
When playback patterns drift
A loop on a world object may start from an emitter, gameplay script or proximity component. Older settings may be copied into new features, and two paths may start the same sound. Each path can work alone while ownership becomes unclear.
Reviewers must trace events across registries, components, animation cues and gameplay code. Stop behavior may depend on disable, destruction or an explicit call. Copying the first example found adds another variation.
The catalog provides a shared vocabulary for playback behavior: a defined pattern to select and a known contract to inspect. It addresses inconsistent ownership before another local implementation is added.
Designing the sound-call contract
Define the contract before the call
A sound call model is a named implementation pattern. It describes how a sound is triggered, where its event is selected, what the event must support and how playback ends.
The approach has five design goals:
- Assign each supported use case to one model. When an uncovered behavior appears, review the catalog before adding another local implementation.
- Make names informative enough to guide an implementer toward the expected behavior.
- Define stopping and release as part of the pattern.
- Wrap the host audio API and registry so existing systems can continue to operate.
- Check the event and target object before creating the implementation.
These are design goals for the supported catalog, rather than evidence that 15 models cover every project.
The creation workflow takes an audio event and a target object as inputs. The catalog supplies candidate models, recipes and integration boundaries. The workflow then validates the selection, creates supported components or produces instructions for changes that remain with the studio's programmers.
The host project retains its playback API, registry, gameplay logic and dedicated systems. A model adds a consistent call contract above that infrastructure; it does not become a replacement audio engine.
Read the behavior in the name
The regular naming pattern is Family + Space + Trigger + Length. Some names omit fields or use a specialized suffix, so the catalog remains the authoritative reference.
| Part | Values used by the catalog | Meaning |
|---|---|---|
| Family | Sx · Mx · Amb · Vo | Sound effects, music, ambience or voice. |
| Space | 2D · 3D | Whether playback is positioned in the world. |
| Trigger | Area · Gate · PassThrough · Stinger · Animation · Vfx · Code · UI · no explicit trigger | The trigger or owning context. A model with no explicit trigger can represent a placed object. |
| Length | OneShot · Loop | Playback that ends by itself, or playback requiring an explicit stop contract. |
Sx3DAnimationLoop describes a spatialized sound effect whose start and stop follow animation events. Mx2DGateLoop describes non-spatial music controlled by a directional crossing.
Event prefixes follow the same family vocabulary: sx_, mx_, amb_ and vo_. The validator checks whether the assigned event's prefix matches the model family.
Three names need explicit interpretation. SxCodeOneShot and SxCodeLoop do not encode a spatial mode in their names; the name alone does not establish whether a particular code call is spatialized. Amb2DSceneBed uses SceneBed rather than a OneShot or Loop suffix and refers to a state of the shared ambience event. It is an interface to a dedicated system, not a description of that system's complete lifecycle.
The 15-model catalog of game audio implementation patterns
The event-source column is also a tracing guide: it identifies where a reviewer should look for the assigned event.
Scene
| 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
| 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
| 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
| 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
| Model | Use it for | Event comes from | Care | Creation-tool availability |
|---|---|---|---|---|
| Sx2DUIOneShot | Hover, press or click on a UI element. Plain buttons in the described setup already have default playback. | Component | Green | Not identified as withheld in the source |
| Vo2DOneShot | Non-spatial voice, such as narration. One event per line. | Component | Client code | Not yet released |
| Vo3DOneShot | A character's voice in the world. One event per line. | Component | Client code | Not yet released |
The group counts are 6 Scene, 2 Animation, 2 VFX, 2 Code and 3 UI and voice models. Inclusion in this catalog does not establish creation-tool availability for every entry.
Spline-shaped sources, such as rivers or coastlines, and the full ambience system use dedicated tools. Amb2DSceneBed provides the catalog's scene-bed entry point without replacing the broader ambience system.
Playback behavior and lifecycle
Check the event recipe
The model supplies one half of the contract. The audio event supplies the other. A recipe checks whether the selected event supports the behavior the model expects.
The following are six check categories. Their applicability depends on the model; a non-spatial one-shot does not need the same distance and release configuration as a spatial loop.
| Check | Rule | Illustrative failure when mismatched |
|---|---|---|
| Name prefix | Match the event prefix to the model family. | An event assigned to the wrong family escapes the intended convention. |
| Space | Use a spatialized event for a 3D model and a non-spatialized event for a 2D model. | A UI sound changes position as the camera moves. |
| Length | Use looping events for loop models and events that finish for one-shot models. | An intended one-shot continues occupying a voice. |
| Output bus | Route the event to a permitted bus or one of its children. | Expected global volume or ducking does not affect the sound. |
| Max distance | Set distance deliberately for 3D models. | Audibility ends at an unsuitable distance. |
| Parameters | Provide required or suggested parameters where applicable, such as a release tail or playlist step. | A loop stops abruptly instead of following its intended release. |
The failure examples explain the purpose of the checks; they are not a list of reproduced production bugs.
Matching a prefix alone does not establish correct routing. Likewise, passing a recipe check does not establish that a scene transition, animation interruption or effect shutdown has been validated in execution.
Stopping is part of the model
Starting playback is only one part of the call contract. A loop also needs an owner and a defined exit path.
| Pattern | Stop and release contract described by the source | Validation focus |
|---|---|---|
| One-shots | Playback ends by itself; the model manages instance release. | Confirm completion and release with the actual event. |
| Area and gate loops | Leaving an area or crossing back stops playback. A short stop delay and restart cooldown reduce repeated switching at the boundary. | Test entry, exit and repeated boundary crossings. |
| Animation loops | Two named animation events share a key for start and stop. Playback exits through a release-tail parameter. | Test the paired events and interruption paths. |
| VFX loops | Playback follows the effect's lifetime. | Test effect completion, cancellation and object disable. |
| Code loops | Gameplay requests stop and release. Object disable also performs cleanup. | Test both explicit gameplay stop and disable during scene changes. |
| Placed object loops | The catalog identifies Sx3DLoop, but the source does not specify its complete disable and destruction contract. | Define and verify the exact lifecycle before adapting this pattern. |
| Scene ambience bed | Amb2DSceneBed selects a state in a dedicated ambience system. | Verify ownership and transitions in that system rather than assuming the generic loop rules apply. |
The validation column is an adaptation checklist, not a record of completed tests. The source does not provide timings for stop delays, restart cooldowns or release parameters; these remain implementation decisions for the target project.
Choose by trigger and duration
Start with the audio family and spatial behavior. Then identify what owns the trigger and whether playback finishes by itself.
| Trigger or owner | Selection rule |
|---|---|
| Placed world object | Use Sx3DLoop for the catalog's persistent object-loop pattern. |
| Entry or pass-through | Use Sx2DStingerOneShot for a stinger on entry, or Sx3DPassThroughOneShot for playback as the player passes through an object. |
| Music region or crossing | Use Mx2DAreaLoop for a zone and Mx2DGateLoop for a directional crossing. |
| Scene ambience | Use Amb2DSceneBed only at the dedicated ambience system's defined interface. |
| Animation | Choose Sx3DAnimationOneShot for a frame cue or Sx3DAnimationLoop for paired start and stop cues. |
| Visual effect | Choose Sx3DVfxOneShot for a spawn moment or Sx3DVfxLoop for the effect's lifetime. |
| Gameplay code | Choose SxCodeOneShot or SxCodeLoop according to duration, then define the caller's spatial behavior and ownership explicitly. |
| UI | Use Sx2DUIOneShot for the UI interactions covered by that component. |
| Voice | Choose Vo2DOneShot or Vo3DOneShot according to spatial behavior. Creation-tool rollout is still pending. |
A missing combination is a review point. Do not infer that any combination of name fragments is an implemented model. Compare the behavior with the existing catalog, decide whether a dedicated system is more appropriate and add a model only when the new contract is justified.
Integration and tooling
Declare the integration boundary
An external audio team works inside another studio's project. Care levels identify the scope of a change before it reaches the host codebase.
| Level | Models | What it touches | Tooling behavior |
|---|---|---|---|
| Green | 7 | Scene objects, reusable object templates and the audio team's own components. | Creates and connects supported objects and components. |
| Yellow | 3 | A small, standard change in a host file, such as a registry entry or an event block in an effect graph. | Shows the exact change and applies it after confirmation. |
| Client code | 5 | The studio's gameplay code. | Generates implementation instructions for the studio's programmers rather than editing that code. |
The counts total 15 catalog entries, including the two voice models awaiting release in the creation tool. They describe integration categories, not 15 equally available automated creation paths.
Care level does not remove review. A Green change can still select the wrong event or create duplicate playback. A Yellow change can still conflict with another registry edit. The level tells reviewers which boundary is crossed and which team owns the next action.
One catalog, several consumers
The source describes the catalog as data shared by the creation tool, validator and written guide. The intention is to maintain the model definition in one place and have those consumers use the same rules.
Suggestion and validation
Given an event and a target object, the tool ranks models using the event prefix, spatialization, duration, relevant parameters and existing target components. Those may include an animator, an effect, a trigger or a UI element. Models that contradict the event are filtered out.
Selecting a model component exposes its recipe check in place, with a pass indication or a message explaining the mismatch. This helps catch an incompatible assignment before running the scene.
Creation and change requests
The creation workflow creates the required object and connects the event. For Yellow models, it proposes the host-file change. Existing reusable object templates are upgraded in place rather than rebuilt.
Scene and template changes can also be submitted as small job files for the editor to execute. This workflow delegates serialization to the editor rather than asking a person or script to edit serialized scene files directly.
Migration and documentation
Migration helpers convert supported older patterns when the conversion is considered safe, one category at a time. They do not establish that the entire legacy implementation has been migrated.
The written guide includes a decision tree and a page for each model. The same rules can guide coding assistants, although sharing instructions does not itself demonstrate equivalent implementation quality across people and tools.
What the evidence establishes
The source describes use in a live production and reports qualitative observations. It does not include implementation code, execution logs, retained profiler captures, a before-and-after defect count or an implementation-time study.
Three conclusions can be separated:
- Catalog structure
- the supplied documentation lists 15 models in five groups, with event sources and care levels.
- Production observations
- the author reports easier tracing and fewer orphaned loops appearing during profiler sessions.
- Validation still needed
- measured implementation speed, the scale of defect reduction and equivalent output quality across implementers are not established by the supplied material.
| Claim | Supporting material supplied | What it establishes | Limit |
|---|---|---|---|
| A shared catalog defines call patterns. | The 15-entry catalog, naming rules, recipes and integration categories. | The documented structure and intended contracts can be inspected. | Documentation alone does not verify runtime conformance. |
| Tracing became a lookup. | A qualitative production account and an event-source column for each model. | A defined place to begin tracing each documented pattern. | No comparison of investigation time or search effort is supplied. |
| Orphaned loops appeared less often. | The author's report that loops left running after scene changes stopped appearing in profiler sessions. | A reported observation within the sessions described. | No captures, session coverage or defect counts are supplied; this does not establish that orphaned playback was eliminated. |
| Implementation was simplified. | The described selection, recipe-check and creation workflow. | The workflow standardizes decisions and setup steps. | No timing study supports a quantified productivity gain. |
| Implementers and assistants share the same rules. | The described model guide and assistant instructions. | The intended implementation contract can be shared. | No output comparison demonstrates equal quality or consistent compliance. |
| Documentation can precede implementation questions. | The described per-model guide and decision tree. | The workflow includes documentation alongside the catalog. | Generated-document synchronization is described rather than independently demonstrated here. |
Where the catalog needs restraint
Standardize new work first
The described rollout applies the catalog to new work. Older implementations remain unless they are already being changed or are causing a bug. This limits migration scope but leaves a period in which catalog models and legacy patterns coexist.
Give the catalog an owner
A closed list needs a gatekeeper. Adding another model should require an identified behavior, event recipe, stop contract, integration boundary and validation plan. Otherwise, the list accumulates the same drift it was introduced to control.
Keep dedicated systems dedicated
Continuous sources with complex geometry and broader ambience behavior may need their own tools. A scene-bed entry can expose part of such a system without claiming to describe all its transitions and ownership rules.
Maintain the wrapper
The additional layer has a maintenance cost. Changes in the host API, registry or event conventions can require updates to model definitions, tooling and documentation. Shared data reduces the number of places where a rule is authored; it does not remove the need to verify each consumer.
Treat rollout as a separate status
The voice entries are cataloged but not yet released in the creation tool. The source also leaves the full placed-object-loop lifecycle unspecified. A team adapting the approach should close those contracts explicitly rather than treating the catalog table as proof of readiness.
Build the catalog your project needs
- Inventory the current call paths. Record where events are assigned, what starts them and who owns their stop and release.
- Group patterns by family, spatial behavior, trigger and duration. Preserve meaningful exceptions rather than forcing every system into the same lifecycle.
- Write a contract for each supported pattern. Include the event source, recipe checks, owner, normal stop path and interruption cleanup.
- Declare integration boundaries. Identify changes the audio team can create, changes requiring a reviewed host-file edit and changes owned by gameplay programmers.
- Store the catalog as data. Connect the validator, creation workflow and guide to that definition, then verify that they interpret it consistently.
- Test representative transitions. For the patterns you adopt, exercise normal completion, repeated triggers, disable, interruption and scene changes. Retain the records needed to support later claims.
- Apply the catalog to new work. Migrate older patterns when there is a concrete reason, and review uncovered behaviors before expanding the list.
Flutu's earlier publication, Before We Touch a Sound, describes the inventory and inspection work that can precede this process. The transferable method is to make playback ownership, compatibility and exit behavior explicit before another local call path is added.
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.
What is a sound call model in game audio?
A sound call model is a reusable implementation contract describing who triggers a sound, where its audio event comes from, which event settings must be compatible and how playback ends. It works above the project's existing audio API and event registry.
How are the 15 sound call models organized?
The catalog groups patterns by scene, animation, VFX, gameplay code, and UI or voice. Models describe audio family, spatial behavior where relevant, trigger ownership, playback duration and the integration boundary. They are documented patterns, not proof that every path has been automatically deployed.
How do you prevent audio loops from continuing after gameplay ends?
Assign each loop a responsible owner and explicit stop or release path. Test normal completion, disable, interruption and scene transitions. Animation, VFX, area and code loops need different cleanup contracts rather than relying on one generic stop rule.
What does the sound creation validator check?
A recipe can check event naming prefixes, spatialization, one-shot versus loop behavior, output routing, maximum distance and required parameters. Passing the recipe is a configuration check; runtime validation and listening QA remain necessary.
What do Green, Yellow and Client code mean?
Green covers supported changes to audio-owned components or reusable objects. Yellow indicates small reviewed edits in host files. Client code identifies changes that remain the game studio's programming responsibility. These categories describe ownership and review requirements.