Year 6 Scratch Guide › Week 5 › Week 6 — Persisting State & Final Project
Week 6 of 6 · Final Lesson

Persisting State & Final Project

Today you bring it all together: a proper menu screen, game-over screen, a state machine that controls the whole game, and a cloud high score that saves between sessions.

1
2
3
✓
4
5
✓
6
7
🏆
1
Plan your game screens on paper first
Every professional programmer plans before coding — so should you

Before touching Scratch, take a piece of paper and draw three boxes:

  1. Box 1 — Menu screen: What does it say? (e.g. "Press SPACE to start") What is the background?
  2. Box 2 — Game screen: Where are the sprites? What shows on the stage?
  3. Box 3 — Game over screen: What does it say? Does it show the score?
  4. Draw arrows between the boxes: what triggers each transition? (e.g. "press SPACE" or "lives = 0")
  5. Write down the variable names you will need: gameState, score, lives.
👀 Why plan first?

When you know exactly which screens exist and what connects them, the code almost writes itself. Programmers call this a state diagram — it is a real technique used in the games industry.

2
Add three backdrops
One backdrop per screen: Menu, Game, Game Over
  1. Click the backdrop square at the bottom-right of the stage.
  2. Click the Paint button to create a new backdrop.
  3. Design a simple Menu backdrop: e.g. a coloured background with the game title. Name it exactly Menu (click the backdrop name and rename it).
  4. Create a second backdrop for the Game screen — this can be your existing game background. Name it Game.
  5. Create a third backdrop for Game Over — add text saying "Game Over". Name it GameOver (no space).
  6. Click on each backdrop in the list on the left to check they all have the correct names.
⚠️ Watch out!
  • The exact name matters. Your code will say "switch backdrop to [Menu]" — if the backdrop is named "menu" (lowercase) or "Menu Screen", it won't match. Use the exact names: Menu, Game, GameOver.
  • To rename a backdrop: click the Backdrops tab, click on the backdrop name in the panel on the left, and type the new name.
  • If you accidentally paint on the wrong backdrop, press Ctrl + Z to undo.
3
Create the "gameState" variable and initialise everything
gameState tells the program which screen it is currently on
  1. In the Variables section, create a new variable called gameState (For all sprites).
  2. On your main/player sprite, find or create the flag-clicked script.
  3. Make sure the flag-clicked script sets ALL starting values:
// Flag clicked — master initialiser
when 🚩 clicked
  set [gameState] to "menu"
  set [score] to 0
  set [lives] to 3
  switch backdrop to [Menu]
⚠️ Watch out!
  • The string "menu" in the gameState block is just a label — any word works, but you must use the exact same word everywhere you check it. Stick to lowercase throughout.
  • If the game starts in the wrong place (e.g. on the Game screen instead of Menu), check this flag-clicked script runs first and "switch backdrop to [Menu]" is there.
🔍 Check Your Progress — After Step 3
  • Three backdrops exist: Menu, Game, GameOver — names spelled exactly
  • The gameState variable exists ("For all sprites")
  • Clicking the green flag switches to the Menu backdrop
  • Score and lives both reset on green flag
🆘 Something looks wrong?
  • Green flag doesn't switch to Menu backdrop: Check the "switch backdrop to" block is connected in the flag-clicked script and the name "Menu" matches your backdrop name exactly (capital M).
  • I can't see the three backdrops: Click the stage icon (not a sprite) in the Sprite Pane, then click the Backdrops tab at the top. You should see all three listed on the left.
  • gameState variable is not appearing: Make sure you created it in Variables → Make a Variable, chose "For all sprites", and typed the name correctly.
4
Build the Menu screen transition
Wait on the menu until the player presses SPACE, then start the game
  1. On your main sprite, add a new script:
  2. when backdrop switches to [Menu] (from Events — use the dropdown).
  3. Add wait until <key [space] pressed?> (Control → wait until, then put Sensing's "key space pressed?" into it).
  4. After the wait: set [score] to 0 and set [lives] to 3 again — resetting for a new game.
  5. Then: set [gameState] to "playing".
  6. Finally: switch backdrop to [Game].
  7. Test: press flag, the Menu screen appears. Press SPACE — does it switch to the Game backdrop?
👀 What you should see

After clicking the flag, the stage shows your Menu backdrop. Pressing SPACE switches to the Game backdrop and the game begins.

⚠️ Watch out!
  • The key [space] pressed? sensing block goes inside the hexagonal slot of the wait until block — not snapped below it.
  • If SPACE immediately skips the menu without waiting, you may have a key-pressed event block already running on the player sprite from earlier lessons. Check for a stray "when space key pressed" script and remove it.
  • The "when backdrop switches to" block is in the Events section — scroll down past the other event blocks to find it.
5
Handle the Game Over screen
When "game-over" is broadcast, switch backdrop and stop scripts
  1. On your main sprite, add a script: when I receive [game-over].
  2. First: set [gameState] to "gameover".
  3. Then: stop [other scripts in sprite] — this stops the game loop without stopping THIS script.
  4. Then: switch backdrop to [GameOver].
  5. Add a short pause then show the final score: wait 1 second → say (join [Final score: ] (score)) for 4 seconds.
  6. Test: play the game until lives = 0. Does the Game Over screen appear?
⚠️ Watch out!
  • Use stop [other scripts in sprite] — not stop [all]. "Stop all" would prevent this very script from finishing (it would never reach the "switch backdrop" or "say" blocks).
  • If the Game Over screen appears immediately when the game starts, your "lives" variable might not be initialising to 3. Double-check the flag-clicked script.
  • All sprites running game-logic scripts need to stop on game-over. Add when I receive [game-over] → stop [other scripts in sprite] to each sprite (coin, enemy, etc.).
🔍 Check Your Progress — After Step 5
  • Green flag → Menu screen, press SPACE → Game screen
  • Losing all lives → Game Over screen with final score displayed
  • gameState variable shows "menu", "playing", or "gameover" correctly
  • All sprites stop moving on game-over
🆘 Something looks wrong?
  • Sprites keep moving after game over: Each active sprite needs its own "when I receive [game-over] → stop [other scripts in sprite]" script. Check the coin/enemy sprites too.
  • The Game Over backdrop doesn't appear: Check the backdrop name in your switch backdrop block. It must be exactly GameOver — no space, capital G and O.
  • I get an immediate game-over when the game starts: One of your sprites might be broadcasting "game-over" at start-up, or lives is being set to 0 somewhere. Add a step-through: click the flag and watch which sprite says "game-over" first.
6
Add a cloud high score (teacher demo)
Cloud variables save to the internet and persist between sessions

Note: Cloud variables require a signed-in Scratch account. This step is demonstrated by the teacher — you can watch and understand how it works.

  1. In the Variables section, click "Make a Variable".
  2. Name it high score and tick "Cloud variable (stored on server)".
  3. Click OK. You will see a ☁ symbol on the variable name in the palette.
  4. In the game-over handler script, after stopping other scripts, add an if block:
// Check and update the cloud high score
if (score) > (☁ high score) then
  set [☁ high score] to (score)
end
⚠️ Watch out!
  • Cloud variables are public — anyone who runs your project can see and change them. Never store names, ages, or personal information in a cloud variable.
  • Cloud variables only store numbers. You cannot store words in them.
  • If you are not signed into a Scratch account, the ☁ option will not appear. Use your teacher's account for the demo.
  • Cloud variables update in real time across all players. If your teacher opens the same project in another browser, both will share the same high score!
7
Final project — polish and submit
Check everything works, customise your game, and share the link

Use this checklist to make sure your final game is complete:

  1. ☑ Menu screen — shows a title, waits for SPACE to start
  2. ☑ Keyboard-controlled player — all four directions work
  3. ☑ Collision detection — touching an enemy does something
  4. ☑ Score and lives — both reset on flag, both update during play
  5. ☑ Clones or collectibles — objects are created during gameplay
  6. ☑ Game over screen — appears when lives reach zero, shows score
  7. ⭐ Extension: high score saved using a cloud variable (teacher account)
  8. ⭐ Extension: a "level" variable that increases difficulty (speed up enemies per level)
👀 Final test checklist
  • Play the game from start to finish at least twice in a row — does everything reset correctly?
  • Ask a classmate to try your game without you explaining it. Can they figure out how to play?
  • Share the project link with your teacher.
⚠️ Before you share
  • Click the green flag one final time to confirm everything starts correctly from the Menu screen.
  • Make sure no debug variables (like "gameState") are visible on stage during gameplay — use hide variable [gameState] in your flag-clicked script.
  • Save your project: File → Save now. Name it "Week 6 — My Final Game".
🎓

You have completed the whole unit!

In six weeks you went from your first Scratch block to building a complete game with menus, collision detection, variables, clones, and persisting state. That is real programming — well done!