prototype-fast Checked

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.