Give one system responsibility for music
A common early problem is not sound quality but ownership. One scene starts a loop, a second scene starts another, and a restart leaves both alive. Decide which system controls the music lifecycle. It should know the current state, the requested state and whether a transition is pending. Other game systems should request a change rather than independently starting competing copies of the score.
Define startup, scene transfer, pause, failure and shutdown behaviour before expanding the asset list. Decide whether music continues across loading screens and whether pausing freezes musical time or only changes volume. There is no universal answer. What matters is that the composer and programmer are working toward the same answer and can reproduce it in a test build.
Choose tools around the actual workload
Native engine audio may be enough for a small project with a few loops and straightforward fades. Unity's audio documentation, Unreal Engine's audio documentation and Godot's audio documentation are appropriate starting points for understanding available routing, playback and import options. Verify the documentation against the engine version used by the project.
Wwise or FMOD can be useful when an audio specialist needs to author transitions, parameters and mix behaviour without making every edit in gameplay code. They also introduce integration, licensing, versioning and build responsibilities. Evaluate current licence terms directly with the vendor. Do not assume middleware is required for professional results, or that adopting it automatically reduces work on a small game.
Prepare assets for predictable playback
Agree a source format and a runtime conversion policy. Keep high-quality lossless masters, then let the platform and engine requirements guide compression and streaming decisions. A sample rate of 48 kHz is common in game production, but the correct delivery specification is the one your pipeline has explicitly agreed. Do not resample repeatedly simply because different export presets happen to be available.
Check loop boundaries after import and encoding, not only in the workstation. Confirm that a file's leading silence, encoder behaviour or loop metadata does not introduce a gap. Test reverberation tails and pickups deliberately. Long assets may benefit from streaming; short frequently triggered material may favour a different loading policy. Profile memory, disk access and decoding on the intended hardware rather than relying on desktop playback.
Schedule musical time deliberately
A game frame is not a musical boundary. For beat-aligned transitions, use the scheduling or music-timing facilities appropriate to the engine or middleware. Document tempo, meter and the relationship between file starts and bar positions. Avoid building a critical music clock from frame-by-frame assumptions when a sample-accurate or dedicated scheduling mechanism is available.
Log the requested state and the active state separately. This makes it easier to distinguish an incorrect gameplay request from a correct request that is waiting for its scheduled boundary. Add debug controls that can force states, repeat transitions and show active voices. These modest tools save time when a bug only occurs after several rapid scene changes.
Mix around information, not just impact
Music should not routinely obscure dialogue, enemy tells or navigation feedback. Create a clear routing structure with separate music, speech and effects controls. Use arrangement, equalisation, level changes and carefully designed ducking where appropriate. Ducking should have an intentional attack and recovery; a mix that audibly pumps on every minor sound can be more distracting than the original masking.
ITU-R BS.1770 defines algorithms for loudness and true-peak measurement, while EBU R 128 is a broadcast loudness recommendation. They provide useful measurement context, not a universal game loudness target. Establish a project reference, leave suitable headroom and compare representative gameplay at consistent monitoring levels.
Test the paths that are easy to forget
Build an audio test matrix covering fast travel, repeated failure, save and reload, long idle periods, menu transitions and a device change where supported. Listen on headphones and ordinary speakers. Check reduced music volume and muted music: essential gameplay information should not disappear solely because the player adjusts the soundtrack. Provide appropriate visual or other non-musical feedback for information the player must receive.
- Only the intended music instance survives a scene transition.
- Queued transitions cancel or complete according to a documented rule.
- Loops remain clean in the shipping import format.
- Music settings persist as intended and do not reset unexpectedly.
- Target-device profiling covers the busiest valid music state.
Record each issue with the build version, location, steps and expected result. A short gameplay capture is often more useful than an isolated audio render because it preserves the event that caused the problem. Integration is finished when the asset behaves reliably in the game, not when the file has merely been imported.
Next: agree the delivery →