Why a game is the perfect second project.

A page waits. A game runs.

The site you built in Course 01 is real and useful, but it's fundamentally a document: the browser reads it once, draws it, done. A game is a different animal. Sixty times a second it asks "what's true right now?" and redraws the world to match. Something is alive in there, and that aliveness is built from exactly three ideas:

• State — a list of facts describing the world right now. Where the player is standing. Which door is open. What's on each screen. Just facts, stored in variables.
• Input — things that change the facts. A key press moves the player one tile. That's it — input never draws anything, it just updates the facts.
• The loop — a tireless little artist that reads the facts and repaints the screen, over and over, forever. It doesn't know or care why the facts changed.

Here's why this is worth two or three hours of your life: this is not a game thing. A booking widget is state (chosen date, chosen time) plus input (taps) plus a redraw. A live dashboard is a loop reading facts and repainting charts. Your email inbox, your maps app, the little heart that fills in when you like a post — state, input, loop, wearing different outfits. A game is simply the most fun possible place to meet them, because in a game you can see the state (that's you, standing in the room) and feel the input (you pressed the key; you moved).

What we're building — and the actual point of it

Over the next four lessons you'll build the Pixel Lab: a small pixel-art computer lab you walk around with the arrow keys. A few desks, a few glowing screens, one suspiciously healthy plant. You saw the finished thing on the course page — go waddle around it for thirty seconds if you haven't.

But the game is the vehicle, not the destination. The real curriculum is smuggled in the back seat:

• Lesson 3: you'll move the lab's contents out of the code and into a data file — and discover you can change an app without touching code. This is the single most transferable idea in this course.
• Lesson 4: the magic trick. Claude Code will scan your real computer — the actual folders with your actual projects — and write that data file for you. Every screen in the lab will show a real project of yours, with a real summary. Your game becomes a dashboard of your work. Then you'll automate the whole thing with your first custom slash command.
• Lesson 5: you'll give the project a memory with a CLAUDE.md file, so future work sessions start smart instead of from zero.

None of those three skills has anything to do with games. That's the design. Anyone can prompt an AI into producing a game — you already know that's possible, and it would teach you nothing new. What you're actually practicing here is how professionals work with Claude Code: content lives in data, repeated work becomes a command, and projects carry their own context. The game just makes it fun enough that you'll actually finish.

What you need before lesson 2

• Claude Code installed and working. If claude in a terminal means something to you, you're set. If not, do Course 01, lesson 2 first — it's a 25-minute detour.
• The Course 01 habits. Brief like a contractor, work in small rounds, plan first, commit save points. We'll lean on all of them. (Rusty? Skim lesson 4 — five minutes.)
• 2–3 hours, ideally in one sitting. The course is paced so the "it knows my actual projects" moment lands while you're still warm.