How to Make a Title Screen and Menu in Scratch

Most first Scratch games drop you straight into the action with no way back, which makes them feel like a prototype rather than a finished thing. A title screen fixes that in an afternoon. It gives players a moment to settle, a clear start button, and somewhere to put instructions, a high score or a credits line. It also forces you to think about game state, which is a skill every larger project needs. This guide walks through building a title screen and a small menu in Scratch using backdrops and broadcasts, the two tools that do almost all of the work.

Think in states before you place a sprite

A game with a title screen has at least two states: the menu and the game itself. The single most common beginner mistake is letting both run at once, so enemies move while the title is still showing. Decide up front that only one state is active at a time, and that switching between them happens through a clear signal rather than by accident. In Scratch that signal is a broadcast message. Sketch the states on paper first, even just two boxes with an arrow labelled start between them. Five minutes of planning here saves an hour of chasing sprites that will not stay hidden when they should.

Build the title backdrop

Open the stage and add a new backdrop for your title. Keep it simple: a background color or image, the game name in large readable text, and a short line telling the player what to do, such as click start. Resist the urge to crowd it. A title screen is a doorway, not a poster, and white space makes the start button obvious. Name this backdrop title and give your actual game its own separate backdrop with a clear name too. Naming backdrops properly now means your scripts can say switch to the game backdrop in plain language instead of relying on a number you will forget.

Add a start button that broadcasts

Create a button sprite with the word start on it and place it on the title screen. Give it a script that runs when this sprite clicked, and have it broadcast a message named start game. That broadcast is the whole mechanism: one clean signal that every other sprite can listen for. Keep the button script short. Its only jobs are to broadcast start game and to hide itself so it does not sit on top of the gameplay. If you want a little polish, make the button change costume or grow slightly when the mouse touches it, so players can tell it is clickable before they even press.

Make every sprite react to the signal

Now teach the rest of the project to obey the state. At the start of the project, each gameplay sprite should hide, and the stage should switch to the title backdrop. When the start game broadcast fires, those same sprites show themselves, move to their starting positions and begin their behavior. Your player character, enemies, score and timer all wake up on that one message. This pattern keeps the title screen clean, because nothing gameplay-related does anything until the signal arrives. It also scales: when you later add a game over screen, you just broadcast a different message and have everything react to that instead.

Add simple menu options

A menu is just a title screen with more than one button. Common extras are an instructions button, a toggle for sound, and sometimes a difficulty choice. Each one is a sprite with its own clicked script. Instructions can switch to a separate backdrop with the controls written out and a back button that returns to the title. A sound toggle can flip a variable named sound on that your other scripts check before playing a clip. Keep the menu to the two or three choices a small game actually needs. A tidy menu with three working buttons beats a crowded one where half the options do nothing.

Show scores and persist with a variable

A title screen is the natural home for a high score. Make a variable named high score and set it to update whenever a run beats the old best, then display it on the title backdrop. For a project shared on the Scratch site, a cloud variable can remember the best score across players, though cloud variables only store numbers and have real limits worth reading about before you rely on them. For a single-player game, an ordinary variable is plenty. Showing the best score on the title gives returning players a reason to press start again, which is exactly what a menu is for.

Test the full loop and polish

Play the whole cycle as a stranger would. Start the project cold and confirm the title shows with nothing else moving. Click start and check that every sprite appears and behaves. Reach the end of a run and make sure the project returns to the title cleanly rather than freezing or leaving ghosts on screen. Only once that loop is solid should you add polish: a short sound when the menu opens, a gentle animation on the title text, a fade between states. Polish is worth doing last, because a beautiful title screen attached to a broken state machine is still a broken game.

Frequently asked questions

Do I need separate sprites or separate backdrops for the menu? Both, used together. The backdrop sets the scene for each state, while buttons are sprites with their own click scripts. Backdrops handle the look of the title and game screens; sprites handle the things players interact with on top of them.

How do I stop gameplay from running during the title screen? Have every gameplay sprite hide and do nothing at the start of the project, and only begin moving when they receive the start game broadcast. If something still moves on the title, its script is probably running on green flag instead of waiting for the broadcast.

Can a title screen remember the high score between plays? A normal variable remembers it within a single play session. To keep a best score across visits by different players on the Scratch site, you need a cloud variable, which stores numbers only and has limits on how often it can be written.

A doorway worth building

A title screen turns a loop of code into something that feels like a game you made on purpose. The real win is not the screen itself but the habit it teaches: one state active at a time, clean signals between them, and sprites that wait their turn. Carry that pattern into your next project and bigger features like pause menus, levels and game over screens stop feeling scary, because they are all the same trick again. Build the doorway once, understand why it works, and the rest of the house gets easier to frame.