Learning Goals 3 min
By the end of this lesson you will be able to:
- Name the five-step project rhythm — plan, vertical slice, playtest, polish, ship — and explain why each step exists.
- Tell the difference between a 50-block script and a 500-block project, and explain why the second one needs a workflow while the first one doesn't.
- Sketch a one-page plan on paper for a simple game (today: Egg Catcher) listing sprites, variables, broadcasts, and the smallest vertical slice you could build first.
Warm-Up — the 500-block wall 7 min
Everyone in this class has built a 50-block project. Cat walks, cat bounces off edges, cat says Hi when you click it. You can hold the whole thing in your head. If something breaks, you scroll up to the top of the script and trace down — and within two minutes you've found it.
Now imagine a project with 500 blocks. Three sprites, eight variables, four broadcasts, two lists, a custom block called from six places, gravity, jumping, a title screen, a pause menu, a game-over screen, and a high-score list. You sit down on a Saturday afternoon to add one new enemy type. Where do you even start?
What usually happens
Without a workflow, what happens is: you find the player sprite, scroll through its eleven scripts, eventually find the collision check, paste in a new if, click the flag — and the title screen now freezes because the new if mentions a variable the enemy hasn't set yet. Twenty minutes of debugging later, you discover that fixing the freeze breaks the pause menu. An hour after that, you close Scratch and decide to play Roblox instead.
This isn't a Scratch problem. It's what happens to every programmer the first time they try to extend a project that's bigger than they can hold in their head. The solution isn't to write smaller projects. The solution is to follow a workflow that handles the size for you.
Today's lesson is the workflow. No new blocks. By the end of class you'll have a single piece of paper that solves the "where do I start?" problem before it shows up.
New Concept — the five-step rhythm 15 min
Real software teams — the people who build the games you play and the apps on your parents' phones — follow some version of these five steps. The names vary. The order doesn't.
| Step | What you do | What you must not do |
|---|---|---|
| 1 · Plan | Pen and paper. List sprites, variables, broadcasts. Sketch the screen. | Do not open Scratch. |
| 2 · Vertical slice | Build the smallest playable version. One sprite, one mechanic, no polish. | Do not add a title screen, sounds, or art. |
| 3 · Playtest | Let a real person play your slice. Watch silently. Take notes. | Do not explain what they should do. |
| 4 · Polish | Title screen, sounds, art, feel. Add the bits that turn it into a real game. | Do not add new mechanics. |
| 5 · Ship | Save, name, upload to scratch.mit.edu, write notes and credits. | Do not keep tweaking. Ship and move on. |
Why plan on paper first?
Because changing a sketch costs ten seconds, and changing a 200-block project costs ten minutes. When you plan on paper, you find your mistakes early — when they're cheap. You might realise "wait, the basket and the egg need to share a variable" before you've dragged a single block. That realisation on paper is worth twenty realisations made halfway through a build.
A good Scratch plan is one piece of A4 paper with four boxes:
- Sprites: a list of names with one sentence each. ("Basket: follows the mouse, catches eggs.")
- Variables: a list of names with their type and starting value. ("score · number · 0".)
- Broadcasts: the named messages sprites send each other. ("egg-caught", "game-over".)
- Stage sketch: a stick-figure drawing of what the screen looks like at the start of the game.
What is a vertical slice?
A "vertical slice" is borrowed from real game studios. It means: build the smallest version of your game that you can actually play, end to end. No menus. No score. No sound. No fancy art. Just "the thing happens, and the player does the thing".
For Egg Catcher (our example today), the vertical slice is: one egg falls from the top, you can move a basket with the mouse, the egg either lands in the basket or hits the floor. That's it. No score yet. No new eggs after the first one. Just the one mechanic, working.
Why so small? Because if the basket-catches-egg part doesn't feel good, no amount of title screens and music will save the game. The slice tests the heart of your idea before you spend hours decorating around it.
Why playtest before polishing?
You wrote the game. You know exactly what the player is supposed to do. Of course it makes sense to you. The playtest tells you whether it makes sense to anyone else. Sit a friend or a sibling in front of the slice. Don't explain anything. Watch. Take notes. Common discoveries:
- They expect arrow keys, not the mouse. (Now you know which controls to ship with.)
- They didn't notice the egg fell behind the basket. (The egg needs to be visually in front, or the basket needs a clearer collision zone.)
- They tried to click the egg to catch it. (Add "catch by clicking" or paint a clearer instruction.)
If you skip the playtest and go straight to polish, you spend hours making a title screen for a game whose main mechanic is confusing. Bad trade.
Why polish before shipping?
The slice works. The polish delights. A title screen named "TELUR TANGKAP" with a big start button feels like a real game. A "splat" sound when an egg hits the floor and a "ding" when you catch one — adds two minutes of work, changes the whole feel. A score counter in the corner gives the player something to chase. These things are cheap to add after the slice works and impossible to retrofit if the slice is broken.
Why ship at all?
Because a finished project that nobody plays is a project that taught you nothing about your audience. Shipping means: save the file with a clear name, upload to scratch.mit.edu, write the project notes ("how to play"), credit anyone whose remix or art you used, and let go. Don't keep tweaking forever. The next project will be better — start it.
Worked Example — Egg Catcher, all five steps 14 min
Mei wants to build "Egg Catcher". The player drags a basket left and right to catch eggs falling from a chicken at the top. Each catch is +1 point. Three misses and it's game over. We'll walk Mei through all five steps without writing the full final build — just enough to see the rhythm.
Step 1 — Plan on paper (5 minutes)
Mei takes a piece of A4 and writes four boxes:
- Sprites: Chicken (top, spawns eggs), Egg (falls), Basket (follows mouse, catches eggs).
- Variables:
score · number · 0,misses · number · 0,state · text · play. - Broadcasts:
egg-caught,egg-missed,game-over. - Stage sketch: chicken at top centre. Basket near bottom. Egg drawn mid-air with an arrow pointing down. "Score: 0" in top-right corner.
This entire plan is one page. Mei has not opened Scratch yet. Total cost so far: 5 minutes and a piece of paper. If Mei realises now that she actually wants the basket on the keyboard and not the mouse, she rewrites the "Basket" sentence in 10 seconds. Compare that to changing a finished basket script.
Step 2 — Vertical slice (15 minutes)
Mei opens Scratch and builds the absolute minimum:
- One Basket sprite that follows the mouse's x.
- One Egg sprite that starts at the top and falls — no clones, no score, no chicken, no second egg.
- If the egg touches the basket, it says "Caught!" for one second.
- If the egg falls below the floor, it says "Missed!" for one second.
The whole slice is around 15 blocks across two sprites. Looks like this on the Egg:
when flag clicked
go to x: (0) y: (160)
repeat until <<touching [Basket v] ?> or <(y position) < (-170)>>
change y by (-4)
end
if <touching [Basket v] ?> then
say [Caught!] for (1) seconds
else
say [Missed!] for (1) seconds
end
And on the Basket:
when flag clicked
forever
go to x: (mouse x) y: (-140)
end
Mei clicks the flag. The egg falls. She moves the basket. The egg either says "Caught!" or "Missed!". The heart of the game is working. No polish yet — and that's the point.
Step 3 — Playtest (5 minutes)
Mei calls her younger brother Daniel over. "Try it." She doesn't explain anything. Daniel clicks the flag, sees the egg fall, and… tries to click on the egg. He missed entirely that the basket follows the mouse. After a few seconds he figures it out, catches one, smiles. Mei writes down: "Daniel didn't notice the basket. Needs to be more obvious — maybe make it bigger, or add a 'move me!' arrow on the title screen."
One playtester. One real observation. Worth more than an hour of solo guessing.
Step 4 — Polish (15 minutes)
Now Mei expands. She adds:
- The Chicken sprite at the top, with a cluck sound every spawn.
- Egg clones spawned by the Chicken every 1.5 seconds, instead of just one egg.
- A
scorevariable that the Egg increments on catch. - A
missesvariable that the Egg increments on miss; at 3, broadcastsgame-over. - A title screen — "Press SPACE to start!" — and a state machine gating everything on
state = play. - A "splat" sound on miss and a "ding" sound on catch (from Scratch's sound library).
- A bigger basket sprite so Daniel's playtest note is addressed.
None of this is a new mechanic. Every item polishes something the slice already did. After polish, the project is maybe 200 blocks across three sprites — but it grew from a working slice, not from a blank screen.
Step 5 — Ship (5 minutes)
Mei saves as egg-catcher-v1.sb3. She logs in to scratch.mit.edu, uploads, and writes in the project notes:
"Move the basket with your mouse. Catch the falling eggs from the chicken! 3 misses and it's game over. Press SPACE to start. Sounds from Scratch's built-in library. — Mei"
She clicks "Share". Done. The project is now playable by anyone with the link. Mei has not started polishing v2 yet — she ships first, then opens a fresh file for the next idea.
What you just saw: 50 minutes of total work. 5 of those minutes were planning, 5 were playtesting, 5 were shipping. The 15 spent on the slice and the 15 spent on polish were each fully focused — Mei never had to ask "what should I build next?" because the plan said.
Try It Yourself — three workflow drills 15 min
Goal: Plan-only. Take a piece of paper. Plan a tiny "Click the Mango" game where a mango sprite appears at random positions and you click it to score. Fill in the four boxes — sprites, variables, broadcasts, stage sketch — and stop. Do not open Scratch.
Think: You probably wrote Sprites: Mango, Variables: score, Broadcasts: (none yet). That's a complete plan for a 20-block game. Notice how fast it was. Now imagine doing the same for the multi-level platformer you'll build in cluster D — the plan would be three sheets of paper, but each one would still take 5 minutes to write.
Goal: Slice-only. Build the absolute minimum vertical slice of "Click the Mango" from your plan. One sprite, one variable, no title screen, no sounds, no high score. Just: mango appears, you click, score goes up.
when flag clicked
set [score v] to (0)
forever
go to x: (pick random (-200) to (200)) y: (pick random (-150) to (150))
wait until <touching [mouse-pointer v] ?>
wait until <mouse down?>
change [score v] by (1)
end
Think: The wait until blocks are perfect for a slice — they pause the script until the condition is true, no polling needed. Polish would add: a timer, a sound on click, an animation when it teleports, a title screen. But the heart of the game — appear, click, score — works in 8 blocks. Now you have something to polish instead of a blank screen to start from.
Goal: Playtest-only. Take the Mango slice you just built (or someone else's) and recruit one person who has never seen it. Sit them in front of the Stage. Don't say anything except "try it". Watch. Write down three observations:
- What did they do first?
- What confused them, even for a second?
- What did they expect to happen that didn't?
Think: The hardest part of playtesting isn't the watching — it's the not talking. Every time you say "no, click on the mango", you erase a real observation about what your game communicates without explanation. Real games ship to players who never get an explanation from the developer. The playtest simulates that.
Mini-Challenge — Aljay's 400-block disaster 5 min
"I think I'm done. Why won't it work?"
Aljay sits down on Saturday morning and starts building a quiz game. He doesn't plan. He opens Scratch and starts dragging blocks. Four hours later, he has 400 blocks across five sprites. The title screen sometimes shows, sometimes doesn't. The score sometimes resets, sometimes doesn't. The questions sometimes shuffle, sometimes repeat. He shows you the project at the end of the day, exhausted, and says "I think I'm done. Why won't it work?"
You've been through this lesson. What single piece of advice — not a code fix, not a debugging trick — do you give Aljay?
Reveal the advice
"Close Scratch. Get a piece of paper. Plan it."
Aljay's mistake wasn't a coding mistake — it was a workflow mistake. He skipped step 1 (plan) and went straight to step 4 (polish, sort of) without ever building a clean slice. His 400 blocks are the messy in-between: every sprite is half-built, every variable is partially gated, every broadcast is half-wired. There's no single bug to fix. The project has hundreds of tiny bugs because there was no map.
The cure isn't to keep adding fixes — that just adds more half-things. The cure is to step back, plan what the game should be on paper, then either:
- Restart with the plan in hand. Yes, throwing away 400 blocks. The new build will be done in two hours with the plan, instead of the next four hours of debugging the old one.
- Or refactor the existing project against the plan — script by script, gate each one on the state variable, rename broadcasts so they match. Slower, but you keep the art and the questions.
Either way, the plan comes first. You cannot debug your way out of an unplanned project. L4 is the level where this becomes true for the first time — every project from cluster B onwards is too big to wing.
Recap 3 min
You learnt the five-step rhythm — plan, vertical slice, playtest, polish, ship — that real software teams (and real Scratch L4 students) use to build projects that don't collapse under their own weight. You saw Mei plan Egg Catcher in five minutes, build a 15-block slice in fifteen, playtest with Daniel, polish into a 200-block game, and ship to scratch.mit.edu — all in under an hour. And you saw Aljay's 400-block disaster: what happens without the workflow. The plan is not extra work. The plan is the work that lets the rest of the work happen.
- Plan (the four-box paper)
- A one-page A4 sketch with four boxes: sprites, variables, broadcasts, stage sketch. Written before opening Scratch. Costs 5 minutes; saves hours.
- Vertical slice
- The smallest playable version of your idea — one mechanic, no polish, no menus, no sound. Tests the heart of the game before you decorate around it. If the slice isn't fun, no polish can save it.
- Playtest
- One real person, not you, plays your slice while you watch in silence. You take notes. They reveal what your game communicates without your help — which is how it'll be played by everyone who isn't you.
- Polish
- The work that turns a slice into a real game: title screen, sounds, art, score, game-over, feel. No new mechanics. Polish multiplies a good slice and cannot rescue a bad one.
- Ship
- Save with a clear name, upload to scratch.mit.edu, write project notes, credit any borrowed art or remixes, click Share. Then stop tweaking and open the next blank project.
- 50-vs-500 split
- A 50-block project fits in one person's head and needs no workflow. A 500-block project does not fit in anyone's head and cannot be built without one. Every L4 project lives in the second category.
Homework 2 min
Plan + slice + ship. Pick any tiny game idea — "Catch the Ondeh-Ondeh", "Click the Capital of Malaysia", "Dodge the Roti Canai". Take it through three of the five steps.
- Plan on paper. Four boxes: sprites, variables, broadcasts, stage sketch. Take a clear photo of the page. (Aim for 5 minutes. If it takes 20, the game is too big — shrink it.)
- Build the vertical slice. One mechanic only. No title screen. No sound. No score. Aim for under 30 blocks total across all sprites.
- Ship the slice to scratch.mit.edu as
L4-02-slice-yourname. Project notes: "This is a vertical slice for L4-02. The polished version comes later."
Bring back next class:
- The photo of your paper plan.
- The scratch.mit.edu link to your shipped slice.
- Your completed remix plan from the Mission above.
- Your answer to: "How long did the plan take, and how long did the slice take? Was the plan worth it?"
Heads up for next class: SCR-L04-03 is the second workflow lesson — Reading Other People's Projects. We'll open your chosen remix target on scratch.mit.edu, click "See Inside", and learn how to read 500-block stacks the way you read a book. Reading other people's projects is the fastest way to steal — er, learn — new tricks.