Planning Multi-Sprite Projects — paper before pixels

Learning Goals 3 min

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

1. Use the index card method to write one card per sprite — name, job, and the broadcasts it sends or listens to — before you open Scratch.
2. Draw a stage sketch showing roughly where each sprite starts on screen and which backdrop it sits on.
3. Estimate whether a project idea is a 20-minute, 1-hour, or multi-class build, and split the bigger ones into milestones you can finish in one session.

Warm-Up — Daniel's three-hour mess 7 min

Daniel sat down after class last Tuesday and decided to build "a really cool RPG with three rooms and a boss fight." He spent two hours dragging blocks. At the end, the door sprite in room 1 was teleporting the player into the boss room instead of room 2. He couldn't figure out why. He went home angry.

Looking at his project, you find this on the door sprite in room 1:

when this sprite clicked
broadcast (boss v)
        

Why did Daniel write boss instead of room2?

Today's lesson is about the 10 minutes of planning that would have saved Daniel those two hours. It's not as fun as dragging blocks — but it's the difference between finishing a project and abandoning one.

New Concept — paper before pixels 15 min

You wouldn't build a house by buying bricks and starting to stack them at random. You'd draw a plan first — how many rooms, where the doors go, where the kitchen is. Scratch projects are houses too. The bricks are sprites and broadcasts. The plan is what we're learning today.

The index card method

Get a stack of small cards or just fold an A4 sheet into eight rectangles. One sprite per card. On each card write four things:

• Name — what you'll call the sprite in Scratch. Tikus, Title, Aisyah. Real names, not Sprite1.
• Job — one sentence. "Pops up at random holes for the player to whack."
• Sends — list every broadcast this sprite fires. If none, write none.
• Listens for — list every broadcast this sprite reacts to with a when I receive.

That's it. Three minutes per card. You'll finish a 5-sprite project's plan in fifteen minutes.

The broadcast list

Once all your cards are done, line them up and circle every broadcast name you wrote. Now check:

• Every broadcast someone sends, someone else listens for. If you wrote start-game under "Sends" on card 1, at least one other card must have start-game under "Listens for". Otherwise that broadcast does nothing.
• Every broadcast someone listens for, someone else sends. A listener with no sender will sit forever waiting for a cue that never arrives.
• Names match exactly. game-over and gameover are different broadcasts to Scratch. Pick one form and stick to it across all cards.

This three-minute check catches Daniel's bug before a single block is dragged.

The stage sketch

On a separate sheet, draw a rectangle the shape of the Scratch stage (a bit wider than it is tall). Inside, put a dot or letter for each sprite roughly where it starts. Label them. You don't need pixel-perfect art — even stick figures work. The point is to see the project before you build it.

If your project has multiple scenes (different backdrops), draw one rectangle per scene and label which sprites are visible in each. "In Scene 2 the Mum sprite is hidden" is the kind of thing that's obvious on paper but takes ages to spot in code.

Time-boxing the idea

Before you commit, look at your card stack and estimate:

• 1–2 sprites, 0–1 broadcasts — a 20-minute project. Build it in one sitting.
• 3–4 sprites, 2–4 broadcasts — a 1-hour project. Build it in one class.
• 5+ sprites, 5+ broadcasts, multiple scenes — a multi-class project. Split it into milestones (Scene 1 today, Scene 2 tomorrow, polish on Wednesday).

Daniel's RPG was a multi-class project. He tried to do it in one sitting. Even if his broadcast names had been perfect, he'd have run out of energy before the boss fight was playable.

What the final scripts look like

Just to anchor this in real Scratch, here's the kind of script the plan turns into. For a "Title clicks → game starts" pattern your cards would predict:

when this sprite clicked
broadcast (start-game v)
hide
        

when flag clicked
hide
when I receive (start-game v)
show
forever
  go to x: (pick random (-150) to (150)) y: (pick random (-100) to (100))
  show
  wait (0.8) seconds
  hide
  wait (1) seconds
end
        

If your cards say "Title sends start-game" and "Tikus listens for start-game", these scripts almost write themselves. The plan is the code, one level above the blocks.

Worked Example — planning a "Kuih Catcher" game 15 min

Let's plan a small game together. We won't build it — we'll plan it well enough that you could build it cleanly in 30 minutes. The game: kuih (Malaysian sweets) fall from the top of the screen, the player moves a basket left and right to catch them. Score goes up for each catch. Game ends after 30 seconds.

Step 1 — Brainstorm sprites on scrap paper

What needs to exist on stage? Quick list: a basket the player moves, a kuih that falls, the score, the timer, maybe a title screen, maybe a game-over screen.

Step 2 — Cut the list down

Score and timer aren't sprites — they're variables. Cross them out. We're left with: Basket, Kuih, Title, GameOver. Four cards.

Step 3 — Card 1: Basket

Write one card:

• Name: Basket
• Job: Follows the mouse pointer left and right at the bottom of the stage. Catches falling kuih.
• Sends: none
• Listens for: start-game, game-over

Step 4 — Card 2: Kuih

• Name: Kuih
• Job: Spawns at the top in a random x position, falls to the bottom, resets. When touched by basket, adds 1 to score and respawns.
• Sends: none
• Listens for: start-game, game-over

Step 5 — Card 3: Title

• Name: Title
• Job: Shows the game title. When clicked, broadcasts start-game and hides.
• Sends: start-game
• Listens for: none

Step 6 — Card 4: GameOver

• Name: GameOver
• Job: Hidden until the timer hits 30. Shows the final score. Broadcasts game-over so other sprites stop.
• Sends: game-over
• Listens for: none (it triggers itself off the timer in a forever loop)

Step 7 — Cross-check the broadcasts

Two broadcasts in total: start-game and game-over.

• start-game — sent by Title, listened for by Basket and Kuih. Wired.
• game-over — sent by GameOver, listened for by Basket and Kuih. Wired.

Every send has a listener, every listener has a sender. No typos. If you find a mismatch here, fix it on paper — not in Scratch.

Step 8 — Stage sketch

One rectangle. Inside, draw:

• Title in the centre, big.
• Basket at the bottom centre (small).
• Kuih near the top (small, will fall).
• GameOver in the centre (hidden at start, will appear later).

Step 9 — Time estimate

4 sprites, 2 broadcasts, 1 scene. That's a 1-hour project — exactly one class. No need to split into milestones.

Step 10 — What the Basket sprite's script will look like

Once you start building, the plan turns into something like this for the Basket:

when flag clicked
hide
when I receive (start-game v)
show
forever
  set x to (mouse x)
end
when I receive (game-over v)
stop [other scripts in sprite v]
        

What you just did: turned a vague idea ("a kuih catcher game") into a buildable spec in fifteen minutes. When you sit down at Scratch, you won't be inventing names or wondering what sprite to make next. You'll just be typing in a list that's already on paper.

Try It Yourself — plan three projects (no Scratch!) 12 min

For each task, do the plan only — index cards, broadcast check, stage sketch, time estimate. No keyboards.

when flag clicked
ask [What is your name?] and wait
say (join [Hello, ] (answer)) for (3) seconds
        

Mini-Challenge — Priya's missing listener 5 min

"Priya's title screen does nothing"

Priya built a small game. She has a title sprite that says "Click to start". When clicked, it should hide and start the game. She shows you the title sprite's script:

when this sprite clicked
broadcast (begin v)
hide
        

And here's her player sprite's only script:

when flag clicked
hide
when I receive (start v)
show
forever
  move (5) steps
  if on edge, bounce
end
        

When Priya clicks the title, the title hides — but the player never appears. What's wrong, and what does the index-card check catch?

Recap 3 min

You learned the planning ritual: one index card per sprite (name, job, sends, listens for), a stage sketch, a broadcast cross-check, and a time estimate. None of this is code, and all of it is what stops the three-hour-debug-because-I-typed-the-wrong-broadcast-name kind of mess. Real Scratch developers (yes, that includes you now) treat planning as part of building — not a chore that delays it. The next time you have a project idea, reach for paper before you reach for the mouse.

Index card method

One card per sprite, with four fields: name, job, sends, listens for. The cards together describe the whole project before any blocks are dragged.

Broadcast cross-check

Looking at all your cards and confirming that every broadcast someone sends, someone else listens for — and vice versa. Catches typo bugs in seconds.

Stage sketch

A quick drawing of the Scratch stage with each sprite labelled where it starts. One sketch per scene if you have multiple backdrops.

Time-box

An honest estimate of how long a project will take, based on sprite and broadcast count. 20-minute, 1-hour, or multi-class — and split the big ones into milestones.

Milestone

A chunk of a bigger project small enough to finish in one session. "Scene 1 working end-to-end" is a milestone. "The whole RPG" is not.

Homework 2 min

Plan a project of your own — on paper, no Scratch. Pick something you actually want to build. The next four lessons in Cluster H are Build lessons, so this plan can become a real project you take to class.

1. Brainstorm the idea in one sentence. "A pet sim where I feed my cat kuih and it gets happier."
2. List the sprites. Cut variables (numbers) out of the list — they're not sprites.
3. Make one index card per sprite. Fill in all four fields: name, job, sends, listens for.
4. Do the broadcast cross-check. Fix mismatches now, on paper.
5. Draw a stage sketch — one per scene if you have more than one backdrop.
6. Estimate the time-box. If it's multi-class, split it into 2–3 milestones with what you'll finish each session.

Bring all of it on paper (or photograph the cards). We'll trade plans in class and you'll review someone else's project the way you reviewed Priya's title screen.

Bring back next class:

• Your index cards (or a clear photo).
• Your stage sketch.
• Your time-box estimate and milestone breakdown if it's multi-class.
• Your answer to: "Which bit of the plan changed your mind about how to build it?"

Heads up for next class: SCR-L02-46 is all about debugging — when scripts go wrong, how do you figure out which block lied to you? Planning prevents some bugs; debugging fixes the rest.