Your First Game: The Pixel Lab · Lesson 2 ⏱ ~45 min

Build the lab: a world you can walk around.

Same workflow as Course 01 — brief, look, adjust in rounds — pointed at a very different kind of thing. By the end of this lesson there's a little person in a little room, and the little person is yours to steer.

Step 1 — new folder, new start

The moves you know:

cd ~/Desktop
mkdir pixel-lab
cd pixel-lab
claude

Step 2 — the opening brief

Games have more moving parts than pages, so the brief earns its keep here. Context, outcome, constraints — and plan first, always:

The opening brief — use it as-is

I want to build a small top-down pixel-art game as a single HTML file, plain JavaScript, no frameworks. It's a cozy computer lab: one room with walls, a tiled floor, and four desks along the top wall, each with a computer whose screen glows a different color.

I control a little pixel character with the arrow keys or WASD. The character can't walk through walls or desks. When I'm standing near a computer, a small hint appears saying "Press E". Pressing E opens a panel in the middle of the screen showing that computer's name — just placeholder names like "Computer 1" for now — with a close button, and Escape also closes it.

Use a chunky retro pixel look (crisp pixels, no smoothing). Draw everything in code on a canvas — no image files. Before you write any code, tell me your plan in a few sentences so I can adjust it.

Read the plan it gives you. If it mentions things you don't recognize — "canvas", "collision map", "requestAnimationFrame" — that's fine and expected; you'll interrogate the code in a minute. If the plan sounds like more than you asked for ("I'll also add enemies and a score system!"), rein it in now: "No extra features — just the room, the character, and the panels." Then tell it to go.

Step 3 — first walk

Open the file in your browser (ask Claude to open it if you like) and take your first lap around the room. Course 01's 70% rule applies to games too — it'll mostly work, and the gaps will be obvious the moment your hands are on the keys. Common first-pass complaints, and how to say them:

Round: movement feel

Movement works but feels slippery — the character keeps sliding after I release the key. I want crisp tile-by-tile steps: one tap of the arrow key moves exactly one tile, holding it keeps stepping. Also it's too fast; slow the steps down a touch.

Round: the room

The room reads as flat gray. Give the floor a subtle checkerboard of two dark shades, make the walls clearly darker than the floor, and put a rug in the middle. The four computer screens should each glow a different color — cyan, purple, pink, green — with a soft halo.

Notice what you're doing: you're not describing code, you're describing feel. "Slippery" is a perfectly good bug report. Claude Code speaks fluent vibes as long as you say what you observed and what you wanted instead.

Step 4 — the interactions

Round: the hint and the panel

Two fixes. First, the "Press E" hint should only appear when I'm within about one tile of a desk, and it should sit under that specific computer, not in a corner. Second, when the panel is open, the character shouldn't move — arrow keys should do nothing until I close it.

That second one matters more than it looks: you just told the game that input means different things in different states (walking around vs. reading a panel). Congratulations, you have opinions about state machines now. This is what lesson 1 meant by meeting the ideas in person.

💾Save point. The moment the room feels right: "This is working — set up git if needed and commit it." Same reflex as Course 01. Games especially reward this, because one enthusiastic physics change can scramble the whole feel, and you'll want a way back.

Step 5 — the new skill: make it explain itself

Here's what's different about this course. In Course 01 you could treat the code as a sealed box. This time, open the box — not by learning to code, but by asking:

The prompt

Walk me through how this game works, like I'm brand new to code. Short and plain: what's the game loop, where does the game keep track of where my character is, and what happens between me pressing an arrow key and the character moving on screen?

Simulated run — your wording will differ, the shape won't.

Ask follow-ups until it clicks: "Show me the exact lines where the arrow key changes the position." "What would break if I deleted the collision check?" (Then actually ask it to try that, walk through a wall like a ghost, and have it put the check back. Free lesson, zero risk — git remembers.)

This habit — interrogating code you didn't write, in plain English — is worth more than the game. It's how you'll one day understand a freelancer's handoff, a plugin you bought, or any mysterious folder of code you inherit. Every codebase on earth is now explainable to you, on demand, in your language.

Checkpoint — before lesson 3 you should have
✓ a room you can walk around, tile by tile
✓ walls and desks you can't walk through
✓ four glowing computers; "Press E" near each
✓ E opens a placeholder panel; Esc closes it
✓ at least one git commit
✓ a plain-English answer to "how does this work?"

Something's broken or weird? → Lesson 6 of Course 01 rules apply: paste the error or describe exactly what you see, ask why before asking for a fix. Games break in funnier ways than pages. The method is identical.

You can now…

  • Brief a game like a contractor — world, controls, rules, look
  • Tune game feel by describing it, one round per prompt
  • Ask Claude Code to explain any code in plain English
  • Recognize state and input as things you can point at
← Why a game Next: Data vs code →
Want the course by email? Lessons in your inbox, plus new ones as I write them.

Running a business and would rather this get built for you? That's literally my job — start with the free audit.