How to Make a Game on Scratch: A Step-by-Step Guide

Most children can drag blocks around Scratch within ten minutes. Finishing a game that somebody else actually wants to play is a different skill, and it is where the majority give up.

This guide shows you how to make a game on Scratch in eight steps, naming the exact blocks rather than describing them vaguely, so a child can follow it alone and know at each stage whether it worked. It also fixes the single most common piece of bad advice in Scratch tutorials, which is how to build a timer.

Everything here was checked against Scratch and the Scratch Wiki in October 2026.

What you need before you start

Scratch runs free in a browser at scratch.mit.edu and needs no installation. A free account is worth making straight away, because without one the project cannot be saved and an hour of work disappears when the tab closes. That single step prevents the most demoralising thing that can happen to a beginner.

The screen has four parts worth naming, because the rest of this guide refers to them: the block palette on the left, the code area in the middle, the stage top right, and the sprite pane under the stage.

Step 1: Write the plan down before opening Scratch

Three questions, on paper, in one minute. Who does the player control? What are they trying to do? How does the game end?

This is not a formality. The most common reason a child abandons a Scratch project halfway is that the game has no ending, so there is nothing to build toward and no moment where it is finished. "Collect ten apples before the timer runs out" is a complete specification. "A game about a cat" is not.

Step 2: Choose a backdrop

In the bottom-right corner, below the sprite pane, is the backdrop button. Choose one from the library, upload an image, or draw your own in the Paint Editor.

Pick something plain. A busy backdrop makes collisions genuinely hard to see, and a beginner debugging a game they cannot see is a beginner about to quit.

Step 3: Add your sprites

Click the round cat-face button in the bottom-right to open the sprite library. A chase game needs two sprites: the one the player moves, and the one they are chasing or avoiding.

Rename both immediately by clicking the sprite and editing the name field above the stage. Scripts that refer to Sprite1 and Sprite2 become unreadable within twenty minutes, and the touching block later in this guide reads much more clearly as touching Apple? than touching Sprite2?.

Step 4: Make the player move

Select the player sprite, then drag these blocks into the code area.

1. when green flag clicked, from Events. This is the hat block that starts everything.
2. forever, from Control, attached beneath it.
3. Inside the forever loop, four if <> then blocks from Control.
4. Into each one, drop key (right arrow) pressed? from Sensing, and set each to a different arrow key.
5. Inside each if block, add change x by (10) or change y by (10) from Motion, with the right sign for that direction.

You know it worked when holding an arrow key moves the sprite smoothly rather than one hop per press.

That last point is the reason for this structure. Scratch also offers a when (right arrow) key pressed hat block, which is simpler, but it repeats at the keyboard's own repeat rate and produces a stutter. Checking the key inside a forever loop gives smooth movement, and it is the pattern every real game uses.

Step 5: Add a score

Open the Variables palette and click Make a Variable. Name it Score and leave it set to "for all sprites".

On the sprite being collected, build this script:

1. when green flag clicked, then set Score to (0). Resetting at the start matters, otherwise the score carries over from the previous game.
2. forever, and inside it if <touching (Player)?> then from Control and Sensing.
3. Inside that: change Score by (1), then go to random position from Motion.

You know it worked when touching the sprite makes the score tick up once and the target jumps elsewhere.

Step 6: Add a timer that does not drift

This is where most Scratch tutorials give bad advice, so it is worth doing properly.

The common instruction is to make a variable called Timer, set it to 60, and then loop wait (1) seconds followed by change Timer by (-1). It looks correct and it is wrong. A wait (1) seconds block does not take exactly one second, because the time spent running the rest of the script is added on top. Over sixty repeats the error accumulates, and a sixty-second countdown can finish several seconds late.

Scratch already solves this. The Sensing palette holds a timer reporter, which reports the time in seconds since the project loaded or since the timer was last reset, and it keeps running on its own. Use it:

1. Under when green flag clicked, add reset timer from Sensing.
2. Add a forever loop containing if <(timer) > (60)> then.
3. Inside that, add stop (all) from Control.

To show the countdown rather than the count up, make a variable called Time Left and set it inside the loop to (60) - (timer) using the subtraction block from Operators.

You know it worked when the game stops at sixty seconds measured against a real clock. We go through the same correction in more depth in our guide to making a timer in Scratch.

Step 7: Add sound and feedback

A game with no response to the player's actions feels broken even when it works. Two blocks fix that.

Use say (Nice) for (1) seconds from Looks when the player scores, and add start sound (Pop) from Sound in the same place. The Sound tab at the top left holds a library, and sounds can also be recorded directly.

Keep the say duration short. A two-second message inside a fast game blocks the script while it displays, which beginners read as a freeze.

Step 8: Test after every change, not at the end

Click the green flag after each block you add, not once at the end. A child who builds for forty minutes and then tests has to search forty minutes of work for the fault. A child who tests every two minutes always knows the problem is in the last thing they touched.

Three questions find most faults: does the sprite move correctly, does the score change exactly once per collision, and does the game stop when it should. If something misbehaves, read the script aloud as a sentence. The step that does not make sense when spoken is almost always the broken one. Our guide to teaching children to debug covers the method properly.

The three mistakes beginners always make

The third one is the most instructive. The script is running many times a second, so a sprite that stays in contact for half a second scores repeatedly. The fix is not more code, it is removing the condition that keeps being true. That idea comes back constantly in programming.

What to build next

Once a chase game works, the natural progression is to add a second level, then an enemy that moves on its own, then a start screen. Each one introduces one new idea rather than many, which is what keeps a child finishing projects instead of abandoning them.

Our guide to Scratch projects by age group suggests what to try next, and the Scratch curriculum progression guide sets out the longer sequence. When a child starts finding Scratch itself restrictive rather than the projects too easy, this is how to tell they are ready to leave Scratch.

You can also see how a structured sequence works in our Scratch coding classes for kids.