Music for games basics: loops, stems, adaptive audio and middleware

A film cue knows how long the scene is. A game cue never does. The player might clear the room in forty seconds or wander around it for twenty minutes, and the music has to sound intentional either way. That single fact shapes everything about writing for games: you are not delivering a song, you are delivering a kit of parts plus the rules for putting them together.

This guide is for producers and composers who can already finish a track in a DAW and want to make music a game can use. If you are coming from stem work, our guide to stem mastering covers the balancing side; here we focus on how game engines consume stems.

Step 1: write a loop that does not announce itself

The base unit of game music is the loop. Two things break loops: audible seams and listener fatigue.

Seams. Write the last bar so it leads naturally into the first. Let reverb and delay tails from the end of the loop exist at the start too: the common trick is to render the loop twice in a row, then cut the second pass out, so the start already contains the tail of the previous pass. Cut on exact sample boundaries at your project tempo, with no fades.

Format. Export WAV for delivery, and expect the game to compress to Ogg Vorbis or a platform codec. Vorbis tracks position to the sample through its granule positions, as set out in the Vorbis I specification, which is one reason it is the usual choice for looping music.

Fatigue. A 16-bar loop heard for ten minutes becomes torture. Longer loops help, but variation helps more: alternate A and B sections, or give the engine several interchangeable bars to pick from.

Step 2: think in two directions

Adaptive music has two basic moves, and almost every system is a mix of them.

• Horizontal re-sequencing changes which section plays next: explore to combat, combat to victory sting. The craft is in transitions: decide in advance where a switch is allowed to happen and what bridges the two sections.
• Vertical layering keeps one section playing and fades stems in and out: add percussion when an enemy spots you, drop the melody when you open a menu. Every stem must start at the same sample and share the same length, or they drift.

A practical starting kit for one game area: a 32 to 64 bar loop split into four or five stems (pads, bass, percussion, melody, tension layer), one intro, two transition bars and one end sting.

Step 3: hand the engine a musical clock

Games render frames, not bars. If a transition fires on whatever frame the player dies, it lands off the beat. Engines solve this by scheduling against the audio clock:

• Unity: AudioSource.PlayScheduled starts a clip at an exact time on the audio system's DSP clock, so a programmer can line the next section up with the end of the current bar.
• Godot: AudioStreamInteractive switches between clips with transition rules. A small team can get real adaptive music from the free engine alone.

Your job as composer is to document tempo, meter, bar length in samples and which points are safe exit points. A one-page cue sheet that says "exits allowed on bars 8, 16, 24 and 32" saves a programmer hours.

Step 4: decide whether you need middleware

Middleware sits between your audio and the game code. Two widely used tools are FMOD Studio from Firelight Technologies and Wwise from Audiokinetic. Both give the composer a timeline-and-logic editor in which you build the behaviour yourself: parameters (such as "danger" from 0 to 1) that drive layer volumes, transition markers, randomised playlists and stingers. The programmer then only sends the parameter value.

That handover is the real benefit. Without middleware, every musical decision becomes a code ticket. With it, you can audition behaviour, change it and ship a new bank without touching game code.

When to skip it: a short jam game, a small mobile title, or a Godot project where the built-in classes cover your needs. Read each vendor's current licensing page before you promise a client "we'll use Wwise".

Step 5: deliver like a professional

• Name files so a stranger understands them: forest_explore_loop_120bpm_44m_perc.wav.
• Deliver at the sample rate the team asks for, with consistent loudness across cues so a switch does not jump in level. Our loudness targets guide explains LUFS metering, though game teams set their own targets.
• Keep your DAW sessions. You will be asked for "the same, but 10% calmer" six months later.
• Get the licence in writing: who owns the master, whether you keep soundtrack album rights, and whether the music can be used in trailers. The rights thinking in our sync licensing basics applies directly.

What we think

The industry talks about adaptive audio as a technology problem, and the big labels are now treating it as a catalogue opportunity, as with the UMG and Tyger deal to turn existing songs into reactive game music. We think the more interesting shift is creative and it favours independent artists.

A stem-based adaptive score rewards exactly the skills bedroom producers already have: arranging in layers, thinking in loops, knowing which element carries the tension. A composer who designs the behaviour inside FMOD or Wwise is authoring the experience, not supplying a file, and should be paid and credited that way. Our advice: learn one middleware tool well enough to hand over a working bank, not just a folder of WAVs. That is what turns "music supplier" into "audio collaborator", and it is the thing that a catalogue licensing deal or a generative system cannot easily replace.

The other thing we would push back on is the idea that adaptive means endless. The best game scores still go quiet. Write silence into the system on purpose; a loop that knows when to stop is more memorable than one that never does.