Computing · Year 3

Active learning ideas

Developing a Simple Interactive Game

Active learning helps Year 3 students grasp event-driven programming by letting them experience cause and effect firsthand. Moving from abstract blocks to tangible interactions builds confidence in sequencing logic and debugging real-time responses.

• National Curriculum Attainment Targets
• KS2: Computing - Programming
• KS2: Computing - Information Technology

• 25–45 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Plan-Do-Review
• 25 min · Pairs

Pair Programming: Game Storyboarding

Pairs select a game theme and draw storyboards showing start screen, controls, goals, and end states. They list events like 'spacebar jump' and outcomes. Present to another pair for quick feasibility checks before coding.

Construct a simple interactive game using event-driven programming.

Facilitation Tip

During Pair Programming: Game Storyboarding, have each pair use sticky notes to map out their game’s events and outcomes before coding begins.

What to look for

Ask students to demonstrate their game to the teacher. The teacher will ask: 'What happens when you press the [specific key]? How does the score change when [specific event] occurs?'

• Remember
• Apply
• Analyze
• Self-Management
• Decision-Making
• Self-Awareness

Activity 02

• Plan-Do-Review
• 45 min · Small Groups

Small Groups: Core Mechanics Build

Groups assemble basic code for one mechanic, such as sprite movement and collision detection. Test in rounds, logging issues on sticky notes. Swap mechanic with another group to integrate into full games.

Critique your game's design for user-friendliness and playability.

Facilitation Tip

For Small Groups: Core Mechanics Build, rotate among groups every 10 minutes to spot logic gaps or missing event handlers.

What to look for

Students play a partner's game and complete a short feedback form: 'What was your favorite part of the game? Was it easy to understand how to play? Suggest one way to make the game even better.'

• Remember
• Apply
• Analyze
• Self-Management
• Decision-Making
• Self-Awareness

Activity 03

• Plan-Do-Review
• 35 min · Whole Class

Whole Class: Playtest Critique

Students share games via projector or shared drive. Class plays each, using a simple rubric for controls, fun, and clarity. Creators note top feedback and commit to one fix on the spot.

Explain the most challenging aspect of creating your game and how you overcame it.

Facilitation Tip

During Whole Class: Playtest Critique, project one student’s game and model how to give specific feedback about controls and scoring.

What to look for

Facilitate a whole-class discussion using the prompt: 'What was the hardest part of making your game? Share one problem you solved and how you solved it.'

• Remember
• Apply
• Analyze
• Self-Management
• Decision-Making
• Self-Awareness

Activity 04

• Plan-Do-Review
• 30 min · Individual

Individual: Debug and Reflect

Each student runs their game 10 times, noting bugs in a log. Code fixes, then explain one challenge and solution in a short video or written note for portfolio.

Construct a simple interactive game using event-driven programming.

What to look for

Ask students to demonstrate their game to the teacher. The teacher will ask: 'What happens when you press the [specific key]? How does the score change when [specific event] occurs?'

• Remember
• Apply
• Analyze
• Self-Management
• Decision-Making
• Self-Awareness

A few notes on teaching this unit

Teach this topic by modeling iterative design: start with minimal viable code, playtest immediately, and revise based on evidence. Avoid rushing to visual polish before the core mechanics work. Research shows that young learners solidify concepts through repeated testing and peer explanation, so build time for reflection into every session.

Students will design a working game prototype with responsive sprites, clear scoring, and a win/lose condition. They will test, identify issues, and explain how events control gameplay. Success includes sharing their process and receiving peer feedback.

---

Watch Out for These Misconceptions

• During Pair Programming: Game Storyboarding, watch for students who treat the storyboard as a linear script instead of a set of independent events.

  Have pairs label each sticky note as an event, then physically act out their sprites’ responses to reinforce parallel triggers and broadcasts.

• During Small Groups: Core Mechanics Build, watch for students who skip playtesting until the end.

  Prompt each group to test one mechanic after every 5 minutes of coding and record glitches on a shared ‘bug list’ poster.

• During Whole Class: Playtest Critique, watch for students who focus only on graphics or sound effects.

  Guide the discussion back to responsiveness and scoring by asking, ‘Does the sprite move the way you intended when you press the key? What score change happens when the sprite touches the target?’

---

Methods used in this brief

• Plan-Do-Review