🗺️ How to Plan a Game (The Method)

This is the most important doc in the whole guide. Learn this method once and you can plan any game — not just the three in here.

The goal of planning is to turn a scary big question...

❓ "How do I build Pac-Man?!"

...into a stack of small, friendly questions:

✅ "How do I draw a maze?" → "How do I move a player?" → "How do I stop him at walls?" → "How do I eat a dot?" → ...

Small questions have answers. That's the whole trick.

Part 1 — Every game is made of the same building blocks

Before you plan a specific game, you need the vocabulary. Almost every 2D game is built from these seven building blocks. Learn these names — the workbooks and the Playground use them constantly.

1. The Screen & the Game Loop

The game runs on a canvas (a rectangle of pixels). A hidden loop runs about 60 times every second — each pass is one "frame." Every frame the game: reads the controls, moves things a tiny bit, checks for collisions, and redraws. Motion is just "move a little, 60 times a second." (Playground: Technique 1)

2. Game Objects (the "actors")

Everything you can see is a game object: the player, an enemy, a wall, a dot, a score label. Think of them as the actors on your stage. In KAPLAY you make one with add([...]). (Playground: Techniques 2 & 3)

3. Components (an object's "traits")

An object is built out of components — little traits you snap together. A component gives the object an ability or a property:

You mix and match. A wall might be rect + color + area + body. A floating dot might be just circle + color + area. Choosing which components each object needs is a big part of your plan. (Playground: Technique 3)

4. Input (the controls)

How the player tells the game what to do — usually the keyboard. "When the left arrow is held, move the player left." (Playground: Technique 4)

5. Rules & Systems (the "verbs")

These are the behaviors that make it a game:

• Movement — things change position over time. (Technique 5)
• Gravity & jumping — for platformers. (Technique 6)
• Solid walls / platforms — things that block other things. (Technique 7)
• Collisions — "when A touches B, do something" (eat it, lose a life, bounce). (Technique 8)
• Spawning — new objects appear over time (barrels, fish, dots). (Technique 9)

6. States / Scenes

A game is in different states at different times: the title screen, the playing state, the you-won screen, the game-over screen. Each is a "scene." (Playground: Technique 11)

7. Score, Lives & Win/Lose

How you track progress (score, lives, a timer) and the exact conditions that end the game — the win condition and the lose condition. (Playground: Technique 12)

Part 2 — The 6-step planning method

Here's the repeatable process. Do this on paper or type into the workbook. You're only writing words and lists here — no JavaScript yet.

Step 1 — Say the game in one sentence

Force yourself to describe the core in a single line. This keeps you honest about what the game is.

"Steer a fish around the sea, eat fish smaller than you to grow, and avoid fish bigger than you."

Step 2 — List what's on the screen (the objects)

Just name every kind of thing you'd see.

player fish, smaller fish, bigger fish, the score text, the background.

Step 3 — For each object, list what it DOES (its behaviors)

Give every object its verbs.

player fish: follows the mouse/keys. Other fish: drift across the screen. Score text: shows my size.

Step 4 — List the RULES (what happens when things interact)

This is where the "game" lives. Write them as "when ___, then ___" sentences.

When player touches a smaller fish → eat it, grow, +points. When player touches a bigger fish → game over.

Step 5 — List the STATES (scenes)

What screens does the game move between?

Title → Playing → Game Over → (back to Title).

Step 6 — Turn it into a build order (milestones)

Now put it in the order you'll actually build it. Always start with the smallest thing you can see working, then add one layer at a time. Each milestone should be testable in a minute or two.

1. Player fish appears and moves.
2. Other fish spawn and drift.
3. Touching a small fish eats it and scores.
4. Player grows as it eats.
5. Touching a big fish ends the game.
6. Title and Game Over screens.

That milestone list is your to-do list. You'll build them top to bottom, one at a time.

Part 3 — The Architecture Map (your reusable template)

The Architecture Map is a table that captures your whole plan on one page. Fill one out for each game. Copy this template:

🎯 Game: ________________

One-sentence core: ________________________________________

Objects table — every kind of thing on screen:

Rules ("when ___, then ___"):

• When ______________ then ______________
• When ______________ then ______________

States (scenes): ______________ → ______________ → ______________

Score / lives: ________________ Win condition: ________________ Lose condition: ________________

Build order (milestones):

Filling in the last two columns of the objects table ("Components it needs" and "Technique(s)") is where planning meets code. You're deciding, in advance, what each object is made of and which tool you'll reach for. When those columns are full, building is mostly just... doing what you already wrote down.

Part 4 — A worked example (so you see the method in action)

Let's plan a brand-new tiny game — "Coin Catcher" — so you can watch the method work before you tackle the big three. (This isn't one of your games; it's a warm-up.)

Step 1 — One sentence: "Move a bucket left and right to catch coins falling from the sky; miss three and you lose."

Step 2 — Objects: bucket, coins, score text, lives text.

Step 3 — Behaviors: bucket moves left/right with arrow keys; coins fall downward; texts show numbers.

Step 4 — Rules:

• When a coin touches the bucket → remove the coin, +1 score.
• When a coin falls off the bottom → remove it, −1 life.
• When lives hit 0 → go to Game Over.

Step 5 — States: Playing → Game Over.

Step 6 — Filled-in Architecture Map:

Rules: coin+bucket → score up; coin+floor → life down; lives 0 → game over. States: Playing → Game Over. Build order:

1. Bucket appears and moves L/R. (Techniques 1, 2, 4)
2. Coins spawn at random x and fall. (Techniques 5, 9)
3. Catching a coin scores a point. (Technique 8, 12)
4. Missing a coin costs a life; 0 lives → Game Over. (Techniques 8, 11, 12)

See what happened? We never wrote a line of JavaScript, but the game is now completely planned. Every milestone points at a technique. To build it, you'd open the Playground, learn techniques 1, 2, 4 for milestone 1, and write it. Then 5 and 9 for milestone 2. And so on. That is exactly what you'll do for Pac-Man, Donkey Kong, and Fishy.

Part 5 — Your toolbox at a glance (the Technique Index)

The Technique Playground has a live, runnable example for each of these. This table is your map of what's available and which game each tool helps with. When a workbook says "you'll need spawning here," you'll know that's Technique 9.

✅ Planning checklist

Before you write code for a game, you should be able to check all of these:

• I can say the game in one sentence.
• I listed every object on the screen.
• I wrote down what each object does.
• I wrote the rules as "when ___, then ___".
• I listed the states/scenes.
• I filled in the Architecture Map, including the Components and Technique columns.
• I have a build order — a numbered list of small milestones, each testable.

When those are checked, you're ready. Open your game's workbook — Pac-Man, Donkey Kong, or Fishy — and start mapping. 🧭