game-retrospective

Files (1)

• SKILL.md

SKILL.md (first lines)

# AlterLab GameForge -- Game Development Post-Mortem

The game industry has the best post-mortem tradition in software. Gamasutra's classic
post-mortem series — Diablo II, Baldur's Gate, Black & White, Thief — taught an entire
generation of developers more than any textbook because they were brutally honest. Five
things that went right. Five things that went wrong. No spin, no corporate sanitizing,
no "learnings and opportunities." Just the truth about what happened when a team tried to
ship a game.

This workflow follows that tradition. Not Scrum retrospectives. Not agile ceremonies. Game
development post-mortems — the format that Supergiant used to iterate Hades from a decent
roguelike into a genre-defining masterpiece, that ConcernedApe used to survive five years
of solo development on Stardew Valley without losing his mind, that the Dwarf Fortress
brothers used to sustain a twenty-year development cycle without burning out or losing
direction.

The difference between a corporate retro and a game post-mortem: a corporate retro asks
"what could we improve?" A game post-mortem asks "did we build the right game, and did we
build it the right way?" One optimizes process. The other interrogates the creative and
technical decisions that determine whether your game ships, and whether it is worth
shipping.

### Purpose & Triggers

Run this workflow when:
- A sprint ends and the next one has not started
- A milestone lands (vertical slice, alpha, beta, gold)
- A project ships or is cancelled
- Development feels stuck and nobody can articulate why
- The game is "fine but not fun" and the team needs to diagnose the gap
- A major pivot or scope cut just happened and the dust has settled
- Before starting a new project, to extract lessons from the last one

Problems this solves:
- Repeating the same design mistakes because nobody documented why a feature failed
- Cutting the wrong features because scope pressure overrides design judgment
- Technical debt accumulating invisibly until it blocks progress
- Teams that playtest but never analyze the patterns in playtest data
- Solo developers who skip reflection and wonder why their third prototype dies the
  same death as the first two
- The "it felt off but we shipped it anyway" regret cycle

### Critical Rules

1. **GDC format, not agile format.** The structure is "What Went Right / What Went Wrong /
   Lessons Learned." Not "went well / didn't go well / action items." The distinction
   matters: GDC format forces you to commit to a judgment. Something either went right or
   it went wrong. Fence-sitting is not allowed.

2. **Game-specific lenses, not generic process questions.** Every retrospective passes
   through six game development lenses (detailed below). "Did we communicate well?" is a
   process question. "Did the core loop deliver the intended experience?" is a game
   development question. This workflow asks the second kind.

3. **The Kill List is mandatory.** Every retrospective includes a review of what was cut.
   The discipline to cut is the discipline to ship. The Kill List forces you to evaluate
   whether your cuts were correct, premature, or too late.

4. **"The One Thing" is mandatory.** After all analysis, distill everything to a single
   sentence. One lesson. The one that changes how you work next time. If you cannot pick
   one, you have not thought hard enough.

5. **Evidence over feelings.** "The combat felt off" is not a finding. "Playtesters
   disengaged during combat encounters longer than 45 seconds, suggesting the damage
   loop is too slow for the encounter scale" is a finding. Back everything with data,
   playtest observations, or specific incidents.

6. **Read the last post-mortem first.** Before starting, review the previous retrospective.
   Did those lessons actually change anything? If the same problems appear twice, the issue
   is not awareness — it is execution. That distinction changes the action plan entirely.

7. **Solo devs do this too.** ConcernedApe developed Stardew Valley alone for five years.
   He has spoken publicly about the burnout, the scope creep, the periods where he almost
   quit. Solo developers have zero external feedback loops. This workflow IS your external
   feedback loop. Write it down. Do not just think about it.

### The Six Game Development Lenses

These lenses replace generic retro questions. Every retrospective — sprint, milestone, or
project — passes through all six. Not every lens will produce findings every time. That is
fine. But you must look through each one.

---

**Lens 1: Core Loop Validation**

Did the core loop deliver the intended experience? Was it fun in isolation before content,
narrative, and progression systems were layered on top?

Celeste's core loop — dash, jump, climb — was fun in a blank room with white rectangles.
Madeline's movement felt good before a single strawberry, B-side, or story beat existed.
If your core loop is not fun in a blank room, content will not save it. This is the most
important lens because everything else is built on top of it.

Questions to answer:
- Strip away all content, progression, and narrative. Is the core verb set satisfying on
  its own? Can you play the loop for 10 minutes in a test room and want to keep going?
- Where in the loop does the player feel agency? Where do they feel constrained? Are those
  the right places?
- What is the loop's rhythm? Is it the rhythm you designed, or did it drift during
  implementation?
- How long is one cycle of the loop? Is that length correct for your genre and session
  target?
- Reference check: Hades' core loop (enter room, fight, choose boon, repeat) was iterated
  for over a year in Early Access. Supergiant shipped the loop first and layered content
  on a proven foundation. Did you do the same, or did you build content on an unproven
  loop?

---

**Lens 2: Pillar Integrity**

Did the design pillars hold through implementation, or did they drift? If they drifted,
was the drift intentional evolution or unconscious erosion?

Pillars are only useful if they survive contact with production. A pillar that reads
beautifully in a GDD but gets quietly abandoned when implementation gets hard was never a
real pillar — it was an aspiration. This lens detects the gap between stated pillars and
shipped reality.

From AlterLab-IEU/AlterLab_GameForge, MIT.

More from AlterLab-IEU/AlterLab_GameForge