Close your eyes and imagine the sound a cheap web game makes when you collect a coin. You just heard a sine wave, didn't you — that thin electronic "bloop" that says a programmer generated me in one line of code. For a while, our games sounded like that too. It undid everything the graphics were achieving: a hand-painted world that beeped like a microwave.
The rule and the library
The fix followed our usual pattern — a hard rule backed by real tooling. The rule: all audio, music and sound effects alike, comes from sampled instruments. Not synthesized approximations of instruments; recordings of real ones. To make the rule followable we built an in-house library of 84 sampled instruments spanning enough territory to score any genre the builder produces — orchestral strings and brass for adventure, plucked and mallet instruments for cozy puzzles, drums and bass for arcade energy, pads and keys for ambient moods. Alongside it sits a collection of recorded ambience: rain, surf, wind, room tone, crowds.
So a harbor management game gets water lapping under gull cries, and its success chime is a real mallet hitting a real bar. A success chime played by a marimba and the same notes played by an oscillator are different products.
Composed per build, not looped from a folder
The audio engine composes for each game — the design director's brief covers the audio palette the same way it covers color, so the instruments match the world. A noir game and a farm game don't share a soundtrack any more than they share a font. Sound effects are placed by the same logic: what object, what surface, what size, what mood.
Verified like everything else
Because we'd been burned by silent-but-passing builds before, audio is part of verification: the in-browser check listens. A game whose world layer is mute, or whose effects fall back to bare oscillators, fails the pass — that's not a style note, it's a defect. One of our own builds got escalated and auto-fixed for exactly that recently; the story's in How builds verify themselves.