Session 17 — Levels & Challenge

Duration: 60 min · Format: live online · Ages: 8–11

Session goal: by the end, students can use if/then decisions, detect collisions with the "touching" block, and give a game real win and lose conditions.

Before class — prep (5 min)

• Open Scratch and click Create — you'll screen-share and live-build.
• Have a starter idea ready: the "catch" game from Session 16, upgraded so that when the basket touches the apple the score goes up, and if the apple touches the floor the player loses a life.
• Load your Session 16 project (or the students' version) so you can extend it live.
• Ask students to open Scratch with their Session 16 project ready.

Agenda

0:00 · Hook (5 min)

Ask the class and take a few answers (chat or unmute):

• "How does a game know when you caught the coin, or fell in the pit?"
• "What makes a game feel too easy or too hard?"
• "How does the screen decide to show 'You Win!' or 'Game Over'?"

Let them guess, then reveal: today your game learns to make decisions. It will check "is this touching that?" and then choose what to do — score, lose a life, win, or end.

0:05 · Teach — If/then makes decisions (12 min)

Explain, on your shared Scratch screen:

• An if / then block (Control) is a decision: if something is true, then do these blocks. If it's not true, it skips them.
• The diamond-shaped slot at the top holds a question that is true or false — for example, "is the apple touching the basket?"

Demo in Scratch:

• Build if <touching [Basket]?> then → change [Score] by 1. Drop it inside a forever loop so the game keeps checking.
• Run it and drag the apple onto the basket — the score jumps. Explain: the loop asks the question many times a second; when the answer becomes true, the then blocks run.

⚠ Watch for a runaway score: because the loop checks constantly, one touch can add hundreds of points. Fix it live by adding, right after scoring, a reset — go to x: 0 y: 150 (send the apple back to the top) so it's no longer touching. This is a great teaching moment.

Ask: "The diamond slot needs a question that is true or false. Is 'the apple' a good fit for it? What about 'the apple is touching the basket'?" (Answer: the second — it can be true or false.)

0:17 · Teach — Touching, collisions, win & lose (13 min)

Explain: the touching [ ]? block (Sensing) is how a game notices collisions — two things bumping into each other. It's the heart of catching, hitting, and dodging.

Picture the collision logic: if touching the wall, react; otherwise keep moving.

Demo in Scratch, building live:

• Scoring collision: in the apple's forever loop, add if <touching [Basket]?> then → change [Score] by 1, play sound [Pop], go to x: (pick random -200 to 200) y: 150 (respawn somewhere new).
• Losing collision: add if <touching [floor]?> then → change [Lives] by -1 and reset the apple to the top. (Use a floor sprite or check if y < -150.)
• Lose condition: somewhere in a loop, add if <Lives = 0> then → broadcast [game over] → stop [all]. Add a sprite with when I receive [game over] → say [Game Over!].
• Win condition: add if <Score = 10> then → broadcast [you win] → stop [all], with a sprite that says "You Win!"

Now making it harder (levels):

• Explain: a game gets harder by speeding up or adding more. Show change y by -5 → change the -5 to a variable Speed, and change [Speed] by -1 every 10 points so falling gets faster.

Key point to land: if/then + touching lets a game react — that's what turns moving sprites into a real, winnable, losable game.

Ask the class: "To make the game harder, should the apple fall faster or slower? What block changes that?" (Answer: faster; change the change y by number to a bigger negative.)

0:30 · Activity (20 min)

Students upgrade their catch game. Screen-share your version as a reference.

Build this, step by step:

1. On the falling sprite: wrap the fall in forever → change y by -5.
2. Inside the loop, add if <touching [your catcher sprite]?> then → change [Score] by 1, play sound [Pop], go to x: (pick random -200 to 200) y: 150.
3. Add if <y < -150> then → change [Lives] by -1 → go to x: (pick random -200 to 200) y: 150 (missed it — reset).
4. Make sure Lives starts at 3 and Score starts at 0 on the green flag.
5. Add a lose check: if <Lives = 0> then → broadcast [game over] → stop [all].
6. Add a win check: if <Score = 10> then → broadcast [you win] → stop [all].
7. Add a sprite that shows "Game Over!" on when I receive [game over] and "You Win!" on when I receive [you win].
8. Test: catch apples to win, miss three to lose.

Circulate for: - Scores that shoot up by hundreds — the caught sprite isn't resetting, so it stays touching. Add the respawn line. - The if/then placed outside a loop, so it only checks once — move it inside the forever loop. - Win/lose messages that never show — check the broadcast and when I receive names match, and that stop all isn't stopping the message sprite before it can say anything (put the say before stop all if needed).

Encourage: ask students to change the win score or starting lives to tune how hard their game feels.

0:50 · Check for understanding (7 min)

Ask these aloud or drop them in the chat. Answer key (for you):

1. What does an if/then block do? → It checks a true-or-false question; if it's true, it runs the blocks inside; if not, it skips them.
2. Which block lets a game notice two sprites bumping into each other? → The touching [ ]? block (Sensing) — it detects a collision.
3. How could you make a "You Win!" message appear when the score reaches 10? → if <Score = 10> then → broadcast [you win]; a sprite with when I receive [you win] says "You Win!".

0:57 · Wrap-up + homework (3 min)

• Ask one student to describe, in their own words, one win condition and one lose condition in their game.
• Homework — Tune the Challenge: change one thing to adjust the difficulty — the falling speed, the number of lives, or the score needed to win — and decide whether it made the game better. Bring it to Session 18.

Teaching notes

• Correct this misconception: "if/then only runs once when I click it." Alone it checks a single time; games put if/then inside a forever loop so the question is asked continuously. Show both so students feel the difference.
• Fast finishers (extension): have them add a second level — when Score reaches 5, broadcast [level 2], switch the backdrop, speed up the falling sprite, and maybe add a second falling object to dodge. Challenge them to add an enemy the player must avoid: if <touching [enemy]?> then change [Lives] by -1. This is real level design in miniature.
• Low-tech fallback: if a student can't run Scratch, have them draw a flowchart on paper: a diamond "Is the apple touching the basket?" with a Yes arrow (score up) and a No arrow (keep falling). Understanding the decision is the goal; the blocks just copy the flowchart.

Practice set

Assign in class or as homework. Answers are for you, after the arrow.

1. Make the score go up only when the falling sprite touches the catcher. → Inside a forever loop: if <touching [catcher]?> then change [Score] by 1.
2. Stop one touch from scoring hundreds of points. → After scoring, move the sprite away so it isn't touching anymore: go to x: (pick random -200 to 200) y: 150.
3. Take away a life when the sprite reaches the bottom of the screen. → if <y < -150> then change [Lives] by -1 then reset its position to the top.
4. End the game when lives reach 0. → if <Lives = 0> then broadcast [game over] → stop [all]; a sprite says "Game Over!" on when I receive [game over].
5. Show "You Win!" when the score reaches 10. → if <Score = 10> then broadcast [you win] → stop [all]; a sprite says "You Win!".
6. Make the game get harder as the player scores. → Store the fall speed in a Speed variable and change [Speed] by -1 every few points, so the sprite falls faster over time.

Going deeper (optional)

• True/false questions can be combined. Show the green operator blocks: and, or, not. Build something like if <(touching [catcher]?) and (Score < 10)> then …. Ask students to invent a rule that needs two things to be true at once (for example, "touching the door and you have the key"). This deepens what a "condition" really is.
• Random makes replaying fun. Use pick random -200 to 200 for where the apple appears, and pick random 1 to 3 to choose which of three objects falls next. Ask: "Why does a game feel more fun when it isn't exactly the same every time?" This connects a small code trick to good game feel.

Common mistakes & fixes

• Mistake: the if/then is outside the forever loop, so the game only checks once at the start. → Fix: drag the if/then inside the forever loop so the question is asked continuously.
• Mistake: the score explodes because the sprites stay touching for many frames. → Fix: after scoring, move the sprite away (reset its position) so it stops touching.
• Mistake: the touching [ ]? dropdown points at the wrong sprite (or the edge), so collisions never register. → Fix: click the dropdown and pick the exact sprite to collide with.
• Mistake: stop all runs before the "You Win!" sprite can speak, so no message shows. → Fix: put the say block before stop all, or add a short wait so the message appears first.
• Mistake: using = when they mean "reached or passed," e.g. if Score = 10 but the score jumped from 9 to 11. → Fix: use > or > combined with = thinking — if <Score > 9> catches it whether it lands on 10 or skips past.

Vocabulary

Resources

• Scratch — free, in your browser, no install (main tool).
• Scratch Wiki: If ... Then — friendly reference on decisions.
• Scratch Wiki: Touching — how collision detection works.
• Scratch Ideas page — starter guides for catch, maze, and dodge games.

Next session

Session 18 — Design & Showcase Your Game: students plan their own small game, build it using everything from this unit, playtest with a partner, and present it to the class — the unit's build project.