A middleware-ready sound is not the same thing as a good sound. A recording can be beautifully produced and still be the wrong asset for FMOD or Wwise, because it was built to be a fixed object rather than a system response. The distinction shows up the first time someone asks the sound to change pitch with engine RPM, to shift timbre as the player moves from grass to metal, or to thin out as health drops — and the only available answer is “export another WAV.”
The alternative is to design the sound around the parameter that will drive it, before the file is rendered. That changes what gets recorded, what gets exported, and how many files exist at the end. The sections below work through the decisions in the order they constrain each other: which Game Sync type the sound belongs to, what that type means for the asset, and how the same logic appears in FMOD’s parameter system.
Wwise Has Four Game Sync Types, and Each One Implies a Different Asset
Wwise’s own documentation separates interactive changes into four categories, and the separation is not administrative. Each type answers a different question about how the sound should respond, and each produces a different kind of asset.
State applies a global adjustment to existing sounds, music, or motion — a “mixer snapshot” that changes properties like volume and low-pass filter across many objects at once. The canonical example in the documentation is a character moving underwater: a State changes the volume and low-pass on gunfire and grenade explosions that are already playing, so the same objects sound submerged without new assets being loaded. The asset implication is that the source should be exported dry and unprocessed, because the State is going to apply the filtering and level change. A file with underwater filtering already baked in cannot be un-filtered by the State.
Switch is a conditional replacement: the game has discrete conditions (concrete, grass, mud), and each condition gets its own sound object. The documentation’s footstep example is exactly this — a switch container holds a different footstep set for each surface. The asset implication is the opposite of the State case: the variants are genuinely different recordings or renders, and they are organised into a Switch Container rather than being parameter-modulated.
RTPC maps a continuously variable game parameter to an audio property, and the mapping is expressed as a curve. Changing the parameter value changes the property according to that curve, rather than snapping between discrete objects. This is the type that most directly changes what a “middleware-ready” asset is, because it allows one file to carry a range of behaviours rather than a single fixed character.
Trigger starts a stinger — a short musical phrase layered over the current music. It is the one type that is not usually relevant to a standalone SFX asset, but it matters for the same reason: the trigger is an event, not a parameter, and the asset is a one-shot phrase rather than a modulated bed.
| Game Sync | What it does | What the asset should be |
|---|---|---|
| State | Global property adjustment on existing objects | Dry, unprocessed; the State applies the filter and level |
| Switch | Discrete conditional replacement | Separate variants, one per condition, in a Switch Container |
| RTPC | Continuous parameter-to-property mapping via a curve | One source that can change continuously; properties exposed rather than baked |
| Trigger | Starts a stinger phrase | One-shot musical phrase, not a modulated bed |
“Twelve Switch Variants” vs. “One Source and Twelve Curve Points”
The most common middleware-unready pattern is using a Switch where an RTPC would be correct. The designer wants a footstep that changes gradually as the player moves from concrete to gravel, so they record four variants and set up a Switch with four values. The result works, in the sense that the game plays a different file depending on the surface, but it does not respond to anything between the four values, and the transition between them is a jump rather than a shift.
The RTPC version uses one source and maps a parameter to several properties at once. Wwise’s RTPC curve defines “the overall relationship between the two parameters,” and a single Game Parameter can drive multiple properties — a curve for pitch, a curve for low-pass cutoff, a curve for volume — so that one input value produces a coordinated set of changes. A footstep with a single gravel source and an RTPC controlling playback rate, filter cutoff, and a layer of surface noise can cover the whole range between concrete and mud without a Switch at all, and the intermediate values are continuous rather than absent.
The asset consequence is significant. Twelve Switch variants means twelve files, each of which has to be recorded, trimmed, and maintained. One source with twelve curve points means one file and a mapping table. The mapping table is cheaper to edit and cheaper to maintain, and it can be adjusted without re-rendering the audio. The UI sound design guide covers the same trade-off in the context of confirm and cancel sounds: a hierarchy of discrete states is sometimes the right answer, but it should be a deliberate choice rather than the default because recording is the only tool at hand.
The RTPC approach also changes what “the sound” is. A Switch asset is a file. An RTPC asset is a file plus a curve, and the curve is part of the design. A designer who treats the curve as an afterthought — mapping parameter 0–100 to volume 0 to −6 dB with a straight line, because that is the default — is not designing the sound’s behaviour. The attack-time guide is relevant here because the RTPC curve is doing for a continuous parameter what an envelope does for time: it shapes how the change is experienced, not just what the end values are.
FMOD’s Parameter Types Map to the Same Decisions, With Different Names
FMOD Studio does not use the term “Game Sync,” but its parameter system covers the same ground with a different vocabulary, and the asset implications are the same.
FMOD’s user parameters come in three types: Continuous (float values for smooth, gradual changes), Discrete (integer values for stepped states), and Labeled (string values for named categories). The built-in parameters cover distance, direction, elevation, cone angle, orientation, and speed — the geometric and kinematic properties the engine can compute without the game explicitly setting a value.
The mapping is direct. A Continuous parameter is the equivalent of an RTPC: it drives properties smoothly, and it is the right type for engine RPM, health percentage, or intensity. A Discrete or Labeled parameter is closer to a Switch: it selects between discrete states, and the event’s logic responds to the value as a category rather than as a continuous variable. The practical difference from Wwise is that FMOD’s parameters live inside the Event rather than in a project-wide Game Syncs folder, which means the same parameter name in two Events is two separate parameters unless it is explicitly made global. Global parameters are project-wide variables that exist once and can be read or modified from anywhere.
The asset decision that follows is whether a given sound should
respond to a local parameter or a
global one. A weapon’s heat level is local to
that weapon instance; a weather intensity is global. The
documentation gives concrete examples from a real project:
ArenaIntensity (Discrete, 1–3), Daytime
(Continuous, 0.0–24.0), MissionCombatMode
(Labeled), and Rainfall (Continuous, 0.0–1.0).
A middleware-ready asset for rainfall should be designed
against the Rainfall parameter from the start —
its layers mapped to values 0.0, 0.5, 1.0 — rather than built
as a single “rain” file and then retrofitted with a parameter
later.
What Changes in the Asset Itself When the Parameter Exists First
The asset-level changes are concrete and mostly happen before rendering.
Layers replace variants. A sound that will be driven by a continuous parameter is usually built as layers with different behaviours, not as a single mixed file. A rainfall bed might have a base layer that plays from the start, a mid layer that fades in around 0.3, and a heavy layer that only appears above 0.7. The layers are the curve, in audio form; the RTPC or parameter is what moves between them. The layering guide covers the frequency separation that keeps the layers from competing when they overlap, which matters more here than in a static layered sound because the overlap changes with the parameter value.
Processing moves from the file to the object. If the sound will be filtered by a State or an RTPC, the file should not already contain that filtering. A footstep that will be low-passed when the player is underwater should be exported without the low-pass, because the State is going to apply it. A weapon that will be pitched down as it overheats should not have its pitch baked into the file at a single value. The asset is the source, and the processing is the mapping.
The loop point becomes parameter-sensitive. A looping bed driven by a parameter may need its loop crossfade to scale with the parameter value, because a dense layer at high parameter values may need a longer crossfade than a sparse layer at low values. The loop versus one-shot guide covers the structural difference between a loop and a one-shot; the parameter-driven case adds the requirement that the loop’s behaviour can change while it is playing.
Variation and parameter modulation are different things. A randomized variation system changes the sound between triggers; a parameter changes it during a single playback. Both are useful, and they are not substitutes. A footstep system might use variation to avoid repeating the same file, and an RTPC to change the surface character continuously within a single step. The controlled randomness guide covers the variation side; the parameter side is about designing the sound so that the parameter has something meaningful to modulate.
SoundSeed Grain and the “Parameter-Ready Source” Case
Wwise’s SoundSeed Grain is a useful edge case because it makes the parameter-readiness question explicit. It is a granular synthesis source plugin that segments an audio file into grains, applies envelopes, and controls grain emission interval, duration, playback position, and pitch independently. All of these parameters can be modulated by RTPC and by the plugin’s internal modulators (Mod 1–4).
The asset implication is different from the layering case. A SoundSeed Grain source is not layered; it is a single file that is re-segmented in real time. The “middleware-ready” quality of that file is not about how it was mixed, but about whether it contains enough spectral and temporal variety for the granular engine to find interesting material. A file that is already dense and uniform gives the grain engine little to work with; a file with variation across its length gives the RTPC something to scan through. The plugin’s documentation notes that the granular approach allows a designer to use a single source file to generate a wide variety of sounds, and that all parameters can be modulated — which means the source file’s job is to be a rich palette, not a finished sound.
This is the most demanding version of the middleware-ready principle, because it asks the designer to think of the file as raw material for a synthesis process rather than as the sound itself. Most projects will not use SoundSeed Grain directly, but the mindset applies to any parameter-driven source: the file should be designed for the range of behaviours it will be asked to produce, not for the single behaviour it will produce at the default parameter value.
A Quick Audit for an Asset That Is About to Enter Middleware
Before a sound is imported into FMOD or Wwise, four questions catch most of the middleware-unready cases.
- Is the processing that the parameter will apply already baked into the file? If the file is already low-passed, pitched, or compressed in a way that the RTPC or State is supposed to control, the parameter has nothing left to do. Export the dry source.
- Is the sound built as a set of variants or as a layer stack with parameter curves? If the intended behaviour is continuous, the asset should be layered and mapped, not split into discrete files. If the intended behaviour is genuinely discrete, a Switch or Labeled parameter is correct — but the choice should be deliberate.
-
Does the parameter name exist in the project, and
is it local or global? A sound designed against
Rainfall(global) cannot be reused with a local parameter of the same name without rework. The parameter should be named and scoped before the sound is authored. - Can the sound’s variation system and its parameter system be described separately? If the answer to “how does this sound change?” is only “it plays a different file,” the sound is variant-based. If the answer includes “the filter opens as the parameter rises,” the sound is parameter-ready. Both can be correct; the mistake is claiming the first is the second.
The pipeline decisions guide covers the structural questions that sit upstream of these — middleware path, bus structure, loading mode. The questions above sit one level down, at the asset itself: given the pipeline that exists, is this file designed for the way the middleware is going to use it? A sound that passes this audit is not necessarily a good sound. It is a sound that can still become a good sound after the parameter curve is written, because the file has not already decided what the curve is allowed to say.