1. Review and demonstration (2+ minutes):
Begin by asking coders to talk with a neighbor for 30 seconds about something they learned last time; assess for general understanding of the practices and concepts from the previous project.

Explain that today we are going to create a player controlled maze game with a jump scare (the jump scare appears near the end of level 4 in the sample project). Display and demonstrate the sample project (or your own remixed version).

Video: Project Preview (1:17)
Video: Lesson pacing (1:48)

This can include a full class demonstration or guided exploration in small groups or individually. For small group and individual explorations, you can use the videos and quick reference guides embedded within this lesson, and focus on facilitating 1-on-1 throughout the process.

Example review discussion questions:

• What’s something new you learned last time you coded?
  • Is there a new block or word you learned?
• What’s something you want to know more about?
• What’s something you could add or change to your previous project?
• What’s something that was easy/difficult about your previous project?

2. Discuss or review (3+ minutes):
Have coders talk with each other about how they might create a project like the one demonstrated. If coders are unsure, and the discussion questions aren’t helping, you can model thought processes: “I noticed the sprite moved around, so I think they used a motion block. What motion block(s) might be in the code? What else did you notice?”

After the discussion, coders will begin working on their project as a class, in small groups, or at their own pace.

Note: Discussions might include full class or small groups, or individual responses to discussion prompts. These discussions which ask coders to predict how a project might work, or think through how to create a project, are important aspects of learning to code. Not only does this process help coders think logically and creatively, but it does so without giving away the answer.

Example discussion questions:

• What would we need to know to make something like this in Scratch?
• What kind of blocks might we use?
• What else could you add or change in a project like this?
• What code from our previous projects might we use in a project like this?
• What kind of sprites might we see in a maze?
  • What kind of code might they have?
• How could we use a keyboard to control a character?
• How could we switch to a different level when we reach a goal?
• What could happen if we touch a wall?

4. Review or introduce a maze game (20-60+ minutes, or at least one class)
If this is the first maze project, go through steps 4-8 of the An Amazing Maze Game lesson to learn how to create the base project of this maze game.

Otherwise, have coders open their previous project and give them about twenty minutes to read through their prior comments to review what they created, and to add even more to their project (perhaps some project extensions).

Suggested questions:

• How did your comments from your previous project help remind you what your code does?
  • What could you change to improve your comments?
• What’s something new you’ve learned since you first created this project that you could add to make it even better?

5. Clean up your code with functions (10+ minutes)
Note: This chunk was a “Project Extension” in the An Amazing Maze Game lesson and a part of the main lesson in the Blinking Maze Game, so coders may have already completed this step.

5 minute demonstration
Pull up your code with the forever loop and ask the class to figure out what the three sections of the forever loop are (movement, checking if touching a wall, and checking if touching the goal). Tell the class we can make this much easier to read by putting each of these sections into their own functions (My Blocks) with a descriptive name.

Demonstrate how to do this with each of the three sections and make note that My Blocks don’t move on to the next algorithm until the previous block (function) is completed.

5+ minutes to clean up their code and 1-on-1 facilitating
Leave your code on the screen and give coders time to clean up their code. Encourage peer-to-peer assistance and facilitate 1-on-1 as needed.

Video: Clean up your code with functions (3:54)
Quick reference guide: Click here

Suggested questions:

• How do functions and comments help you understand the parts of a project?
  • What’s the difference between the two?
• What other projects could you make easier to read by creating functions for each part of the code?
• When shouldn’t you use functions and just keep a longer algorithm?

A note on using the “Coder Resources” with your class: Young coders may need a demonstration (and semi-frequent friendly reminders) for how to navigate a browser with multiple tabs. The reason why is because kids will have at least three tabs open while working on a project: 1) a tab for Scratch, 2) a tab for the Coder Resources walkthrough, and 3) a tab for the video/visual walkthrough for each step in the Coder Resources document. Demonstrate how to navigate between these three tabs and point out that coders will close the video/visual walkthrough once they complete that particular step of a project and open a new tab for the next step or extension. Although this may seem obvious for many adults, we recommend doing this demonstration the first time kids use the Coder Resources and as friendly reminders when needed.

6. Code a hidden jump scare (25+ minutes)
5+ minute small group discussion
Ask coders to get together in small groups or pairs to try and figure out how to add a funny jump scare in a maze game. Point out that there are several ways to create a funny jump scare in a maze game and encourage groups/pairs to compare and contrast each method they come up with. After a couple minutes of discussion, ask for volunteers to share different approaches with the full class (or larger groups) and compare each approach.

10+ minute reverse engineering
Without displaying the code, use the sample project (or your remixed project) to demonstrate how the funny jump scare occurs when the sprite reaches a certain location on the final level. Ask coders to try and reverse engineer what they saw in the sample project. Note, younger coders should continue to work in small groups or pairs for this process, but they will add the code to their own projects.

Every couple of minutes, demonstrate the jump scare in the sample project again and give one of the following hints:

• You will need a sprite for your funny jump scare and another sprite that triggers the funny jump scare
• The sprite that triggers the funny jump scare will blend into the background of your maze and won’t do anything until your player’s sprite touches it
• You’ll need to combine a control block with a sensing block before triggering your funny jump scare
• You’ll need to broadcast a message from your hidden sprite to the funny jump scare sprite

Bonus challenge if someone figures it out early: Try and figure out how to make it so the funny jump scare appears when the player’s sprite reaches a certain location on the screen (using X and Y coordinates) rather than bumping into a hidden sprite.

2+ minute demonstration and discussion
Demonstrate how to combine a wait until block with a touching block to detect when the player touches the hidden sprite. Point out the hidden sprite needs to cover the entire path or the player might miss it.

8+ minute implementation time
Give time for coders to either watch the video demonstration or use the quick reference guide to create their own funny jump scare. If coders have completed their funny jump scare, encourage them to spend time testing and debugging the project to make sure the funny jump scare only occurs on their final level.

Video: Code a hidden jump scare (5:19)
Quick reference guide: Click here

Video: Suggestions for reverse engineering (4:25)

7. Play testing (20+ minutes, or an entire class)
5+ minute play testing
Either in pairs or in small groups, give coders a few minutes to take turns trying out each other’s maze games and discussing how they used code and the image editor tools to create their mazes.

5+ minutes to revise their project and 1-on-1 facilitating
Give coders five or so minutes to revise their projects based on feedback and ideas they gathered from their peers. Encourage peer-to-peer assistance and facilitate 1-on-1 as needed.

I recommend repeating this process several more times to encourage sharing ideas and getting peer feedback

Facilitation tip: It may help to model the kind of feedback one might give to a game like this. To practice this, display the maze I created for this lesson or one of the mazes I previously created in this studio. Ask coders what’s something they like about the project, what they might be curious about, and what suggestions they might have for improving the project(s).

Note: When testing out specific levels, a quick way to get to the desired level is to use code to switch to the specific backdrop when the green flag is clicked.