You have built games in Scratch and in MakeCode Arcade. Today those games come off your screen and into other people's hands.
You will play each other's games, give clear feedback, and then make one real improvement based on what you heard.
Open by naming the two things students already have: the Scratch projects from earlier in the strand and the Arcade games they finished and saved. Ask who can open at least one of those games right now. Anyone whose work is missing gets the recovery line in the next step, not a panic.
Keep this beat short. The time belongs to playing and improving.
Useful feedback is short and specific. For every game you give feedback on today you will say:
- One strength: something that already works well (controls that feel fair, a clear goal, a satisfying win or lose moment, a clever idea).
- One improvement: one concrete change that would make the game better (a bug to fix, a missing sound, a score that never resets, a level that is too hard or too easy).
Vague praise such as "it's good" does not help the maker. Name the thing.
Open one of the games you saved earlier so it is ready to share. If yours is missing, open the class sample or starter template your teacher shares so you still have a game to show.
Model one strength and one improvement on a sample game on the board (one of yours, or a volunteer). Make the contrast clear: "The controls are smooth" beats "nice game"; "the score never resets when you lose" beats "fix the scoring".
Grouping: put students in groups of two or three before the showcase starts. Mixed groups work well so Arcade and Scratch games both get played.
Missing projects: have a concrete fallback ready before the lesson: a class sample project students can open, or a two-minute starter template (a moving sprite and a goal) already shared the class way. Offer that fallback only; do not ask students to rebuild a full game in this beat. Do not let a missing file sideline anyone for the whole lesson.
In your group, take turns so every game gets played.
- The maker opens their game and stays quiet while the others play it for about 90 seconds.
- Each player then names one strength and one improvement for that game. Be specific.
- The maker writes both down (a short note is enough). Do not argue with the feedback yet.
- Rotate until every game in the group has been played and has feedback.
By the end of this round you should have at least one strength and one improvement written for your own game.
Run this as a structured rotation in groups of two or three. Keep each play-pass short (about 90 seconds of play, then one minute of feedback) so every game is reached. In a group of three, cap at two games if the clock is tight: every maker must still leave with at least one strength and one improvement written before you move on.
If time is short: stop the rotation and ensure every maker has at least one strength and one improvement written down. A finished round of feedback for every student beats an unfinished full rotation.
Look-fors
- Feedback names a concrete thing ("the enemy spawns too fast") rather than a vague feeling.
- Makers write the feedback down instead of defending the design on the spot.
- Quieter students still get a full turn as maker and as player.
If a group finishes early, have them replay the game that got the most interesting improvement idea and check whether they still agree.
Circulate with a simple prompt: "What is one thing that already works, and one thing you would change?"
Pick one improvement from the feedback on your game and make it.
Done looks like this:
- You chose a single, specific change (not a full redesign).
- You edited the game and ran it to check the change works.
- If something broke, you used the debugging routine: read the symptom, find the block or line, form a hypothesis, test it.
- You saved the improved game the way your teacher just said.
If you finish early, test the change once more with someone from your group and ask whether the improvement landed.
Keep the scope tight: one improvement only. Students who try to rebuild the whole game will run out of time and save nothing.
Common fruitful improvements at this stage: fixing a collision that never fires, resetting score or lives on restart, slowing a spawn rate, adding a clear win or lose message, or tightening controls that feel laggy.
Predict before run: before a student hits run on their edited game, pause them with one question: "What do you expect to see when this runs?" Get a short spoken prediction (for example, "the score should go back to zero when I lose"), then let them run and compare. That predict-then-check beat is the PRIMM moment for this lesson; it only works when the change is already on screen.
Name the debugging routine out loud if someone hits a break: symptom, find the block, hypothesis, test. Praise a clean test as much as a clever change.
Save call-out (final two minutes): stop the room and name the exact save method aloud (for example, File then Save to computer, or Save to the shared drive folder). Do not rely on students remembering a silent habit. Every student must save the improved game before you pull them back.
Pull back together. The useful feedback today was specific: it named a strength that already worked and one change worth making. The improvement that landed was the small, tested one, not a full rebuild.
Evaluating each other's work, and acting on one piece of feedback, is how programs get better after the first version runs.
Take two or three quick shares only: one strength someone heard that surprised them, and one improvement that was simple to make but changed how the game felt. Link it plainly to LO 1.9 (evaluate in a small group) and LO 1.8 (test the change).
Do not reopen the full showcase. Protect the last few minutes for reflect and recap.
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.