How does a computer-controlled character know when to chase the player?
In this Scratch chase game, kids build a simple cat-and-mouse game where the player controls a mouse, collects cheese, and tries to stay away from a cat that changes its behavior based on distance.

The mouse uses the arrow keys to move around the room and collect pieces of cheese. Each piece increases the player’s score, while the cat continuously checks how far away the mouse is.
When the mouse is farther away, the cat uses a simple wandering behavior. Once the mouse gets within range, the cat switches into chase mode, points toward the mouse, and begins following it.
Get too close and the cat catches the mouse.
The player starts with three lives and needs to collect 10 pieces of cheese to win.

This project is a great way to introduce distance sensing, autonomous sprite behavior, keyboard input, random placement, variables, conditionals, Boolean logic, broadcasts, collision detection, and basic game AI in Scratch.
Play the Scratch chase game below, then click See Inside to explore the code.
Open or Remix the Scratch Chase Game →
How This Scratch Chase Game Works
The game has three main interactive pieces:
- The mouse, which is controlled by the player
- The cat, which moves independently
- The cheese, which appears at random locations
The player earns one point every time the mouse reaches the cheese.
The cheese then moves somewhere else on the Stage.
Meanwhile, the cat continuously checks its distance from the mouse.
If the mouse is far enough away, the cat follows its wandering behavior. If the mouse gets within 150 pixels, the cat switches to a chase behavior and points directly toward the mouse.
The closer the cat gets, the faster it moves.
If the cat touches the mouse — or comes within 15 pixels — the player loses a life.
The first goal is simple:
Collect 10 pieces of cheese before losing all three lives.
Behind that simple objective is a program where several independent systems are constantly sharing information.
Start the Mouse with a Score and Three Lives
When the green flag is clicked, the mouse establishes the player’s starting state.
The project:
show
set [Score] to 0
set [Lives] to 3
switch costume to [Mouse Right]
go to x: -212 y: -158
Then it enters a forever loop that handles movement, collisions, cheese collection, and the win condition.

Starting the variables at known values matters.
Without:
set [Score] to 0
set [Lives] to 3
the program would not have a reliable starting point for determining whether the player has won or lost.
Variables allow Scratch to store information that changes while the game is running.
In this game, Score answers: How many pieces of cheese has the mouse collected?
Lives answers: How many catches can the mouse survive?
Those values become part of the game’s decision-making later.
Move the Mouse with the Arrow Keys
The mouse uses four keyboard conditions inside the same forever loop.
Pressing the right arrow runs:
if <key [right arrow] pressed?> then
switch costume to [Mouse Right]
change x by 10
end
The left arrow changes x by -10 and switches to the left-facing costume.
The up and down arrows change the y-coordinate:
change y by 10
or:
change y by -10
This gives the player movement in all four directions.
The x-coordinate controls horizontal movement.
The y-coordinate controls vertical movement.
Positive values move the sprite right or up, while negative values move it left or down.
This is one of the simplest ways to turn Scratch’s coordinate system into player controls.
Change Costumes to Show Direction
The mouse does more than move.
When the player presses the right arrow, Scratch switches to the Mouse Right costume.
When the player presses the left arrow, it switches to Mouse Left.
That small visual change helps the sprite appear to respond naturally to the player’s movement.
It also demonstrates that costumes are not limited to animation sequences.
They can communicate state.
In this case, the state is: Which direction is the mouse facing?
Keep the Mouse on the Stage
The mouse also checks whether it reaches the edge.
When the sprite touches the edge, the game plays the Boing sound.
Scratch also uses:
if on edge, bounce
to keep the mouse from simply disappearing outside the Stage.
The room therefore becomes a contained play area.
That is an important game-design detail because player movement needs boundaries.
A sprite that can escape the visible Stage quickly makes a chase game difficult to play.
Collect Cheese to Increase the Score
The same mouse script checks whether the player reaches the cheese.
if <touching [Cheese Sprite]?> then
change [Score] by 1
play sound [Collect] until done
broadcast [moveCheese]
end
This combines three different game systems.
First, sensing detects the collision.
Then the Score variable stores the result.
Finally, a broadcast tells the cheese sprite to move somewhere else.
The player therefore receives both numerical and audiovisual feedback.
The score increases.
The collection sound plays.
The cheese disappears from its previous location and shows up somewhere new.
Use a Broadcast to Move the Cheese
The cheese sprite has its own custom block called: newCheese
When the green flag is clicked, the cheese runs that block.
It also listens for: moveCheese
When that broadcast is received, it runs newCheese again.
This means the mouse does not need to know how to position the cheese.
The mouse only needs to say: A piece of cheese was collected. Move the cheese.
The cheese sprite handles the rest. This is a great reason to use broadcasts.
One sprite announces that something happened, while another sprite decides how to respond.
Place the Cheese at a Random Position
The cheese begins with:
go to [random position]
Random placement prevents players from memorizing a fixed route through the game.
But the project goes one step further.
The cheese does not automatically accept the first random position Scratch chooses. Instead, it checks the distance from the cat.

The custom block uses:
repeat until <distance to [Cat Sprite] > 50>
go to [random position]
end
Then the cheese shows itself.
This creates a useful programming pattern: generate → test → retry
Scratch generates a random location. The program tests whether that location satisfies the rule.
If the cheese is too close to the cat, Scratch chooses another random position.
The loop continues until the position is more than 50 pixels away.
Random Does Not Have to Mean Uncontrolled
This cheese code demonstrates an important idea.
Randomness does not mean the programmer gives up control.
We can still place rules around random values.
The game says: Choose a random location, but only keep it if it is far enough away from the cat.
That makes the game fairer.
If the cheese appeared directly beside the cat, collecting it could immediately put the player in danger.
The constraint helps balance the random placement.
This is a useful example of how programmers can combine randomness and validation.
Create the Cat’s Basic Behavior
The cat runs independently from the mouse.
When the green flag is clicked, Scratch sets:
chaseSpeed = 2
and moves the cat to its starting position.
Then the cat repeatedly calls a custom block named: catBehavior

This custom block decides whether the cat should wander or chase.
The decision is based on:
distance to [Mouse Sprite]
That sensing reporter gives Scratch a numerical value representing the distance between the two sprites.
Use Distance Sensing to Decide When the Cat Should Chase
The central rule of the game is:
if <distance to [Mouse Sprite] < 150> then
chaseMouse
else
wander
end
This gives the cat two different modes.
If the mouse is more than 150 pixels away, the cat follows the wander behavior.
Once the mouse moves within 150 pixels, Scratch calls: chaseMouse
This makes the cat feel much more responsive than a sprite that blindly moves toward the player at all times.
The game has effectively created a simple detection radius.
Outside the radius: wander
Inside the radius: chase
That is one of the simplest ways to introduce basic game AI in Scratch.
What Does AI Mean in a Scratch Game?
The cat is not using artificial intelligence in the modern machine-learning sense.
It is following rules written by the programmer.
But this is still a useful introduction to game AI behavior.
A computer-controlled character observes information about the game world and selects a behavior based on that information.
The cat asks: How far away is the mouse?
The answer determines what happens next.
That is the basic structure behind many more complicated non-player characters: sense → decide → act
In our Scratch game: sense the distance → choose wander or chase → perform the behavior
Make the Cat Chase the Mouse
When chaseMouse runs, the first instruction is:
point towards [Mouse Sprite]
Scratch automatically calculates the direction from the cat to the mouse.
The cat then moves forward. The normal chase speed is stored in: chaseSpeed which begins at 2.
That means:
move (chaseSpeed) steps
moves the cat two steps at a time.
Using a variable instead of typing 2 directly into every movement block makes the value easier to change later.
Make the Cat Faster When It Gets Close
The chase behavior contains another distance test.
if <distance to [Mouse Sprite] < 50> then
move 4 steps
else
move (chaseSpeed) steps
end
Now the cat has more than a simple on/off chase state.
There are effectively three distance zones.
Far away: wander.
Within 150 pixels: chase at the normal speed.
Within 50 pixels: chase faster.
This produces behavior that changes gradually as the cat approaches the mouse.
That is a useful example of using numerical sensor data to create more than two outcomes.
Use Distance and Touching for the Catch
The cat does not rely on only one collision test.
The project uses:
if <<touching [Mouse Sprite]?> or <distance to [Mouse Sprite] < 15>> then
broadcast [caught]
end
This is a compound Boolean expression.
Scratch considers the mouse caught if:
the sprites are physically touching
OR
the cat is closer than 15 pixels
Only one condition needs to be true.
That makes the collision slightly more forgiving than requiring exact overlap.
Game programming often requires this kind of decision.
The mathematically strictest collision is not always the best gameplay.
Use OR Logic to Combine Two Catch Conditions
The green or operator evaluates two Boolean conditions.
A Boolean condition can only be true or false.
The combined expression is true if either side is true.
So these combinations work like this:
Touching = true / Distance = false → caught
Touching = false / Distance = true → caught
Touching = true / Distance = true → caught
Only when both are false does the cat fail to catch the mouse.
That gives us a practical reason to use Boolean logic instead of teaching or as an isolated block.
Respond When the Mouse Is Caught
The mouse listens for the caught broadcast.
When that message arrives, the script:
broadcast [resetCat]
change [Lives] by -1
play sound [Head Shake] until done
go to x: -212 y: -158

The order here matters.
The project broadcasts resetCat first so the cat can move away from the mouse before the rest of the catch sequence continues.
That prevents the cat from remaining in collision range and repeatedly triggering caught.
This is a useful debugging example because every individual instruction can be correct while the order of those instructions still creates a bug.
Why Order of Operations Matters in Games
Imagine subtracting the life while the cat and mouse remain touching.
The cat’s chase code is running inside a forever loop.
It can immediately test:
touching [Mouse Sprite]?
again.
If the sprites are still colliding, another caught message can fire.
Then another.
The player’s lives can disappear almost instantly.
Resetting the cat first breaks the collision.
Only then does the game continue with the life loss and player reset.
This demonstrates an important programming lesson:
The order in which events occur can be just as important as the events themselves.
Debugging is often about timing and state, not merely finding an obviously incorrect block.
Reset the Cat After a Catch
The cat listens for: resetCat
When received, it returns to its starting location and points in its starting direction.
The same script checks:
if <Lives < 1> then
broadcast [gameOver]
end
That ties the reset system to the player’s remaining lives.
As long as the player still has lives, the chase continues.
When no lives remain, the program triggers the game-over state.
Use a Randomized Wander Behavior
When the mouse is outside the cat’s detection range, the project calls: wander
The current wander behavior uses:
if <pick random 1 to 10 = 1> then
move 3 steps
end
followed by:
if on edge, bounce
That means the cat’s wandering movement is controlled by chance.
Each time the custom block runs, Scratch chooses a random number between 1 and 10.
The cat moves only when that value is 1.
That produces intermittent movement rather than a continuous chase.
Random numbers are useful for making computer-controlled characters less predictable.
Compare Wandering and Chasing
The cat now has two very different behaviors.
Wander
Movement depends on a random condition.
The cat is not actively targeting the mouse.
Chase
The cat:
- Points toward the mouse.
- Checks the distance.
- Chooses a movement speed.
- Checks for a catch.
The catBehavior custom block chooses between those two sets of instructions.
This is exactly why decomposition is helpful.
Instead of putting every cat behavior inside one enormous script, the project gives each behavior a descriptive name.
catBehavior
chaseMouse
wander
The code becomes easier to read because the custom blocks describe what each section is supposed to accomplish.
Win by Collecting 10 Pieces of Cheese
The mouse checks the Score variable each time cheese is collected.
After increasing the score, Scratch asks:
if <Score = 10> then
broadcast [winner]
end
That turns the score into more than a number displayed on the Stage.
It becomes part of the game’s logic.
When the player reaches exactly 10 pieces of cheese, Scratch broadcasts the winner message.
Create Separate Winner and Game-Over States
The winner sprite waits for: winner
When received, it:
- Moves to the front layer
- Shows itself
- Plays the
Winsound - Stops the game

A separate game-over sprite listens for: gameOver
It follows a similar structure:
- Move to the front
- Show the game-over screen
- Play the losing sound
- Stop all scripts

This gives the game clear end states.
The main chase system does not have to display its own results.
It simply broadcasts what happened.
The result sprites decide how that outcome should look and sound.
Use Broadcasts to Connect Different Game Systems
This project uses several messages to connect sprites:
moveCheese
caught
resetCat
winner
gameOver
Each broadcast represents an event.
A piece of cheese was collected.
The mouse was caught.
The cat needs to reset.
The player won.
The player lost.
Thinking in terms of events makes the program easier to organize because each sprite can respond only to the messages that matter to it.
Test the Scratch Chase Game Like a Programmer
Do not only play the game normally.
Try to break it.
Stand close enough to the cat to trigger chase mode, then move beyond 150 pixels again.
Watch whether the cat changes back to wandering.
Approach within 50 pixels and see whether the chase becomes faster.
Let the cat catch the mouse repeatedly.
Make sure only one life disappears for each catch.
Collect cheese near different parts of the room.
Check that new cheese positions remain more than 50 pixels from the cat.
Collect the tenth cheese and verify that the winner state appears.
Lose all three lives and make sure the game-over state activates.
These edge cases are often where the best debugging lessons happen.

Experiment with the Cat’s Detection Radius
One of the easiest ways to remix the game is to change:
distance to [Mouse Sprite] < 150
Try 75.
The mouse can get much closer before the cat begins chasing.
Try 200.
Now the cat notices the player from much farther away.
That single number dramatically changes the difficulty.
Kids can make a prediction first: Will increasing the detection distance make the game easier or harder?
Then test it.
Experiment with Chase Speed
The game begins with:
chaseSpeed = 2
Try setting it to 1.
Then try 4.
The cat also speeds up to four steps when the mouse is within 50 pixels.
Those values can be adjusted independently.
Kids could even create difficulty levels:
Easy: slower cat and smaller detection radius
Medium: current settings
Hard: faster cat and larger detection radius
Now variables become tools for balancing gameplay rather than merely storing scores.
Remix the Scratch Chase Game
There are plenty of directions to take this project.
- Add obstacles that block the mouse.
- Give the player a temporary speed boost.
- Make the cat slow down after a missed catch.
- Add more lives.
- Require 15 pieces of cheese to win.
- Create a second cat.
- Add a safe zone where the cat cannot enter.
- Make the cheese disappear after a few seconds.
- Add a timer.
- Change the characters entirely.
- A shark could chase a fish.
- A dragon could chase a knight.
- A robot could chase an alien.
The programming structure can remain largely the same even if the story changes.
That is another useful lesson in computational thinking.
The code represents behavior, not merely one specific character.
Open and Remix the Scratch Chase Game →
What Kids Learn from This Scratch Chase Game
This project introduces and reinforces:
- Keyboard input
- x- and y-coordinate movement
- Costumes
- Variables
- Score and lives
- Sensing
- Distance sensing
- Collision detection
- Boolean
orlogic - Conditional statements
- Nested decision-making
- Random numbers
- Random placement with constraints
- Custom blocks
- Decomposition
- Broadcast messages
- Autonomous sprite behavior
- Simple game AI
- Game states
- Debugging
- Order of operations
- Difficulty balancing
- Iterative game design
The most important idea is how the cat turns information into behavior.

Scratch senses the distance between two sprites.
The program compares that number with a threshold.
Then the cat chooses an action.
That creates the basic pattern: sense → decide → act
Once kids understand that idea, they can use it to build far more complicated computer-controlled characters.
You’ll Also Like
Scratch Frog Game: Catch the Flies Before Time Runs Out
Build another character-based Scratch game while exploring keyboard movement, jumping, random movement, collision detection, variables, timers, and clones.

Scratch Space Game: Build a Timed Star Collector
Create a complete arcade-style Scratch game with falling collectibles, hazards, clones, broadcasts, variables, collision detection, and win-or-lose logic.

Scratch Rainforest Coding Activity
Combine coding and science while using movement, sensing, Boolean logic, variables, lists, and classification rules to explore the layers of the rainforest.


Meet Toni, the Maker Mom behind Our Family Code
Hey there, I’m Toni! I’m a software engineer and Maker Mom that finds my joy in unleashing my children’s curiosity by exploring STEAM concepts with my fantastic five!
When I’m not chasing toddlers or raising tweens, you can find me tearing things up and putting them back together over here at Our Family Code.
I am the owner and content creator of multiple educational websites designed to increase access to STEAM & STEM education with a focus on teaching computer science and coding to kids of all ages!













