Session 18 — Design & Showcase Your Game

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

Session goal: by the end, students have planned, built, playtested, and presented their own small Scratch game using everything from this unit.

Before class — prep (5 min)

• Open Scratch and click Create — you'll screen-share and live-build a quick example while students build their own.
• Have a starter idea ready to show the shape of a finished game: a tiny "dodge the falling rocks" game — arrow keys to move, score for surviving, lose a life on a hit, "Game Over" at zero lives.
• Prepare a simple one-line game plan on screen to model the planning step (goal, controls, win, lose).
• Ask students to open Scratch. They may start fresh or remix their catch game from Sessions 16–17.

Agenda

0:00 · Hook (5 min)

Ask the class and take a few answers (chat or unmute):

• "If you could invent any game, what would the player try to do — catch, dodge, race, collect?"
• "What would make someone say 'one more go!' after they play it?"
• "Today you are the game designer. What's the first thing a designer should do — start coding, or make a plan?"

Let them guess, then reveal: today you design and build your own game from start to finish — plan it, build it, test it, and show it off.

0:05 · Teach — Plan before you build (12 min)

Explain: great game-makers plan first so they don't get lost. A small game needs just four things. Write this frame on your shared screen and fill it in for your example:

• Goal — what is the player trying to do? (Catch 10 apples. / Dodge the rocks for 30 seconds.)
• Controls — which keys make things happen? (Arrow keys move; space to jump.)
• Win — what makes the player win? (Score reaches 10.)
• Lose — what makes the player lose? (Lives reach 0.)

Demo in Scratch: show your one-line plan, then point to how each part maps to blocks students already know:

• Goal + controls → sprites and key-press events (Session 15).
• Keeping score, keeping it running, messages → variables, forever loops, broadcasts (Session 16).
• Win and lose → if/then and touching (Session 17).

⚠ Watch for over-scoping: students often plan a giant game with ten levels and bosses. Steer them to one simple, finished game. Say: "A small game that works beats a big game that's broken." Cap it at one screen, one goal, one win, one lose.

Ask: "In one sentence, what is your game's goal?" Have three students share aloud before anyone opens blocks.

0:17 · Teach — Build, then playtest (8 min)

Explain: after building, real designers playtest — they let someone play and watch what happens without helping. Model it live:

Demo in Scratch: run your example game and "playtest" it out loud:

• "Can the player tell what to do without being told? If not, add a say [Use arrow keys!] at the start."
• "Is it too easy or too hard? Change the speed or the number of lives."
• "Does anything break? Score not counting, sprite stuck, message not showing — fix the biggest bug first."

Give them a simple playtest routine to use with a partner later:

1. Partner plays for one minute; the builder just watches (no helping).
2. Builder asks: "What did you think you were supposed to do?"
3. Builder writes down one thing to fix and fixes it.

Key point to land: plan → build → playtest → improve. A game is never "done" on the first try — testing makes it better.

Your game moves through a cycle: plan, build, test, improve, present — the make-a-game cycle.

Ask the class: "Why should the builder stay quiet while a partner playtests?" (Answer: to find out if the game explains itself; if you have to explain it, players in real life won't get it.)

0:25 · Activity — Build your game (25 min)

This is the unit's build project. Students design and build their own small game. Screen-share your example as a reference but keep encouraging their ideas.

Their checklist (share on screen):

1. Plan (2 min): write your goal, controls, win, and lose in one or two lines.
2. Sprites & stage (5 min): pick a player sprite, at least one other sprite (target or enemy), and a backdrop.
3. Controls (5 min): move the player with key-press events.
4. Score & loop (5 min): add a Score variable and a forever loop that keeps the action going.
5. Win & lose (5 min): add if/then with touching for scoring and for losing; add a win and a lose message with broadcasts.
6. Polish (3 min): a start message telling the player what to do, a sound, and tuned difficulty.

Circulate for (breakout rooms or shared screens): - Students stuck choosing an idea — offer three quick templates: catch (collect falling things), dodge (avoid falling things), maze (reach the goal without touching walls). - Missing an event hat — a sprite that won't move usually needs a when [key] pressed block. - No win or lose yet — remind them a "game" needs a way to end; help them add one if/then. - Over-scopers — gently trim: "Get one level fully working first, then add more if there's time."

Encourage every student to reach a playable state and do at least one partner playtest before the showcase.

0:50 · Showcase + check for understanding (7 min)

Invite 3–4 students to screen-share and give a 30-second demo: name the goal, show it being played, and name one thing they'd add next. Applaud each one.

Then confirm understanding — ask aloud or in chat. Answer key (for you):

1. What four things did you decide in your game plan? → Goal, controls, win, lose.
2. Which blocks did you use to make the player win or lose? → If/then with touching (and a score/lives check), plus a broadcast to show the win/lose message.
3. What is playtesting, and why does it help? → Letting someone play while you watch; it shows what's confusing or too hard so you can fix it.

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

• Ask one student to finish: "The best part of designing my own game was…"
• Homework — Share & Polish: show your game to one person at home, watch them play, and add one improvement based on what you saw. If you like, click Share in Scratch to publish it. Bring your finished game to Session 19.

Teaching notes

• Correct this misconception: "a bigger game is a better game." Reframe: a small, finished, fun game is a real success; professionals ship small and add later. Celebrate anything playable.
• Fast finishers (extension): have them add a second level (switch backdrop and speed up when the score hits a target), a high-score variable that remembers the best run, or a title screen sprite that says the game's name and waits for a key to start. Challenge: add a sound track with a forever → play sound … until done loop on the stage.
• Low-tech fallback: if a student can't build, have them design on paper — draw the game screen, label the sprites, and write the four plan items — then pair up to help a partner build that plan in Scratch. Designers and builders both count.

Practice set

Assign in class or as homework. Answers are for you, after the arrow.

1. Write a one-line plan for a game: goal, controls, win, lose. → Any clear plan, e.g. "Catch 10 stars with arrow keys; win at 10; lose if you miss 3."
2. Add a start message that tells the player what to do. → On the player sprite: when green flag clicked → say [Use arrow keys to move!] for 2 seconds.
3. Make your game end with a clear win screen. → if <Score = 10> then broadcast [you win] → stop [all]; a sprite says "You Win!" on receive.
4. Change one thing to make your game a little harder, then test it. → e.g. increase falling speed, reduce lives, or raise the score needed to win; play it to check.
5. Playtest with a partner and write down one thing to improve. → Partner plays for a minute while the builder watches; builder notes one confusing or too-hard part.
6. Add one polish item: a sound, a background, or a second sprite. → Any of: play sound on an event, a chosen backdrop, or an extra sprite with its own behaviour.

Going deeper (optional)

• Give feedback that helps. Teach a tiny review frame for the showcase: "One thing I liked… one thing I'd add…" Have listeners use it after each demo. Kind, specific feedback is a real designer skill and keeps the showcase positive.
• Remix and credit. Explain that in Scratch you can remix someone's project to learn from it, and that the original maker is always credited. If they published their game, show where the "remix tree" appears. This introduces sharing and giving credit — good habits for any maker community.

Common mistakes & fixes

• Mistake: planning a huge game and running out of time with nothing playable. → Fix: cap it — one screen, one goal, one win, one lose; add extras only if time remains.
• Mistake: no way to win or lose, so the "game" just moves forever. → Fix: add at least one if/then that ends the game with a broadcast and stop all.
• Mistake: the player can't tell what to do. → Fix: add a say block at the start with the controls and the goal.
• Mistake: forgetting to reset Score and Lives on the green flag, so old numbers carry into the new game. → Fix: start every play with set [Score] to 0 and set [Lives] to 3.
• Mistake: skipping playtesting and assuming it's fine. → Fix: always let a partner play while you watch silently — the bugs and confusing bits show up fast.

Vocabulary

Resources

• Scratch — free, in your browser, no install (main tool).
• Scratch Ideas page — starter guides for catch, dodge, and maze games.
• Scratch Starter Cards — printable one-page project ideas.
• Scratch: How to Share a Project — steps to publish a game safely.

Next session

Session 19 — Your First Web Page (Unit 5 — Make a Website): students start a brand-new unit and build their very first web page — the beginning of making things for the web.