Program a Maze with Paper
You probably use computer programs every day. Every time you use the internet, play a video game, or us a smartphone, you are using computer programs. Do you want to learn a little bit about computer programming, without the need to actually use a computer? In this fun activity, you will write a “program” – a set directions for a volunteer to find their way through a maze. Can you help them find their way through without crashing?
A computer program is a list of instructions or commands that tell a computer what to do. For example, when you are typing on a computer, there are commands that tell it to display certain characters on the screen when you push a key on your keyboard. The program for a video game might have different instructions that tell the game to move the on-screen character when you push the joystick on a controller. A web browser has instructions to tell it what to do when you use your mouse to click on different buttons. There are many, many more examples of what computer programs can do. Can you think of more?
Computers are very good at following directions, but that can lead to one problem. What happens if a human programmer accidentally gives a computer the wrong directions? The computer can’t think for itself – it will go ahead and follow the directions it was given, even if they’re wrong! This can cause the program to “crash,” or not function as it was intended. Computer programmers call errors in computer code “bugs,” and the process of finding and removing them “debugging.” In this project, you will write a set of directions for a volunteer to navigate a maze, using commands like “move forward,” “turn left,” and “turn right.” If you make a mistake with your directions, the volunteer will “crash” into the wall of the maze, and you will have to debug your program and try again!
- Use a sheet of graph paper to create a small maze that fits on a rectangular grid. All of the maze’s walls should be vertical or horizontal – no diagonal or curved lines.
- Start out with a small, easy-to-solve maze, and you can make a more difficult one later.
- Make sure the maze has clearly labeled “start” and “finish” points.
- Optional: you can also use a coloring or activity book that contains mazes, as long as it has some mazes with only vertical and horizontal lines.
- Imagine that you are a person walking through your maze, starting at the “start” point. On a separate piece of paper, write down directions, one step at a time, for how you would walk through the maze. For example, use commands like “Move forward 2 squares,” “turn left,” and “turn right.” Continue writing directions until you have enough to reach the “finish” mark of the maze. Optional: if you prefer, you can draw arrows instead of writing out the words (a straight arrow for “move forward,” and curved arrows for turning).
- Now, hand your maze, the directions, and pencil to your volunteer. Instruct them to follow your directions exactly as they go through the maze, even if they see a mistake. They are not allowed to solve the maze on their own or change the directions.
- Watch closely to see if the volunteer successfully completes the maze by following your directions. Do they crash into any of the walls, or do they make it all the way to the finish line?
- If your volunteer makes it all the way to the finish line, then congratulations! Your program did not have any bugs. Try making a bigger, more complicated maze, and starting over.
- If your volunteer crashed into one of the maze’s walls, you need to debug your program. Carefully trace through your program step by step to see where things went wrong. Did you tell them to move one block too far, or turn one block too early? Just one mistake can throw off your entire program and cause a crash later on, so look carefully!
- After you discover the bug, re-write your program. If you only need to change one or two steps, you can just erase them instead of re-writing the whole thing (this is one of the advantages of programming on a real computer – it is very easy to delete and re-write text!).
- Have your volunteer try the maze again, following your new program. Can they solve it this time? If not, keep debugging your program until they can solve the maze.
Extra: computer programs are written in many different “languages,” which all have slightly different formats, but very similar underlying concepts. For example, some computer programs use punctuation and spelling differently – this is called the program’s “syntax.” For this project, can you come up with a different “language” that accomplishes the same task of solving the maze? For example, what about using commands that are defined relative to absolute directions on the piece of paper like “move up,” “move down,” “move left,” and “move right;” as opposed to turning left/right as if you were a person standing in the maze? Can you see how, although these two languages are different, they can both be used to do the same thing?
Extra: can you try the project with more complicated mazes that include diagonal or curvy lines? If you can no longer rely on a rectangular grid for movement, how would you write the program? Hint: try introducing new commands like “move forward until you reach an intersection” or “move forward until you hit a wall.”
Extra: instead of using a maze on paper, write a program to navigate a person walking through your house or school. Can they move from room to room without bumping into a wall by only following your directions?
Observations and Results
You probably found that it only takes one bug early on in a program to cause a crash. When solving a maze, there is little room for error – make one wrong turn, and you can bump into a wall or get lost! You might have noticed the same thing if you have ever been riding in the car with an adult attempting to follow directions from a GPS system.
Have you ever used a computer program that crashed, or played a video program with a glitch? Did you find the experience frustrating? This is why companies do lots of debugging and testing before they release a program to the public, and sometimes have to release patches to update a program after a bug is discovered.