Activity 01
Pair Programming: Mouse Chase Game
Pairs create a sprite that follows the mouse only when within 100 pixels, using 'if touching mouse-pointer?' and 'distance to mouse < 100' conditions. They add a score variable that increases on contact. Test and swap roles to debug.
Explain how sensors act as the 'eyes' of a computer program.
Facilitation TipDuring Pair Programming, circulate to ensure both partners take turns coding and testing, reinforcing teamwork and shared debugging.
What to look forPresent students with a simple code snippet using an 'if-then' block and a sensor. Ask them to predict what the sprite will do when the condition is met (e.g., 'If touching color red, then say Hello'). Then, have them test the code to verify their prediction.
AnalyzeEvaluateCreateDecision-MakingSelf-ManagementRelationship Skills
Generate Complete Lesson→· · ·
Activity 02
Small Groups: Color Platform Jumper
Groups program a sprite to jump only when touching a blue color platform, incorporating gravity simulation with forever loops and if-else for direction. Record successes in a shared log. Present one feature to the class.
Analyze the relationship between a physical input and a digital decision.
Facilitation TipIn Color Platform Jumper, encourage groups to swap sprites and platforms to test how size and position affect touch detection.
What to look forOn a slip of paper, ask students to write one example of a sensor a computer program could use and one action that program might take based on that sensor's input. For instance, 'Mouse position sensor, program moves sprite to follow mouse.'
AnalyzeEvaluateCreateDecision-MakingSelf-ManagementRelationship Skills
Generate Complete Lesson→· · ·
Activity 03
Whole Class: Condition Debug Relay
Display buggy code on the board; teams suggest fixes for sensing errors like wrong color detection. Vote on best solution, then implement class-wide. Discuss why conditions failed.
Construct a program for a sprite to only move when it is touching a specific color.
Facilitation TipFor Condition Debug Relay, provide identical starter code to each small group but vary the condition values so students compare solutions and explain differences.
What to look forAsk students: 'Imagine you are designing a game where a character needs to collect coins. How could you use a sensor to make the character pick up a coin only when it is touching the coin sprite?' Discuss their ideas, focusing on the conditional logic.
AnalyzeEvaluateCreateDecision-MakingSelf-ManagementRelationship Skills
Generate Complete Lesson→· · ·
Activity 04
Individual: Sensor Extension Challenge
Each pupil adds two new conditions to their game, like pausing on edge touch or speeding up near mouse. Self-assess with a checklist and peer review.
Explain how sensors act as the 'eyes' of a computer program.
Facilitation TipDuring Sensor Extension Challenge, ask students to annotate their code with comments that describe each condition’s purpose before they test.
What to look forPresent students with a simple code snippet using an 'if-then' block and a sensor. Ask them to predict what the sprite will do when the condition is met (e.g., 'If touching color red, then say Hello'). Then, have them test the code to verify their prediction.
AnalyzeEvaluateCreateDecision-MakingSelf-ManagementRelationship Skills
Generate Complete Lesson→A few notes on teaching this unit
Start by demonstrating how a single if-then block changes behavior when a condition is met versus not met. Avoid explaining sensor logic in abstract terms—instead, let students experience the gap between expectation and reality through immediate testing. Research shows that debugging live code builds stronger conceptual understanding than reading about conditions alone.
By the end of these activities, students will consistently use if-then blocks with precise sensor conditions to control sprite behavior. They will predict outcomes, test hypotheses, and explain why a condition was or was not met during gameplay.
Watch Out for These Misconceptions
During Pair Programming, watch for students who set vague proximity triggers like 'if near mouse' without defining what 'near' means in pixels.
Guide partners to replace broad terms with concrete code, such as 'if distance to mouse < 50', then ask them to measure and adjust the value collaboratively.
During Color Platform Jumper, watch for groups that assume edge contacts count as touches without testing partial overlaps.
Have students resize sprites and platforms to see how hit detection behaves at boundaries, then adjust the 'touching color' condition’s tolerance if available.
During Condition Debug Relay, watch for students who believe outputs change randomly each run, leading to unnecessary retests.
Replay the same input sequence side-by-side with different groups to prove deterministic behavior, then discuss why identical inputs always yield identical outputs.
Methods used in this brief