Learning Goals 3 min
By the end of this lesson you will be able to:
- Walk through a 7-point pre-share checklist for any Scratch project, in order, and tick off each item before clicking the Share button.
- Spot the five most common public-shaming bugs (variables not reset, undocumented controls, broken first-play, accidental infinite loops, missing credits) and fix them in under five minutes each.
- Apply the green-flag reset pattern — every variable, every list, every sprite position set to its starting value at the top of when ⚑ clicked — so your project plays the same on the 1st run as the 100th.
Warm-Up — the project that worked yesterday 7 min
Imagine this. You spent three lessons building your Malaysia Trivia game (SCR-L04-41). You tested it. It worked. You clicked Share. You sent the link to your cousin.
Your cousin opens it. Clicks the green flag. The cat says You scored 7. Try to beat the high score of 8!. Cousin says "what high score?" — they're confused. They click flag again. The cat says Player 2 wins! even though they're playing alone. They give up after 30 seconds.
What happened? The game worked perfectly on your computer. So what went wrong?
Reveal the answer
Two classic public-shaming bugs.
Bug 1. Your last test session left high-score at 8 and your cousin's first play was a 7 — but you never set high-score to 0 (or loaded from cloud) on the green flag. The variable kept its last value from your session and travelled into the saved project file.
Bug 2. Your last test session ended in 2-player mode with mode set to 2. The Title sprite asks for mode at the start of each game, but somewhere a script reads mode before the Title hands over — and the leftover value tricks the EndScreen into running the 2-player win-check.
Both bugs are state leaks — values that survived from one play session into the next. They never showed up in your testing because you played in the same order every time. They blew up the first time someone else played in a different order. Today's lesson is the 7-point routine that catches these before you click Share.
Sharing a Scratch project is the moment your code stops being yours and starts being other people's. The bugs you don't fix become their first impression. Worth 30 minutes.
New Concept — the 7-point checklist 15 min
Every professional software team has a "pre-release checklist". Big studios call it a "QA pass". For Scratch projects, your version is shorter — seven items, about 30 minutes to run through. The order matters: each one catches a different category of bug.
The checklist
| # | Check | Why it matters | Time |
|---|---|---|---|
| 1 | Project name is descriptive | "Untitled-42" gives no one a reason to click. "Malaysia Trivia: 2-Player Quiz" tells the visitor what they're getting in three seconds. | 1 min |
| 2 | Project notes explain how to play | The notes panel under the player is the only manual your player gets. List goal, controls, and any tips. | 5 min |
| 3 | Credits acknowledge whose work you used | Sprite from another Scratcher? Sound from a library? Tune from a song? Credit them, by name and project link. Scratch culture lives or dies on credit. | 3 min |
| 4 | All variables reset on green flag | This is the bug that breaks shared projects most often. See "the green-flag reset pattern" below. | 5 min |
| 5 | Controls are documented | Which arrow keys? Space to jump? Click to fire? Mouse to aim? Players cannot guess. State every control in the notes. | 3 min |
| 6 | Tested by someone who didn't build it | You know how it works because you built it. A fresh tester will find the things you can't see anymore. Watch them play — don't help — and write down where they get stuck. | 10 min |
| 7 | Playtime is reasonable (not an infinite-loop trap) | Your game needs an end. Either a win/lose screen or a clear "press flag to restart". A game with no exit feels broken even when it works. | 3 min |
The green-flag reset pattern (item #4 in detail)
Item 4 is the technical heart of the checklist. The rule is simple: every variable, every list, every sprite position, every visibility — anything that can change while the game runs — must be set to its starting value inside when ⚑ clicked.
That means somewhere near the top of one of your scripts (often the Stage's), you should have a block of "set everything" lines:
when flag clicked
set [score v] to (0)
set [lives v] to (3)
set [level v] to (1)
set [mode v] to (1)
set [current-player v] to (1)
set [game-over v] to (0)
delete (all) of [asked v]
delete (all) of [enemy-clones v]
hide variable [high-score v]
The same idea on each sprite: set its starting position, costume, size, visibility:
when flag clicked
go to x: (-200) y: (0)
set size to (100) %
switch costume to (idle v)
point in direction (90)
show
The "press flag to restart" convention
Item 7 — playtime — is partly about end-screens, but mostly about giving the player a way out. The Scratch convention is: clicking the green flag always starts a fresh game. If your end-screen says "Game Over!", players will instinctively click the flag again. As long as your green-flag reset pattern is right (item 4), this works automatically.
Worked Example — running the checklist on your Trivia Quiz 10 min
Open your SCR-L04-41 Malaysia Trivia Quiz project from last lesson. We'll run the 7-point checklist on it, in order, in about ten minutes. This is the routine you'll repeat for every project you share for the rest of your life.
Step 1 — Rename the project
Top of the editor, the project title is probably Untitled-7 or similar. Click it. Rename to something descriptive: Malaysia Trivia: 2-Player Quiz. Hit Enter. One minute.
Step 2 — Write the project notes
Below the player, you'll see two text boxes: Instructions and Notes & Credits. Fill Instructions:
- What the game is (one sentence).
- How to play (controls, how to start).
- Goal (how to win).
Example:
A 10-question Malaysia trivia quiz! Click the green flag, type 1 for solo play or 2 for pass-and-play with a friend, then type each answer and press Enter. Get more correct than your opponent (or beat your own high score) to win.
Step 3 — Write the credits
Fill Notes & Credits:
- Who you are (first name and class is fine — never your full name or school).
- Where you got any sprites, sounds, or backdrops (link if they're from another Scratcher).
- Any questions you took from a source (a quiz book, a website, a parent). "Trivia questions written by me with help from Mum" is fine.
Step 4 — Audit your green-flag resets
Click each sprite in turn. Look at every when ⚑ clicked script. Does each one set the sprite's starting position, size, costume, and visibility? Does the Stage script reset every variable (except high-score) and every list?
For the Trivia Quiz, your Stage flag-click should look something like:
when flag clicked
set [mode v] to (0)
set [current-player v] to (1)
set [score-p1 v] to (0)
set [score-p2 v] to (0)
set [q-index v] to (0)
set [turn-count v] to (0)
delete (all) of [asked v]
The Title sprite needs show, the Quiz sprite needs hide, the EndScreen sprite needs hide — all on their own when ⚑ clicked. Without these, the wrong sprite is visible at the start of the second game.
Step 5 — Document the controls
For Trivia, the only "control" is typing the answer and pressing Enter. Add a line to Instructions: "Controls: type your answer in the text box at the bottom, then press Enter." Sounds obvious — but children unfamiliar with Scratch don't always know where the answer field is.
Step 6 — Hand it to a fresh tester
This is the most important step and the one most people skip. Pick someone who hasn't seen the project — a sibling, a parent, a cousin. Sit them in front of the computer. Don't help. Watch them. Write down:
- Where they paused (those are the spots that need clearer instructions).
- What they did wrong (those are the spots that need better defaults or error handling).
- What made them laugh or smile (those are the bits you keep — they're working).
Ten minutes of watching is worth more than ten hours of your own testing.
Step 7 — Check for infinite loops
For Trivia, the game ends after 10 questions and shows an EndScreen. Good. But check: after the end-screen, can the player click the flag and get a fresh game? Run it twice in a row. The second game should look identical to the first — same starting state, same fresh shuffle, no leftover high-score popping up at the wrong moment. If the second game breaks, go back to Step 4.
What you just did: the entire 30-minute pre-share routine on a real project. From now on, every project you upload to scratch.mit.edu gets the same 7-step pass. Build this habit now and your shared projects will be in the top 10% of Scratch quality just by avoiding the obvious mistakes.
Try It Yourself — three checklist drills 10 min
Goal: Find three different Scratch projects on scratch.mit.edu (try the front page or your Studios). For each one, rate it against checklist items 1, 2, and 3 (project name, instructions, credits) on a scale of 0–2. Write your scores in your notebook.
Think: You'll be shocked how many high-view, high-loved projects fail items 1–3. Good Scratch creators are not automatically good at the sharing checklist — they're just good at the coding. Today's lesson is your edge.
Goal: Open your trivia project from L04-41 and add the green-flag reset pattern to the Stage and to all three sprites. Then break it on purpose: pick one variable (say, score-p1) and remove its reset line. Click the flag. Play a partial game (answer 3 questions). Click the flag again to "restart". Note what happens.
when flag clicked
set [score-p2 v] to (0)
set [current-player v] to (1)
delete (all) of [asked v]
Think: Seeing the bug yourself is the only way to truly believe item 4 matters. Restore the missing line when you're done — leave the project clean.
Goal: Build a standalone reset block using a custom block (My Blocks). Define a custom block called reset-all that contains every reset line. Then call reset-all from inside when ⚑ clicked on the Stage. Bonus: also call reset-all at the start of your when I receive (game-start v) handler so a mid-game "restart" works the same as a flag-click.
define reset-all
set [mode v] to (0)
set [current-player v] to (1)
set [score-p1 v] to (0)
set [score-p2 v] to (0)
set [q-index v] to (0)
set [turn-count v] to (0)
delete (all) of [asked v]
when flag clicked
reset-all
when I receive (game-start v)
reset-all
broadcast (begin-quiz v)
reset-all custom block is now the single source of truth — if you add a variable, you add it in one place. Two callers, identical behaviour.Think: Naming your reset routine and calling it from multiple places is the start of code reuse — the same idea that powers libraries, frameworks, and every shared Scratch utility. One name, many callers. Whenever you find yourself writing the same five blocks twice, ask: should this be a custom block?
Mini-Challenge — the project that "works" but doesn't 5 min
"Wei Han's shared platformer"
Wei Han uploaded his platformer from SCR-L04-24 to scratch.mit.edu. He tested it himself five times before sharing and it played perfectly. Now his comments page has three messages:
- "I clicked the flag and the cat was already at the boss fight??"
- "How do I jump?? I tried every key and nothing happens"
- "Game says I won but my score is 0??"
Wei Han is confused. The game works on his machine. Which checklist items did he skip, and what's the smallest fix for each comment?
Reveal one valid solution
One missed item per comment.
Comment 1 (boss-fight start) — Wei Han missed item 4 (green-flag resets). His last test session ended on level 3, so level was 3 when he saved. New players click the flag and the level loader sees level = 3 and jumps straight to the boss. Fix: add set [level v] to (1) at the top of the Stage's flag-click reset.
Comment 2 (how to jump) — Wei Han missed item 5 (document the controls). His instructions said "play the game" but never said "spacebar to jump". Fix: open the Instructions panel and add "Controls: arrow keys to move, spacebar to jump."
Comment 3 (winning with 0 score) — Wei Han missed item 6 (fresh tester). His own playtests always picked up coins along the way out of habit, so he never noticed that the win-screen never checks whether the player actually has any coins. A fresh tester just ran past every coin and still won the boss fight. Fix: either change the win-screen to display the score honestly (no congratulations if score = 0) or — better — make a minimum-score gate that requires at least one coin to access the boss room.
The rule: sharing without the checklist is a public bug-discovery event. Sharing with the checklist makes your project page look professional from minute one.
Recap 3 min
You met the 30-minute routine that separates polished shared projects from embarrassing ones. The 7-point pre-share checklist runs in order: name, instructions, credits, green-flag resets, controls, fresh-tester pass, playtime check. The technical heart is item 4 — the green-flag reset pattern, where every variable, list, sprite position, costume, and visibility is set to its starting value inside when ⚑ clicked. The one exception is high-score, which is meant to persist. Run the checklist in order, every time, before you click Share. Half an hour now saves you a week of confused comments later.
- Pre-share checklist
- The 7-point routine — project name, instructions, credits, green-flag resets, controls documented, fresh-tester pass, no infinite-loop trap — to run on every project before clicking Share on scratch.mit.edu.
- State leak
- A value that survived from one play session into the next, because no script reset it on the green flag. State leaks are the #1 source of "works on my machine" bugs.
- Green-flag reset pattern
- The script at the top of every game that runs on when ⚑ clicked and sets every variable, list, sprite position, costume, and visibility back to its starting value. The single most important fix to apply before sharing.
- Fresh tester
- A person who hasn't seen your project, sitting at the keyboard while you watch without helping. Ten minutes of fresh-tester observation finds bugs that your own testing can never find — because you know how the game is "supposed" to be played.
- Cloud-vs-local persistence
- Most Scratch variables reset when the project file is reloaded. Cloud variables (☁ prefix) and explicit save patterns (like the L04-39 high-score routine) persist across sessions. Knowing which is which prevents accidentally resetting your high score.
- "Works on my machine"
- The classic software-engineer's excuse — the project ran fine in the developer's hands but broke for everyone else. The pre-share checklist is the cure.
Homework 2 min
The Checklist Pass. Take any two projects you have lying around — your trivia quiz from L04-41, your platformer from L04-24, an old project from Level 3, anything — and run the full 7-point checklist on both.
- For each project, write a short table in your notebook with columns "Item #", "Pass/Fail", "What I changed". Seven rows per project.
- Where you fail item 4 (green-flag resets), fix the script and re-save. Where you fail items 1, 2, 3, or 5 (project page metadata), update the Scratch project page.
- For item 6 (fresh tester), ask the same family member to play both projects. Watch where they get stuck for each one.
- Set both projects to Shared.
- Re-save the polished
.sb3files asHW-L4-42-Project-A-Polished.sb3andHW-L4-42-Project-B-Polished.sb3.
Bring back next class:
- Both shared Scratch URLs.
- Both checklist tables from your notebook.
- Your answer to: "Which of the 7 items did you fail most often across both projects? Why do you think that's your weak spot, and what habit will you build to stop missing it?"
Heads up for next class: SCR-L04-43 — Project Notes & Credits zooms in on items 2 and 3 of today's checklist. You'll learn the templates for great Instructions panels (goal, controls, tips) and great Credits sections (sprites, sounds, music, inspiration), with examples from professional-looking Scratch projects. Bring one of your polished projects from today — we'll rewrite its notes panel together as the worked example.