gilde

← All craftbooks

Full Game with Title & Game-Over Screens

Build: interactive and webevalv1.0.0released 2026-06-05workflow: build-loop

Build a complete single-file HTML game with the full screen flow — a title/start screen, the gameplay screen, a game-over screen showing the score, and a restart back to a fresh game — wrapping any core arcade or survival mechanic. Designs the mechanic and the screen-state machine first, a cohesive visual look across all screens, then implements a screen manager so transitions are clean and restart truly resets. Many small models nail gameplay but ship with no start or game-over screen; this archetype makes the screen flow a first-class, gated requirement.

Steps

Entry step: game-design. Each step names the specialist role it wants; the full working prompt is expandable.

  1. Game designgame-designerentry

    mechanic + the title/play/over/restart state machine

    Show working prompt
    Design the game AND its screen flow. (1) Define the core mechanic, controls, scoring, and the lose condition (a survival/arcade loop). (2) Specify the screen state machine: TITLE (instructions + a start control) -> PLAYING (the game) -> GAME OVER (final score + a restart control) -> back to a FRESH PLAYING state. (3) Define exactly how each transition triggers (press key/click to start; lose -> game over; restart -> reset all state). (4) Write an acceptance-criteria checklist of 6-8 items, e.g. 'a title screen shows before play with a start control', 'starting begins gameplay', 'the mechanic and controls work', 'losing shows a game-over screen with the final score', 'restart returns to a fully reset game (score 0)', 'no leftover state between runs', 'no console errors'. Write to notes/game-design.md and via write_task_note. No code yet.
  2. Visual designvisual-designer

    cohesive look across all three screens

    Show working prompt
    Design a cohesive look across all screens. (1) Pick one palette (hex) and type used on title, gameplay HUD, and game-over so they feel like one game. (2) Design the title screen (game name, brief how-to, start prompt), the in-game HUD (score, lives), and the game-over screen (final score, restart prompt). (3) Specify the entity shapes/sprites for gameplay (canvas primitives, no external assets). (4) Add a touch of juice on transitions. Write the visual spec to notes/visual-design.md and via write_task_note. No code yet.
  3. Builddeveloper

    implement screen manager + game in index.html

    Show working prompt
    Implement the full game in a single index.html (inline CSS + JS) to the visual spec, satisfying every criterion. (1) Maintain a gameState variable ('title' | 'playing' | 'over') and route rendering and input by it. (2) Build the title screen with a start control that switches to 'playing' and initializes fresh state. (3) Implement the gameplay loop (mechanic, input, scoring, collision) on canvas. (4) On the lose condition switch to 'over' and show the final score with a restart control. (5) Restart must RESET all state (score 0, entities cleared) and return to a fresh 'playing' (or title). Vanilla JS, no CDN, no external assets. On a loop-back, fix only the named gaps without regressing passing criteria. write_task_note the path and passing criteria.
  4. Evaluatereviewer

    Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.

    Show working prompt
    Play a full cycle twice. Open index.html if possible: from the title, start, play until you lose, see game-over with the score, restart, and confirm it begins fresh. Check EACH criterion from notes/game-design.md and write PASS/FAIL with a reason: is there a title screen with a start control, does starting begin gameplay, do the mechanic/controls work, does losing show a game-over screen with the final score, does restart fully reset (score back to 0, no leftover entities), zero console errors? Stale state after restart, or a missing title/game-over screen, is a FAIL — loop back to build.

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.
  5. 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.

Source

View this craftbook on GitHub · MIT license