Design Feedback Before, During, and After an Action
Feedback does not begin only after success. Fill in the following table for a single action:
| Moment | Check |
|---|---|
| Before the action | Conditions, objective, risks, and clues the player can evaluate |
| At the moment of input | Whether the input was accepted, rejected, or is still being processed |
| State change | Which position, object, relationship, or opportunity actually changed |
| Outcome explanation | Why this outcome occurred and how much was accomplished |
| Next opportunity | What is now possible or impossible, and where to look next |
| Feedback channel | How visuals, sound, animation, text, and UI divide the work |
Feedback should point back to the rule. A generic “Success” message does not reveal which condition was met, while “Failure” alone does not help the player change the next attempt.
Give Each Feedback Channel a Distinct Job
A single change can use complementary signals:
- An object moving, a door opening, or a character animation can show that the world state has changed.
- Sound can indicate that an input was accepted, signal direction, or warn of approaching danger.
- Brief text can explain a rule-based cause that visuals alone cannot convey.
- The UI can preserve states and opportunities that players need to read continuously.
Important outcomes need a redundant path. Color can help distinguish information, but it should not be the only channel. Players who cannot see debug values must still be able to judge the result through the actual visuals or sound. More channels do not automatically make feedback clearer: numbers, flashes, pop-ups, and long explanations presented together compete for attention. Assign each piece of information a primary channel, then add only the supporting signals it truly needs.
Original Design Example: A Misdirected Package at a Mechanical Post Office
This is a paper design, not a built or playtested game. In a fictional mechanical post office, the player sorts packages on the night shift. Each package carries a destination stamp and a handling symbol: a crescent permits only Slow tubes; a triangle permits Slow or Fast tubes. Direction always follows the destination stamp, and every tube entrance shows both direction and speed. While the North tube is under repair, North-bound packages must be held rather than sent to another district.
The station has two separate readouts: a destination dial for the district and a processing sign showing “Pending” or “Held.” A lever selects a route without moving the package. The dispatch pedal triggers the check: sending requires a matching destination, an available tube, and compatible speed; holding requires an empty rack slot. The station accepts one package at a time and admits the next only after processing. An empty station cannot execute a pedal press.
The station currently holds a “North District + Crescent” package. The North tube is under repair, and one rack slot is empty.
| Moment | Feedback and actual change |
|---|---|
| Before input | The North stamp is inside the inspection frame, and the destination dial points north. The crescent legend says “Slow tubes.” The North entrance shows “Slow” and “Under repair.” The rack shows one empty slot; the processing sign reads “Pending” |
| Selecting West | The west gate turns, but the destination dial still points north. Two rebound sounds accompany a locked pedal and “Destination mismatch.” The processing sign remains “Pending”; the package stays on the station |
| Selecting North | The lever stops halfway and springs back; the repair sign sways. The pedal stays locked, and “North tube under repair; hold first” appears. The package does not move |
| Selecting Hold | The side rail aligns with the empty slot. The pedal unlocks, and “Route selected; press pedal to hold” appears. The arm stays still and the processing sign remains “Pending” |
| Pressing the pedal | After checking the slot again, the arm moves the package into it. Slot H3 lights up, and the station sign changes to “Held.” A short message reads “North package in H3; retrieve after North repairs end.” The destination dial has not changed to another district |
| Next opportunity | The completed hold remains visible; an empty station cannot execute the pedal. When another package enters, the dial reads its stamp and the sign resets to “Pending.” The player can process another destination or open the holding record for H3 |
Selecting West exposes a mismatch between the package’s destination and the chosen route. It must not play the successful sending animation. Selecting Hold means the input was accepted; moving the package after the pedal press means holding is complete. If the slot becomes occupied between selection and the pedal press, the package should remain at the station with “Rack full.” That branch has not occurred in this example.
The H3 record preserves the North destination and crescent speed requirement. The declared later rule allows retrieval to an empty station once the North tube publicly shows repairs complete, followed by selecting North and pressing the pedal. This is a condition for a later action, not a delivery already completed in this turn. For repeated input, specify whether the station is empty or contains a new package; an extra pedal press cannot hold the same H3 package again.
Hidden State Is Not Player Feedback
A design document may track congestion, alert level, or a rule phase, and the implementation may contain internal variables. If players cannot perceive a corresponding effect, they cannot use that state to make a decision.
The mechanical post office can track the north tube’s repair progress internally, but players need at least one readable signal: the repair sign, a change in the machinery’s sound, or a public timetable. Showing an exact internal value is not always appropriate either. Feedback should fit the player’s role and the game’s mode of expression. What matters is that the player can use it to decide what to do next, not that the designer knows a variable changed.
Explain Outcomes Until the Player Can Act
When explaining failure, focus on the nearest relationship the player can change:
- Unmet condition: identify the visible condition that is missing.
- Incomplete input: show what still needs to be selected, held, or confirmed.
- Changed state: explain why the original action can no longer be performed.
- Weaker outcome: show what was completed and which opportunity was lost.
Do not reveal a complete answer the player has not discovered. In a puzzle, the game can indicate that an input was rejected and let the environment expose the contradiction; it does not need to display the correct action outright. The goal of feedback is to help the player form the next judgment.
Compare Adjacent Paths to Check Whether Feedback Is Honest
On paper, place three paths side by side: one in which the condition is met, one missing a single condition, and one that repeats the input after the state has already changed. Compare input acceptance, changes in the world, explanatory text, and the next step across all three.
If every path displays the same “Complete” message, the feedback hides the rule differences. If a failed path plays a success animation without committing the result internally, the visuals contradict the state. If the game still says a reward can be claimed after success, it misrepresents the next opportunity.
A paper review can expose obvious gaps. Whether players actually notice, understand, and trust these signals must be observed in a real candidate; it cannot be inferred from the table.
Common Feedback Problems and Fixes
| Problem | Fix |
|---|---|
| No response after input; the player must wait for final resolution | Immediately show whether the input was accepted, rejected, or is in progress |
| Success appears only as a higher number | Show how facts in the world and new opportunities changed |
| Failure says only “Conditions not met” | Identify a condition the player can see and change |
| A critical threat uses only one color | Add readable channels such as shape, animation, sound, or text |
| A value exists in the debug panel, so the player is assumed to know it | Provide a signal the player can observe within their role |
| Feedback gives away the puzzle answer | Explain the contradiction and rule outcome while preserving what the player must still judge |
FAQ
Is more game feedback always better?
No. Give each piece of information a primary channel, then add only the necessary redundancy. Multiple pop-ups, sounds, and animations repeating the same fact at once can obscure the state change players actually need to observe.
Can failure feedback say only “Try again”?
It can be brief when players can already read the cause from the visuals and rules. When the cause is not visible, identify the nearest condition or action they can change so the retry has a basis.
Do it with the skill
In a project that already has SOURCE_BIBLE.md, a selected CONCEPT.md, and PRODUCT_BRIEF.md, use /game-world-design ($game-world-design in Codex) to document the core rule’s pre-action conditions, input response, state change, reason for the outcome, next opportunities, and feedback channels. Compare three paths: success, a missing condition, and repeated input. Deliver the design only; do not build the game or claim that players already understand it.
Read the method: World rules and feedback · Motion, sound, and information hierarchy