AI Game Bootcamp

Guide and planner · The Dream Game Sprint

Your first game in 30 days

The roadmap we use: five stages (the 5 P’s) day by day, what “done” looks like each week, and the rules that keep a small game small enough to finish. Set your start date and it becomes your calendar.

15 minute readAbout 1.5 hours a dayUpdated October 2026

01Your 30 days at a glance

Pick your Day 1. The track shows the five stages, the five playtests (sessions where you watch someone play) and the dates that matter. Everything saves in this browser.

Pitch the idea Play the main action Places the levels People hero, art, sound Polish test, finish, launch
PlaytestMilestone

By hand vs with the coach

This calendar works on paper. The Dream Game Coach turns it into your one next step every day: it runs your playtests and checks, keeps your dates, and warns you when your scope starts to slip. See Premium

02The pace

The plan assumes about 1.5 hours a day, around 45 hours in total. That fits people with a full-time job. Hobbyists who finish games usually manage 10 to 20 hours a week, often in short sessions: one developer made 12 games in a year working 30 to 45 minutes before bed plus weekend mornings.12

Expect a big share of that time to go to things that aren’t building. One first-time solo developer logged their hours: about 43% went to fixing bugs, testing, admin and marketing.3 The plan leaves room for that.

Where one beginner’s time went

  • Art22%
  • Features20%
  • Tidying code, planning, design, tools15%
  • Fixing bugs18%
  • Marketing10%
  • Admin8%
  • Testing7%
One example, not a rule: a first-time solo developer’s first couple of months, from their own time log (Three Raccoons, itch.io, 2025).3 Your split will differ.

Behind schedule? Cut scope (how much you’re making). Never cut playtests, and never cut sleep.

03Six milestones, six yes-or-no tests

Studios use these words loosely. Use them strictly: each one has a test you can answer with yes or no.45

MilestoneDayWhat it meansThe test
Toy (main action, no goal)3 to 5A rough version of your one main action, built from plain grey blocks. No goal yet.Can a stranger play it for a minute and want another go?
Last pivot (last big change)6Playtest 1. Keep the idea, twist it, or change it. After today, new ideas go on a list for the next game.Did someone who isn’t you enjoy the main action?
Feature freeze (no new features)14Every feature exists and the game plays start to finish, even if rough. Nothing new gets added after this. Your art style is locked too.Is everything on your Must list in the game? Then stop adding.
Content lock (everything is in)22All levels, art, text and sound are in. Stand-in art and sound are gone. From here you only tune, fix and polish.Is there any grey box, “TODO” or stand-in left?
Release candidate (ready to ship)28A build you’d be happy to ship today, with no known bugs that break the game.Would you upload this exact file if launch were in an hour?
Ship (it’s live)30The public release, then a short post-mortem (a look back).Page live, game playable from a link, first post sent?

04Week by week

Tick things off as you go. The dates follow your Day 1.

05Playtest early, small and often

A playtest means watching someone else play your game. You don’t need many people per round. In Nielsen’s model, one tester finds about 31% of the problems and five find about 85%. After that, each extra tester finds less and less, so three small rounds beat one big one.6

Problems found, by number of testers

0%25%50%75%100% 0151015 Number of testers 1 tester:about 31% 5 testers: about 85% After five, each extra tester finds fewer new problems
Drawn to scale from Nielsen’s model, where each tester finds about 31% of the problems.6 It was built for websites and apps, but the lesson holds for games: test small and often.
Weekly

Valve tested Portal every week

With people who had never played it, watching from start to finish. Testing began with one half-finished room.7

2 + 1

Fix two, boost one

After each round, group notes by pattern. Fix what two or more testers hit, and make one moment they loved even better. Park the rest.

How to run one

  • Don’t explain the game first. Let them play as they would at home.7
  • Watch what they do more than what they say. Ask them to think out loud, stay quiet, and note where they get stuck.8
  • Trust the problem, not the suggested fix. When testers say something doesn’t work, they’re almost always right. When they say exactly how to fix it, they’re often wrong.

Six questions to ask afterwards

FWhat was the most frustrating moment?
FWhat was your favourite moment?
WWhat did you want to do but couldn’t?
WWith a magic wand, what would you change?
DWhat were you doing, in your own words?
DHow would you describe it to a friend?

Adapted from Schell Games’ “ffwwdd” playtest questions.9

06Keep it small enough to ship

A game that keeps growing (“scope creep”) is one of the problems that comes up again and again when researchers read hundreds of game post-mortems.10 These rules keep a 30-day game a 30-day game.

  • Fixed time, flexible scope. The ship date doesn’t move. What fits before it does.
  • Must, Should, Could, Won’t. Sort every idea into one of these four lists. Keep the Must list to about 60% of your hours, so there’s room for surprises.11
  • Write a “Not” list. Everything you’ve decided this game won’t have. New ideas go on it, or on a list for your next game.
  • A playable version every day. If you stopped today, you’d still have a game.
  • Cut features before you cut the finish. A small, polished game beats a big, broken one.
  • Polish in moderation. In player studies, some “juice” (screen shake, sparks, sound) beat none, and too much was no better.12 Save it for the moments that matter.

07Launch lead times

Stores take longer to let you in than your game takes to build. Start the slow ones on Day 1, or plan them for your second release.

Days from signing up to your first release

The dashed line is day 30, the end of your sprint. Steam only fits if you sign up and pay on Day 1. For web portals, the faded part is the range.
WhereWhat to know
itch.ioFree, and you can go live today. Keep the page private until it’s ready: a new page only gets one turn on the “Most Recent” list.13
Steam$100 per game, and about 30 days from paying to your first release. Best as your second release.14
Google PlayNew personal accounts must run a private test with real people for two weeks before release.15
Web portalsCrazyGames and Poki put your game in front of their players for a short test first. Poki asks for web exclusivity: your game can’t be on other websites.16
For the curious: the exact store rules
  • itch.io: pages start private. Add a cover image, 3 to 5 screenshots and up to 10 tags, and tick the AI disclosure box if you used AI.13
  • Steam: Valve’s pages say 21 or 30 days between paying and your first release, so plan for 30. A Coming Soon page must be live for at least 2 weeks, and the store page and build reviews each take 3 to 5 business days.14
  • Google Play: the closed test needs at least 12 testers opted in for 14 days in a row, then review can take up to 7 days.15
  • Web portals: CrazyGames runs a basic launch of 7 to 21 days. Poki runs a 3 to 5 day web test.16

08Tell someone every week

In a study of 149 adults working on a four-week goal, the group that sent weekly progress reports to a friend did best.17 But announcing who you’ll become (“I’m making an epic RPG”) can make people work less, because it already feels like progress.18

Share progress, not promises.Each week, post one GIF (a short looping clip) and two lines: what you built and what’s next.

A devlog (a short progress post) on your itch.io page or a post in the AI Game Bootcamp community both work. Don’t expect devlogs alone to bring players; treat them as a way to keep yourself on track.

09Write your post-mortem

Within a week of launch, while you still remember, write down what happened. This look back is how one finished game becomes a better second one. Use this template:

  1. The facts. Game name, link, engine, days taken, hours logged, tools (including AI tools), where it’s released.
  2. Plan vs reality. What was on your Must list on Day 1, and what shipped.
  3. Three to five things that went right, each with one example.
  4. Three to five things that went wrong, each with its cause, not just what happened.
  5. The numbers. Playtest rounds and testers, first-week plays, ratings or comments.
  6. Three rules for next time, written as actions.
  7. What’s next. An update, the next game, or the Steam version.

10Words you’ll see

Playtest
Watching someone else play your game.
Greybox
A rough version built from plain grey blocks.
Toy
Your main action, playable, with no goal yet.
Juice
Small effects that make actions feel good (shake, sparks, sound).
Vertical slice
One short part of the game at near-final quality.
Feature freeze
The day you stop adding new features.
Content lock
The day all levels, art and sound are in.
Release candidate
A build you’d be happy to ship today.
Build
A playable version of your game.
Stand-in (placeholder)
Temporary art or sound you replace later.
Devlog
A short post about your progress.
Post-mortem
A written look back after launch.

AI Game Bootcamp Premium

Go from guide to finished game

This guide gives you the plan. Premium gives you the coach and the lessons to follow it all the way to launch.

  • The Dream Game Sprint video masterclassComing soon
    Step-by-step video lessons from first idea to launch day.
  • The full Dream Game Coach for Claude Code
    It guides your game every day: research, design, levels, art, sound, playtests and launch, with automatic checks.
  • A personal gameplay review from John
    Honest notes on your game from someone who ships them.
Join Premium

11Sources

The 30-day plan is the Dream Game Coach’s schedule. Outside sources were checked in October 2026.

  1. GameMaker, “Hobbyist survival guide”, 12 Dec 2019. gamemaker.io
  2. Hacker News thread with a #1GAM finisher, 16 Dec 2014. news.ycombinator.com
  3. Three Raccoons, “How my time actually breaks down as a first-time solo game dev”, itch.io blog, 3 Nov 2025. itch.io
  4. Supergiant Games, “From alpha to content lock”, 11 Mar 2014. supergiantgames.com
  5. Derek Yu, “Finishing a Game”, 2010 (archived). web.archive.org
  6. Nielsen Norman Group, “Why you only need to test with 5 users”, 2000. nngroup.com
  7. Kim Swift et al., “Thinking with Portals”, Game Developer, 2008. gamedeveloper.com
  8. Mike Ambinder, “Valve’s Approach to Playtesting”, GDC 2009 slides. steamstatic.com
  9. Schell Games, “The Definitive Guide to Playtest Questions” (secondary). schellgames.com
  10. Politowski et al., dataset of problems from 200+ game post-mortems, 2020. arxiv.org
  11. MoSCoW prioritisation guidance (DSDM): Must items at or under about 60% of effort (secondary).
  12. Studies on “juiciness” and player experience, summarised in our research notes (secondary).
  13. itch.io creator docs: getting started, getting indexed, quality guidelines. itch.io
  14. Steamworks: Steam Direct, onboarding, Coming Soon, review process. partner.steamgames.com
  15. Google Play Console Help, testing requirements for new personal accounts (secondary). support.google.com
  16. Poki and CrazyGames developer documentation. developers.poki.com
  17. Gail Matthews, goals research summary, Dominican University. dominican.edu
  18. Gollwitzer et al., “When intentions go public”, Psychological Science, 2009 (secondary). pubmed.ncbi.nlm.nih.gov