Project: Maze Game

One-sentence summary

In this project we build a Scratch character steered by the arrow keys; it returns to the start when it touches a wall and wins the game when it reaches the goal.

Why it matters

So far we have learned sequence, condition, loop, variable and debugging one at a time. A game uses all of these pieces at once. A maze game is a small but real project: we define a problem, sketch a design, connect the blocks and test the result.

This lesson is not a copy-and-paste recipe. The goal is for you to understand why each part of the game is there. That way you can later build your own game from scratch. When I first made this game, not everything worked on the first try; we will also see where I got stuck and how I fixed it.

Step 1: Define the problem and the design

Writing down what the game should do, before you touch any code, prevents many later mistakes.

Problem statement

• The player moves a character with the arrow keys.
• If the character touches a wall (a specific colour), it returns to the starting point.
• When the character reaches the goal, a "You win!" message appears.

Sprites and backdrop needed

In Scratch, every object is a sprite and the background is a backdrop.

An important design choice: all the maze walls should be the same colour. That is because we will answer the question "did I touch a wall?" by checking that colour. If we draw the walls in blue, the code will ask "touching the colour blue?"

Step 2: Move the character with the arrow keys

The character must move in four directions. We do this with Events and Motion blocks.

The simplest method is to use a separate event block for each arrow key. The x position controls left–right and the y position controls up–down.

when right arrow key pressed
  change x by 10

when left arrow key pressed
  change x by -10

when up arrow key pressed
  change y by 10

when down arrow key pressed
  change y by -10

The number 10 sets how many steps the character slides on each press. A large number makes the character fast but rough; a small number makes it slow but precise. If the maze corridors are narrow, a small number works better.

Step 3: React to the wall and the goal

Now we reach the heart of the game: the character must return to the start when it touches a wall, and win when it reaches the goal. For this we use Control, Sensing and Looks blocks together.

Return to start when touching a wall

We need to check the character's state continuously, because a collision can happen at any moment. So we place a condition inside a forever loop.

when green flag clicked
go to x: -200 y: -140
forever
  if <touching color [blue]?> then
    go to x: -200 y: -140

At the start we place the character at the maze entrance (-200, -140). Then the loop keeps asking "am I touching the blue wall?" If the answer is yes, it sends the character back to the same starting point. So if the player hits a wall, they have to start again from the beginning.

Win when reaching the goal

We add a second condition to the same forever loop. This time we check the goal sprite, not the wall.

when green flag clicked
go to x: -200 y: -140
forever
  if <touching color [blue]?> then
    go to x: -200 y: -140
  if <touching [Goal] sprite?> then
    say "You win!" for 2 seconds
    stop [other scripts in sprite]

The touching color? block is in the Sensing category and checks the wall's colour. The touching Goal sprite? block is also in Sensing, but this time it measures touching another sprite. The say "You win!" block comes from the Looks category and shows a speech bubble on screen.

Step 4: Run the test scenarios

As we learned in the previous lesson, writing code is not enough; you have to test it. Start the game with the green flag and try these scenarios one by one:

1. Normal walking: Press the arrow keys. Does the character move smoothly in all four directions?
2. Hitting a wall: Drive into a wall on purpose. Does the character return to the start?
3. Reaching the goal: Guide the character to the exit. Does the "You win!" message appear?
4. Restarting: Press the green flag again. Does the character start at the entrance again?

For each scenario, write your expected result first, then observe what actually happens. If the two differ, you have found a bug.

Step 5: A bug and its fix

When I first built this game, scenario 2 did not work. I drove the character into a wall, but it did not return to the start; it passed straight through the wall. Here is how I found the bug:

Goal: Character returns to start when touching a wall
Problem: Nothing happens when the character touches a wall
Check 1: Are the walls really blue? -> Yes
Check 2: Does the colour box in the condition show the right blue? -> No
Cause: I had picked the wrong shade of blue in the colour box
Fix: I clicked the colour box and used the dropper to take the wall's colour

In Scratch, the colour inside the touching color? block must match the wall's colour exactly. Using the dropper (colour picker) to take the colour straight from the wall is the safest method. This small detail decided whether the game worked or not.

Step 6: Ideas to extend the game

Once the basic game works, you can grow it with tools from earlier lessons:

• Add a counter: Create a variable, name it "score". Increase the score by 1 when the character reaches the goal.
• Track time: Use a second variable to count the seconds. How fast did the player finish the maze?
• Add sound: Play a short sound from the Sound category when the character hits a wall.
• New level: When the character reaches the goal, switch the backdrop and show a harder maze.

None of these ideas are required. The point is to enjoy growing a simple working game step by step.

Mini practice

Build your own maze:

1. Open a new Scratch project and draw a maze on the empty backdrop in one colour.
2. Add two sprites: a player and a goal.
3. Add the four arrow-key blocks above to the player sprite.
4. Add the two conditions (wall and goal) inside a forever loop.
5. Run the four test scenarios in order and write the results on paper.

When you finish, ask yourself: which scenario got you stuck, and how did you solve it?

Common mistakes

Drawing walls in different colours

If some walls are blue and some are dark blue, the touching color? block catches only one shade. Keep all walls the same colour.

Forgetting the starting position

If you do not place the character at the entrance when the green flag is clicked, the game starts from a different place each time. Remember to add the go to x: … y: … block before the loop.

Not putting the checks inside the loop

If you do not put the wall check inside the forever loop, the program looks for a collision only once and misses it. The check must run at all times.

Choosing too large a step size

If you write change x by 50, the character can jump right through the walls. In narrow corridors a small number (5–10) is safer.

Safety note

This lesson is done entirely at a screen. Looking at a screen for a long time tires the eyes; a short break every 20 minutes to look into the distance helps. When you share your project on Scratch, do not write your real name, school or address; use only a nickname. It is safer to review comments on a public project together with an adult.

Lesson summary

• A game project uses sequence, condition, loop and variables all together.
• Designing the problem, sprites and backdrop before coding reduces mistakes.
• Arrow-key movement is built with Events and Motion blocks, using change x/y by.
• Reactions to the wall and the goal come from conditions inside a forever loop with Sensing blocks.
• Test scenarios and debugging are how you make sure the game really works.

Check questions

1. Why do all the maze walls need to be the same colour?
2. Which block and value are used to move the character to the right?
3. Why do we put the wall check inside the forever loop?
4. What happens if we forget to place the character at the starting point when the green flag is clicked?
5. What happens if the colour in the touching color? block does not exactly match the wall's colour?

Answers

1. Because we tell whether the character touched a wall by checking that colour. If the colours differ, the block cannot see some walls.
2. Inside the when right arrow key pressed event, the change x by 10 block is used (a positive value moves it right).
3. Because a collision can happen at any moment. The loop repeats the check constantly; a single check would miss the collision.
4. The game starts from wherever the character was last; the player cannot begin from a fair starting point.
5. The block does not detect the wall, and the character passes through it. Taking the colour straight from the wall with the dropper fixes the problem.

Source and verification note

For “Project: Maze Game”, verification focuses on whether the relationship between Step 1: Define the problem and the design and Sprites and backdrop needed remains consistent across examples. Block names are kept consistent with the current core Scratch categories. Project behaviour should be tested separately for start-up, normal play, errors and restarting.

Next lesson

Project: Basketball Shooting Game