Quick answer: The industry-standard split: uncompressed WAV for short, frequent sounds (UI, footsteps, impacts) where decode latency matters, and OGG Vorbis for music and long ambience where file size matters. Avoid MP3 in games — looping gaps and patent-era inertia made it the bug-prone choice — and let your engine's import settings do the platform-specific compression.
The industry-standard split: uncompressed WAV for short, frequent sounds (UI, footsteps, impacts) where decode latency matters, and OGG Vorbis for music and long ambience where file size matters. Avoid MP3 in games — looping gaps and patent-era inertia made it the bug-prone choice — and let your engine's import settings do the platform-specific compression. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.
Why the WAV/OGG split is the standard
Short sounds fire constantly and must play instantly; uncompressed PCM (WAV) decodes for free at trivial file sizes when clips are under a few seconds. Music is the opposite: minutes long, one or two instances playing, completely tolerant of streaming decode — OGG's ~10x size reduction is pure win there.
The engine usually implements this as 'decompress on load' for short sounds versus 'streaming' for music. Getting those import flags right per asset matters as much as the source format — a streamed UI click stutters; a fully-loaded 5-minute track wastes a quarter-gigabyte of RAM.
MP3's specific sins
MP3 encoders pad silence at the start of files, which breaks seamless loops audibly — the classic 'why does my music gap' bug. Its licensing history also left engines with second-class support compared to Vorbis. There's no upside MP3 offers that OGG doesn't match or beat for game use; the only reason it appears in projects is source material arriving in it.
If assets arrive as MP3, transcode the master WAVs if you can get them; transcoding MP3→OGG stacks two lossy generations and audibly degrades.
Source discipline and the platform layer
Keep originals at full quality — 44.1/48 kHz, 16/24-bit WAV — in your source tree, and compress at import/build time. Engines re-encode per platform anyway (consoles and mobile have preferred codecs); feeding them pre-compressed audio just locks in quality loss before their encoder adds its own.
Consistency checks worth automating: one sample rate project-wide (mismatches cause subtle resampling artifacts), mono for 3D-positioned sounds (stereo files defeat spatialization), and loudness normalization at import so no asset arrives 12 dB hotter than its neighbors.
Audio is half the feel of your game
Players rarely praise game audio directly — they say the game feels 'satisfying' or 'atmospheric' and can't tell you why. Sound is doing that work. A well-timed impact sound makes a weak animation feel strong; a thin one makes a great animation feel hollow.
That's why audio repays attention even on a tiny budget. You don't need an orchestra; you need the handful of sounds players hear hundreds of times — jump, hit, click, collect — to feel exactly right.
Test your audio where players actually listen
Your mixing environment lies to you. Audio balanced on studio headphones can be mud on laptop speakers, painful on earbuds, and inaudible on a phone. Players will use all of those, and the loud minority will tell you about it in reviews.
Make a habit of checking builds on the worst hardware you own. If dialogue survives a laptop speaker and the mix doesn't clip on cheap earbuds, you're most of the way to safe.
Plan for the bugs you won't see coming
Whatever else you take from this, build yourself a way to hear about problems. Once your game is on other people's machines, most failures happen out of sight: the crash on hardware you don't own, the save that corrupts once in fifty exits, the bug players mention in a review instead of a report.
A lightweight crash and bug reporting setup — even just Bugnet's free tier wired into your engine — turns that silence into a fixable list. The devs who look calm at launch aren't luckier; they just see their problems earlier.
Putting it to work
Don't try to act on all of this at once. Pick the one change that costs you the least and pays the most this week, do it, and see what actually happens before reaching for the next.
Most of this rewards steadiness over intensity. A small improvement made every week, checked against how real players respond, outruns any single burst of effort — in this corner of game development and every other one.
Get the five sounds players hear most to feel perfect before touching anything else.