Bad Endings Are More Than Failure Screens: Making Death, Regret, and Rollbacks Narrative Rewards
Design bad endings around causal, informational, character, and skill rewards, and reduce repetitive punishment with well-chosen rollback points.
Introduction
A bad ending should do more than cut to black, tell players they chose wrong, and make them rewatch twenty minutes. Good failure rewards players with information, emotion, or ability, helping them understand the world better, care more about their next decision, or retry more efficiently.
Four Effective Types of Reward
Causal endings tie back to early decisions; informational endings reveal secrets unavailable on the main path; character endings complete a relationship or character arc; skill endings expose rules players have yet to master. Every bad ending should provide at least one.
Fair Failure Needs Three Stages
Signal risk before the choice, give feedback on changes in state after the choice, and tie the ending back to its key causes. Surprises can exceed players’ expectations, but should not invent rules at the last minute.
Rollback Distance Is Part of the Design
A local execution error is best handled by returning to a nearby node. An ending caused by a long-term relationship can send players back to a key branch, but should offer skipping of previously read content, a story map, or state indicators. The weight comes from the people and opportunities lost, not from repetitive sequences that cannot be skipped.
| Ending | Prior State | Risk Signals | Player Reward | Rollback Point |
|---|---|---|---|---|
| E03 | Low trust, no evidence | Two instances of relationship feedback | New information | N12 |
If a bad ending provides no risk signals and no reward, yet requires a long replay, it should usually be removed or rewritten.
The number of endings does not equal depth of content, either. Twenty deaths caused by the same kind of accidental input are less valuable than three failures that help players understand different characters and rules. When designing an ending tree, fill in the causes, rewards, and rollback points first, then decide whether each ending is worth producing.
Failure Must Make Cause and Effect Clearer
After failing, players first ask: Why did I end up here? The ending should pay off at least one previously observable signal, such as a character’s hesitation, insufficient resources, or a risky route. You can hide the complete formula, but not every basis for the outcome. If failure depends solely on a new rule that suddenly appears just before the ending, players learn not how the world works, but that the author can change the answer at any time.
Causal callbacks can work on three levels. The immediate level explains what the action just taken caused; the medium-term level identifies which earlier relationship or resource made the situation worse; the thematic level shows what values the character’s choices exposed. Not every ending needs to explain all three levels, but a key ending should at least give players one clue they can use to make judgments on their next run.
You Do Not Need to Provide All Three Types of Reward
Informational rewards reveal secrets, perspectives, or rules; emotional rewards complete a farewell, reconciliation, or betrayal; operational rewards let players return to a key node faster. An ending has value if it delivers just one of these well. Conversely, cramming in extensive lore without responding to players’ choices does not count as a real reward.
Bad endings can also change how players read the next run. The story map can mark newly unlocked nodes, fast-forwarding through previously read content can retain reminders of key differences, and character profiles can add information just confirmed. If the product allows memory across playthroughs, it must clearly distinguish between “what the player knows” and “what the character knows,” preventing the protagonist from inexplicably using information from the previous run.
Rollback Design Must Match the Scope of Responsibility
A single wrong QTE input is best retried from a few seconds earlier; misjudging a subject of investigation can send players back within the current scene; a relationship breakdown caused by prolonged neglect can send them back to the most recent explicit warning. If the rollback is too short, players cannot change the cause; if it is too long, punishment becomes repeated viewing. The save-point interface should ideally explain which collectibles, relationship states, and previously read content will be retained.
Check Fairness with a Failure Receipt
A test build can show an internal “failure receipt” after an ending: trigger conditions, risk signals the player has seen, key state changes, newly acquired content, and a recommended rollback point. It need not be shown to players in the released version, but can help writers and QA assess whether the design is internally consistent. If testers can generally recount the cause yet still want to try another path, the failure is usually effective; if all they say is “the system screwed me over,” rewrite the signals or shorten the rollback.
Finally, track ending reach rates, immediate exit rates, rollback rates, and changes in the second choice. Data can only identify where investigation is warranted; it cannot establish on its own whether the emotion works. Combine it with interviews asking what players understood, what they lost, and what they plan to change next time.
Remove Worthless Failures Before Release
Put all bad endings in one table and compare their trigger conditions, warnings, informational rewards, emotional rewards, and retry costs. If two endings differ only in their death footage but teach players the same thing, keep the one with stronger expression. The production budget saved should go toward clearer causal feedback or smoother rollbacks.
Ask testers to explain why they failed without reading the design document, and to identify what they would change on the next run. Being able to accurately recount the cause while still feeling sad usually indicates that the tragedy works; completely failing to understand the conditions is a readability issue; understanding them but being unwilling to retry often calls for checking repetition length and reward strength.
Final footage acceptance should also confirm that bad endings have subtitle, volume, skipping, and accessibility support consistent with the main path. Failure paths are not low-priority peripheral content; since they carry narrative rewards, they should meet the same production and testing standards.
