Design priority and interruption

919. Lesson identity

Module

2.14 — Audio

Lesson

Design priority and interruption

Academic type

Systems

Schema type

text

Order

2

Estimated time

30–40 minutes

The previous lesson, Audio observes gameplay contracts, established that gameplay systems own facts and audio responds to validated events. This lesson adds the response policy: what happens when several valid audio events arrive at the same time.

920. Learning objective

After this lesson, you can specify a bounded audio priority contract that assigns responses to channels, ranks competing events, and defines when interruption is allowed.

921. Why this matters

Multiple audio responses can be correct at once. A movement loop, an interaction denial, an alarm cue, and a critical warning may all be requested during the same moment. Without an explicit policy, the result depends on callback order, asset timing, or whichever system happens to play last. A priority contract makes those decisions reviewable and prevents every audio response from becoming an unowned rule system. It also gives AI-generated implementation work precise constraints instead of asking an agent to invent behavior from scattered examples.

922. Prior knowledge

You should be able to distinguish gameplay authority from audio observation and describe an event with a stable identity and minimal payload. The previous lesson, Audio observes gameplay contracts, introduced the authority–event–observer model. You should also be able to identify a presentation response that does not mutate gameplay state.

923. Core concept

Audio priority is a presentation policy for resolving competition among valid responses. It is not a second gameplay authority.

A useful contract answers four separate questions:

1. Priority: Which response wins when two responses compete for the same channel?
2. Channel: Which responses may play simultaneously because they serve different presentation roles?
3. Interruption: May a new response stop an existing response, and under what condition?
4. Fallback: What happens when the preferred response cannot start, is already playing, or has no suitable asset?

Priority should be assigned to the communication role of the sound, not merely to the order in which an event arrived. A critical warning may outrank a routine interaction cue on a shared feedback channel. A looping ambience response may continue on its own channel while the warning plays. A short denial cue may be discarded or delayed when the channel is occupied, depending on the contract.

The audio policy may choose to play, replace, queue, layer, duck, or ignore a response. Each choice should be intentional. The gameplay event remains true regardless of which presentation policy is selected. If the warning sound is unavailable, the gameplay warning still exists; the audio system applies its defined fallback.

924. Mental model

Use the channel–priority–interruption–fallback model:

For a bounded scene, describe the policy as a table:

The numbers are local to this contract; they do not describe gameplay importance globally. A priority value is useful only when its channel and tie behavior are also defined.

925. Concrete example

Consider a stealth scene in which the player reaches a locked container while an alarm has just started. Two validated events arrive close together: interaction_denied and alarm_started.

The contract assigns both responses to different communication roles. The denial cue uses the feedback channel at priority 2. The alarm cue uses the alert channel at priority 3 and may interrupt lower-priority alert content. The alarm does not need to stop ambience, because ambience has a separate channel and does not compete for the same role. If the feedback channel is already playing another priority-2 cue, the contract may omit the denial cue rather than queueing an accumulation of stale confirmations.

This policy does not decide whether the container is locked or whether the alarm is active. Those facts were decided by gameplay systems and communicated through events. The policy only decides how much of those facts the player hears, in what order, and through which channel.

926. Common mistake

A common mistake is treating every new event as permission to interrupt whatever is currently playing. This produces noisy feedback and makes an event's arrival time an accidental priority rule.

Another mistake is using one global priority list without defining channels. A high-priority ambience transition could then suppress a critical alert, or several routine cues could compete with one another even though they could have played on separate channels. A third mistake is defining that a sound “must play” without a fallback. Missing assets, occupied channels, and rapid repeated events are normal conditions that require an explicit response.

Do not use audio priority to compensate for unclear gameplay authority. If a sound system must decide which gameplay result is true, the previous contract is missing an ownership boundary.

927. Guided practice

Write a priority contract for this bounded scene:

• A movement loop is already playing.
• The player receives a routine item_acquired event.
• The player attempts a locked interaction, producing interaction_denied with reason = locked.
• A validated alarm_started event arrives before the denial cue finishes.
• The preferred alarm asset is unavailable.

Use three channels at most: ambience, feedback, and alert. For each event, specify:

1. channel;
2. priority from 1 to 3;
3. the same-channel competition rule: whether it may replace, interrupt, queue behind, layer with, or be omitted when that channel is occupied;
4. the cross-channel rule: whether it may play alongside another channel, interrupt another channel, or duck another channel's volume;
5. fallback if the channel is occupied or the preferred asset is unavailable.

Keep two decisions separate. Same-channel competition determines what happens when responses share a channel: priority and tie behavior decide which response plays, waits, replaces the current response, or is omitted. Cross-channel interruption or ducking determines whether a response on one channel affects a different channel: it may coexist, stop that channel, or temporarily reduce its volume. A higher priority on one channel does not automatically authorize interruption or ducking of every other channel.

Your key design decision is how alarm_started should relate to the denial cue. State whether the alarm uses the same feedback channel or a separate alert channel. If it uses the same channel, define the competition and replacement rule. If it uses a separate channel, define whether it coexists with, interrupts, or ducks feedback and ambience. Defend the decision by naming the communication role and the player-facing cost of losing or masking each response. A valid contract may choose different policies, but it must be consistent and bounded.

928. Validation / evidence

Your evidence is a completed policy table and a short rationale for the interruption decision. The table must make it possible to answer both kinds of competition separately:

• Which responses compete on the same channel?
• When a same-channel tie or conflict occurs, which response wins and what happens to the other one?
• Which responses can coexist across different channels?
• Can a response on one channel interrupt or duck another channel, and under what explicit condition?
• Which events may interrupt, and which may not?
• What happens when playback cannot use the preferred asset?

The work is valid when another developer can implement the policy without inferring behavior from callback order or asset names. It must also state that changing the audio policy does not change the underlying gameplay result. A complete answer distinguishes same-channel replacement or queuing from cross-channel coexistence, interruption, or ducking; naming only a global priority order is insufficient.

929. Key takeaways

• Priority resolves competition among audio presentations; it does not establish gameplay truth.
• Channels define which responses compete and which may coexist.
• Same-channel competition requires explicit priority and tie behavior.
• Cross-channel interruption or ducking must be authorized separately rather than inferred from priority alone.
• Every bounded audio policy needs interruption rules and fallbacks.
• A sound may be omitted without invalidating the gameplay event it would have presented.

930. Next lesson

Next: 2.15 — Accessibility.

931. Knowledge check