Audio observes gameplay contracts

905. Lesson identity

Module

2.14 — Audio

Lesson

Audio observes gameplay contracts

Academic type

Concept

Schema type

text

Order

1

Estimated time

25–35 minutes

This lesson establishes a boundary: gameplay systems decide what happened, while audio observes that decision and presents an appropriate response. The preceding module is 2.13 — Persistence.

906. Learning objective

After this lesson, you can map explicit gameplay events to audio responses without making the audio layer responsible for gameplay state or rules.

This is a systems exercise using a hypothetical or explicitly labelled example. It is not documented CONTRABAND production history unless a verified theme is named.

907. Why this matters

Audio is most reliable when it reacts to a stable gameplay contract rather than trying to infer game state from presentation details. This separation lets a rule change without requiring every sound response to recreate that rule. It also gives AI-generated implementation work a clearer target: an event name, a payload, and an observer response can be reviewed independently.

908. Prior knowledge

You should already be able to distinguish a gameplay rule from its presentation and identify the systems that own state. The preceding module, 2.13 — Persistence, is relevant because its lesson Restore systems in a deliberate order reinforces ownership, contracts, and sequencing: a system should receive valid information before it applies or presents it.

909. Core concept

Gameplay events are contracts between the system that owns a fact and the systems that respond to that fact.

An event should communicate a meaningful occurrence, such as item_acquired, alarm_started, or interaction_denied. The gameplay system remains authoritative: it validates the action, changes state, and emits the event only when the occurrence is real. An audio observer subscribes to the event and chooses a sound, variation, or silence. It does not decide whether the item was acquired, start the alarm, or alter the inventory.

A useful contract has three parts:

1. Event identity: a stable name describing the occurrence.
2. Relevant payload: the minimum context needed by observers, such as item category or alert level.
3. Observer response: a presentation decision made after the event is accepted as true.

The event is not a command to the audio system to fake a result. It is a statement from an authoritative system that a result has already occurred. Audio presentation content—sound selection, variation, or silence—is a response to that fact, not the source of gameplay authority.

910. Mental model

Use the authority–event–observer model:

The direction is one way:

player action → authoritative rule → gameplay event → audio observer → sound response

If the audio observer needs to ask the gameplay system to decide whether something happened, the boundary is probably reversed. If the event contains raw implementation details that observers do not need, the contract is probably too tightly coupled. A sound response can communicate a gameplay fact, but it cannot establish that fact.

911. Concrete example

Imagine an interaction system handling a locked container.

1. The interaction system checks the player's access condition.
2. If access is denied, the interaction system leaves the container state unchanged.
3. It emits interaction_denied with a small reason such as locked.
4. The audio observer maps interaction_denied: locked to a restrained rejection sound.
5. A separate UI observer may show a message.

The audio observer must not unlock the container because a sound played successfully. It must not inspect a button animation and guess that the interaction failed. It receives the gameplay fact and presents it. The rejection sound is presentation content; the denied interaction remains a gameplay result owned by the interaction system.

A second event, container_opened, should be emitted only after the authoritative system has completed the state change. The audio response can then play an opening sound, but the sound is not evidence that the container is open.

912. Coverage extension: event mapping across gameplay contexts

The same authority–event–observer boundary applies across several gameplay contexts. Map the validated result first, then define the audio response:

These events should be emitted only after their owning gameplay systems validate the result. Audio may select or omit a response based on the payload, but it must not decide whether damage occurred, an objective completed, an interaction succeeded, or an arrival was valid.

913. Common mistake

A common mistake is putting gameplay decisions inside audio callbacks: for example, allowing a sound handler to decrement ammunition, unlock an object, or decide whether an interaction succeeded. This makes a presentation system an accidental authority. It also creates hidden dependencies: disabling, delaying, or replacing a sound can then change gameplay behavior.

Another mistake is emitting an event for an attempted action and naming it as though the action succeeded. open_button_pressed is not the same contract as container_opened. The first describes input; the second describes an authoritative gameplay result. Audio feedback must know which kind of fact it is observing.

914. Guided practice

Use the following event candidates for a stealth interaction system:

• button_pressed
• door_opened
• door_open_failed
• alarm_level_changed
• play_door_sound

For each candidate, make three decisions:

1. Is this an authoritative gameplay fact, an input signal, or a presentation command?
2. Should an audio observer consume it directly?
3. If it is suitable, what minimum payload would help audio choose a response?

Record the suitable candidates in an authority–event–observer table. Add a final note identifying any audio responses that could occur simultaneously or compete for attention; you will use those cases in the next lesson.

Then select one candidate and write a compact contract using this format:

Event: door_open_failed
Authority: interaction system
Payload: reason = locked
Audio response: short denied-access cue
Gameplay mutation by audio: none

Your meaningful decision is whether the event should describe the attempted input or the validated gameplay outcome. Prefer the outcome when audio needs to communicate what actually became true, and preserve input events only when another system has a clear reason to observe them.

915. Validation / evidence

Your evidence is a completed authority–event–observer table and one event contract. It must show:

• which system owns the gameplay fact;
• whether the event describes an attempt or a validated result;
• the minimum payload required by audio;
• the audio response as presentation content;
• which responses could occur simultaneously or compete for attention;
• an explicit statement that audio does not mutate gameplay state or establish the outcome.

The work is valid if another developer can identify where the rule is decided without reading the audio response, can replace the sound without changing the gameplay outcome, and can locate the competing responses that will require priority or interruption rules.

916. Key takeaways

• Gameplay systems own rules and state changes.
• Events communicate meaningful facts through explicit contracts.
• Audio should observe gameplay outcomes rather than infer or authorize them.
• Event payloads should provide enough context for presentation without exposing unrelated implementation details.

917. Next lesson

Next: 2.14 L2 — Design priority and interruption. Carry your completed authority–event–observer table into that lesson. Use the responses you marked as simultaneous or competing to define priority and interruption rules without transferring gameplay authority to the audio layer.

918. Knowledge check