When the audio budget is “almost nothing,” the instinct is to cut the sounds that sound worst. That instinct is wrong. The sounds that sound worst in solo are often the ones carrying the most gameplay information — a thin UI click, a short impact transient, a dry footstep — and the sounds that sound richest in solo are often decoration. Cutting by taste in a near-zero budget produces a game that is still unreadable, just thinner.
The criterion that holds up under pressure is information density: how much gameplay feedback a sound delivers per byte of memory it occupies. A sound that tells the player what just happened, whether it worked, and what to do next is protected. A sound that tells them the room is quiet is the first candidate for reduction. The sections below work from the arithmetic of memory upward, because the budget is small enough that the arithmetic matters.
The Budget Is a Number, and the Formula Tells You Where It Goes
Uncompressed PCM memory is not mysterious. The storage per second is sample rate × bit depth / 8 × channels. At 48 kHz, 16-bit, mono, that is 96 KB per second; at 44.1 kHz, 16-bit, mono, it is roughly 88 KB per second; at 24-bit, 96 kHz, stereo, it is 576 KB per second.
If the entire sound effects pool has 4 MB, then the uncompressed PCM budget is roughly 42 seconds of 48 kHz mono audio. That is not a lot of footsteps. If the same pool is encoded to ADPCM at roughly 4:1, the playing time extends to roughly 170 seconds without changing the sample rate or the channel count. The arithmetic is the first decision: before choosing which sounds to cut, decide how much time the budget buys at each format.
The sample rate and format guide covers the per-platform sample rate choices; the budget arithmetic here is downstream of those choices and should be run against them, not instead of them.
ADPCM Is the Format That Protects Transients at 4:1
Wwise’s conversion guidance gives approximate compression ratios and the CPU/memory trade-off for each codec: PCM 1:1, low CPU, high memory; ADPCM 4:1, low CPU, moderate memory; Vorbis 3–40:1, moderate-to-high CPU, moderate- to-very-low memory; Opus 10–60:1, high CPU without hardware acceleration and very low CPU with it.
The numbers alone suggest Vorbis or Opus for everything. The limitation is what determines where each format belongs. ADPCM’s documented limitation is that it can only loop on 64-sample boundaries, which matters for looping ambience but not for one-shot SFX. Vorbis’s documented limitation is that its metadata overhead is slightly larger than other formats, and the guidance explicitly says to avoid it for very small sounds shorter than a few tens of milliseconds.
That single constraint reorganises the entire low-budget format strategy. A UI click at 60 ms is exactly the kind of sound Vorbis is wrong for: the metadata cost can rival the encoded payload, and the compression ratio that makes Vorbis attractive on a two-minute music track does not apply to a sound with almost no duration to compress. ADPCM at 4:1 is the correct choice for short, transient-heavy SFX: it keeps the attack intact at low CPU cost, and its looping limitation is irrelevant for a one-shot.
| Asset profile | Format choice under near-zero budget | Reason |
|---|---|---|
| Short one-shot SFX (under ~200 ms): UI click, impact transient, pickup | ADPCM | 4:1 ratio; Vorbis metadata overhead is wrong at this length; low CPU preserves the attack |
| Medium one-shot SFX (200 ms–2 s): footsteps, weapon bodies, most gameplay feedback | ADPCM, or Vorbis if memory is tighter and the transient can tolerate it | ADPCM protects transient detail at low CPU; Vorbis saves more memory at higher CPU and some transient softness |
| Long looping beds: ambience, machinery, wind | Vorbis or Opus, or stream | Looping on 64-sample boundaries is restrictive for ADPCM; long duration makes Vorbis/Opus ratios worthwhile |
| Dialogue | Vorbis or Opus, with seek table | Long duration; seek table needed for jump-in playback; metadata overhead is amortised |
| Music | Stream; Vorbis or Opus if in memory | Long duration, rarely needs zero-latency; streaming avoids the memory cost entirely |
The table is a default, not a rule. The file size reduction guide covers the quality side of these choices; the low-budget point is that “use the most compressed format” is wrong for the shortest sounds, because the overhead and the CPU cost are paid on assets that have almost no duration to amortise them.
What to Protect: Feedback, Not Fidelity
Under a near-zero budget, the protected set is the set of sounds that carry gameplay information the player cannot get another way. That is a narrower category than “important sounds,” and it is worth defining precisely because the budget forces the definition.
Protect input feedback. The sound that tells the player a button press registered, a jump started, a weapon fired. These are short and high-frequency, which is why ADPCM at 4:1 is appropriate: the attack is the information, and compression that preserves the attack preserves the feedback. The UI sound design guide covers the hierarchy between confirm, cancel, and error; the low-budget rule is that confirm and error are protected, and hover is the first candidate for reduction or removal.
Protect state-critical feedback. Low health, taking damage, death, an enemy telegraph. These sounds fire under pressure, when the player needs them most, and they are often the sounds a budget-cut instinct would reduce because they are not “pretty.” A telegraph that is inaudible is a gameplay bug, not a budget saving. The sound prioritization and voice limiting guide covers how to keep these above the rest of the mix at runtime; the asset-level rule is that they keep their transient and their ADPCM encoding.
Protect the primary verb. Whatever the player does most often — fire, swing, build, jump — is the sound they hear most often, and it is the sound whose repetition will expose every compression artifact. A primary weapon encoded to a format that softens its attack will feel wrong on the hundredth shot in a way it did not on the first. The weapon sound effects guide covers the attack-to-weight relationship; the budget rule is that the primary verb is the last asset to compress aggressively, not the first.
What falls outside the protected set is equally specific. Decorative ambience that duplicates another layer, distant chatter, prop rustles, and any sound whose absence would not change a player decision are the correct cuts. The test is not “does it add atmosphere.” The test is “if this sound were missing, would the player do something differently or fail to understand something.” If the answer is no, the sound is decoration, and decoration is what the budget can no longer afford.
Streaming Is Not a Free Lunch: The Buffers Still Cost Memory
The obvious escape from a memory budget is to stream everything. The budget arithmetic says that is not free. FMOD’s stream buffer documentation states that larger buffer sizes consume more memory, and the default file buffer size is 16384. If the raw-bytes unit is used, the memory allocated is two times the size passed in, because FMOD allocates a double buffer. Smaller buffers reduce memory but risk buffer under-run, starvation, or stuttering caused by disk access delays or CPU load.
There is also a hard concurrency limit that matters more than the buffer size. FMOD’s own guidance notes that most platforms can only support a single-digit number of simultaneously playing streams. A game that streams every footstep and every weapon body will hit that limit long before it hits the memory limit, and the failure mode is not “slightly quieter” — it is dropped or stuttering sounds during combat. Streaming belongs on long, low-concurrency assets: music, long ambience, dialogue. It does not belong on the high-frequency SFX that the budget was trying to protect.
Wwise’s guidance is consistent with this. The stream playback buffer size should be based on the maximum number of simultaneously streaming sounds, the bitrate of those sounds, and the safety time required for the stream. A small buffer sized for one ambient bed is not sized for a combat scene that streams three layers at once. The pipeline decisions guide covers the loading-mode decision as an asset-specification field; the low-budget point is that streaming is a decision about which assets can tolerate disk I/O, not a universal memory reduction.
A Cut Order That Starts With the Cheapest Savings
The procedure below is ordered so that the first steps recover memory without touching the protected set. When the budget is “almost nothing,” the first steps usually recover more than expected, and the protected set survives.
- Convert short one-shots to ADPCM before cutting any of them. A 4:1 ratio on the short SFX pool is often the single largest saving, and it preserves the transient that the protected set depends on. Vorbis on those same sounds saves more ratio but costs more CPU and can soften the attack; under a near-zero budget, the CPU headroom is usually the constraint that decides against it.
- Halve the sample rate of sounds that do not contain high-frequency information. Halving the sample rate halves the PCM memory cost. A low rumble, a distant machinery bed, or a bass-heavy impact can often be resampled to 22.05 kHz or 24 kHz without an audible loss, because there was little energy above 11 kHz to begin with. Do not apply this to UI clicks or bright transients; the high-frequency content is the sound.
- Mono-convert anything that does not need spatialisation. A stereo source that the engine will spatialise is often a waste of a channel. The mono or stereo export framework covers the decision; under a low budget, the default for one-shot SFX should be mono unless the stereo content is carrying information.
- Stream the long, low-concurrency assets. Music and long ambience are the correct targets. Keep the stream buffer sized for the maximum simultaneous stream count, not the average. Do not stream high-frequency SFX.
- Cut decoration, in this order: duplicate ambience layers, distant chatter, prop rustles, one-time menu sounds. Each cut should be evaluated against the information-density test, not against how it sounds in solo.
- Only after the above, reduce variation count on protected sounds. A footstep set that had six variations can go to three before it goes to one. The controlled randomness guide covers how much variation is needed to avoid mechanical repetition; the low-budget rule is that variation is a candidate for reduction after format, sample rate, and decoration, not before.
The budget is small enough that the order matters. A team that cuts variation first and converts format last will remove the sounds that make the game feel alive, and still be over budget. A team that converts format and sample rate first often finds that the protected set fits, and the decoration was the only thing that had to go.
The mobile file size and performance guide covers the platform-specific encoding and memory ceilings; this guide is the decision layer above it: given a budget that is close to zero, which assets carry information and which carry decoration, and which format preserves the former at the lowest cost to the latter.