Resetting Variables on Start — Scratch L2

Where this arc is heading: hit the green flag and the HUD always snaps to score 0 and lives 3 — never haunted by the last round. The reset block is the spine of every replayable game.

Learning Goals 3 min

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

Place set [score v] to (0) and set [lives v] to (3) as the first blocks under when ⚑ clicked in every game project.
Explain why a variable keeps its value between flag clicks until something forces it back — and why that's a bug for games.
Use the right block for the job: set when you know the exact target value, change when you want to add or subtract from whatever's already there.

Warm-Up — Priya's second game 7 min

Priya built a simple catch-the-kuih game last week. She has a score variable, and every time the cat catches a piece of kuih lapis, she does:


when this sprite clicked
change [score v] by (1)

Click the kuih, score goes up. Simple.

Priya plays a round. She catches 17 pieces. Score watcher reads 17. She clicks the green flag to start a new round.

What does the score watcher show now?

Reveal the answer

It still reads 17. Clicking the green flag does not reset variables. Scratch only resets variables when you close and reopen the project, or when something in a script tells it to. Priya's "new game" started with last game's score already on the board.

Worse: imagine a lives variable that ended last game at 0. New flag click → still 0 → game-over fires before the player has even moved.

The fix is one block at the top of one stack — and once you start using it, you'll never not use it again.

New Concept — the reset block at the top 15 min

Variables are sticky. Whatever value they end on, they keep — through the next flag click, through hitting the red stop sign, through everything except closing the project. That's actually useful sometimes (a "best lap time" should stick across games). But for almost every variable in a game, you want each round to start the same way.

The rule

Every variable that needs a known starting value should be set as the first thing the green-flag script does. Not somewhere in the middle. Not inside the forever loop. The very first blocks, right under the hat.


when flag clicked
set [score v] to (0)
set [lives v] to (3)
forever
  ...game stuff...
end

The reset block. Two sets before any other code runs. Every game in this course will start this way.

Why the top?

Scratch runs blocks in order from top to bottom. If you put the set after some game logic, the game runs for a moment with last round's value before the reset happens. By that time, an enemy may have already collided, a score may have already updated, a game-over may have already fired. Putting the resets first guarantees nothing game-related runs until variables are clean.

set vs change — the most-confused pair

These two orange blocks look almost identical, and they do completely different things:

set [score v] to (0) — forces the variable to be exactly 0, no matter what it was before.
change [score v] by (1) — adds 1 to whatever the variable already holds.

For resets, you almost always want set. change is for during the game (add a point, lose a life). If you accidentally write change [score v] by (0) at the top of your script thinking you're resetting, the score doesn't move from 17 — adding zero changes nothing.


set [score v] to (0)

Reset: score becomes 0, no matter what it was.


change [score v] by (1)

Increment: score becomes (whatever it was) + 1. Use during gameplay, not at the start.

What needs resetting?

Every game is different, but the usual suspects are:

score → set [score v] to (0)
lives → set [lives v] to (3) (or 5, or whatever you start with)
level → set [level v] to (1)
game over → set [game over v] to [no]
timer → set [timer v] to (60)

If your project has a variable and you're not sure whether to reset it — reset it. The cost is one extra block. The cost of not resetting is a bug that only appears on the second play-through.

Common mistakes

Putting the resets inside forever. Now the score gets slammed back to 0 every frame and you can never score a point. Resets go above the forever, not inside it.
Using change instead of set. change [lives v] by (3) adds 3 to whatever was there — first game starts at 3, second at 6, third at 9. Always set for resets.
Resetting on the wrong sprite. A global variable like score can be reset by any sprite, but the convention is to reset it on the Stage or on the player sprite. Pick one place and stick to it — two reset scripts firing at the same time confuse no-one but you'll forget which one to edit later.
Forgetting that watchers update instantly. The moment your reset runs, the Stage watcher snaps to the new value. Players see "17 → 0" as the flag click happens. That's actually a feature — it tells the player "new game starting".

Worked Example — Daniel's coconut catcher 12 min

Build a tiny score-and-lives skeleton with proper resets. Seven steps.

Stage plan. The player cat (the only sprite you script — see the ✏️ badge) carries the reset stack. The two watchers show their starting values: every green flag forces them back to 0 and 3.

Step 1 — Start fresh

New Scratch project. Keep the cat for now. The cat will be the player.

Step 2 — Make two globals

Open Variables. Click Make a Variable. Name: score. Leave For all sprites ticked. OK. Repeat for lives. Both watchers appear on the Stage.

Step 3 — Add the reset stack on the cat

On the cat sprite, build:


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

Three blocks. Click the flag — both watchers slam to 0 and 3.

Step 4 — Click the flag and check

Score watcher: 0. Lives watcher: 3. Click the flag again — same thing. Click it ten more times — still 0 and 3. The reset is doing its job.

Step 5 — Fake some gameplay

Add a second script under the same hat to simulate scoring: press space to gain 1, press x to lose 1 life.


when flag clicked
forever
  if <key [space v] pressed?> then
    change [score v] by (1)
    wait (0.2) seconds
  end
  if <key [x v] pressed?> then
    change [lives v] by (-1)
    wait (0.5) seconds
  end
end

Mash space — score climbs. Tap x — lives drop. (Real games trigger these from collisions; we use keys for testing.)

Step 6 — Play a round, then re-click the flag

Get the score to 8 and lives to 1. Now click the flag again. Watch the watchers: they jump back to 0 and 3 instantly. Without the reset stack, they'd still read 8 and 1.

Step 7 — Comment out the resets to see the bug

Drag the two set blocks out of the script (don't delete them — Scratch keeps them off to the side). Click the flag. Play a round. Click the flag again. The watchers still hold last round's values. Snap the set blocks back in — bug fixed.

The full assembled stacks


when flag clicked
set [score v] to (0)
set [lives v] to (3)
forever
  if <key [space v] pressed?> then
    change [score v] by (1)
    wait (0.2) seconds
  end
  if <key [x v] pressed?> then
    change [lives v] by (-1)
    wait (0.5) seconds
  end
end

One hat. Two resets at the top. One forever underneath. The two resets always come first, before the forever — that's the whole pattern.

What you just built: the spine that every Scratch game in the rest of this course will use. Reset, then loop, then react.

Try It Yourself — three reset drills 15 min

🟢 Easy

Goal: Make a variable called clicks. Build a tiny clicker — every time the cat is clicked, clicks goes up by 1. Add a reset stack so every new flag click starts clicks at 0.


when flag clicked
set [clicks v] to (0)

The reset.


when this sprite clicked
change [clicks v] by (1)

The increment. Two separate hat blocks on the same sprite.

Think: Click the cat ten times. Click the green flag. Score zeros. Click the cat again — counting from zero. Tiny project, big lesson.

🟡 Medium

Goal: Build a three-variable reset on the Stage. Reset score to 0, lives to 3, and level to 1. Show all three watchers on the Stage so you can see them snap into place every time you click the flag.


when flag clicked
set [score v] to (0)
set [lives v] to (3)
set [level v] to (1)

A reset stack on the Stage. Many games put resets on the Stage because it's neutral — not tied to any one sprite.

Think: Click the Stage thumbnail in the sprite list to add a script to the Stage. The Variables palette only shows globals there, because the Stage can't own locals.

🔴 Stretch

Goal: Add a "high score" feature. score resets every flag click. high score does not — it keeps its value across rounds. Inside the gameplay forever loop, check if score is bigger than high score; if so, copy it over. This mixes a reset variable with a non-reset variable.


when flag clicked
set [score v] to (0)
forever
  if <key [space v] pressed?> then
    change [score v] by (1)
    wait (0.2) seconds
  end
  if <(score) > (high score)> then
    set [high score v] to (score)
  end
end

score is reset on flag. high score is not — it survives across rounds, only updated when a new score beats it.

Think: Notice high score doesn't appear in the reset block. That's deliberate. Some variables should survive between games — high scores, total coins ever collected, unlocked levels. Knowing which to reset and which not to reset is a real design choice.

Mini-Challenge — the lives that won't refill 5 min

"Aisyah's vanishing lives"

Aisyah is building a snake game. Her player starts with 3 lives. She writes this on the snake sprite:


when flag clicked
forever
  set [lives v] to (3)
  if <touching [wall v] ?> then
    change [lives v] by (-1)
    wait (1) seconds
  end
  if <(lives) = (0)> then
    stop [all v]
  end
end

Aisyah's script. She thinks the set [lives v] to (3) at the top of the forever is her reset.

She plays. The snake hits a wall. lives drops to 2. Half a second later, it's back to 3. She can never die. Why?

Reveal one valid solution

The set [lives v] to (3) is inside the forever loop, so it runs many times a second — re-resetting lives back to 3 before the game-over check has a chance to fire. The reset has to live above the loop, not inside it.


when flag clicked
set [lives v] to (3)
forever
  if <touching [wall v] ?> then
    change [lives v] by (-1)
    wait (1) seconds
  end
  if <(lives) = (0)> then
    stop [all v]
  end
end

One block moved up one slot. The reset now happens once when the flag is clicked, and then the forever can do its damage-and-game-over thing. The position of a block isn't decoration — it's logic. Inside vs outside the C-block is everything.

Recap 3 min

Variables in Scratch are sticky — whatever value they end on, they keep until something forces them back. Every game needs a reset stack: a column of set blocks right at the top of the green-flag script that puts every gameplay variable back to its starting value. The placement matters: above the forever, not inside it; before any gameplay block, not after. Use set to force a known value; use change only when adjusting a running value during play. Get the reset right and every "new game" actually starts new — get it wrong and the second game is always haunted by the first.

Reset: The act of forcing a variable back to a known starting value, usually with set. Almost always done at the top of a when ⚑ clicked stack.
set: set [name v] to (value) — replaces the variable's contents with the exact value you provide. The right block for resets.
change: change [name v] by (value) — adds the value to whatever the variable already holds. The right block for during-play updates (score going up, lives going down).
Starting value: The value a variable should hold when a fresh game begins. Decided by the designer (you), enforced by the reset block.
Sticky variable: A variable that should survive across rounds — high score, total coins, unlocked levels. You deliberately don't include it in the reset stack.

Homework 2 min

The Reset-First Audit. Open any one game project you've made in the last few weeks — pick the buggiest. Audit its variables.

For each variable, write down: name, what it tracks, what value a fresh game should start with.
Add a when ⚑ clicked stack to the Stage (or your main player sprite) with a column of set blocks — one for every variable that needs a starting value.
If a variable should survive across rounds (high score, best time), don't include it. Note next to its name why you're leaving it out.
Play two rounds in a row without closing the project. Confirm the resets fire — watchers should snap back to the starting values on the second flag click.
Build a fresh new project: a mini "tap the cat" game. Cat moves to a random spot every 2 seconds; clicking the cat adds 1 to score. Reset score to 0 at the top of the cat's flag-click stack.

Save as HW-L2-35-Reset-Audit.sb3.

Bring back next class:

The audited .sb3 file (or screenshot of the reset stack you added).
The mini tap-the-cat .sb3 file.
Your answer to: "Name one variable from your audit that you decided not to reset. Why?"

Heads up for next class: SCR-L02-36 is the cluster's project lesson. You'll combine reset blocks, two variables (score and lives), watcher widgets, and a click-to-score sprite into one tiny complete game.