First Distinguish Hard Failure, Soft Failure, and Weaker Outcomes
The three result types serve different purposes. Use only the ones the project needs:
- Hard failure: The current run cannot continue and enters an explicit recovery or restart.
- Soft failure: A goal, an uncommitted gain, or a local opportunity is lost, while the main progression continues.
- Weaker outcome: The player completes the goal but returns with less evidence, fewer relationships, or a smaller reward. It is still a valid terminal state.
Do not call every imperfect outcome a failure. A player who deliberately withdraws while preserving completed content may have reached a weaker outcome; missing an optional objective may simply be a path variation. The classification should match the actual state and the opportunities that remain.
Fill Out a Failure and Restart Card
| Item | What to define |
|---|---|
| Failure trigger | Which observable condition ends this segment or initiates recovery |
| Readable cause | How the player can identify the most recent action or relationship they could have changed |
| Completed outcomes | Which facts, rewards, relationships, or progress have already taken effect |
| Lost content | What is lost, and why that loss follows from the cause of failure |
| Preserved content | What does not roll back, so completed actions are not erased |
| Retry point | The current action, the current situation, the start of the segment, or the initial state of the full run |
| Defined initial state | The location, tools, event history, and random conditions after a restart |
| Recovery path | What the player can change next, rather than merely repeating the punishment |
What is preserved and what is lost should have a causal relationship. If a local mistake clears an unrelated chapter, the player will struggle to learn from the failure. If every cost is restored automatically, the rules lose their meaning.
Original Design Example: Failure and Restart in an Old-City Photo Exhibition
The following is an original paper design, not a conclusion from a build, playtest, or balance test. In this fictional game, the player prepares a photo exhibition for an old-city archive. On the table are three photographs of an old street, a publicly available date ledger, and oral-history material from a longtime resident. The main task is to arrange the photographs by date. Captions about relationships between people are optional; when uncertain, the player can honestly mark them as “To Be Verified.” In this example, the oral-history material is available only once during this round of preparation because the story establishes that the resident will accept only one interview for this exhibition. This is not a general rule based on the number of failures. The exhibition has only one print run: if the submitted main timeline conflicts with the public date ledger, the opening organizers cancel the exhibition for this run.
| Result | Trigger and state |
|---|---|
| Weaker completion | Trigger: All three photographs are correctly ordered according to the date ledger; the player marks an unverified relationship as “To Be Verified,” then selects “Send to Print”. State: The timeline is correct, the relationship caption remains blank, and the exhibition opens for this run. Next: The catalog explicitly preserves the unconfirmed item rather than presenting a guess as fact; the printed catalog cannot be changed during this run |
| Soft failure | Trigger: During the oral-history interview, the player states an unsupported family relationship as fact; the resident immediately points out the lack of support and withdraws the oral-history material. State: The only opportunity to consult the oral-history material ends, but exhibition preparation continues; the date ledger and photographs already placed remain, and nothing has been sent to print. Next: The player can still use the public dates to complete the main timeline and mark the relationship as “To Be Verified”; the oral-history material cannot be recovered during this run, and the main process does not reset |
| Hard failure | Trigger: The submitted photograph order conflicts with the date ledger visible on the table, and the player still selects “Send to Print” as the final action. State: The review sheet marks the conflicting dates; because this run allows only one print and the incorrect catalog cannot be reprinted, the exhibition is canceled and the run ends. Next: The only option is “Restart Preparation,” which enters the complete initial state defined below; the player cannot quietly revise the printing in a run that has already ended |
Current state after the soft failure. For example, the player has placed two photographs according to the date ledger, while the third remains in its photo slot. The date ledger stays open, the two existing placements remain, and the relationship caption is still unconfirmed. The oral-history material changes to “Unavailable for the Rest of This Run,” and the interview request has ended. The print state remains unsubmitted, the exhibition-canceled flag is false. The interface displays: “Oral-history material withdrawn; you can still complete the timeline using public dates.” The player's next available action is to consult the open date ledger and place the third photograph, or to leave the relationship caption marked “To Be Verified.” No button can request the same oral-history material again; continuing the main task is not a retry of the interview.
Full restart after the hard failure. The player returns to the preparation table in the archive. No result card or print dialog is open in the interface. All three photographs return to their respective photo slots. The date ledger returns to the opening page authored for this run and remains available to consult. The interview request returns to “Not Yet Conducted.” All placements, relationship captions, review findings, print records, and opening states are cleared. The exhibition-canceled flag is false. The first available action after the restart is to open the date ledger and check the date of one photograph. This example reuses the same photographs, date ledger, and authored sequence after a restart; it does not draw a new puzzle or change a random seed.
Sequence rule. The photographs and date evidence are fixed in this example. After the soft failure, the current arrangement and public dates remain in effect; the current run does not reset. Only a restart after hard failure clears the preparation state and begins again from the same authored sequence. This only shows which state each recovery path reads in the paper design. It does not establish that the prompts are easy to understand, that the exhibition rules are fun, or that an implementation can reset correctly.
The Cause of Failure Should Point to What the Player Can Change Next
A failure explanation should connect the most recent action the player could still change, the rule's response, and the consequence. In the archive-exhibition example, “oral-history material unavailable” states only the result. “The player presented an unsupported family relationship as fact, so the resident withdrew the oral-history material for this run” identifies what the player did, why that optional source was lost, and which public evidence remains available. A hard failure likewise should not display only “Exhibition Failed.” It should identify which visible date record conflicts with the order sent to print and explain that the opening arrangement for this run has been canceled. The explanation should not reveal facts the player has not obtained or present a random result as if it were the player's mistake.
A Restart Must Restore a Defined Initial State
Writing “restart” is not enough. Decide where the player returns, what state the interface shows, whether objects and evidence are restored, whether completed outcomes remain, whether temporary input and in-progress resolution are cleared, and whether a random situation is retained, reset, or replaced. The soft failure in this example is not a restart: the interview opportunity is gone, while the photographs and date ledger can still be used to complete the main task. Only the hard failure ends the run. A full restart restores the three photographs, the date ledger, the interview request, relationship captions, print record, and opening state to the authored preparation state. If the same “Continue” button sometimes preserves state and sometimes clears it, the result screen should state the scope of this recovery.
A Recovery Path Should Provide a New Opportunity to Act
The recovery path after failure should respect what has already been lost. After the oral-history material is withdrawn, do not provide a button that resets the same interview as though it never happened. Let the player complete the main timeline with the date ledger that remains available and leave an unsupported relationship marked “To Be Verified.” After a hard failure, the run has ended, so the player can only enter an explicitly labeled full restart rather than continue sending material to print from an opening process that has already been canceled. Information can become clearer, but the recovery rules should not quietly erase a consequence the player has already caused.
Walk Through Failure, Recovery, and the Next Action on Paper
Starting from one complete initial state, walk through two paths. In the first, the player loses the oral-history source by making an unsupported claim about a relationship, then checks the public date ledger, completes the timeline, and sends it to print with the relationship caption marked “To Be Verified.” In the second, the player places a photograph in a position that conflicts with a visible date and still sends it to print; the review identifies the conflict and cancels this run, after which the player selects a full restart. At each step, write down the result screen, the state that was preserved and lost, and the next available action. A paper walkthrough can only check whether the description is internally consistent. Actual reset behavior and whether players understand the cause still require validation after a build exists.
Common Failure-Design Problems and Fixes
| Problem | Fix |
|---|---|
| Treating every imperfect outcome as failure | Distinguish a valid weaker outcome, a soft failure, and a failure that ends the run |
| Explaining failure only as “Mission Failed” | Identify the observable trigger and the most recent relationship the player could change |
| Clearing unrelated progress after a local mistake | Define what is preserved and choose an appropriate retry point |
| Leaving resources and event history ambiguous after a restart | Define the initial state and random conditions item by item |
| Preserving a reward after soft failure but allowing it to be claimed again | Make history and claim state part of the recovered state |
| Claiming there is no problem merely because the player can return to the beginning | Validate the actual state in a build and playtest whether players understand the cause and cost |
FAQ
Must Failure Always Consume Resources or Clear Progress?
No. The consequence should follow from the cause of failure and the project's promises. The player can lose a local opportunity, enter a weaker outcome, or return to an appropriate decision point. The scope of what is preserved should be explicit and honest.
What Is the Difference Between a Soft Failure and a Bad Ending?
A soft failure usually lets the main progression continue while losing a local gain or opportunity. A bad ending is a completed terminal state. The name matters less than ensuring that the player knows whether the current run has ended, which state is preserved, and what they can still do.
Do it with the skill
In a project with an existing SOURCE_BIBLE.md, a selected CONCEPT.md, and a PRODUCT_BRIEF.md, use /game-world-design ($game-world-design in Codex) to record the trigger, readable cause, preserved and lost content, retry point, defined initial state, and recovery path for each type of failure, then walk through the first action after recovery. Deliver design only; do not build the game or claim that playtesting is complete.
Read the method: Method used in this article