Two platformers can have the same jump arc, the same spike placement and the same hit points, and one of them gets called "tight" while the other gets called "unfair." The difference usually isn't in the challenge at all. It's in the three seconds after the player dies: how long they wait, how much they lose, and whether they understood what killed them.
Most teams design failure by accident. The death state is whatever fell out of the engine template — a fade to black, a reload, a respawn at the last trigger — and then difficulty gets tuned by changing enemy damage numbers instead. That's tuning the wrong end of the loop. Failure is a mechanic with its own budget, and it deserves a page in your design docs next to the jump height.
Failure has four costs, and you choose each one
When a player fails, they pay in some combination of four currencies. Write them down separately, because teams routinely charge for all four when they meant to charge for one.
- Time — how many seconds between the failure and being back in meaningful play.
- Progress — how much of the level, run or quest has to be redone.
- Resources — currency, consumables, ammo, equipment durability, squad members.
- Knowledge — what the player learned. This is the only cost that can be negative: a good failure teaches, so the player comes back richer than they left.
Look at how differently well-known games spend these. Celeste charges almost nothing but time, and the time is a fraction of a second — you restart the same screen, keep every strawberry, and the retry is so cheap that dying becomes part of the vocabulary. Dark Souls charges time (the run back from the bonfire), resources (your dropped souls, retrievable once) and progress (respawned enemies), but never knowledge: the boss's moveset doesn't change, so repetition is literally the progression system. Hades charges a whole run of progress but explicitly refunds knowledge and meta-currency — you walk back into the House of Hades with Darkness, new dialogue and a better build next time. Into the Breach hands you one free turn reset per mission, which converts a specific class of failure (a misread of the enemy's telegraphed move) from a cost into a lesson.
None of those is the "right" answer. They're four different bills for the same event.
Set a retry budget before you tune difficulty
Pick a target retry time per failure type and treat it as a performance requirement, not a nice-to-have. Here is a reasonable starting table for a small team; adjust to your genre, but write the numbers down so they can be tested.
| Failure type | Target time to meaningful play | Progress lost | Notes |
|---|---|---|---|
| Precision platforming death | under 1s | current screen/room | No fade, no logo, no "You Died" card |
| Combat death, room-scale | 2–5s | current encounter | Enemies reset, consumables refunded |
| Combat death, boss | 5–10s | boss only, not the approach | Never make players re-walk a corridor |
| Failed stealth, non-lethal | 0s (state change) | nothing | Alert state is the penalty |
| Run end (roguelike) | 15–45s | whole run | Must include a meta-progression beat |
| Failed mission (tactics) | 30s | the mission | Campaign continues; losses are narrative |
The brutal practical test: instrument it. Log a timestamp when the death state triggers and another when the player regains input control with the camera settled, then look at the median across a playtest session. Teams are routinely shocked — a "fast" restart turns out to be 4.2 seconds once you count the death animation, the fade, the level reload and the camera lerp. If your target is one second, everything in that chain is a budget line.
Two cheap wins almost every project leaves on the table:
- Keep the level loaded. Reset entity state instead of reloading the scene. This is a technical decision that makes a design target reachable, which is exactly the kind of thing that needs to be in the doc before the engineer builds the level loader.
- Cut the ceremony. Death stingers, slow-motion flourishes and confirmation prompts are charming on the first death and infuriating on the fortieth. If you want the flourish, make it skippable by any input on frame one.
Make the cause legible within one second
A failure the player can't explain reads as unfair no matter how cheap the retry is. Legibility is three separate jobs:
Telegraph before
The attack that kills must have had a tell with enough frames to react. Pick a reaction-window floor — 12 frames at 60fps is a common lower bound for a wind-up a human can actually answer — and audit every lethal attack against it. Anything below the floor either gets more wind-up frames or stops being lethal.
Mark the moment
Hit-stop, a distinct damage sound for "this one was fatal," a brief freeze-frame on the killing blow. The player should be able to name the thing that killed them without a replay.
Confirm after
A single line is often enough: "Killed by Ashguard — Overhead Slam." Fighting games go further with frame data; horror games deliberately withhold it. Choose deliberately rather than by default.
A useful playtest instrument: after each death, ask the player "what killed you?" If more than about one in five answers is wrong or vague, you have a readability bug, not a balance bug — and lowering enemy damage will not fix it.
Design the recovery, not just the respawn
The strongest failure systems give the player something to do with the setback.
- Soft fail — the attempt continues in a worse state. Failed a Disco Elysium check and the conversation moves on down a different, often more interesting branch. Failed stealth becomes a fight. Blown a timed objective yields a partial reward instead of a reset.
- Comeback mechanics — Mario Kart item distribution weighted by position; a second-wind window where one successful hit restores a sliver of health. Powerful, and dangerous: they flatten skill expression, so gate them to the modes where closeness matters more than accuracy.
- Convert loss into currency — the Hades pattern. If a run must be lost, it should buy something permanent, even if it's just a new conversation.
- Give failure a floor — a bad-luck guard so the same wall can't be hit indefinitely. After N consecutive failures on the same encounter, offer a skip, a hint, or a quiet 10% damage reduction. Name the threshold in your docs and expose it as a tunable value.
A checklist you can run this week
- Every failure state in the game is listed by name, not assumed.
- Each one has a target retry time, and the measured median is within 20% of it.
- Each one states explicitly what is lost across time, progress, resources and knowledge.
- No lethal attack has a wind-up shorter than your reaction-window floor.
- Four out of five playtesters can correctly name what killed them.
- Repeated failure on one obstacle has a defined escape hatch.
- Death ceremony is skippable on the first frame of input.
Where this lives in your documentation
Failure design goes stale fast because it's spread across disciplines — the animator owns the death stinger, the engineer owns the reload, the designer owns the penalty. Keep it in one place: a mechanics entry for each failure state with its four costs and its retry budget, the thresholds (reaction-window floor, consecutive-failure escape hatch, comeback trigger) as rows in your balance sheet so they're tunable instead of hard-coded, and the "what killed you?" question as a standing item in your playtesting notes so the readability number gets tracked across builds rather than relitigated every milestone. In GameDesignerX those are three linked records, which matters mostly because it means the retry budget stops being folklore that only the person who set it remembers.
Players will forgive a hard game. They won't forgive a slow one, and they really won't forgive one they can't learn. Budget the three seconds after death as carefully as the three before it.