# Build a game

> Your first real Claude Code session should not be the most important thing on your plate. It should be a small game. Here is why, and a structured exercise to do it tonight

_20 min · beginner · track: vibe-coding · id: build-a-game_

> **Team:** 
>
> The instinct after installing [Claude Code](/course/claude-code) is to point
> it at the most important thing on your plate: the dashboard you have been
> meaning to rebuild, the workflow you want to automate, the strategy doc you
> have been putting off. Don't. The first thing you build with a new tool
> should be small, fun, and disposable, because that is how you learn what the
> tool can actually do without your stakes clouding the lesson.

## Why a game

**Most people pick the wrong first project.** They open Claude Code with a real problem in mind, the agent runs for ten minutes, the result is rough around the edges, they conclude the tool is not ready. The conclusion is wrong; the first project was wrong.

A game is the right first project for three reasons:

- **The model knows games cold.** Flappy Bird, Wordle, Snake, Tetris, a top-down RPG. The form is in the training data ten thousand times over. You provide a single sentence; the model fills in the rules, physics, styling, win condition. The first try is good.
- **You can tell instantly if it works.** A game either feels playable or it doesn't. There is no internal review loop, no "let me check with finance." You open the file, you click around, you know.
- **The stakes are zero.** Nothing depends on this. You can throw it away. Which means you can be brave with the prompt (silly, weird, specific) in a way you never quite are when the output is for real.

Everything you learn here transfers. The plan-execute loop, the make-it-better iteration, the way you steer the agent with one sentence instead of ten: those are the same moves you reach for later on the dashboard or the inbox automation. You learn them faster on something you do not care about.

## A worked example

Our CTO Jeroen turned the TechWolf public Slack history into a Pokemon-style onboarding game. New hires walk a top-down pixel-art office, bump into colleagues, and discover the team's culture (the inside jokes, the values, the running gags) through gameplay instead of through a 40-page handbook nobody finishes. You can play the live version at [license-to-skill.com](https://license-to-skill.com).

<div class="image-row">
  <img src="/courses/build-a-game/onboarding-game-ghent.png" alt="TechWolf onboarding game, Ghent office: pixel-art top-down view with characters and a system prompt" />
  <img src="/courses/build-a-game/onboarding-game-nyc.png" alt="TechWolf onboarding game, entering the NYC office, with HUD and inventory bar" />
</div>

A top-down RPG was already in Claude Code's head, so the prompts could go on the content (the actual TechWolf culture, pulled from Slack) instead of on the game mechanics.

> **Warning:** 
>
> This took about a weekend of focused work, which is a lot longer than "an afternoon" and a lot longer than the 20 minutes you are about to spend. Even fun vibe-coding projects can get out of hand: the prompt that worked in five minutes pulls you into a polish loop that stretches across two evenings. That is fine, and often the point. Letting yourself get pulled in is one of the fastest ways to learn how the tool actually behaves under sustained use. Just go in with your eyes open.

That move (pick a form the model knows, layer your content on top) is the headline pattern in [Vibe coding patterns](/course/vibe-coding-patterns). This course is the warm-up exercise.

## Pick a form, pick a hook

**The two ingredients are a form (a game the model knows) and a hook (something you actually care about).** A random prompt produces a random result. A specific one produces a small thing that feels like yours.

Forms that one-shot well in Claude Code:

- **Flappy Bird.** A bird, gravity, two pipes, a score. Trivial physics, instantly playable.
- **Wordle.** Five letters, six guesses, green/yellow/grey. A custom word list takes thirty seconds.
- **Snake or Tetris.** Classic arcade. The model gets the controls right.
- **Top-down RPG.** A character, walls, NPCs you bump into for a line of dialogue. Slow to perfect, fun to start.
- **Trivia or Jeopardy.** A board of categories and questions. Plug in real content from a doc you have lying around.

Hooks that turn the form into something memorable:

- A running joke from your team's Slack.
- A coworker's birthday, an anniversary, a farewell.
- A customer your team is about to meet.
- A company value or principle that nobody reads in the deck.
- A topic you are studying right now: a language, a subject, a book.

Combine them. "Wordle where every word is a meeting type at our company." "Flappy Bird themed around our Q3 launch." "A two-room top-down RPG of our office for a new hire's first day." The combination is what makes the result specific. The combination is also what makes it fun to share afterwards, which is what gets you to do it again.

> **Heaven:** Twenty minutes. One specific theme tied to something you actually care about. A small thing that makes someone smile when you send it. You learned how Claude Code thinks while building it.
>
> **Hell:** Three hours on a 'simple to-do app' you'll never use, with a generic prompt that produced a generic result. You concluded that vibe coding is overrated.

## The exercise

This is the actual point of the course. The reading above is just here to convince you to do it.

1. **Open Claude Code in an empty folder.** `mkdir ~/projects/first-game && cd ~/projects/first-game`, then `claude`.

2. **Pick a form and a hook in under a minute.** Do not agonise. The first idea that makes you smirk is the right one. Write one sentence: "A `<form>` themed around `<hook>`."

Examples:
- "A Wordle clone where every word is a meeting type at our company."
- "Flappy Bird where the bird is our CEO's coffee mug and the pipes are calendar invites."
- "A top-down RPG of my apartment where my cat is the final boss."

3. **Hand the sentence to Claude Code.** Add: "Single HTML file, no build step, opens in a browser." That keeps the result trivial to run.

```
Build a Wordle clone where every word is a meeting type at our company. Single HTML file, no build step, opens in a browser.
```

Let it run. Don't interrupt. Don't course-correct. Just watch what shows up.

4. **Open the result.** Most likely: `open index.html`. Play it for one minute. Notice the parts that surprised you (the model picked a palette you didn't ask for) and the parts that fell flat.

5. **Tell the agent "make it better." Twice.** No other instructions. Read the diff each round. Notice what it tightens (layout, palette, edge cases) and what it leaves alone. Round three almost always feels crafted in a way round one didn't.

6. **Send it to one person.** A teammate, a friend, a group chat. Their reaction is the feedback that matters, and the reaction is what tends to make you want to keep building, which is the whole point of the exercise.

## Reflect

- Was the version Claude Code built on round zero already playable, or did the make-it-better passes do most of the work? What does that tell you about how to point the tool tomorrow on something that matters?
- Pick one thing at your work that is currently a slide deck, a doc, or a meeting. Could that thing be a game? If yes, the prompt for your next vibe-coding session is already written.
