HTML Arcade Game
Build a playable single-file HTML/canvas arcade game (shooter, runner, dodger, etc.). Splits design into game-mechanics and visual look, builds, then evaluates against a playability bar and loops until it is actually fun and bug-free.
Steps
Entry step: game-design. Each step names the specialist role it wants; the full working prompt is expandable.
- Game designgame-designerentry
mechanics, controls, win/lose, difficulty
Show working prompt
Design the GAME, not the code. Decide: core mechanic (what the player does), controls (keys/mouse/touch), win and lose conditions, and the difficulty curve. Then write an **acceptance-criteria checklist** (4-8 concrete, checkable items, e.g. "arrow keys move the ship", "colliding with an enemy ends the game", "score increments on hit", "game is playable for >30s without a JS error"). `write_task_note` the mechanics + the checklist. No code, no visuals yet.
- Visual designvisual-designer
palette, shapes/sprites, layout, juice
Show working prompt
Decide how it LOOKS. Pick a palette, the shapes or sprites for player/enemies/projectiles, the HUD layout (score, lives), and a touch of juice (a flash on hit, a simple particle). Keep it self-contained — canvas drawing or CSS, no external asset downloads. `write_task_note` the visual spec so the build phase has a concrete target. Still no game code.
- Builddeveloper
implement the game in one index.html
Show working prompt
Implement the game in a single `index.html` (inline CSS + JS) that satisfies the acceptance criteria and matches the visual spec. Real game loop, real input handling, real state. On a loop-back, fix only the gaps the reviewer named — do not regress criteria that already passed. `write_task_note` the path and which criteria now pass.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Actually exercise the game. If a browser/QA capability is available, load `index.html`, play it, and watch the console for errors; otherwise read the source and trace the loop. Check each acceptance criterion (mechanic works, controls respond, win/lose fires, no console errors) and write a PASS/FAIL per criterion. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "build" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. If you advance without a target, the loop sends you back by design. After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- arcade game
- space shooter
- html game
- build a game
Source
View this craftbook on GitHub · MIT license