1 - Getting Started ~5 mins
Open the game you saved earlier in this project. Does your character already move left and right? Is there a coin or a score yet?
Name one thing a visitor would still wish the game could do. Today we will add that missing piece, fix any mistakes we find, tidy the code, and show this version to a partner.
Have every pair open the project they saved earlier in this project before you start. If a pair cannot find their save, pair them with a neighbour whose game is working so nobody is stuck watching a blank screen.
Hook question: What is one thing your game still cannot do that a visitor would notice? Take three quick answers (a score, a forever check, a button jump, a win or lose moment). Keep the language plain here; introduce loop and event properly in the next step, and model bug and simplify during the demo.
Nature of STEM: Coders almost never ship the first version. They test, find bugs, strip clutter, and share so other people can try the work. Irish game studios use the same cycle of build, test, fix and share. Today's bar is one solid improvement plus a tidy-up, not a polished commercial game.
2 - Loops and Events ~6 mins
A loop keeps something useful happening again and again, for example checking every moment whether the sprite has touched a coin. Look at the forever block on the board: that shape is a loop.
An event waits for something to happen, such as a button or a bump, then runs its blocks, for example the sprite jumps when A is used. Look at the on A button block on the board: that shape is an event.
Watch for both ideas when we model next. You will choose one of them later when you improve your own game.
Keep the board short. Before you define the words, open MakeCode Arcade and briefly point at two block shapes only (do not build the full feature yet): the purple forever block under Loops, and the on A button block under Controller. Leave those two shapes visible while you say the definitions so loop and event attach to something pupils can see.
Focus pupils on loop and event as today's two taught concepts. Treat bug and simplify as practice language you will model in the demo only — do not define them on the board here. Use the table below yourself; do not project it.
| Concept | Why it matters | Example |
|---|---|---|
| Loop — a set of instructions that repeats so the game keeps doing a useful action without rewriting the blocks | Games need things to keep happening (checking for coins, enemies moving) every moment someone is using the game | A forever loop that checks whether the sprite has touched a coin and adds a point when it has |
| Event — something that happens which makes a part of the program run | People expect the game to react when they use a button or when two sprites meet | When A is used the sprite jumps; when the sprite hits a wall a sound plays |
| Bug (model in demo, not board glossary) — a mistake in the program that stops it doing what you meant | Finding and fixing bugs is normal coding work, not a sign the maker failed | The sprite moves left when right is used because the wrong arrow is linked to the move block |
| Simplify (model in demo, not board glossary) — remove blocks that do nothing useful so the program says the same thing more clearly | Fewer leftover blocks make the next fix faster and help a partner understand your game | Deleting a sound block that never runs, or two move blocks that cancel each other out |
Misconception to head off: pupils often think a bug means they are "bad at coding". Revoice during the demo: a bug is information. Real coders expect bugs and hunt them on purpose.
Misconception: more blocks means a better game. Challenge that in the demo: a short, clear program that works beats a long messy one that almost works.
Do not force the loop-versus-event choice in this step. Pairs decide after they have run their own saved game once in the main build step.
3 - Watch the Next Steps ~7 mins
Watch the board. We will add one improvement to a sample game, run it, find a mistake on purpose, fix it, and remove one block that does nothing useful.
Today's modelled feature is a jump on A. Before we run: if A does nothing, or if the sprite flies off and never comes back, what will you notice on screen?
Before the Lesson
- Open MakeCode Arcade on the IWB with a sample project that already has a player sprite and basic left/right movement (the Part 1 base from earlier in this project).
- If your course injects a partner MakeCode Arcade source lesson, prefer those board steps mapped onto the two labelled routes below. If it does not, use the fallback model below so you can teach from this lesson alone.
Fallback model (use when no partner source is open)
Default sample: one player sprite that moves with the arrow keys. Optional: one coin sprite and a score of 0 already on screen if you want Route A visible as a reminder.
Deep-model one route only (Route B — jump on A). Leave Route A as a short static board label for pairs who already have a coin and score. Do not live-build both routes in this slot.
Route B palette path (say it as you drag):
- Sprites → set mySprite ay to 300 (acceleration y / gravity so the sprite falls back after a jump).
- Controller → on A button pressed.
- Inside that event, Sprites → set mySprite vy to -150 (vertical speed upward so the sprite jumps).
Run: using A should make the sprite jump and land. Without gravity first, the jump either does nothing lasting or sends the sprite off-screen with no return.
Deliberate bug to show: first wire the jump to B instead of A. Ask the class what they notice (sprite ignores A). Fix with one careful change (move the blocks into on A). Name the words bug and fix aloud here for the first time.
Simplify: delete a leftover play sound block that is not inside any loop or event so it never runs. Run again to prove the game still works. Name simplify aloud as you delete, and say in plain words: we removed a block that does nothing useful.
Route A — static board label only (do not live-build unless a pair later needs it): Route A: Loops → forever; inside it Sprites → if player overlaps coin → Info change score by 1 → move or destroy the coin. Warn on the label that scoring without relocating the coin makes the score rocket every frame.
Leave short labelled reminders of both routes on the board for the whole build step: Route B (default): Sprites set ay 300, then Controller on A → set vy -150; Route A (if you already have coin + score): forever + overlap → score + move coin.
Pre-run question (match the deep-modelled route)
- If A does nothing, what will you notice? (sprite ignores A)
- If gravity (ay) was never set, what might you notice? (sprite flies off and never comes back)
- Circle the matching prediction option before you run.
Modelled cycle (say it aloud)
I wonder… what would make this game feel ready to show: a button that makes the sprite react?
I predict… if I wire jump to A with gravity on, using A should lift the sprite and it should fall back.
I test… add the event using the Route B path above. Run it. Then show the deliberate bug (jump on B) so the class can hunt it.
I observed… name what actually happened on screen (sprite ignored A; or sprite flew off with no return).
I think… the bug was X, so I change Y. Run again. Then delete one block that does nothing useful and show the game still works — that is simplify.
What to expect: the class will call out the bug faster than they can name the fix. Praise the notice first, then the fix. Fold the watchers in: Are they right? What would you try next?
Low-cost / no-kit: if devices are short, run the whole model and the first build on the IWB with pairs taking turns at the board while others track the bug hunt in their Investigation Journal.
4 - Extend, Debug and Simplify ~25 mins
In pairs, open your saved game from earlier in this project and run it once.
One solid improvement and a tidy-up is enough. Real makers do not finish everything in one go.
Follow this checklist on the board:
- Choose your route (Route B is the default if your save is movement-only; choose Route A only if you already have a coin and score).
- Add that one change.
- Run the game.
- Fix one thing if needed, or name one careful check you ran.
- Tidy: remove one block that does nothing useful, then run again.
- Ready to demo: what you added, a bug or careful check, and the unused block you removed.
Setup
Pairs on tablets or laptops with MakeCode Arcade. Leave both board route labels visible for the whole build, with Route B marked as the default:
- Route B (default): Sprites → set ay to 300; Controller → on A button pressed → set vy to -150 (jump).
- Route A (only if coin + score already exist): Loops → forever; inside it if player overlaps coin → change score by 1 → move or destroy the coin.
Pairs pick one route first; they do not need both. If a partner MakeCode source is injected, map its steps onto these two labelled routes so the agency claim matches what is on screen.
Movement-only saves: steer them to Route B by default. Do not ask them to build a coin and score before they can start. Adding a basic coin sprite and a score of 0 is stretch only, for pairs who finish Route B cleanly and want a second small loop later.
Say once at the start of the build: If your save is movement-only, take Route B. Route A is for pairs who already have a coin and score.
Oral reminders (keep off the dense board list)
- Bug size examples if something looks wrong: sprite ignores A; score stays at 0; score rockets while standing on the coin.
- Route A rocket fix: move or destroy the coin inside the if (or score only once per touch).
- Tidy language pupils heard in the demo: remove a block that does nothing useful (not a new word to learn on the board).
Success look-fors while you circulate
- The pair can point to the new loop or event and say what it does in plain words.
- They ran the game more than once and can name a bug they found or one careful check they made when testing (even a small one). Either path meets the outcome.
- They deleted or tidied at least one unused or duplicated block.
- The game still runs after the tidy-up.
- Route A only: if the score flies up while the sprite stands on the coin, guide them to move or destroy the coin inside the if.
Support
If a pair is lost, ask them to say the game's job in one sentence, then find the single block stack that should do that job. Point at the matching board label: "jump needs gravity plus an on-button event" (Route B) or "score needs a loop that keeps checking" (Route A). If the project will not open, they may fork a neighbour's working base and still complete the extend–debug–tidy cycle.
Stretch
Confident pairs may add a second small event (a sound on score, a simple win screen) only after the first change works and the unused blocks are gone. Movement-only pairs who finish Route B may then try a basic coin + score and Route A as stretch.
Agency
Pairs choose whether their main improvement is a loop or an event (within the Route B default / Route A if-ready rule), and which leftover blocks to remove. The board supplies both how-tos; the pair owns the what.
Safety: carry devices with two hands; no food or drink at the desks; coil cables so nobody trips.
Timing cue: at about 15 minutes, call a 30-second freeze: everyone runs their game once and whispers to their partner one thing that still feels buggy or one check they are glad they ran.
5 - Record the Bug and the Change ~8 mins
On your Investigation Journal page, record three things using these starters:
- We added… so that a visitor can…
- The bug was… We fixed it by… (or: The check we ran was…)
- We removed… because…
This is the paper beat. Pupils use the Investigation Journal page (sheet type InvestigationLog) for the technical record (feature added · bug or careful check · fix · unused block removed). No separate written reflection sheet: keep pride and "what felt tricky" for the spoken close.
If a pair's game still misbehaves, they still record honestly: what they tried and what remains broken. That is real debugging evidence, not failure. If their first change worked cleanly, the middle starter can name the careful check they ran instead of inventing a failure. Either path meets the learning outcome.
Circulate and check that each journal names a concrete change, not only "we made it better". If a pair confuses observation with inference, prompt gently: Write what you saw (score stayed at 0) on one line, and what you think it means (the overlap block never ran) on the next.
Unlock the full learning experience
You're previewing this lesson. Get full access to this lesson and hundreds more — each one ready to teach, with interactive activities, printable resources and pupil progress tracking built in.
This lesson is copyright of Coding Ireland 2017 - 2025. Unauthorised use, copying or distribution is not allowed.