The standards and checks that carry audio from composition into the engine
Choosing sample rate and bit depth, weighing compression formats, loudness and dynamic range, size versus load time, and the composing-to-engine handoff.
All audio assets should be produced and archived as high-specification masters, from which the compressed versions used in the game are exported. During production, a uniform lossless format at 48 kHz / 24 bit is recommended, preserving ample dynamic headroom; once a master is stored at low quality, no amount of later processing can recover the detail.
Sample rate determines the highest reproducible frequency, and both 44.1 kHz and 48 kHz cover the range of human hearing; short interface sounds dropped as low as 22.05 kHz are hard for most players to distinguish on a phone speaker, which makes this the first place to look when compressing file size. Bit depth determines dynamic range, and reducing to 16 bit for the game export is entirely sufficient.
The most overlooked yet most trouble-prone part of audio delivery is loudness consistency. If assets are mixed by different people in different environments, the game ends up with "this sound is unusually loud, that piece of music is unusually quiet," and adjusting levels one by one after the fact is both time-consuming and hard to converge.
The correct approach is to normalize everything against integrated loudness (LUFS) before delivery, rather than relying on peak level. Background music is recommended to land around -16 LUFS, while sound effects are tiered by category: interface sounds lowest, celebration sounds highest, with a fixed loudness gap held between tiers; at the same time, leave roughly 1 dB of true peak headroom to prevent digital clipping from amplitude summing when several sounds play at once.
Dynamic range has to account for context as well. Most players are on a phone speaker in a noisy environment, and too much dynamic range makes quiet passages inaudible; but over-compressing glues the sound into a single mass, and the layering of the tiered sounds disappears with it.
In web-based slot development, the choice of compression format directly affects compatibility and file size:
The best strategy is to prepare both formats, and at runtime use the browser's format-support query interface to select a playable version dynamically. If looping music has to use a format that introduces padded silence, then precise loop point parameters must specify the start and end positions in the audio manager, working around the format's own limitation.
Bandwidth and memory constraints on mobile demand strict control over the total volume of audio resources, and a general recommendation is to keep an entire game within 3 to 5 MB. Workable strategies include assigning different sample rates by asset type; converting short sounds to mono (almost indistinguishable to the ear, and it halves the size outright); using variable bitrate encoding; and stripping the leftover excess silence at the head and tail of assets.
Another cost that is easily underestimated is the memory footprint after decoding. A compressed file may be only a few hundred KB, but decoded into uncompressed sample data it can balloon more than tenfold. When assessing the budget, you have to look at both "download size" and "resident size after decoding."
The loading strategy needs to strike a balance between "time to first screen" and "playback immediacy":
In addition, most mobile browsers impose an autoplay restriction: audio output has to be unlocked by the player's first touch, so the loading flow needs an explicit entry interaction point, and the audio environment should be initialized within that interaction.
A professional sound system uses several independent buses, letting players control the volume of each audio category separately:
All buses ultimately feed a single master output, and the player's global volume control acts there. This architecture also greatly simplifies dynamic mixing: ducking only needs a gain adjustment on a single bus, rather than handling the playback state of individual sounds one at a time.
Before production begins, the game designer needs to prepare a sound requirements specification that lists every sound required, item by item:
A unified naming convention is essential for team collaboration. A structured naming scheme of "type prefix + scene + action + index" is recommended:
Use lowercase and underscores throughout, to avoid load failures caused by case sensitivity.
Sound integration should use an event-driven trigger architecture: the game logic layer does not call playback functions directly, but dispatches semantic event notifications, and the audio manager decides what to play, on which bus and at what priority. This decoupling lets the sound logic be adjusted independently without touching core logic, and lets the same mechanism be reused across different projects. The principle applies equally in Cocos Creator, Unity or a pure web environment.
It is also worth pairing this with an event-to-asset mapping table maintained by the sound designer. Replacing a sound or adjusting a tier threshold then only requires editing the table rather than changing code, putting tuning back in the hands of the person who understands sound best, and shortening the iteration cycle of repeated listening passes.
Once integration is complete, testing has to be carried out in a variety of environments:
A complete audio pipeline, from requirements definition through to final delivery, requires close collaboration between game designers, sound designers and frontend engineers; only through standardized conventions and quality gates can every game deliver a professional-grade listening experience.
And what these specifications and processes ultimately serve is the emotional foundation established by the background music, along with the layers of feedback built by tiered sound effects and interactive audio systems. The other two articles in this series each go deeper into those two topics.