/game-prototype

name: game-prototype
description: >
  Runs hypothesis-driven prototyping: one question per prototype, a falsifiable hypothesis, the
  cheapest fidelity that answers it (paper, simulation, agent-built throwaway), a time box, observed
  playtests and a kill-or-promote call. Use for "prototype", "proof of concept", "test this
  mechanic", "is this fun". Not for building a small shippable game (use game-vibe-code).
argument-hint: "[question or mechanic to test]"
effort: high
allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(git status *), Bash(git switch *), Bash(git branch *), Bash(mkdir *), Bash(npm create *), Bash(npm install *), Bash(npm run *), Bash(npx playwright *), Bash(godot --headless *)

AlterLab GameForge -- Hypothesis-Driven Prototyping

A prototype is an experiment, not a demo. Every prototype exists to answer one question, usually "is this worth building?", and the moment you start polishing it you have stopped prototyping and started building, possibly the wrong thing. This workflow enforces the discipline: name the question, write a hypothesis that can fail, build the cheapest thing that tests it, watch real players, and make a binary kill-or-promote call on the evidence.

Coding agents changed the cost of the build step, not the discipline. An agent can produce a playable throwaway in an hour, which makes it tempting to skip the question and "just build it." Cheap builds make a clear question more important, not less: without one you get ten prototypes and no answers.

**Continuity through files.** Read `.gameforge/project.json` (pillars, phase), `design/concept.md`, earlier reports in `design/prototypes/`, and `production/session-state/active.md`. Each prototype lives in `prototypes/<name>/` with a `QUESTION.md`; the report goes to `design/prototypes/<name>-report.md`; `active.md` gets the decision and the next step. If the project's phase is still `concept` or `pre-production`, offer to set it to `prototype`.

When NOT to use me

| The user wants... | Route to | |---|---| | A small, complete, shippable game (web or jam) built with an agent | `/gameforge:game-vibe-code` | | A jam entry with a deadline | `/gameforge:game-jam-mode` | | An idea to prototype in the first place | `/gameforge:game-brainstorm` | | A vertical slice to show investors or a publisher | That is a demo; plan it with `/gameforge:game-producer` | | Tuning numbers in a mechanic already proven fun | `/gameforge:game-balance-check` | | A structured playtest of a real build with many players | `/gameforge:game-playtest` | | Content questions ("do players like this art style?") | `/gameforge:game-playtest` or `/gameforge:game-art-director` |

Critical Rules

1. **One question per prototype.** Two questions means two prototypes. Combined questions contaminate results: when it fails, you will not know which part failed. 2. **Time-box it.** Hours for paper and agent-built throwaways, one to three days at most for anything else. If the question cannot be answered inside the box, decompose it. 3. **Prototype code does not graduate.** When the hypothesis is confirmed, production starts from a spec, not from the prototype. This is cheaper than ever with agents: hand the agent the report and let it build clean. Celeste is a well-documented example: *Celeste Classic* was a PICO-8 game made in four days for a 2015 jam; the 2018 game was a separate C# build. 4. **Ugly is correct.** Rectangles, primitives, placeholder sounds. AI-generated placeholders are fine if they are logged and never ship by accident (see AI placeholder assets below). 5. **Observe behavior, not opinions.** What players do outranks what they say. 6. **Kill without sentiment.** Clever, beloved, expensive: irrelevant if the evidence says no. 7. **Original designs only.** Prototype genre mechanics and your own ideas, not a recreation of a specific existing game; Claude Code declines those, and they teach you nothing about your game. 8. **Use the shared theory.** MDA, Flow and Self-Determination Theory are in `${CLAUDE_PLUGIN_ROOT}/docs/game-design-theory.md`.

Step 1: Name the question

Start with the question, then the hypothesis. Ask the user (one AskUserQuestion round, defaults offered) what decision this prototype will drive and what kind of question it is:

| Question type | Example | Cheapest fidelity | Evidence that answers it | |---|---|---|---| | **Feel** | Does a momentum grapple feel exhilarating? | Digital throwaway | Testers chain swings unprompted; lean in; retry instantly | | **Comprehension** | Do players understand the rewind rule without text? | Digital throwaway or paper | Time to first correct use; number of interventions | | **Decision tension** | Does stamina create real choices with two enemies? | Paper or digital | Visible pauses before acting; varied choices across testers | | **Systems and balance** | Does the economy stay tight for ten runs? | Spreadsheet or headless simulation | Distribution of outcomes over hundreds of simulated runs | | **Technical feasibility** | Can 500 units path on a mid-range phone at 60 fps? | Technical spike (not a design prototype) | Profiler numbers on the target device | | **Desirability** | Will strangers click this hook on a portal? | Clip, mock store page, or 5-minute build | Click-through, plays, replays |

Then write the hypothesis in this exact form:

> "We believe that **[mechanic or system]** will produce **[player behavior or emotion]** when > **[specific condition]**."

And the falsification criteria: at least two observable signals that would prove it false. If you cannot say what failure looks like, the hypothesis is untestable.

| Strong | Weak (and why) | |---|---| | "We believe a grappling hook with momentum preservation will make traversal feel exhilarating when the player chains three or more swings without touching the ground." | "The combat will be fun." Fun for whom, when, measured how? | | "We believe asymmetric co-o