Fail-State Postmortem
Take one real game's failure design apart using the taxonomy from weeks 1 and 2, and say what it's actually forgiving
Due: 22 March 2027 · Weight: 30%
The brief#
Pick one game and explain, precisely, what happens when a player fails at it — and why the designer chose that, rather than the obvious alternative.
Vague failure-design writing tends to stop at description: “this game has checkpoints” is not an analysis, it’s an observation. A strong postmortem uses the taxonomy from weeks 1 and 2 to say something more specific — which tier of loss the game inflicts, why that tier and not another, and what would change about the game if the designer had picked differently.
Pick a game you know well enough to be specific about. An unfamiliar game analyzed shallowly is a worse submission than a familiar one analyzed precisely.
What you submit#
A single written document, roughly 2000 words (a shorter piece that does the same work well is not penalised for length). Structure is your choice, but a reader should be able to identify your central claim, the evidence for it, and where the taxonomy is doing analytical work rather than decoration.
The spec
The brief poses the problem and leaves room for a response. The spec is the fixed part: what a marker checks. Some lines can be checked mechanically; the rest call for judgement.
- submitted by the deadline, as a single document (2000 words or equivalent)
- names the game and identifies at least two tiers of the taxonomy it uses
- argues a specific claim about what the game's fail state is doing, not just what it is
How it is marked
Hover or tab through the bar to see each criterion.
| Criterion | Weight | Your mark | Contributes |
|---|---|---|---|
| Correct use of the failure taxonomy | 40% | — | |
| Depth and specificity of the analysis | 40% | — | |
| Clarity of the written argument | 20% | — | |
| Projected total | Enter marks above to see a projected total. | ||