If they didn’t receive it, it didn’t happen

474. Lesson identity

Module

1.12 — Player feedback

Lesson

If they didn’t receive it, it didn’t happen

Academic type

Concept

Lesson type

text

Order

1

Estimated time

20–30 minutes, including practice

475. Learning objective

After this lesson, you can identify the game rule being confirmed, mark a game moment that needs confirmation, and specify audio, visual, or UI feedback that ties the player-facing evidence to that rule.

476. Why this matters

A game event is not complete merely because the game state changed. The player also needs evidence that the change occurred and what it means. Audio, visual effects, and UI elements are feedback carriers: they carry the meaning of a rule and its result to the player. They are not a content pipeline whose purpose is to add more assets or activity. When feedback is missing, the correct first response is to improve the communication of the existing rule—not to change the rule itself.

477. Prior knowledge

You should already be able to identify what the player can feel in a moment from Module 1.2 — Feel, and describe how that experience is presented to the player from Module 1.6 — Presentation. You should also be able to describe a small player action and its visible result using the Stage 1 loop: ACT → RESPOND → CHANGE → AGAIN. This lesson builds briefly on Module 1.11 by keeping the player’s observable evidence separate from assumptions about hidden profile or system state.

478. Core concept

Confirmation is feedback that makes an important game rule and its resulting change legible to the player.

Audio, visual presentation, and UI can all carry that confirmation:

• Audio: a distinct sound can acknowledge an action, success, rejection, or change.
• Visual: motion, color, animation, contrast, or a focused effect can show what changed.
• UI: text, labels, meters, icons, or state indicators can explain the rule or make the result persistent.

These carriers are not interchangeable decoration. Each must point to a specific player question:

• Did the intended action happen according to the game rule?
• What changed because of that rule?
• Can the player safely continue, or do they need to correct something?

If a rule is correct but the player cannot perceive its result, do not change the game rule merely to compensate for missing feedback. First preserve the rule, state what the player needs to receive, and improve the carrier or combination of carriers that communicates it.

Not every event needs a large effect. The required strength of confirmation depends on the consequence and reversibility of the moment. A low-cost, reversible action may need only a small response. A costly, irreversible, or easily misunderstood action needs stronger and more specific confirmation. This lesson concerns player-facing evidence that an attempt or result occurred; a prompt shown before an irreversible commitment is a separate safeguard and may also be appropriate.

479. Mental model

Use the receipt test for any important moment:

Choose the carrier that best answers the question:

Also check whether essential confirmation depends entirely on sound, color, motion, or another single sensory channel. If that dependence could prevent some players from receiving the rule or result, choose a deliberate combination of carriers. This is a carrier-selection principle, not accessibility implementation guidance.

Then place the moment inside the loop:

ACT → RESPOND → CHANGE → AGAIN

• ACT: The player attempts the action.
• RESPOND: The game acknowledges the attempt.
• CHANGE: The player can perceive the relevant result of the rule.
• AGAIN: The player uses that information to choose the next action.

The test is not “Did the code run?” The test is “Could a reasonable player tell what happened, which rule explains it, and decide what to do next?”

480. Concrete example

Imagine a player selects a locked route from a map. The rule is: a route can be opened only when the player has the required capability.

• ACT: The player selects the route.
• RESPOND: The route highlights and a short sound confirms that the selection was registered.
• CHANGE: The route remains locked. A UI message states that the required capability is missing, while a visual locked-state treatment keeps the result visible.
• AGAIN: The player can choose another route or pursue the requirement.

The audio, visual, and UI signals are carriers of one confirmation. They do not add a new rule, unlock the route, or replace the capability check. They communicate that the selection occurred, that the requirement was checked, and that the route did not open. The important result is not conveyed by sound or color alone.

A weak version changes an internal selection value but gives no meaningful response. The player may click repeatedly, assume the map is broken, or fail to discover why the route is unavailable. Another weak version adds random particles, screen flashes, and sounds everywhere. That creates activity without telling the player whether the route was selected, rejected, or opened. The stronger version preserves the rule and makes its result legible.

481. Common mistake

The common mistake is proposing feedback without first identifying the game rule it is meant to confirm. A visible effect can be noticeable yet unrelated to the outcome. A generic flash after every click may prove that something received input, but it does not confirm whether the intended rule allowed the action, rejected it, or changed something else.

A frequent AI failure mode is “particles everywhere.” When asked to make a moment feel responsive, an AI may add particles, flashes, sounds, and floating text to every event without identifying what each signal communicates. More effects do not automatically produce more confirmation. If the signals are not tied to the rule and result, they increase noise and can make different outcomes look the same.

Another mistake is changing the game rule because its feedback is missing. Do not touch the rule as a first response. Keep the rule stable, identify the missing player-facing evidence, and revise the appropriate audio, visual, or UI carrier. Also avoid over-confirming harmless events while under-confirming consequential ones. The feedback must be proportional to the rule’s consequence and connected to the change that rule produced.

482. Guided practice

Choose one moment from a small game loop: opening a door, spending a resource, selecting an unavailable option, collecting an item, or retrying after failure. Do not implement or audit the whole interaction. Mark the single moment where the player most needs confirmation.

Use this focused worksheet:

1. Moment: What is the player attempting?
2. Game rule: Which rule determines the result?
3. Confirmation-needed mark: Write one sentence beginning, “The player needs confirmation here because …”
4. Minimum carrier: Choose audio, visual presentation, UI, or a deliberate combination. State what the player should receive and check that essential information does not depend only on sound, color, motion, or another single channel.
5. Do-not-touch check: Name the game rule that remains unchanged if its feedback is missing.

Keep the response to one marked moment. Do not compare multiple actions, classify the interaction, test repeatability, or propose a complete feedback audit; those tasks belong to the next lesson.

483. Validation / evidence

Your practice is complete when the record contains:

• one specific player moment;
• one game rule that determines its result;
• one clearly marked confirmation-needed point;
• one reason the player could be confused, misread the result, or miss its consequence;
• one feedback carrier or deliberate combination selected for that moment;
• a check that essential confirmation is not restricted to an unsuitable single sensory channel; and
• one statement that the underlying rule remains unchanged while its communication is improved.

A peer or reviewer should be able to identify the marked moment, the rule it needs to confirm, and the intended player-facing signal without asking for hidden implementation details. This validation does not require a full audit, a comparison with another action, a repeatability check, or a classification; those belong to L2 — Feedback audit.

484. Key takeaways

• A state change that the player cannot recognize is functionally incomplete.
• Audio, visual presentation, and UI are feedback carriers, not a content pipeline.
• Identify the game rule before designing its confirmation.
• Confirmation after an attempt or result is distinct from a safeguard shown before an irreversible commitment.
• Essential confirmation should not depend on an unsuitable single sensory channel.
• If feedback is missing, preserve the rule and improve the carrier before changing behavior.
• Avoid “particles everywhere”: effects must communicate a specific action, rule, or result.
• Use ACT → RESPOND → CHANGE → AGAIN to inspect the player-facing loop.

485. Next lesson

Continue to 1.12 L2 — Feedback audit.

486. Knowledge check