02 / Interactive composition

Build Music That Can Branch

Write the route between musical ideas as carefully as the ideas themselves.

Choose the smallest useful structure

An adaptive score changes in response to the game, but that does not mean every cue needs a complex system. Begin with the player's meaningful changes: entering a place, discovering a threat, committing to an encounter and returning to safety. A musical change should communicate something useful or support a noticeable shift in experience. If a parameter produces no perceptible benefit, it may not deserve an additional composition and testing cost.

There are two common building blocks. Vertical layering changes the combination of simultaneously aligned parts. Horizontal sequencing changes which musical section follows another. They can be combined, but start by solving one representative situation. A convincing two-state prototype tells you more than a large flowchart with no music attached.

Make layers genuinely compatible

Layers need a shared timing plan and an intentional harmonic relationship. Export them from the same start point with identical lengths where synchronisation requires it. If a layer contains a pickup, decide whether it starts early, waits for another boundary or uses a separate transition. “It lines up in the workstation” is not sufficient if the game can start it on an arbitrary frame.

Compose combinations, not merely individual stems. A bass line, a rhythmic layer and a melody may each sound satisfying alone but become crowded together. Test the quietest valid combination, the busiest combination and the transitions between them. Keep reverberation and side-chain processing in mind: a shared effect or bus compressor can make independently exported files behave differently from the original mix.

A small working model

One space, three musical states

ExploreTensionEncounter

Exploration: the harmonic bed and a sparse motif play. A transition request waits for the next bar boundary.

This is a visual planning model, not an audio player or a live engine simulation.

Give transitions an explicit rule

Every change needs an entry condition, a scheduling boundary and an exit policy. For a pulse layer, the next bar might be appropriate. For an urgent failure sting, waiting several seconds may undermine the event. Decide whether a transition may interrupt a phrase, whether it needs a bridge and which event wins if two requests arrive close together. These choices connect composition directly to gameplay priorities.

Prevent state chatter. If a threat value hovers near a threshold, the score should not repeatedly enter and leave tension. Use separate entry and exit thresholds, a minimum dwell time, or another clearly specified stabilisation rule. Also define cancellation: if the player escapes before a queued encounter transition begins, should that transition still play? The answer belongs in the design, not in an accidental implementation detail.

Let repetition breathe

Players can remain in a scene far longer than the capture used for approval. Variation can come from alternate phrases, a changing combination of textures, occasional rests or intentional silence. Randomisation is not automatically musical. If any segment can follow any other, check harmonic compatibility and whether repeated endings begin to sound arbitrary. A constrained set of good connections is often stronger than unlimited combinations.

For listening context, FEZ, by Disasterpeace, is useful when discussing a coherent electronic vocabulary, while Risk of Rain 2, by Chris Christodoulou, can prompt conversations about sustained development and intensity. Treat these as listening references, not proof of a particular implementation technique. A released soundtrack may be edited differently from the assets used in play.

Deliver music and its behavioural specification

The composer and implementer should agree on tempo, meter, loop region, permitted entry points, transition tails and valid layer combinations. Name each state consistently across the cue sheet, exported files and engine events. Include a simple map showing which transitions are supported and which are deliberately disallowed. This prevents an apparently flexible system from requesting musical connections that were never composed.

Implementation tools offer different authoring models. Read the current Audiokinetic Wwise documentation and FMOD documentation when evaluating scheduling, transitions and interactive music authoring. Tool capability does not decide your design. First define what the score must express, then choose the workflow that makes those behaviours clear to author and practical to test.

Finally, test the awkward paths: leave immediately, return repeatedly, pause during a transition, die before the next bar and reload while a layer is active. A score is ready when those paths sound intentional enough for the game—not when the ideal demonstration sounds perfect.

Next: bring it into the engine →

Compose the return journey, too.

Leaving a musical state is part of its identity. A graceful exit often matters more than another layer.