prototype-fast

name: prototype-fast description: > Build a playable prototype in about an hour to answer one question — is it fun? — with greybox primitives, a hard timebox, and explicit keep/kill criteria. Use when prototyping a mechanic, making a vertical slice or MVP, greyboxing/blockout, or judging throwaway vs keep.

Prototype Fast

Get a mechanic into a player's hands fast to learn whether it's worth building. The output of a prototype is a decision (keep / kill / refactor), not a product. Optimize for learning speed, and decide up front whether the code is throwaway or load-bearing.

When to use

• Use when validating a single mechanic or "what if", building a vertical slice / MVP, greyboxing a level or interaction, or de-risking an idea before committing real time.
• Use when the user says "just get something playable", "is this fun?", or "rough it in".

When not to use: a timed competition with a deadline and a submission (use game-jam); shipping or updating a real release (use steam-publish / itch-publish); building the production version of a validated feature (use the engine/genre skill directly).

Core workflow

1. Write the one question. State the single thing the prototype must answer, e.g. "Is grappling-while-falling satisfying to control?" If you have two questions, build two prototypes. A prototype that tests everything tests nothing.
2. Decide throwaway vs keep — before you write code. Throwaway (a spike): hard-code, no architecture, delete after. Keep: still rough, but folder/names you can grow. Most prototypes should be throwaway; pretending otherwise is how prototypes rot into the shipping codebase.
3. Set a hard timebox (30-90 min for a mechanic; one sitting for a slice) and a visible timer. The constraint is the point — it forces you to test the core idea, not the trim.
4. Greybox everything non-essential. Primitives for art (boxes, circles, capsules), built-in fonts, one debug sound or none. Spend zero minutes on anything the question doesn't depend on.
5. Instrument for the question. Add on-screen debug text / gizmos that show the thing you are judging (speed, distance, timing window). You're measuring, not decorating.
6. Playtest immediately and honestly. Play it yourself, then hand it to one other person without explaining the controls. Watch where they struggle.
7. Make the call against your kill criteria (below). Keep → schedule the real build and rewrite, don't promote the spike. Kill → log the lesson and move on. Refactor → narrow the question and spike again.

Patterns

1. The prototype brief (fill this in before coding)

QUESTION:     The one thing this must prove (binary if possible).
CORE VERB:    The single action the player repeats.
THROWAWAY?:   yes -> hard-code freely, delete after.  no -> minimal structure to grow.
TIMEBOX:      e.g. 60 min. Stop when it rings, even if unfinished.
KEEP IF:      observable signal that means "fun / worth building" (see kill criteria).
KILL IF:      observable signal that means "stop".

2. Greybox the core loop, fake everything else (engine-agnostic pseudocode)

# Only the CORE VERB is real. Visuals are primitives; systems are stubs.
on update(dt):
    read_input()
    apply_core_mechanic(dt)        # the ONLY thing you're testing — make this feel right
    draw_primitive(player)         # a box. not a sprite. not animated.
    draw_debug_hud(speed, timing)  # show the numbers you're judging
    # enemies, menus, save, audio, art -> stubbed or absent until the verb proves out

3. Kill criteria — make the keep/kill call observable, not emotional

KEEP when, with placeholder art:
  - a fresh player does the core verb on purpose within ~30s, unprompted, and
  - you (or they) repeat the loop "one more time" without being asked.
KILL when:
  - the verb only feels good after you explain it, or
  - making it fun needs systems far beyond the prototype's scope, or
  - you're adding art/levels to avoid admitting the verb is flat.
REFACTOR when one variable is clearly off (too slow, window too tight) -> retune, retest.

4. Containment: keep a spike out of the shipping codebase

prototypes/<idea-name>/      # separate folder or project, never imported by main game
  - hard-coded values, single file ok, magic numbers welcome
  - committed on a throwaway branch (or not at all)
Rule: a "keep" decision authorizes a REWRITE in the real project, not a copy-paste of the
spike. Prototype code carries prototype assumptions; shipping it ships the assumptions.

Pitfalls

• Polishing too early. Art, menus, and audio make a flat mechanic look finished and delay the verdict. Greybox until the verb is proven.
• No kill criteria. Without a written "kill if", every prototype "has potential" and nothing gets cut. Decide the signal before you're attached to the code.
• Building systems instead of the mechanic. Inventory, save/load, and settings are not the question. Stub them.
• The spike becomes the product. Throwaway code promoted to production is technical debt with a fun origin story. Rewrite on a keep.
• Prototyping in the real codebase. It tangles experiments with shipping systems and makes the spike expensive to delete. Use a separate folder/project.
• Testing only yourself. You know the controls and the intent. One uncoached outside player reveals more in two minutes than an hour of self-play.

References

• For working under a hard external deadline and submitting, read the game-jam skill.
• For the engine-specific core loop you'll greybox in, read that engine's skill (godot-gdscript, phaser-core, love2d-core, unity-csharp-scripting, …).

Related skills

• game-jam — same scope discipline applied to a timed competition with a submission.
• Engine cores and genre skills — where a "keep" decision gets rebuilt properly.