ScratchBeginnersLearning Tips

How to Make a Start Screen and Game Over Screen in Scratch

Michael Murr··15 min read

Last updated: October 2026

This is how to make a start screen in Scratch the way real games do it: a title screen with a Play button, a game over screen with a Retry button that genuinely resets the game, and a pause menu that stops the action without throwing your progress away. The whole thing runs on one variable and a handful of broadcasts.

To have something to wrap the screens around, we will build a tiny dodging game as we go: a cat at the bottom of the stage, a rock falling from the top, and a score for every rock you dodge. By the end you will be able to start it, lose, retry and pause, and every screen will appear exactly when it should.

Parents: if you would rather your child builds this with a tutor beside them, that is exactly what my 1-on-1 Scratch lessons are for, and a free Discovery Call is where we start.

Table of Contents

What you need before starting

  • A Scratch account at scratch.mit.edu, so your project saves as you go.
  • Comfort with forever, if <> then and if <> then else.
  • Optional: the finished game, to compare against as you go. Download the project file, then in Scratch choose File, then Load from your computer. I built it from these exact steps and tested every checkpoint in the Scratch editor. It uses sprites from Scratch's own library.
  • Two ideas you do not need to know yet, because we build them here: variables and broadcasts.

Step 1: Paint three backdrops

Each screen in this game is a backdrop. Click the Stage in the bottom right corner, then open the Backdrops tab.

Your project already has one blank backdrop called backdrop1. Rename it Title, then pick the Text tool and write your game's name across it in big letters. Next, click Choose a Backdrop, pick anything you like for the game itself, and rename it Game. Finally, paint one more backdrop, write GAME OVER on it, and name it Game Over.

The names matter. Later blocks pick these backdrops from a dropdown by name, and backdrop2 tells you nothing when you are choosing in a hurry.

Checkpoint: the Backdrops tab lists three backdrops, named Title, Game and Game Over. Clicking each one shows it on the stage.

Step 2: Make a state variable and show the title screen

Here is the one idea that holds every menu together. At any moment, your game is in exactly one state: on the title screen, playing, paused, or over. Game programmers call this a state machine. In his book Game Programming Patterns, Robert Nystrom describes a finite state machine as one that can only be in one state at a time, and notes that state machines are common in navigating menu screens. That is exactly what we are building.

In Scratch, the state is just a variable. Open the Variables category, click Make a Variable, call it state, and leave it set to For all sprites. Make a second one called score the same way.

Leave both checkboxes ticked, so their values show on the stage while you build. Seeing state change as you play is the fastest way to catch a bug in this project. It is the same principle I use when teaching if statements: make the value you are testing visible before you test it.

Now give the Stage its first script:

when green flag clicked
set [state v] to [title]
switch backdrop to [Title v]

Checkpoint: click the green flag. The stage shows your Title backdrop, and the state display in the corner reads title.

Step 3: Build a tiny game that only moves while playing

The cat that came with the project is your player. Rename it Player in the sprite info panel. Then click Choose a Sprite and add Rocks from the library. Rename it Rock.

Give the Player these three scripts:

when green flag clicked
hide
forever
  if <(state) = [playing]> then
    if <key [right arrow v] pressed?> then
      change x by (6)
    end
    if <key [left arrow v] pressed?> then
      change x by (-6)
    end
  end
end

when I receive [reset v]
go to x: (0) y: (-140)
show

when I receive [title v]
hide

And give the Rock these three:

when green flag clicked
hide
forever
  if <(state) = [playing]> then
    change y by (-6)
    if <(y position) < (-170)> then
      go to x: (pick random (-220) to (220)) y: (170)
      change [score v] by (1)
    end
    if <touching [Player v]?> then
      broadcast [game over v]
    end
  end
end

when I receive [reset v]
go to x: (pick random (-220) to (220)) y: (170)
show

when I receive [title v]
hide

To make the reset, title and game over messages, click the dropdown on a when I receive or broadcast block and choose New message. The Scratch Wiki's page on broadcasts describes a broadcast as a message sent through the program that activates scripts with the matching hat blocks. One sprite sends it, and every sprite listening for it reacts.

Look at what both forever loops do first: they ask whether the state is playing, and only then move anything. That single check is what makes the rest of this tutorial possible. Pausing, game over and the title screen never need to stop a script. They just change the state, and the moving parts stop being allowed to move.

Checkpoint: click the green flag. Both sprites disappear, which is correct: the state is title, and neither of them belongs on the title screen. To test the game before the button exists, drag a broadcast [reset v] block into the Stage's code area and click it, then drag out a set [state v] to [playing] block and click that. The cat and the rock appear, the rock falls, the score goes up every time it reaches the bottom, and the arrow keys move the cat. Delete those two loose blocks when you are done.

Step 4: Add the Play button

Click Choose a Sprite and add Button2 from the library. In its Costumes tab, pick the Text tool and write PLAY on the button. Rename the sprite Play.

Give it two scripts:

when green flag clicked
go to x: (0) y: (-60)
go to [front v] layer
forever
  if <(state) = [title]> then
    show
  else
    hide
  end
end

when this sprite clicked
broadcast [start game v]

Notice that nobody tells the button when to appear. It watches the state and decides for itself: show on the title screen, hide everywhere else. Every button in this game will use this same pattern, which is why the rest go quickly. Hiding matters for another reason too. According to the Scratch Wiki, a hidden sprite cannot trigger when this sprite clicked, so a hidden button can never be pressed by accident.

Now give the Stage the script that actually starts a game:

when I receive [start game v]
switch backdrop to [Game v]
set [score v] to (0)
broadcast [reset v] and wait
set [state v] to [playing]

The order here is deliberate. broadcast [reset v] and wait sends the Player and the Rock back to their starting places, and the Wiki explains that this block waits until all scripts activated by the broadcast end. Only then does the state change to playing. So the game never starts moving from wherever things were left last time.

Checkpoint: click the green flag. You see the title screen with a PLAY button. Click it. The button disappears, the backdrop switches to Game, the cat appears at the bottom, the rock starts falling, the score counts up, and the state reads playing.

Step 5: Add the game over screen and a debug key

Add this to the Stage:

when I receive [game over v]
set [state v] to [over]
switch backdrop to [Game Over v]

The Rock already broadcasts game over when it touches the Player, so this works straight away. The state changes to over, every moving part freezes where it is, and the backdrop switches. Showing a game over backdrop is one of the example uses the Wiki lists for switch backdrop to.

Testing a game over screen by actually losing gets old fast, especially once a game gets harder. A teenage student of mine, building a much bigger game, triggered their death screen with a debug key, and the one change I suggested was to pick an uncommon key, so it would not clash with an "interact" key the game would need later. The same advice works in Scratch. Add this to the Stage:

when [0 v] key pressed
broadcast [game over v]

Why zero? Space, the arrow keys and letters like E are exactly the keys a game grows into as you add jumping, talking and picking things up. A number key rarely is. Delete this script before you share the game.

Checkpoint: click PLAY and let a rock hit you. The backdrop switches to Game Over, the cat and the rock freeze where they were, and the state reads over. Now click the green flag, click PLAY, and press 0 in the middle of the game. You should land on the same screen instantly.

Step 6: Make Retry go back correctly

Right-click the Play sprite in the sprite list and choose duplicate. Rename the copy Retry, change the word on its costume to RETRY, and in its forever loop change title to over. Leave when this sprite clicked exactly as it is.

That is the whole Retry button, and it works because Retry is just Play again. Both buttons send start game, and start game puts everything back: score to zero, cat and rock to their starting places, and only then the state to playing.

The most common Retry bug comes from doing that setup in the wrong place. If the rock's starting position lives under when green flag clicked instead of when I receive [reset v], Retry never moves it, because clicking Retry is not clicking the green flag. The rock is still sitting on the cat from the moment you lost, so as soon as the state flips back to playing, the rock touches the cat and you are straight back on Game Over. Anything that has to be fresh at the start of a game belongs under reset, not under the green flag.

Checkpoint: lose on purpose, or press 0. The Game Over screen shows a RETRY button. Click it. The score goes back to 0, the cat returns to the bottom middle, a fresh rock starts from the top, and the state reads playing. Do it three times in a row to be sure it holds.

Step 7: Add a pause menu that keeps your progress

This last step comes from a teenage student's own reasoning, and it is the best part of the build. In the game they were making, the Escape key sent the player straight back to the title screen. Pressing Play from there started a brand new game, and everything they had done was gone. They worked out for themselves that the real answer is a pause menu, with Continue, Options and Title Screen, laid over the game so it still shows through behind.

Scratch key blocks only offer letters, number keys, the arrow keys, space and "any", as the Wiki's page on the key pressed block lists, so there is no Escape. We will use P.

First, give the Stage a way back to the title screen from inside the game:

when I receive [title v]
set [state v] to [title]
switch backdrop to [Title v]

Next, build the tempting version of pause, so you can see the bug for yourself. Add this to the Stage:

when [p v] key pressed
broadcast [title v]

Click PLAY, dodge a few rocks, press P, then click PLAY again. Your score is back to 0. That is the exact problem the student ran into. Now delete that script and add the real one:

when [p v] key pressed
if <(state) = [playing]> then
  set [state v] to [paused]
end

That is all pausing is: changing the state. Every moving part already checks for playing, so everything freezes exactly where it is, score and all. The Game backdrop stays up, so the game shows through behind the menu.

Now the menu itself. Duplicate the Play sprite three more times and rename the copies Continue, Options and Menu. On their costumes, replace PLAY with CONTINUE, OPTIONS and TITLE SCREEN. TITLE SCREEN is longer than the others, so make its text smaller until it fits on the button. In each one's forever loop, change title to paused. Change the go to x: y: positions so they stack: Continue at y 60, Options at y 0, Menu at y -60.

Then replace each button's click script:

Continue:
when this sprite clicked
set [state v] to [playing]

Menu:
when this sprite clicked
broadcast [title v]

Options:
when this sprite clicked
say [Coming soon!] for (1) seconds

Look at the difference between the buttons. Continue only changes the state. It does not send start game, so nothing resets. Title Screen does reset, because the next time you press PLAY a fresh game begins, and that is fine now: quitting is a choice you made, not an accident.

Options does nothing yet, on purpose. A menu can exist before everything in it works. With a bare menu in place, you can check that every button shows and hides at the right moment, and fill in the options later. I teach older students building much bigger games the same order: a bare menu first, the functionality after.

Checkpoint: click PLAY and dodge a few rocks. Press P. Everything freezes, three buttons appear over the game, the score has not changed, and the state reads paused. Click CONTINUE, and the game carries on from exactly where it stopped with the same score. Pause again and click TITLE SCREEN: you are back at the title with a PLAY button, and pressing it starts a fresh game from 0. Finally, press P while on the title screen. Nothing should happen, because the state is not playing.

Where this breaks

A button is hidden behind the cat or the rock. Every button's green flag script includes go to [front v] layer for exactly this reason. Check that it made it into each duplicate, above the forever loop, then click the green flag again.

A button never appears. The word in its if <(state) = [paused]> block has to match the word in set [state v] to [paused] exactly. One typo, like pasued, and the button waits forever for a state that never comes. With the state display on the stage, you can see the real value and compare.

PLAY works but nothing moves. The state never reached playing. Check that the Stage's start game script ends with set [state v] to [playing], and watch the state display when you click.

Retry lands you straight back on Game Over. Something is still being set up under the green flag instead of under when I receive [reset v]. Step 6 explains why that breaks. Move it.

The debug key ships in the finished game. Delete when [0 v] key pressed before you share. Otherwise a player who leans on the keyboard gets a surprise game over and has no idea why.

Frequently Asked Questions

How do I make a title screen in Scratch without a button? Put when [space v] key pressed on the Stage, with if <(state) = [title]> then and broadcast [start game v] inside it. "Press space to start" works exactly like a Play button, as long as it only listens while the state is title.

What is a broadcast in Scratch? A message sent through the whole project that starts every script beginning with a matching when I receive block. One sprite sends it, and any number of sprites can react at once. That is why one click on PLAY can switch the backdrop, reset the score, move the cat and drop the rock together. If the same message is sent again while a receiving script is still running, the Wiki notes that the script restarts from the top.

Should screens be backdrops or sprites? Use backdrops for the picture behind everything, like your title art and the GAME OVER text, and sprites for anything the player clicks. Buttons need to be sprites, because only sprites can run when this sprite clicked.

What to build next

The easiest upgrade is a high score. Make a high score variable, and in the Stage's game over script add a check: if score is greater than high score, set high score to score. Do not reset it in start game, and it survives every Retry. Once a single rock works, Scratch clones can turn it into a whole shower of them.

After that, make Options real. A difficulty setting is a good first option: turn the rock's -6 into a speed variable, and let the Options screen choose between two values. And the same state variable drops straight into a bigger project. The Scratch platformer tutorial needs exactly these screens, and so does any of these projects for kids aged 8 to 10 that ends with winning or losing.

The pause menu in this post is a student's own solution, not mine, and it is better for it. Endi, a parent whose daughter started with Scratch, put that kind of learning well: "The challenges help you figure things out yourself." That is how my lessons run: I ask the question, then wait while your child finds the answer. Book a free Discovery Call and bring this game along.

This build comes from the kind of project I teach 1-on-1. I built the finished project from these exact steps and tested every checkpoint in the Scratch editor.

Enjoyed this article?

Your child can learn this and more with a dedicated 1-on-1 tutor.

Book a Free Discovery Call