Planning a Game on Paper — seven steps before you touch Scratch

Learning Goals 3 min

By the end of this lesson you will be able to:

1. Walk through the 7-step paper plan — one-sentence pitch, start-screen sketch, sprite list, variable list, list list, broadcast list, and state-machine diagram — before you open Scratch.
2. Explain why thinking on paper catches bugs that thinking-in-the-editor never finds: forgotten sprites, unnamed broadcasts, missing reset values, and untracked state changes.
3. Use a paper plan as a checklist while building, ticking off each sprite, variable, and broadcast as you wire it in.

Warm-Up — Hafiz's missing sprite 7 min

Hafiz spent two weeks building "Durian Defender" — a tower-defence game where durians fall from trees and the player swings a fan to blow them away. He never planned a thing on paper. Two days before showing it off, he realised: there's no win condition. The game runs forever. The player keeps blowing durians, the score climbs, and nothing ever says "you win" or "you lose."

He scrambles to add one. But every script he writes touches the score variable, the timer, the durian spawner, the fan sprite — and the changes ripple. Stuff breaks. He spends another week fixing knock-on bugs from one missing feature.

Predict the answer before you peek: what's the one thing Hafiz could have done in 15 minutes that would have saved that week?

Today's lesson has zero new Scratch blocks. Bring a pencil. We're going to plan a complete game on paper, then look at how the plan turns into code.

New Concept — the 7-step paper plan 15 min

Every game you build from now on follows this checklist. Do it on paper. Use a pencil so you can erase. Don't open Scratch until the page is full.

Step 1 — The one-sentence pitch

Write the whole game in one sentence. If you can't, you don't know what you're building. Bad pitch: "A cool game with stuff." Good pitch: "The player catches falling eggs in a basket; three misses ends the game." The pitch fits on one line. It tells you what's in (eggs, basket, lives) and what's out (no shop, no level-up, no boss).

Step 2 — Sketch the start screen

Draw a rectangle for the Stage. Draw stick figures of every sprite where it starts. Write a title. Draw the score watcher in the corner. This is what the player sees the moment they hit the flag. If you can't draw it, you don't know what they see.

Step 3 — List every sprite and its job

One line per sprite. Format: Name — one sentence on what it does.

• Basket — follows the mouse along the bottom.
• Egg — spawns from the top at a random x, falls, despawns at the bottom.
• Score-text — shows the score watcher (no scripts).

If a sprite has zero scripts, write that. If a sprite has ten scripts, write the one-sentence summary, not all ten.

Step 4 — List every variable and its initial value

One line per variable. Format: Name — what it holds — starts at ___.

• score — eggs caught so far — starts at 0.
• lives — misses remaining — starts at 3.
• state — title / play / game over — starts at "title".

The "starts at" column is the most useful one. Every variable here becomes a set [v] to () in your flag-click handler.

Step 5 — List every list (if any)

Same format. Often empty for small games.

• high-scores — past final scores — starts empty (carries over).

Step 6 — List every broadcast (sender → receivers)

One line per broadcast. Format: broadcast name — who sends — who listens.

• start-game — Stage on flag — basket, egg, score reset.
• egg-caught — egg on basket touch — score sprite (+1).
• egg-missed — egg on bottom touch — lives sprite (−1).
• game-over — lives when 0 — every gated script.

This is the wiring diagram. If two sprites need to talk, there's a broadcast between them. If a broadcast has no listener, delete it. If a script changes the world but no broadcast goes out, you're probably missing one.

Step 7 — Draw the state-machine diagram

A state machine is just the list of moments the game can be in with arrows for "what causes the move from one to the next." Boxes are states; arrows are triggers.

[title]  --(space pressed)-->  [play]
[play]   --(lives = 0)-->      [game over]
[play]   --(p pressed)-->      [pause]
[pause]  --(p pressed)-->      [play]
[game over] --(r pressed)-->   [title]
        

If your state machine has only one box, you don't have a game — you have a screensaver. If it has 20 boxes, you've over-designed; cut some.

Worked Example — planning Egg Catcher 20 min

We'll plan the whole game in one pass. No Scratch yet. Pencil ready.

Step 1 — Pitch

"The player moves a basket with the mouse to catch falling eggs; three misses ends the game; the score is the total caught."

One sentence. Mentions player input (mouse), goal (catch), loss condition (three misses), score rule. That's a full game in 24 words.

Step 2 — Start-screen sketch

Draw it on paper. For this lesson, here's the description:

• Stage: yellow-orange background (chicken farm vibes).
• Title text at the top: "EGG CATCHER — press SPACE to start."
• Basket sprite at the bottom-centre.
• Score watcher in the top-right (says 0).
• Lives watcher under the score (says 3).
• No eggs visible until the player presses space.

Step 3 — Sprite list

• Basket — follows mouse-x along the bottom; sets state to "play" on space.
• Egg — spawns clones at random x from the top; each clone falls; touches basket → broadcast egg-caught + delete; touches bottom → broadcast egg-missed + delete.
• Title-text — shows on state "title", hides on state "play".
• Game-over-text — shows on state "game over", hides otherwise.

Step 4 — Variable list

• score — eggs caught — starts at 0 on start-game broadcast.
• lives — misses left — starts at 3 on start-game broadcast.
• state — title / play / game over — starts at "title" on flag.

Step 5 — List list

• high-scores — past final scores — appended on game-over.

Step 6 — Broadcast list

• start-game — Basket (on space, state="title") — all sprites (reset).
• egg-caught — Egg clone (on basket touch) — Score (+1).
• egg-missed — Egg clone (on bottom touch) — Lives (−1).
• game-over — Lives (when 0) — every gated script (freeze).

Step 7 — State machine

[title]      --(space pressed)-->  [play]
[play]       --(lives = 0)-->      [game over]
[game over]  --(r pressed)-->      [title]
        

The plan becomes the code

Now the magic. Each plan section maps directly to a Scratch script. We're not going to build the whole game today — just look at how the plan turns into the first few scripts.

From Step 4 (variable list) → the flag handler:

when flag clicked
set [score v] to (0)
set [lives v] to (3)
set [state v] to [title]
        

From Step 6 (broadcast list) → the basket's start-game sender:

when [space v] key pressed
if <(state) = [title]> then
  set [state v] to [play]
  broadcast [start-game v]
end
        

From Step 3 (sprite list) → the egg clone's fall script:

when I start as a clone
go to x: (pick random (-200) to (200)) y: (180)
show
forever
  if <(state) = [play]> then
    change y by (-5)
    if <touching [Basket v] ?> then
      broadcast [egg-caught v]
      delete this clone
    end
    if <(y position) < (-170)> then
      broadcast [egg-missed v]
      delete this clone
    end
  end
end
        

Notice what the planning bought you: every variable has an initial value (no leftover bugs); every broadcast has a known sender and receiver (no orphan signals); every script knows which state it runs in (no rogue eggs falling on the title screen). The bugs Hafiz fought for a week? Already designed out, before you typed a block.

What you just did: turned a vague game idea into 7 pages of pencil notes, then watched the first three scripts fall out of the notes almost automatically. The plan didn't make the coding harder. It made the coding boring — in the best way. Boring code ships. Exciting code crashes.

Try It Yourself — three planning drills 12 min

Mini-Challenge — Lea's plan that lies 5 min

"My plan said three sprites but I have eight"

Lea planned a game called "Cat & Mouse." Her plan:

• Pitch: "Cat chases a mouse with arrow keys; touching the mouse scores 1; 30 seconds total."
• Sprites: Cat, Mouse, Score-text.
• Variables: score (starts 0), time (starts 30).
• Broadcasts: start-game (Stage → all), game-over (when time = 0).
• State machine: title → play → game over.

Two days later, her project has eight sprites: Cat, Mouse, Score-text, Cheese-bonus, Wall1, Wall2, Wall3, Restart-button. Her variables list has grown to 5. She didn't update the plan once.

What did Lea do wrong — and what should she do now, before adding anything else?

Recap 3 min

You met the 7-step paper plan: pitch, start-screen sketch, sprite list, variable list, list list, broadcast list, state-machine diagram. The bigger your project, the more time the plan saves. Planning catches missing features, undefined initial values, broadcasts with no listener, and rogue state changes — bugs that take an hour to find in Scratch and 30 seconds to notice on paper. The plan stays alive while you build: tick each item off as you wire it in, add new items to the plan first, treat it as a living document. Plan-first coding feels slow at the start and is twice as fast by the finish.

Pitch

A one-sentence summary of the entire game — what the player does, the goal, and the lose condition. If you can't pitch in one sentence, the game isn't focused yet.

Sprite list

A list of every sprite in the project with a one-sentence job description. The job descriptions become the scripts.

State machine

A diagram of every game state (title, play, pause, game over) with labelled arrows for what causes each transition. The arrows become broadcasts or key hats.

Initial value

What a variable holds the moment the flag is clicked. Every variable on the plan has one. Forgetting an initial value is the most common source of "weird leftover" bugs.

Plan-first vs code-first

Two ways to start a project. Code-first means jumping into Scratch and figuring it out as you go (faster for the first 10 minutes; slower overall). Plan-first means pencil before keyboard (slower for the first 15 minutes; faster overall).

Retrospective

A short review after building, asking "what did the plan miss, and why?" The answers train your planning brain for next time.

Homework 2 min

Plan one game, then build half of it. Pencil time before keyboard time.

1. Pick a game idea — something simple, like Egg Catcher, Whack-a-Mole, or a one-room maze. Don't pick a 3D MMO.
2. Fill in all 7 steps on a single sheet of paper. Photo it for your records.
3. Open Scratch. Build only the first 30 minutes' worth — usually the title screen, the player sprite, and one full state transition. Stop early on purpose.
4. Save as HW-L3-45-Plan-Half-Build.sb3.

Bring back next class:

• The photo of your paper plan.
• The half-built .sb3.
• Your answer to: "What's one thing the plan made obvious that you would have missed if you'd jumped straight into Scratch?"

Heads up for next class: SCR-L03-46 tackles the other side of complexity — debugging complex stacks. We'll take a deliberately broken multi-sprite project and use isolation tricks, hat-disabling, and watcher-spying to find the bug without rewriting the whole thing.