The temptation is to open a generator and make something that sounds good. The problem is that “sounds good” is evaluated through a pipeline that has already been built, and that pipeline determines what the sound is allowed to be before the first oscillator is chosen. A 48 kHz stereo WAV with a baked reverb tail is a different asset from a 22.05 kHz mono WAV that routes into a Bus with a shared reverb send, and the difference is not audible in solo. It is audible in memory budget, in voice count, in whether the sound can be retuned without re-exporting, and in whether the Event that plays it can be reused for a variant.
The questions below are the ones that change how a sound is made, not just how it is played. They are ordered from the most structural decision to the most local one, because the earlier answers constrain the later ones.
Middleware or Engine-Native? The Answer Determines What a “Sound” Is
The first decision is not which middleware, but whether there is middleware at all. The two paths produce different objects with different capabilities, and the difference is not cosmetic.
Engine-native audio in Unity is built around the AudioSource component, which plays a single AudioClip at a time and routes through an Audio Mixer for volume and effects. Adding a second simultaneous sound requires a second AudioSource, and complex behavior — random containers, parameter-driven crossfades, interactive music — generally requires a custom or third-party solution. Unreal’s native path is MetaSounds, a node-based DSP graph that can take multiple sound files or procedurally generated noise and mix them before output. It is more capable than Unity’s AudioSource, and it is also more involved: a simple one-shot still requires connecting a wave player node to the graph’s inputs and outputs, and SoundCue has been deprecated in Unreal 5.x in favor of MetaSounds.
Middleware changes the unit of design from “clip” to “Event.” In Wwise, the sound designer creates Audio Objects — Sound SFX or Sound Voice objects — inside an Actor-Mixer Hierarchy, and the programmer creates Game Objects and triggers Events that play those objects. The two roles are deliberately separated: audio objects are managed in Wwise, game objects and listeners in the game, and Events and Game Syncs form the bridge between them. In FMOD, the equivalent unit is also the Event, which contains tracks and parameters, and Events live inside banks. A studio working with middleware is authoring Events, not files; the file is an implementation detail of the Event.
The practical consequence is that the same sound design can be more or less reusable depending on which path was chosen. A MetaSounds graph can expose input parameters that the game adjusts; an AudioSource requires the game code to manage clip swapping. An FMOD Event can be reused across many game objects with different parameter values; a Unity AudioClip is tied to the AudioSource that plays it. The decision is not about which sounds better. It is about which structure the project can afford to maintain.
In Wwise, the Actor-Mixer and the Master-Mixer Are Doing Different Jobs — and the Difference Changes How Effects Are Applied
Wwise separates the project into two hierarchies that are often conflated: the Actor-Mixer Hierarchy, where audio objects live, and the Master-Mixer Hierarchy, where those objects are routed into buses for final mixing and effects. Both hierarchies eventually feed the master output, but they answer different questions.
The Actor-Mixer is where the sound’s structure is defined: containers group objects for random or sequential playback, properties are applied at the object or container level, and the sound’s identity is authored. The Master-Mixer is where the Bus lives, and the Bus is where mix-level processing is applied — effects that should affect everything routed through that bus, rather than being baked into individual files. Wwise’s own description of the approach puts it directly: audio objects are routed through a hierarchy of buses where additional properties and effects can be applied at a global level.
The design decision that follows is whether a given processing step belongs in the file or on the bus. A reverb tail that should be shared across all impacts belongs on a reverb bus; baking it into every file means every file carries its own tail, and the tail cannot be adjusted without re-exporting. A compressor that should respond to the combined level of all weapons belongs on the weapons bus; putting it on each individual weapon means the compressor reacts to one weapon at a time, which is a different sound. The audio mix hierarchy guide covers how to build the bus structure that makes these decisions consistent across a project; the pipeline point is that the bus structure has to exist before the sounds that depend on it.
The asset-side implication is concrete. If the project uses bus reverb, the source files should be exported dry — without baked reverb — so the bus can apply it. If the project bakes reverb into files, the bus has nothing to do, and the files are larger and less flexible. The export decision framework covers the channel-count side of the same asset specification; dry-versus-wet is the effects side.
Sample Rate and Bit Depth: What the Engine Actually Accepts, and What It Costs
The sample-rate question is usually answered by “use 48 kHz” or “use 44.1 kHz” without explaining why either number matters. The actual constraint is that the engine accepts a range, the source may be higher, and the difference is paid in memory.
Unreal’s documentation states that the engine imports uncompressed little-endian 16-bit WAV files at any sample rate, though 44100 Hz or 22050 Hz are recommended. That is the engine’s supported range, not a quality target. Godot’s documentation makes the cost side explicit: sound effects are typically loaded into memory uncompressed because playback and resampling are cheap, while compressed streaming audio requires significant processor time and only a few streams can play simultaneously. The same documentation gives a concrete comparison: one second of 24-bit, 96 kHz, stereo audio is 576 KB; the same second at 16-bit, 44 kHz, mono is 88 KB, roughly six times smaller, and at IMA-ADPCM it is 22 KB. The reason the conversion is acceptable is stated directly: high bit depths and high sample rates are “completely unnecessary for use in a game, as there is no audible difference.”
The pipeline decision is therefore not “what is the highest quality” but “what is the delivery format, and what does the engine do with it.” A game that imports 96 kHz / 24-bit stereo WAVs is not getting better sound; it is getting files that the engine will either resample on import or play at a higher cost, with no perceptual benefit. The sample rate and format guide covers the platform-specific consequences; the pre-production point is that the delivery format needs to be agreed before the first file is exported, because re-exporting a library after it has been imported into Events is a rebuild, not a setting change.
The same logic applies to channel count. If the sound is a world-space effect that the engine will spatialize, a mono source is usually sufficient and often preferable, because the engine handles panning and stereo reverb. A stereo source that is then spatialized can produce phase issues or wasted bandwidth. The channel-count decision is a pipeline decision before it is a sound-design one.
Memory, Stream, or Compressed: The Loading Mode Determines Which Sounds Can Coexist
The loading mode is the pipeline decision most often deferred until profiling reveals a problem, and by then the assets are already built. The trade-off is between memory, file I/O, and latency, and the right answer depends on the asset’s length, its concurrency, and when it plays.
FMOD’s guidance frames the decision in terms of resource contention. A streaming asset requires constant file I/O and very little memory; a non-streaming asset requires much more memory but only touches the disk when it is first loaded, and that cost is paid once regardless of how many instances are playing. File I/O is a limited resource on most platforms, and a streaming asset that plays while the disk is busy can suffer buffer starvation, which manifests as stuttering or stopping. The conditions under which streaming is appropriate are stated as: the asset would take an awkwardly large amount of memory if fully loaded, few instances need to play simultaneously, few other streaming assets play at the same time, and the asset plays when the game is not reading or writing much to disk. Assets longer than ten seconds are streamed by default in FMOD, but the other conditions depend on the game’s design.
Wwise’s documentation makes a similar distinction and adds a practical detail: streaming reduces memory because audio is read from storage as it plays, but it introduces latency, and both Wwise and Criware allow a small pre-read at the start of a streaming asset to recover zero-latency playback. FMOD does not have an equivalent pre-read setting. The consequence for a game with timing-critical sounds — dialogue lip-sync, rhythm-game hits, UI confirms — is that those sounds should not be streaming, because the latency and the file-I/O contention make precise timing unreliable.
| Asset type | Loading mode | Why |
|---|---|---|
| Short UI click, confirm, cancel | Decompressed in memory (or PCM) | Timing-critical; latency from streaming is unacceptable |
| Footstep, weapon, impact | Compressed in memory (ADPCM or similar) | Short, high-concurrency; compressed memory saves space, decompression cost is manageable |
| Ambient loop (30 s–2 min) | Streaming | Large, low instance count, plays when disk is usually idle |
| Music track | Streaming | Large, rarely more than one or two simultaneous, not timing-critical at sample level |
| Dialogue line | Decompressed in memory or streaming with pre-read | Lip-sync may be timing-critical; pre-read recovers latency where supported |
The table is a default, not a rule. The actual answer depends on the platform’s memory ceiling and the scene’s concurrency, but the default is what prevents the first hundred sounds from being authored in a mode that has to be changed later. The mobile file size and performance guide covers the platform-specific budget side; the pipeline point is that the loading mode is an asset-specification field, not a runtime toggle.
The Event Structure Is the Last Decision and the Hardest to Change
Once the middleware or engine-native path is chosen and the loading modes are set, the remaining decision is how Events are structured. This is the decision that determines whether a sound can be reused, varied, and parameter-driven without rebuilding it.
In Wwise, an Event is the bridge between the game and the audio objects. A Play Event triggers a sound object; a Stop Event stops it; a Set Switch or Set State Event changes a Game Sync that the sound objects respond to. The Actor-Mixer Hierarchy contains the objects, the Events reference them, and the Game Syncs connect the game’s state to the audio’s behavior. The Event is not the sound; it is the instruction that plays the sound.
In FMOD, the Event is also the unit of reuse, but it is organized differently: an Event contains tracks and parameters, and Events live inside banks. The parameters are the variables that control playback — RPM for an engine sound, intensity for an ambience — and they are exposed to the game through the Event’s parameter interface. The FMOD vs Wwise vs MetaSounds comparison covers the authoring-model differences in more detail; the pipeline point is that the Event structure has to be designed before the sounds that populate it, because restructuring Events after they are referenced by game code means changing the code.
A concrete example: if the game needs a footstep system that changes by surface and by player speed, the pipeline decision is whether that variation lives in the Event (a parameter crossfading between surface layers, a parameter controlling playback rate and density) or in the game code (swapping clips on an AudioSource based on a surface string). The Event approach keeps the audio logic in the middleware and exposes a small interface to the game; the code approach gives the programmer control but moves the audio logic into the gameplay layer. The agent-style integration standard puts it bluntly: all game audio must go through the middleware event system except during prototyping, and audio parameters are set through the parameter API, not hardcoded in game scripts. That is a pipeline decision, and it is made before the first footstep is recorded.
The sound prioritization and voice limiting guide is the natural next step after the Event structure is settled, because priority and voice limits are set at the object or Event level, and they only make sense once the Events exist. The pipeline order is: choose the middleware path, define the bus structure, set the asset specification (format, sample rate, channel count, dry/wet), choose loading modes, then structure Events. Reversing any two of those produces a project where a change in one area forces a rebuild in another.
What It Costs to Get the Order Wrong
The cost is not a single bad sound. It is a cascade. If the bus structure is undefined, every sound that needs a shared reverb is baked with its own, and changing the reverb means re-exporting every file and re-importing it into every Event. If the loading mode is chosen per-asset without a rule, the memory budget is discovered at profiling, and the sounds that need to be re-authored are the ones with the most dependencies. If the Event structure is designed after the sounds are referenced by code, renaming or regrouping Events means changing the game code, which is the most expensive kind of change.
The sequence that avoids this is not a methodology, it is a checklist: middleware path, bus structure, asset specification, loading modes, Event structure. Each answer constrains the next, and none of them is audible in a solo listen. They are audible in the project’s ability to change a hundred sounds without rebuilding a thousand references. The prototype vs polish guide covers when the pipeline itself is allowed to be provisional; the pipeline decisions above are the ones that should not be provisional after prototyping ends.