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, scoring, restart behavior, 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", "restart resets the score", "game is playable for >30s without a JS error"). Save the complete mechanics + checklist to artifact `design/game-design.md` with `write_artifact`, and summarize the path in task notes. No code, no visuals yet.
- Visual designvisual-designer
palette, shapes/sprites, layout, juice
Show working prompt
Read artifact `design/game-design.md` with `read_artifact`, then decide how the game LOOKS. Pick a palette with exact color values, the canvas shapes or sprites for player/enemies/projectiles, the HUD layout (score, lives or timer), and at least one feedback effect (hit flash, screen shake, or particles). Keep it self-contained — canvas drawing or CSS, no external asset downloads. Save the concrete visual target to artifact `design/visual-design.md` with `write_artifact`, and summarize the path in task notes. Still no game code.
- Builddeveloper
implement the game in one index.html
Show working prompt
Read artifacts `design/game-design.md` and `design/visual-design.md` with `read_artifact`. Implement the game in workspace `index.html` with `write_file` (inline CSS + JS) so it satisfies the acceptance criteria and matches the visual spec. Include a real game loop, real input handling, score/state, a visible win or lose state, and an in-page restart path. Keep it self-contained with no network assets. On a loop-back, fix only the gaps the reviewer named — do not regress criteria that already passed. `write_task_note` the workspace 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
Read workspace `index.html` with `read_file` and actually exercise the game. If a browser/QA capability is available, load it, play it, test restart, and watch the console for errors; otherwise trace the game loop, input listeners, end-state transition, and reset path in source. Check every criterion from artifact `design/game-design.md` and write 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. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). 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