Audio Is Design, Not Polish: A Sound Spec Your Small Team Can Actually Ship

Your jump has three frames of anticipation, a dust puff, and a satisfying arc. It still feels weightless. So you tune the arc again. And again. The problem usually isn't the arc — it's that the landing makes a single 200ms thud and nothing else in the world acknowledges that a body just hit the ground.

Audio is the cheapest game feel you will ever buy, and it is almost always the last thing a small team specifies. Art gets a mood board, combat gets a spreadsheet, and sound gets a folder called sfx_final with 300 files named hit2_new.wav. Then a contractor asks "what's your sound list?" three weeks before your demo deadline and nobody knows.

Here is a sound spec that fits on a few pages, can be written by a designer who has never opened a DAW, and still gives an audio person everything they need.

Start with the audible moments, not the files

Do not start by listing assets. Start by listing moments where a player needs feedback. Walk one minute of your game, second by second, and write down every state change the player should hear.

For a 2D action platformer, one minute of play produces something like:

• Movement: footstep (per surface), jump, apex, land (soft/hard), slide, ledge grab
• Combat: swing, hit flesh, hit armour, parry, block, whiff, enemy death
• Damage taken: hurt, low health warning, death
• World: door, chest, breakable crate, checkpoint activate, hazard loop (spikes, fire)
• UI: hover, confirm, cancel, error, pause, unpause
• Reward: coin pickup, health pickup, level complete

That's roughly 30 moments — but the asset count is not 30. Each moment needs variations to avoid ear fatigue, and the multiplier depends on how often it fires.

Frequency	Example	Variations	Pitch randomisation
Every 0.4s	footstep	4–6 per surface	±2 semitones
Several times a second	sword swing, coin	3–4	±1.5 semitones
Every few seconds	hit, jump, land	2–3	±1 semitone
Once a minute	door, checkpoint	1–2	none
Once per session	boss death, level complete	1	none

Footsteps across four surface types at five variations each is 20 files before you have a single sword. This table is the single most useful thing in the whole document, because it turns "we need sound" into a number a contractor can quote against and a schedule can absorb.

Give every sound a slot, a priority and a limit

The second failure mode after "we have no sounds" is "we have too many at once." Five enemies die in a cluster, ten hit sounds stack, and the mix clips into mush. Fix that in the spec, not in a panic during certification week.

Define buses first. Four or five is plenty for a small game:

• Master — everything, one output
• Music — score, stingers
• SFX — world and combat
• UI — menus, HUD (never ducked, never affected by in-world reverb)
• VO — dialogue, grunts, barks

Then give each sound category a voice limit and a stealing rule. Concrete example numbers you can start from and tune:

• Footsteps: max 6 concurrent, steal oldest
• Impacts: max 8 concurrent, steal quietest
• Enemy vocals: max 3 concurrent, reject new if full
• UI: max 2, always play, ducks nothing
• Ambience loops: max 4, crossfade 500ms

Add one rule for cooldowns: if the same event fires twice within 40–60ms, play it once. This alone removes most "machine gun" artefacts from multi-hit attacks and particle-driven impacts.

Rank your categories too, so that when the voice pool is full the engine drops the right thing: player damage > VO > player actions > enemy actions > world ambience > distant enemies. Write that ranking down; it is a design decision, not a programming detail.

Layer the important hits

A single file for a big moment is why your landing feels weightless. Meaningful impacts are built from three layers:

1. Transient — the click, crack or slap that carries the timing. 5–20ms. This is what makes it feel exact.
2. Body — the tone that carries the material. Wood, metal, flesh. 100–400ms.
3. Tail — the reverb, debris, or ring-out that carries the size. 300ms to 2s.

A breaking crate is a snap, a hollow knock and a scatter of splinters. A heavy landing is a boot slap, a low thump under it and a dust rustle. You can specify this without producing it: write impact_heavy_land = transient(boot_slap) + body(low_thump_60hz) + tail(dust_settle) and an audio designer knows exactly what you want.

Pair layers with the things around them. A hit that lands on frame 3 of hitstop, with the transient on the first frame of the freeze, reads as twice as strong as the same sound played on frame 1 of a normal animation. Audio, hitstop, screen shake and particle timing are one system. Document them together in the same mechanic entry rather than in four separate places — if you keep mechanics in GameDesignerX, the feedback spec belongs in the mechanic's own page next to the frame data, so nobody has to reconcile two sources of truth.

Mix against a reference, not against your headphones

One: set a reference loudness and never mix louder. Pick a level meter, choose an integrated loudness target for your master, and mix every session at the same monitoring volume. The exact number matters less than consistency — but if you are shipping to consoles, read the current certification requirements from the platform holder directly, because loudness compliance is a real submission gate and the numbers are specified per platform.

Two: build a headroom budget. Reserve the loudest part of your range for the rarest events. If footsteps sit at the same perceived volume as a boss roar, nothing in your game can feel big. A workable starting layout, in relative terms:

• Ambience: quietest layer, always present
• Footsteps, UI: quiet, high frequency of occurrence
• Combat impacts: middle, the workhorse band
• Player damage, death: loud
• Boss reveals, level complete: loudest, used once

Then check the mix on laptop speakers, cheap earbuds and one decent pair of headphones. If your low-frequency landing thump is doing all the work, laptop speakers will delete it and the game will feel weightless again for most of your audience.

Name files so future-you can automate

Naming is boring and it saves weeks. One convention, everywhere:

category_subject_action_variant

• sfx_player_land_hard_01.wav
• sfx_enemy_grunt_hurt_03.wav
• ui_menu_confirm_01.wav
• amb_cave_drip_loop.wav

Lowercase, underscores, two-digit variants, _loop suffix for anything that loops. When variants are numbered consistently, your engine can auto-collect sfx_player_land_hard_* into a random container instead of someone hand-wiring 6 references. When a contractor delivers 200 files, you can check the delivery against your sound list with a script instead of an afternoon.

A sound spec checklist

Before you commission a single asset, your document should answer:

• The list of audible moments, derived from one minute of real play
• Variation counts and randomisation ranges per frequency tier
• Bus layout and what each bus contains
• Voice limits, stealing rules and the retrigger cooldown
• Category priority order for voice stealing
• Layer breakdown for the top 10 most important sounds
• Loudness reference and the relative headroom budget
• File naming convention with three worked examples
• Which moments are silent on purpose
• Owner and review date

That last-but-one item deserves a sentence of its own. Silence is a design tool, and it needs to be written down or someone will fill it. The two seconds before a boss's second phase, the moment a stealth detection meter fills, the beat after a death — if you don't specify "no SFX here, music drops to a single sustained low tone," your mix will be uniformly loud and your peaks will land on nothing.

Do this in an afternoon

You do not need an audio director to start. Record one minute of gameplay, watch it with a notepad, and write down every moment that should make a noise. Sort those moments into the frequency tiers. Multiply. You now have an asset count, a schedule estimate and a brief — and the next time a landing feels weightless, you will have somewhere specific to look.