Session 12 — Design & Showcase Your Game

Duration: 60 min · Format: live online

Session goal: by the end, every student has designed their own game (one-sentence goal → sketch → blocks they'll need), built enough to play, playtested it with a partner, fixed the weakest part, and showcased it to the class with pride.

Soft skill focus — Confidence & presenting

Today's human skill: Confidence & presenting. The session ends with every student standing up to show the game they designed, so today the whole room is a stage.

• Build it in class: for the 30-second showcase, give each student the same frame — "In my game you… and one thing I improved is…" — model a calm, proud tone yourself, and teach the class to clap for every presenter.
• Reflection (wrap-up): ask "What is one tip you'd give someone who feels nervous about showing their game?"

Before class — prep

• Open Scratch in a tab and be ready to screen-share the editor.
• Have the diagram below open to share (the project cycle: plan, build, test, improve).
• Remind students they can remix anything they've built — the catch game, the maze, or the story — into their own idea. A fresh idea is welcome too.
• Have a simple playtest note card ready to model: "One thing I liked… / One thing that confused me… / One idea…"

Hook

Ask the class (chat or unmute):

• "Name your favourite game. Now say what you do in it, in one sentence."

Take three answers ("You jump over pipes." "You catch falling fruit."). Then reveal: "Every giant game started as one sentence like that. Today you are the game designer. You'll write your one sentence, sketch it, build it, let a friend test it — then make it better. That last part is the secret: real designers never get it perfect the first try. They loop."

Teach — The project cycle & designing your game

Share this diagram and trace the loop with your finger as you name each step:

Explain the loop — this is the big idea of the whole course:

• 1 · Plan. Write your game in one sentence (the goal), sketch it on paper, and list the blocks you'll need.
• 2 · Build. Make the smallest version that you can actually play — don't add everything at once.
• 3 · Test. Let someone else play. Watch where they get stuck.
• 4 · Improve. Fix the weakest part. Then loop back and test again.

Model a design out loud so they see the thinking:

1. One-sentence goal: "Catch 10 stars before the timer runs out."

2. Sketch (say what you'd draw): a bowl at the bottom, stars falling from the top, a score in the corner.

3. Blocks I'll need: when green flag clicked, forever, if touching, a score variable with change score by 1, glide/go to x y to drop the stars, a timer.

Ask: "Notice I didn't start with the blocks — I started with the one sentence. Why does that help?" (Answer: the sentence tells you what the game is, so you only build blocks that serve it — no getting lost.)

⚠ Watch for the "too big to finish" trap: a student wants a game with 20 levels, 10 enemies and a boss. Kindly shrink it: "What's the one thing the player does? Build that first — you can always add more if there's time." A tiny finished game beats a huge broken one.

Teach — How to playtest: watch, don't help

Explain: a playtest is when someone else plays your game while you watch quietly. The rule that makes it work is hard for kids: don't help, don't explain. If you have to tell them "no, click there," that's exactly the confusing bit you need to fix.

Model it. Screen-share a tiny game and role-play a tester with a volunteer. Show yourself staying silent while they hunt for the button. Then show the note you'd write:

1. One thing I liked: "The falling stars look great."

2. One thing that confused me: "I didn't know the arrow keys moved the bowl."

3. One idea: "Maybe show 'Use arrow keys!' at the start."

Explain the giver's job and the maker's job:

• Tester: be kind, specific and useful — point at the game, never the person. "The jump felt too slow" beats "it's boring."
• Maker: just say "thank you" and write it down. Don't argue or defend — you're collecting gold.

Ask: "Why is it better to watch someone play than to ask them 'was it good?'" (Answer: people say "yeah it's good" to be nice — but where they got stuck shows you the truth.)

Activity — Design, build, test & improve

Students run the whole loop on their own game. Keep the timer visible and call each phase.

Plan (5 min, on paper):

1. Write your one-sentence goal at the top.
2. Sketch the screen: sprites, where the score/timer go.
3. List the blocks you'll need (peek at your catch, maze or story project for the ones you know).

Build (10 min, in Scratch):

1. Build the smallest playable version — the one thing the player does. Get it working before adding extras.
2. Start from a new project, or remix one of your Unit 3 games as a base.

Test & improve (10 min, in pairs):

1. Swap: your partner plays your game while you watch in silence and they think aloud. Then swap.
2. Write your partner one note card — liked / confused / idea.
3. Fix the weakest part. Pick the one thing that confused your tester most and improve just that.

Circulate and ask: "What's your one sentence? What did your tester get stuck on? What are you fixing first?"

Debrief: ask for a show of hands — "Who changed something because of their playtest?" That's the loop working.

Showcase + reflection

No quiz today — you present. Go around the room (or breakout by breakout) and give each student 30 seconds:

• Say your one sentence: "In my game, you…"
• Play it live for the class from the green flag.
• Name one thing you improved after your playtest.

The class gives a round of applause (or claps in chat) after each. Then a quick reflection — one line each in the chat:

• "The best part of my game is…"
• "Next time I build a game, I will…"

Celebrate loudly. Every student finished a course and shipped a game of their own design — that's a real achievement.

Wrap-up + homework

• Ask one student to name the four steps of the project cycle (plan → build → test → improve).
• Homework — Polish & share: apply one more improvement from your playtest notes, then save and share your project on Scratch and add it to your portfolio. You are now a Scratch Creator.

Teaching notes

• Correct this misconception: "a good game is finished in one go." Professional games are tested and rebuilt dozens of times. Getting stuck, fixing, and testing again isn't failing — it is the job. Praise students who changed their game after a playtest more than those whose game "just worked."
• Fast finishers (extension): run a second loop — playtest with a different partner, since a fresh player finds fresh problems. Or add a start screen with the instructions their first tester was missing (a backdrop + say/broadcast from Session 11).
• Low-tech fallback: no devices? Students design a game on paper — one-sentence goal, a labelled sketch, and the "rules." They playtest the idea by walking a partner through how you'd play, and the partner circles anything unclear. The design → test → improve loop works perfectly with pencils; the computer just makes it playable.

Vocabulary

Resources

• Scratch editor — where students build, save and share (free, in the browser).
• Scratch Ideas page — starter cards and tutorials to spark or extend a game idea.
• Scratch Design Studio — themed design challenges to keep building after the course.

Practice set

Design-thinking and build tasks to run the whole loop. Work them easy → hard, at lab time or for homework. Answers follow each arrow.

1. One sentence. Write your game as a single sentence saying what the player does. → e.g. "You steer a fish to eat 5 smaller fish without touching the shark." (Any clear one-sentence goal is correct.)

2. Name the step. You just watched a friend play and you're writing down what confused them. Which step of the cycle is that? → Test (playtesting).

3. Shrink it (spot the trap). A friend's plan is "a racing game with 50 cars, 20 tracks and a shop." What's your kind advice? → Make it smaller — build one car on one track that you can drive first; add more only if there's time.

4. Give a good note. Turn "your game is boring" into a useful playtest note. → Be specific and about the game, e.g. "There's nothing to do for the first few seconds — maybe start the action sooner."

5. Make it (build task). Build the smallest playable version of your one-sentence game — just the one thing the player does, working from the green flag. → A single mechanic that runs, e.g. when green flag clicked → forever → if key pressed → move; extras come later.

6. Improve the weakest part (harder). Your tester didn't know the game had started. Name one change and the blocks for it. → Add a start message — a backdrop or sprite that does when green flag clicked → say "Press SPACE to start!" for 2 seconds, or a when space key pressed → broadcast [start] so the game begins on a clear signal.

Going deeper (optional)

Optional — for a class that has shipped a game and wants to think like a real studio.

The loop never really ends. Notice the cycle diagram is a circle, not a line. After "improve," you go back to "test." Real games get updated for years — every patch is another trip around the loop. The skill you practised today isn't "make a game"; it's make it, then make it better — and that works for stories, science projects, and anything you'll ever build.

Watching beats asking. The most useful thing a designer owns isn't a fancy tool — it's the habit of watching a real person use their thing without helping. Every confusing moment you see is a gift. Encourage students to test with someone who has never seen their game (a younger sibling is perfect) — beginners find the problems experts have stopped noticing.

Common mistakes & fixes

• Mistake: Designing a game too big to finish, so nothing works by showcase time. → Fix: build the one core action first; treat every extra as a bonus, not a requirement.
• Mistake: Helping or explaining during a playtest, hiding the real problems. → Fix: stay silent, let the tester struggle, and write down exactly where they got stuck.
• Mistake: Giving vague feedback like "it's good" or "it's boring." → Fix: be specific and point at the game — "the bowl moved too slowly," not "it's bad."
• Mistake: Arguing with or ignoring a tester's notes. → Fix: just say thank you and write it down; you can decide later what to change.
• Mistake: Trying to fix everything at once and breaking the game. → Fix: change one thing, test again, then change the next — small steps around the loop.

Next session

Projects & Assessment: put everything together — build your capstone game, then earn your certificate.