game-prototype

AlterLab GameForge -- Hypothesis-Driven Prototyping

Prototypes are experiments, not demos. Every prototype exists to answer one question: "Is this worth building?" The moment you start polishing a prototype, you have stopped prototyping and started building -- and you may be building the wrong thing. Undertale's original demo was rough, ugly, and proved exactly one thing: the bullet-hell-meets-RPG mechanic was worth a full game. Hollow Knight started as a game jam prototype that validated tight combat in an atmospheric 2D world. Celeste began as a PICO-8 prototype that proved a single idea: precise air-dash platforming feels incredible at 8x8 pixel resolution. This workflow enforces that same discipline: define a hypothesis, build the minimum viable test, observe real players, make a binary kill-or-promote decision based on evidence.

Purpose & Triggers

Invoke this workflow when:

• A team member proposes a new mechanic and the response should be "prove it" rather than "ship it"
• The design document contains an assumption that has never been tested with real players
• Two competing mechanic designs need a head-to-head bake-off to determine which one feels better
• A feature sounds good on paper but the team has no visceral sense of whether it will be fun
• Pre-production needs to validate core loops before committing engineering resources
• A pivot is being considered and the new direction needs rapid feasibility confirmation

Do NOT use this workflow when:

• The mechanic is well-understood and already validated in similar games (just build it properly)
• You need a vertical slice for stakeholder presentation (that is a demo, not a prototype)
• The question is about content, not mechanics (content questions need playtesting, not prototyping)

Critical Rules

1. One hypothesis per prototype. If you are testing two things, you have two prototypes. Combining hypotheses contaminates your results -- when it fails, you will not know which part failed.
2. Time-box or die. Every prototype gets a strict time limit: 1-3 days maximum. If the hypothesis cannot be tested in that window, the scope is too large. Decompose it further.
3. Prototype code is biohazard. It does not graduate to production. Ever. When a hypothesis is validated, the real implementation starts from scratch with proper architecture. Letting prototype code leak into production is how technical debt is born. Celeste's PICO-8 prototype shared zero code with the final game -- it proved the feel, then the real build started clean.
4. Ugly is correct. Colored rectangles for characters. Placeholder sounds. Programmer art. Comic Sans labels. If anyone comments on the visual quality of a prototype, they have misunderstood its purpose. The Hollow Knight game jam prototype used simple silhouettes -- the atmosphere came later, the feel came first.
5. Observe behavior, not opinions. Players will tell you what they think you want to hear. Watch what they DO. A player who says "yeah it was fine" but leaned forward and played for 20 minutes straight is giving you different data than their words suggest.
6. Kill without sentiment. If the evidence says the hypothesis is false, the prototype dies. It does not matter how clever the idea was, how much you personally like it, or how much time you spent building it. Supergiant kills prototypes constantly -- their GDC talks reveal dozens of dead mechanics that never made it past the test phase because the team trusts evidence over attachment.
7. Always reference docs/game-design-theory.md for shared theoretical frameworks (MDA, Flow Theory, SDT) when formulating hypotheses about player experience.