Scratch Maze Game: Halloween Trick-or-Treat Candy Hunt

Trick-or-treating is basically a maze game already.

You wander around, avoid obstacles, choose where to go next, and try to collect as much candy as possible before someone decides it is time to go home.

That makes Halloween a perfect theme for building a Scratch maze game.

Our Trick-or-Treat Candy Hunt Maze turns those ideas into an interactive coding project where kids can explore movement, coordinates, sensing, conditionals, game rules, and debugging while navigating a Halloween-themed maze.

Instead of watching an animation run from beginning to end, the player controls what happens. That changes the programming problem completely.

Now the code needs to respond to keyboard input, prevent the player from moving through walls, recognize important objects, and decide what should happen when the player reaches different parts of the maze.

Play our Trick-or-Treat Candy Hunt Maze below, then open the project to explore how the game works.

Open or Remix Trick-or-Treat Candy Hunt Maze on Scratch →

This project is part of our growing collection of Halloween Scratch activities, along with Witch Wardrobe Conditional Statements, Halloween Conditional Collisions, and the Skeleton Dance Party animation project.

What Is a Maze Game in Scratch?

A maze game gives the player control of a sprite and challenges them to navigate through a path without crossing the maze walls.

That sounds simple, but several programming concepts have to work together.

The player needs a way to move.

Scratch needs to know where the sprite is located. The program needs rules for what happens when the character touches a wall.

The game may also need to recognize a goal, collectible object, hazard, or another sprite. That makes a maze a great introduction to interactive game programming.

Start by Playing the Candy Hunt Maze

Before opening the code, play the finished project. Try moving through the maze and pay attention to how the game responds.

Ask:

• Which keys control the character?
• What happens when the player reaches a wall?
• What objects can the player interact with?
• How does the game know when something has been touched?
• What tells the player that they have succeeded?

Those observations give kids a problem to investigate when they click See Inside.

Instead of seeing a giant collection of Scratch blocks, they can begin connecting each block to behavior they already observed in the game.

How Player Movement Works in Our Scratch Maze Game

Unlike an animation that runs through a predetermined sequence, a maze game has to respond to the player.

In our Trick-or-Treat Candy Hunt, Scratch continually checks whether one of the arrow keys is being pressed. Each direction has its own conditional statement inside the custom movement block.

When the player presses the down arrow, Scratch points the character in direction 180 and calls the walk block.

The up arrow uses direction 0.

The right arrow uses direction 90.

The left arrow uses direction -90.

Instead of writing separate movement instructions for every direction, the program changes which way the character is facing and then reuses the same walk block to handle the actual movement.

That is a much cleaner programming structure.

The main game loop repeatedly calls three custom blocks:

movement

candy

Finish

Those three blocks divide the game into separate jobs. One handles navigation, one checks candy interactions, and one checks whether the player has completed the level.

This is another example of decomposition: breaking a larger program into smaller pieces that each have a clear responsibility.

The arrow-key code also uses Boolean operators to combine multiple conditions. Scratch is not only asking whether a key is pressed; it is checking other conditions about the player’s location before calling walk.

That means a single movement decision can depend on more than one true-or-false condition at the same time.

Use a Custom Walk Block to Handle Maze Walls

Moving the player is only half of the maze problem.

If Scratch allowed the character to move forward no matter what was in front of it, the player could simply walk through the maze walls.

Our project handles that problem inside a reusable custom block called:

walk

The block first checks whether the player is touching the black wall color.

If the path is clear, Scratch moves the character forward using the value stored in the walkingSpeed variable.

In our game, walkingSpeed begins at 5, so each movement advances the character five steps.

Conceptually, the first rule is:

if <not <touching color [black]?>> then
    move (walkingSpeed) steps
end

After moving, Scratch checks the wall condition again.

If the player has moved into a black maze wall, the game plays a collision sound, increases the Hit Wall counter, and moves the character backward by multiplying walkingSpeed by -1.

if <touching color [black]?> then
    play sound [collision]
    change [Hit Wall] by 1
    move ((walkingSpeed) * -1) steps
end

Multiplying the movement value by -1 reverses the direction of the movement.

If walkingSpeed is 5, then:

5 × -1 = -5

That backs the player away from the wall.

The overall logic becomes:

Check the path → move forward → check the result → reverse the move if a wall was hit.

This is a good example of conditional logic doing real work inside a game. Scratch evaluates a condition and performs an action only when that condition is true.

It is the same fundamental if/then idea used in our Witch Wardrobe and Conditional Collisions projects, but here the condition enforces the rules of a maze.

Count Wall Hits and Create a Lose Condition

Our game does more than prevent the player from walking through walls.

Every collision increases the Hit Wall variable by one.

That turns a programming rule into a game rule.

The player can make mistakes, but not indefinitely.

When:

Hit Wall = 15

the game calls the restart block and plays the Lose sound.

Now hitting a wall has a consequence beyond simply being pushed backward.

This illustrates the difference between coding a mechanic and designing a game.

The collision detection makes the maze function.

The Hit Wall limit creates a challenge.

Kids can experiment with that value too. A limit of five would make the game much less forgiving, while a limit of 30 would give the player much more room for mistakes.

Experiment with Walking Speed

The walkingSpeed variable gives us one place to control how far the player moves at a time.

A smaller value creates slower, more precise movement. A larger value lets the character cover more distance but can make tight maze paths harder to navigate.

Instead of rewriting movement code in four places, we can change one variable and affect the entire movement system.

That is one of the main reasons variables are useful in programs: they let us store a value once and reuse it.

Game Design Means Making Choices

Programming makes the game function.

Game design determines how the game feels to play.

Kids have to make decisions such as:

How fast should the character move?

How wide should the paths be?

How difficult should the maze be?

Should there be only one correct route?

Should the player collect something along the way?

Should mistakes have consequences?

Those choices change the player’s experience even when the basic code remains the same.

Randomly Place Candy Without Overlapping Other Objects

The candy in our maze does not appear in the same place every time a new game begins.

Each candy sprite uses a custom block called newLocation to find a random position on the Stage.

Simply choosing a random location is not enough, though.

A completely random position could place candy inside a wall, outside the playable part of the maze, directly beside another piece of candy, or on top of another important game object.

So our program does something more useful:

generate a location → test the location → retry if necessary

The newLocation block begins by hiding the candy and setting a variable called:

validLocation

to 0.

Then Scratch enters a:

repeat until <validLocation = 1>

loop.

Inside that loop, the candy moves to a random position and temporarily sets validLocation to 1.

That means the program begins each attempt by assuming:

This location is valid unless one of our tests proves otherwise.

Scratch then tests the location against several rules.

If:

x position < -120

the candy is too far to one side, so validLocation becomes 0.

If:

x position > 197

the candy is outside the other horizontal boundary, so the location is rejected.

If the candy is touching the black maze wall, the position is also rejected.

The program then checks the candy’s distance from other important sprites.

For example:

distance to [lollipop sprite] < 100

or:

distance to [green candy sprite] < 100

If the new piece of candy is within 100 units of one of those objects, validLocation changes back to 0.

If even one test changes validLocation back to zero, the repeat until loop runs again and Scratch chooses another random position.

Eventually, Scratch finds a location that passes every test.

At that point:

validLocation = 1

The loop ends and the candy uses:

show

Now the player can see and collect it.

This is a useful example of validation in programming.

The program does not accept the first answer it generates. It checks that answer against a set of rules before using it.

Why Keep the Candy 100 Units Apart?

The distance rule prevents collectible objects from clustering in almost the same location.

Without that check, several candies could randomly appear together, allowing the player to collect multiple pieces without exploring much of the maze.

The exact candy locations still change every game, but the program places limits on what counts as an acceptable random location.

That gives us two ideas working together:

randomness makes the game unpredictable.

constraints make the random results useful.

Experiment with the Distance Rule

The value 100 is another part of the game kids can test.

Reducing it to 50 lets objects appear closer together.

Increasing it to 150 requires much more space between objects.

Run the game several times after each change.

Does the candy distribution look different?

Does Scratch take longer to find valid locations?

What happens if the required distance becomes too large for the available maze?

Those questions turn one piece of game code into an experiment with randomness, coordinates, constraints, and algorithm design.

Add Candy to the Maze

Collect Candy with Collision Detection

Once the candy has been placed, the game has to recognize when the player finds it.

Each candy sprite checks whether it is touching the player sprite.

Conceptually:

if <touching [player]?> then
    hide
    change [Candy] by 1
end

When the collision occurs, the candy disappears and the Candy variable increases by one.

This gives the collectible three important behaviors:

It can be found.

It disappears after collection.

The program remembers that it was collected.

The player’s own candy custom block also checks for collisions with the different candy sprites and plays the Bite sound when one is touched.

That means different parts of the program can respond to the same interaction.

The candy sprite handles disappearing and updating the variable, while the player code handles the sound effect.

This is another example of breaking a larger behavior into smaller responsibilities.

Use the Candy Variable to Track Progress

The Candy variable is more than a score.

It represents the player’s progress through the level.

At the beginning of the game, the Start block sets:

Candy = 0

Each collected candy increases the variable by one.

Because there are five pieces to collect, the game eventually needs:

Candy = 5

before the player can complete the maze.

Variables are useful because they allow a program to remember something that has already happened.

Scratch does not need to inspect every candy sprite at the end and figure out which ones disappeared.

It simply checks the value stored in Candy.

Require Two Conditions to Finish the Maze

Reaching the finish area is not enough to win our Candy Hunt.

The Finish block checks two conditions:

Is the player touching the green finish color?

and

Does Candy equal 5?

Both must be true.

Conceptually:

if <<touching color [green]?> and <Candy = 5>> then
    ...
end

This uses the Boolean and operator.

With and, the entire condition is true only when both sides are true.

That means a player who reaches the end without collecting all five pieces of candy has not completed the challenge yet.

Likewise, collecting every candy is not enough if the player has not reached the finish area.

This is a stronger game rule than checking only one condition because it combines location with progress.

Celebrate, Advance to the Next Maze, and Reset

Once both finish conditions are true, the program runs a sequence of actions.

The new backdrop gives the player another maze while much of the same programming logic can continue to be reused.

The newGame broadcast tells other parts of the project that a new level is beginning.

The Start block then resets important game state, including the player’s starting position, walkingSpeed, Hit Wall, and Candy.

This is an important game-programming concept.

Changing the picture on the screen is not enough to begin a new level. The program also has to reset the information left over from the previous one.

That includes variables, sprite positions, collectibles, and anything else whose state changed during gameplay.

Remix the Trick-or-Treat Candy Hunt

Once kids understand the existing game, click Remix and change one part of it intentionally.

They could adjust the walking speed, change the 15-wall-hit limit, alter the candy-spacing rule, redesign the maze, add another level, introduce a moving obstacle, add a timer, or change how many candies are required to finish.

Run the game after each change and observe what happens.

The goal is not simply to decorate the project. Kids should be able to explain:

• What did they change in the code?
• What behavior changed because of it?

That cycle of modifying, testing, observing, and revising is a major part of programming and game design.

Open and Remix Trick-or-Treat Candy Hunt Maze on Scratch →

Test and Debug the Maze

A maze can appear to work correctly until a player tries something the programmer did not expect.

Try approaching walls from different directions, cutting through corners, collecting candy in a different order, reaching the finish before collecting all five candies, restarting after losing, and completing more than one level.

Then test systematically.

• Does every arrow key behave the same way?
• Does every wall collision increase Hit Wall exactly once?
• Does every candy increase Candy exactly once?
• Can candy ever generate inside a wall or too close to another object?
• Does the level advance only when both finish conditions are true?
• Does Start correctly reset the player and variables for the next game?

Testing expected behavior shows that the normal path works. Testing unexpected behavior is often how programmers find the bugs they did not know were there.

Scratch Maze Coding Challenge

Challenge kids to build a maze game that includes:

• Keyboard-controlled player movement
• At least one wall or boundary rule
• A sensing condition
• A goal
• A response when the goal is reached
• At least one collectible or obstacle

For an extra challenge, add a score, timer, multiple levels, or moving obstacle.

The finished games do not need to look alike.

What matters is whether kids can explain how their game knows what the player is doing and how the code responds.

Questions to Ask While Kids Code

Ask questions that focus on program behavior:

• What changes when you press an arrow key?
• Which coordinate controls that direction?
• How does Scratch know you touched a wall?
• Why does the program reverse the movement?
• What condition determines whether an object is collected?
• What happens if that condition stays true?
• How does the game know when the player wins?
• Where could a bug occur?
• How could you make the maze harder without changing its size?

These questions help kids move beyond copying blocks and toward explaining the logic underneath the game.

What Kids Learn from a Scratch Maze Game

A Halloween maze can reinforce:

• keyboard input,
• custom blocks,
• loops,
• conditionals,
• Boolean AND/OR logic,
• sensing,
• collision detection,
• variables,
• coordinates,
• randomization,
• validation,
• game state,
• broadcasts,
• debugging,
• and interative game design.

It also introduces an important shift in programming. Animations tell Scratch what should happen.

Games have to respond to what the player does. That means programmers have to think about more possible outcomes.

Try More Halloween Scratch Coding Activities

If kids want to keep coding, explore Scratch Witch Wardrobe for conditional statements and user input.

Then try Halloween Conditional Collisions for sensing, collisions, nested conditions, and broadcasts.

Our Skeleton Dance Party explores animation, custom blocks, coordinates, parameters, randomization, and parallel scripts.

All four projects are published on the Our Family Code Scratch Studio.

They also belong in our 31+ Halloween STEM Activities for Kids collection.

You Might Also Like

Scratch Conditional Collisions

Use sensing and if/then logic to make Halloween sprites respond when they collide.

Try Scratch Collision Detection →

Scratch Skeleton Dance Party

Animate skeletons, bats, pumpkins, music, and coordinated movement using loops and custom blocks.

Try the Skeleton Dance Party →

Scratch Witch Wardrobe

Use player input and conditional statements to help Glenda choose what to wear.

Try Scratch Witch Wardrobe →