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.

Questions to answer:

• For each pillar: name three specific implementation decisions where the pillar guided the choice. If you cannot name three, the pillar was not operational.
• For each pillar: name one moment where the pillar was violated or compromised. What caused it? Schedule pressure? Technical limitation? A better idea that superseded the pillar?
• Did any new implicit pillars emerge during development? Something the team was consistently prioritizing that was never formally named? Name it now.
• Are the pillars still the right pillars, or does the game you actually built suggest different ones?
• Reference check: Hollow Knight's pillar of "atmospheric exploration" held through every expansion. Team Cherry cut content that did not serve it, even content they loved. Did your pillars have that authority, or were they suggestions?

Lens 3: Scope Tier Review

Did the Must/Should/Could prioritization protect the right features? What moved between tiers during development, and were those moves correct?

Scope management is not about cutting features. It is about protecting the features that make your game YOUR game while having the discipline to let go of everything else.

Questions to answer:

• List every feature that was in the "Must" tier at the start of this period. How many shipped? How many were downgraded or cut?
• For each downgraded "Must": was the downgrade correct? If you had to make that call again with current knowledge, would you?
• What "Should" or "Could" features consumed more resources than planned? Were they worth the overrun?
• What is the ratio of planned scope to shipped scope? Is the delta ac