Idle / Incremental Game
Build a single-file idle or incremental clicker game such as a cookie/factory clicker with upgrades, generators, and exponential growth. Designs the resource economy — base click yield, generator costs, cost-scaling factor, and per-second production — first, then the layout, then implements a tick loop with persistent-feeling progression. Idle games are an economy problem before a UI problem: if costs and yields are not tuned the game is boring in 10 seconds or unwinnable, so the economy phase locks the exact numbers and growth curve before any rendering.
Steps
Entry step: economy-design. Each step names the specialist role it wants; the full working prompt is expandable.
- Economy designgame-designerentry
resources, generator costs, scaling, tick rate
Show working prompt
Design the ECONOMY with real numbers. (1) Name the primary resource and the base yield per manual click. (2) Define 3-5 generators: each with a base cost, a per-second production, and a cost-scaling factor applied per purchase (e.g. cost *= 1.15). (3) Set the tick rate (how often production is added, e.g. every 100ms) and ensure offline-free production accumulates while playing. (4) Add at least one upgrade that multiplies click or generator output. (5) Sanity-check the curve: roughly when can the player afford generator 1, 2, 3 — it should feel rewarding within the first minute and keep escalating. (6) Write an acceptance-criteria checklist of 5-8 items, e.g. 'clicking increases the resource', 'each generator costs more after each buy', 'production accrues per tick automatically', 'an upgrade visibly boosts output', 'buttons disable when unaffordable', 'no console errors'. Write to notes/economy-design.md and via write_task_note. No code yet.
- Visual designvisual-designer
big-click target, shop layout, number formatting
Show working prompt
Design the layout from the locked economy. (1) Choose a palette (hex) and a prominent click target (a big button or icon). (2) Lay out the resource counter (with abbreviated large numbers like 1.2K, 3.4M), the per-second rate, and the generator/upgrade shop list with cost and owned-count. (3) Specify affordance feedback: unaffordable items dimmed/disabled, a small pop on click. (4) Keep numbers readable as they grow. (5) Self-contained CSS, no external assets. Write the visual spec to notes/visual-design.md and via write_task_note. No game logic yet.
- Builddeveloper
implement the tick loop + shop in index.html
Show working prompt
Implement the idle game in a single index.html (inline CSS + JS) to the visual spec, satisfying every criterion. (1) Hold resource, generators (count, cost, rate), and upgrades in state. (2) On click, add the click yield. (3) On a setInterval/RAF tick, add total per-second production scaled by elapsed time. (4) Buying a generator deducts cost, increments count, and multiplies its cost by the scaling factor; disable buttons when unaffordable. (5) Apply upgrades as multipliers and format large numbers compactly. Vanilla JS, no CDN. On a loop-back, fix only the named gaps without regressing passing criteria. write_task_note the path and passing criteria.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Play for a minute. Open index.html if possible, else trace the tick loop and cost-scaling math. Check EACH criterion from notes/economy-design.md and write PASS/FAIL with a reason: does clicking add resource, does each purchase raise the next cost, does production accrue automatically per tick, does an upgrade boost output, do buttons disable when unaffordable, zero console errors? Confirm the curve feels rewarding-then-escalating, not instant-win or stuck. Any broken cost-scaling is a FAIL — loop back. 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.
- idle game
- clicker game
- incremental game
- cookie clicker
- factory game
- make an idle game
Source
View this craftbook on GitHub · MIT license