Ibnovate Scratch Creators
⏱ 60 minLive session · ages 7–11

Session 12 — Design & Showcase Your Game

Duration: 60 min · Format: live online · Ages: 7–11

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.

Before class — prep (5 min)

Agenda

Time Segment
0:00 Hook — every game started as one sentence (5 min)
0:05 Teach — the project cycle & designing your game (12 min)
0:17 Teach — how to playtest (watch, don't help) (10 min)
0:27 Activity — design, build, test & improve (25 min)
0:52 Showcase + reflection (5 min)
0:57 Wrap-up + homework (3 min)

0:00 · Hook (5 min)

Ask the class (chat or unmute):

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."


0:05 · Teach — The project cycle & designing your game (12 min)

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

The project cycle: plan, build, test and improve, over and over

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

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.


0:17 · Teach — How to playtest: watch, don't help (10 min)

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:

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.)


0:27 · Activity — Design, build, test & improve (25 min)

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.


0:52 · Showcase + reflection (5 min)

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

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

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


0:57 · Wrap-up + homework (3 min)


Teaching notes

Vocabulary

Term Meaning
Design Planning what your game is before you build it
Prototype The smallest playable version you make first
Playtest Watching someone else play to find what's confusing
Feedback Kind, specific notes that help you improve
Iterate To loop: build, test, improve, and repeat

Resources

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

Next session

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

Ibnovate · Build · Innovate
Type to search · Esc to close
Welcome back
Sign in to continue building.
Accounts are created by Ibnovate — ask your instructor for your login.
🔒