Week 6 — Sprites & Collisions: When Things Touch¶

At a glance


Date	Friday, September 18, 2026
Unit	1 — Think Like a Machine
Big idea	Games become interactive when sprites detect contact and respond.
Goal	Students use sprite kinds and overlap events to make a collectible, obstacle, or win/lose rule.
Student accounts needed	None. MakeCode autosaves in the browser.
Prep time	5 minutes

Why this lesson looks the way it does¶

This is the last direct-teach week before students design their own games. Collisions are the payoff because they connect every earlier concept: setup sequence creates sprites, events respond to contact, loops spawn or move objects, variables track score, and conditionals decide what happens next.

Do not try to teach physics. Teach kinds and overlap. Students need to understand that a Player touching a Food is different from a Player touching an Enemy because the programmer labeled those sprites differently. That idea scales well across the age span.

CSTA 2026 standards¶

Concept area	Connection
Algorithms & Design	Interactive rules can be decomposed into objects, events, and responses
Programming	Sprite kinds and overlap events control behavior when objects interact
Data & Analysis	Collision events can update score, lives, and other tracked data
Systems & Security	Game engines detect object interactions and expose them as programmable events
Computing & Society	Collision rules affect fairness, challenge, and accessibility for players

"I can…" objectives¶

By the end of today, students can say:

I can explain what a sprite kind is.
I can make something happen when two sprites overlap.
I can use a collision to change score, lives, or game state.
I can find an overlap event in JavaScript.

Teacher prep — the 5-minute version¶

Open https://arcade.makecode.com with a tiny player-and-coin project.
Be ready to demo on sprite of kind Player overlaps otherSprite of kind Food.
Write on the board:

Last Friday: Conditionals decide
Today: Collisions respond when things touch
Rule: Every important object needs the right kind
Decide pairs and plan the 0:24 Driver/Navigator swap.
Have paper circles or sticky notes available for unplugged sprite kinds.

Minute-by-minute run sheet¶

0:00–0:04 — Anchor¶

"Last Friday we taught the program to decide: if the score is high enough, then do something. Today we make the game react when things touch. This is the moment our pieces become a real game: player touches coin, score changes; player touches enemy, life changes; player touches door, level ends."

Ask:

"In a game you play, what is one thing that happens only because two objects touch?"

0:04–0:12 — Mini-lesson: kind matters¶

On the projector, create:

Player sprite, kind Player
Coin sprite, kind Food
Enemy sprite, kind Enemy
Overlap Player/Food → change score, move coin
Overlap Player/Enemy → lose life or game over

Think aloud:

"The computer does not see 'coin' the way we do. It sees a sprite with a kind. If I accidentally make the coin an Enemy, the computer will follow that label. This is like sorting objects into teams before writing the rules."

Toggle Blocks → JavaScript and point to sprites.onOverlap(SpriteKind.Player, SpriteKind.Food, ...).

"This line says exactly which two kinds are allowed to trigger the rule. That is why kinds matter."

0:12–0:36 — Paired build¶

Required build:

A controllable Player sprite.
At least one second sprite with a clear kind: Food, Enemy, Projectile, or a custom kind.
One overlap event.
A visible result: score changes, life changes, sprite moves, game ends, or level changes.

"Build one collision rule you can explain cleanly. If everything touches everything, it is not a game yet — it is a traffic jam."

Driver/Navigator swap at 0:24.

"Swap. New Driver, your job is to test the wrong collision too. What happens if the player touches the object that is not part of your rule?"

Tiered challenges¶

🟢 Starter (gr 5–6): Player touches Food → score goes up and the Food moves to a random place.
🟡 Builder (gr 7–8): Add an Enemy. Player touches Food → score up; Player touches Enemy → lose one life or restart.
🔴 Extender (gr 9–10): Toggle Blocks → JavaScript. Find sprites.onOverlap. Create a custom sprite kind such as PowerUp or Door, then write a separate overlap rule for it.

Good extension question

Ask older students: "Should this collision destroy the sprite, move it, or change its kind? Which choice makes your game easier to understand?"

Pick a project with two different collision rules.

"Tell us the two sprite kinds first, then the rule. Player plus what? What happens?"

Ask the room:

"If this rule is firing at the wrong time, what should we inspect first: the artwork or the sprite kind?"

Land on kind.

0:42–0:45 — Teaser + prompt¶

"Next Friday you stop following my build path. You design your own game using sequence, events, loops, variables, conditionals, and collisions. The prompt is below."

"Which two sprite kinds collide in your game, and what rule runs when they touch?"

🤔 Think About This¶

Watch for real-life collision rules: a checkout scanner sees a barcode, an elevator door senses an object, a car warns when something is close, a soccer ball crosses a goal line.

Ask: what counts as 'touching' in that system?

🔌 Unplugged Plan B — if the internet is down¶

Use labeled students and paper zones to model collisions.

Time	Activity
0:00–0:04	Anchor: conditionals decide; collisions respond when things touch.
0:04–0:12	Sprite kind tags. Give volunteers labels: Player, Food, Enemy, Door. When Player touches Food, class adds a point; when Player touches Enemy, class removes a life.
0:12–0:24	Rule writing. Groups create three overlap rules in the form `When ___ touches ___, then ___`. They must include at least two different sprite kinds.
0:24–0:34	Act the game. One group acts as sprites moving slowly around the room while another group calls out which rules fire.
0:34–0:41	Debug: intentionally swap a label so the wrong rule fires. Ask students to diagnose whether the problem is the rule or the kind.
0:41–0:45	Teaser original games and Think About This.

Keep movement slow and safe. The point is detection, not speed.

Common problems & fixes¶

Problem	Fix
Overlap never fires	Check that both sprites have the kinds named in the overlap block. Artwork does not determine kind.
Score skyrockets on one touch	The overlap may fire many times while sprites remain touching. Move or destroy the collectible after scoring.
Enemy acts like food	Inspect sprite kind assignment. Students often duplicate a sprite and forget to change kind.
Sprite disappears before students see what happened	Add a short sound or message before destroying/moving it, or slow the enemy down.
Extender custom kind breaks Blocks view	Use undo if needed. Custom kinds are powerful; keep names simple and no spaces.

Vocabulary¶

Collision — when game objects touch or overlap
Overlap event — code that runs when selected sprite kinds touch
Sprite kind — a label that tells the game what type of object a sprite is
Collectible — an object the player gets for points or progress
Enemy — an object that creates danger or cost for the player

Reflection — fill in after class¶

Did students understand kind vs artwork?
Which collision rules were clear enough for Week 7 projects?
Who needs a simpler design constraint next week?
Which students should be encouraged to use JavaScript custom kinds?

Next week: Week 7 — Build Your Own: Design Your Game