A Scratch maze game: keyboard input and wall checks

The idea

A visual program uses input (arrow keys), branching (if touching the wall colour) and repetition to control a sprite, and a test table shows whether every rule works.

What you need

• 1 computer or tablet per pair with Scratch 3 (the offline app or teacher-managed class accounts)
• A maze backdrop drawn in the Scratch paint editor: walls in one colour, a goal square in a second colour
• Printed test table with columns: test, what should happen, what happened, pass or fix
• Design criteria sheet agreed by the class (for example: the sprite cannot pass through walls; reaching the goal shows a message and stops)

How to do it

1. With the class, write two user stories, for example: as a player, I want the walls to stop my sprite so that the maze is a real challenge.
2. Plan on paper: draw the maze and write, in words, what each arrow key should do and what happens at a wall and at the goal.
3. Program the start: when the green flag is clicked, go to the start position.
4. For each arrow key: when the key is pressed, change x (or y) by 10, then if touching the wall colour, change x (or y) by −10 so the sprite moves back.
5. Add a forever loop: if touching the goal colour, say a message for 2 seconds and stop all.
6. Run the test table: press each arrow once in open space, drive into a wall from all four sides, reach the goal. Mark each test pass or fix.
7. Fix any failed test, run the whole table again, then swap games with another pair and compare the two designs against the criteria.

What you should see

Each arrow press moves the sprite 10 steps. Driving into a wall moves the sprite 10 steps in and straight back 10, so it cannot pass, and reaching the goal shows the message and stops the program. The test table has 9 tests (4 arrows in open space, a wall from each of the 4 sides, and the goal) and the game meets the criteria when all 9 pass. A common bug is placing the wall check before the move, which lets the sprite enter the wall; the wall tests catch it. The learner knows it worked when a partner who did not write the program can run all 9 tests with the same results.

What changes

This activity lists no variables to change, measure and keep the same.

Common misconceptions

Each of these ideas is wrong, and the activity is a chance to test it.

• The program runs the steps in the order they appear on the screen (each script runs when its own event happens).
• If the game works once it has no bugs (only a full set of tests shows every rule works).
• The sprite 'knows' where the walls are (it only checks the colour it is touching).

Safety card

Curriculum references

The NSW syllabus outcomes and Australian Curriculum v9 codes this activity supports. They are references, not a verified or complete curriculum alignment.

• Science and Technology K–6 Syllabus (2017), NESA. The syllabus taught in 2026; the 2024 syllabus replaces it from 2027. Code read from the official syllabus document (DOCX) on 2026-09-22.ST2-3DP-T
• Science and Technology K–6 Syllabus (2024), NESA. Implementation from 2027, so this code describes the future syllabus. Code read from the outcomes page on 2026-09-22.ST2-DDT-02
• Australian Curriculum v9AC9TDI4P04AC9TDI4P01AC9TDI4P03AC9TDI4P05

Sources

The pages the author read to write this activity.

1. www.nsw.gov.au/education-and-training/nesa/curriculum/science/science-and-technology-k-6-2017
2. curriculum.nsw.edu.au/learning-areas/science/science-and-technology-k-6-2024/outcomes
3. scratch.mit.edu/ideas
4. www.digitaltechnologieshub.edu.au/plan-and-prepare/scope-and-sequence-f-10/years-3-4