Scratch sits at the centre of most primary computing schemes, and the blocks themselves are not difficult. The harder part is the distance between reading the unit plan and feeling ready to teach it on Tuesday morning. What usually closes that gap is a worked example you have built yourself, start to finish, so you already know where children will get stuck.

This tutorial walks through a complete game: a mouse the player controls, apples to collect, a score that goes up, and a bat that chases the mouse until it catches it. Fifteen minutes to build. It covers sequence, selection, repetition and variables along the way, and everything in it is free and runs in a browser.

Play the game, and see the code here https://scratch.mit.edu/projects/1380189102/

Getting set up

Head to scratch.mit.edu and make a free account before you start. The account matters more than it first appears. Without one nothing saves, and a class that loses its work at the end of a lesson will not be keen to start again next week.

Once you click Create, you are looking at three areas. The block palette on the left holds every command available. The stage on the right shows your sprites. The code area in the middle is where you assemble the blocks that make things happen.

Get into the habit of checking which sprite you are coding, and get the children doing the same. The outline of the selected sprite appears in the top corner of the code area. Almost every “it isn’t working” moment in a Scratch lesson comes down to code sitting on the wrong sprite.

Making the hero move

Delete the cat and choose a mouse from the sprite library. Before adding any code, spend a minute on coordinates, because this is where a lot of the underlying maths sits. X and Y set the sprite’s position. 0,0 is the centre of the stage, X increases to the right and decreases to the left, and Y increases upwards and decreases downwards. Typing values straight into the X and Y boxes and watching the sprite jump around the screen makes this concrete far faster than explaining it does.

The movement code is a green flag block, a forever loop, and four if statements inside it. If W is pressed, change Y by 5. If S is pressed, change Y by minus 5. If D is pressed, change X by 5. If A is pressed, change X by minus 5. You only need to build the first one. Right click and duplicate gives you the other three, and swapping the key and the value is quicker than starting again. Add a “go to X 0 Y 0” block at the top so the mouse resets to the centre each time the game starts.

To make the mouse look like it is walking, add a second green flag script with a forever loop containing “next costume” and a wait of 0.5 seconds. Point out here that a sprite can run several separate scripts at once. They all start on the green flag, and they do not need to be joined together.

Then paint a background. The stock backdrops are busy for a game like this, so a single block of colour from the paint editor works better.

Something to collect, and a score

Add an apple sprite, set its size to 50%, and give it a starting position. Then add a forever loop with an if statement inside: if touching the mouse, go to a random position. Test it, and the apple should jump away each time the mouse reaches it.

The score is where the computing concept sits. Make a variable called Score, available to all sprites. Set it to 0 when the green flag is clicked, and change it by 1 inside the same if statement that moves the apple. Define a variable plainly for children: it is a labelled box in the computer’s memory that holds a number, and your program can look inside it, change it, or reset it whenever you like. Once that idea lands, timers, lives and high score tables all become available to them without much further teaching.

Add a sound at this point too. Most of the fruit sprites come with a chomp sound already attached, and a start sound block inside the if statement gives immediate feedback when the apple is eaten.

Finish the apple completely before you duplicate it. This one matters, and it is worth saying out loud to a class. Duplicate first and then spot a mistake, and you are fixing it on every copy. Once the code is right, duplicate the apple twice and give each one a different starting position.

Adding the chase

The bat follows the same pattern again. Set a starting position and size, then a forever loop containing “point towards mouse” and “move 2 steps”. Ten steps is far too fast to be playable. Add “set rotation style to don’t rotate” at the top, or the bat tilts alarmingly as it turns.

A second forever loop watches for the bat touching the mouse. Inside it, broadcast a message called “died”, then stop all. The order matters, and it makes for a useful debugging conversation. If stop all comes first, the broadcast never happens and the message never appears.

For the message itself, paint a new sprite using the text tool and type Game Over. Give it two scripts: hide when the green flag is clicked, and show when it receives “died”. Play it through and the words appear at the moment the bat catches the mouse.

Where to take it next

The finished game is a starting point rather than a destination. Children can duplicate the bat for a second enemy, add a countdown timer, build a lives variable, or set the apples to appear in random positions at the start of every game. Because they already understand the structure, those extensions become programming decisions rather than copying from the board.

Classroom Application: Three Steps

  1. Build it yourself before you teach it. Fifteen minutes with this game tells you where children will struggle: coding on the wrong sprite, forgetting the reset blocks, getting the order wrong inside the if statement. Far more useful than any set of teacher notes.
  2. Teach coordinates before you teach movement. Give children five minutes to type numbers into the X and Y boxes and watch what happens. The movement code makes much more sense afterwards, and you are reinforcing maths at the same time.
  3. Stop the class at the variable. When you add the Score variable, pause and make the concept explicit. Variables are the part children most often use without understanding, and two minutes here pays off across the rest of the unit.

This sits comfortably within the KS2 computing expectation that pupils design, write and debug programs using sequence, selection and repetition, and work with variables and various forms of input and output.

For more Scratch tutorials, check out my YouTube Channel.