Skip to main content

Stage 9: Final Build and Demo Practice

Course progressStage 9 of 10
~120 min
Your two tools

Keep both tabs open all week. Open in a new tab — don’t use the buttons in this page to leave the course.

Train your AITeachable MachineOpen in a new tab ↗Build the gameRAISE PlaygroundOpen in a new tab ↗
Build

a clean, bug-free game and a demo script you can say from memory

Learn

how to test your own work like a real game designer

Ship

a parent-demo-ready project saved in RAISE

Teacher demo

Show the room:

  1. Open your own game. Play one full round. Point out one thing that's a little off — "the title screen flickers" or "the catch sound is loud".
  2. Fix it. Show the fix being a small, named change.
  3. Read your six-line demo script out loud, looking at the screen. Don't read it from paper — practice from memory.
  4. Say: "Tomorrow we run this in front of your parents. Today is the day we make sure it doesn't surprise us."

The big idea​

Stages 1–8 were about building. Today is different — today is about finishing.

Finishing means three things:

  • Testing your game on purpose, three times, looking for what's broken.
  • Picking one bug and fixing it (not all of them — the most important one).
  • Practicing your demo so you sound calm and confident on Friday.
   Build phase  (Stages 1–8):  "Does the game run?"
   Finish phase (Stage 9):     "Is the game ready for someone else to see?"
   Demo phase   (Stage 10):    "Show it."

This is the most important non-Friday day of camp. A game that almost works is harder to demo than a smaller game that fully works. Today we make sure your game is in the second group.

You'll also write a demo script — six short sentences you'll memorize and say while you show your game. The script makes you sound prepared. Even if something glitches, the script keeps you talking — and parents won't notice the glitch.

New words
playtest
playing your own game on purpose to find problems
bug
something in your game that's broken or weird
debug
find a bug and fix it
demo script
the short speech you say while showing your game
rehearse
practice your demo out loud, like an actor
Before you start

Your Stage 8 game should be themed and customized. Score, timer, win/lose, and your AI control should all work.

Build it​

Step 1 — Play three full rounds on purpose​

Don't play to win. Play to find what's broken.

Round 1: try to win. Play your best. Did everything work? Did the win sound play? Did the message appear?

Round 2: try to lose. Stand still. Make wrong hand signs. Don't try to catch anything. Did "TRY AGAIN" appear? Did the timer count all the way to 0?

Round 3: try to break it. Press space. Press q. Wave your hand wildly. Walk away from the camera. Hold two hand signs at once. Click the green flag while the game is already running.

For each round, write down anything that looked off — a sound that didn't play, a sprite that froze, a number that did something weird, a moment of confusion.

You should end with a list of at least 2 things.

Step 2 — Pick your worst bug​

Look at your list. Pick one bug to fix. Just one. The worst one.

The worst bug is the one a parent would notice in the first 10 seconds. Common ones:

  • "The cat sometimes flies off the stage and never comes back."
  • "The score keeps going up after the timer ends."
  • "The catch sound plays 10 times for one catch."
  • "The title screen never goes away."

Pick that one. Don't pick more.

Step 3 — Fix the bug​

Open your code. Find the script for the broken behavior. Try one of these tactics:

  • For a sprite flying off-screen: clamp its position. Inside its forever loop, add if x position > 200 then set x to 200 and similar for the other edges.
  • For score going up after the timer: the change score by 1 is still firing. Move the catch detection inside if (timer > 0) then.
  • For sounds playing too many times: add wait 0.5 seconds after the play-sound block, or use a state variable like is_catching to debounce.
  • For a stuck title screen: check that the broadcast (start game) actually fires when you press space. Test with say "test" in the title sprite's script.

Run a fresh round after your fix. The bug should be gone.

Step 4 — Playtest with another camper​

Find a partner. Trade laptops for 60 seconds.

While your partner plays your game:

  • Don't talk. Don't explain controls. Don't fix anything mid-play.
  • Watch their face. Where do they smile? Where do they look confused?
  • Watch what they do. Did they figure out the hand signs without help?

After 60 seconds, ask them ONE question: "What's the first thing you would change?"

Listen. Take notes. You don't have to make the change — but their reaction is data. A parent watching your demo will react the same way.

Step 5 — Write your demo script​

Tomorrow you'll talk while showing your game. Write down what you'll say. Use this template:

1. My game is called __________________________.

2. I trained my AI to recognize ______________________
   (the four hand signs: Rock, Paper, Scissors, and Nothing).

3. My AI controls __________________________
   (the sprite — what kind of character did you pick?).

4. The hardest part was __________________________
   (training the model? customizing? the timer? debugging?).

5. My favorite part was __________________________
   (the magic moment when something clicked).

6. Now I will show you my game.

Write your real answers. Don't leave any blank.

Step 6 — Practice the script out loud​

Read your script out loud at your seat. Then read it again with your game open behind you. Then read it again without looking at the paper.

You should be able to say all 6 sentences from memory by the end of camp today.

Save your project one more time.

Understand it​

The reason we playtest three different ways is that "play to win" only tests one path. A real player tries things you didn't think of — they hold a key down, they don't read the instructions, they expect things you didn't build. Three different tests catch three different kinds of bugs.

Fixing one bug is a discipline. If you fix three things at once and the game still feels off, you don't know which fix caused which result. Pros change one thing at a time and re-test. We learned this in Python Arcade Stage 9 too — same idea, different game.

The demo script matters because Friday is going to feel different. The room will be loud, parents will be standing behind you, your hand might shake. The script gives you something to hold onto. Even if your AI glitches mid-demo, you keep talking through your script and the parents barely notice.

The partner playtest is the most honest feedback you'll get. A coach is too nice; you've been staring at your own game too long. A peer who has never seen it will react the way a parent will. Take the data, even if their first reaction stings a little. "What's the first thing you would change?" is the most useful question in game design.

Try this​

Learning beat

Try this

Three short experiments. Predict before you run, then test your guess.

Predict first

Imagine handing your laptop to your parent right now, no demo script, no explanation. Predict the first wrong thing they would do. (Forget to press the green flag? Hold up the wrong hand sign? Click somewhere?) Write it down. Tomorrow, check if you were right.

Compare

Read your demo script silently. Now read it out loud. Did it feel different? Reading out loud finds awkward sentences — fix the awkward ones now, not in front of an audience.

Connect

Stage 10 is Friday's demo. Look at your six-sentence script. Which sentence are you most nervous about saying? Practice that one three more times right now.

Test your finished build​

  • You played three different rounds and wrote down at least 2 things that needed work.
  • You fixed your worst bug — the one a parent would notice first.
  • You traded laptops with a partner and watched them play for 60 seconds.
  • You filled in all six lines of your demo script.
  • You can say the demo script out loud, looking at the screen instead of the paper.
  • Your project is saved in RAISE Playground.
  • Your Teachable Machine model URL is still saved and the model still loads.
  • Design check. Pretend a stranger just walked in. Can they tell what your game is supposed to be from one round?

If it breaks​

  • My game ran perfectly in testing — I have no bugs. Two possibilities. Either you have a tight little game (good!) — use the extra time on the medium stretch. Or you didn't push hard enough — try the third round again (the "break it on purpose" round) more aggressively.
  • I fixed one bug and broke two others. This happens. Don't panic. Undo your fix (the back arrow in RAISE), then make a smaller fix. Big changes break more than small ones — same lesson as Python Arcade Stage 9.
  • The Teachable Machine model isn't loading anymore. Open the URL directly in a tab. If the page shows your model, the issue is RAISE's caching — refresh the RAISE tab. If the URL page is broken, re-export from Teachable Machine and paste the new URL.
  • My partner's game crashed when I played it. That's their bug to fix today. Tell them, but don't try to fix it yourself.
  • My script feels boring. Read another camper's script. Steal a sentence pattern you like. The script is meant to be yours — sound like yourself, not like a textbook.
Coach notes

This is the longest stage of camp (120 minutes) for a reason — and it's the day campers run out of focus. Plan two movement breaks. One at the 45-minute mark (after Step 2). One at the 90-minute mark (after Step 4). Snack at the second break.

The hardest part for kids 7–9 is restraint. They want to fix every bug and add a new feature and change their theme. Hold the line: "Fix one bug. The worst one. Then practice." The kid who tries to redo everything tonight is the kid who has a half-broken game on Friday.

The partner playtest (Step 4) is gold. The trickiest moment is campers wanting to talk during their partner's playtest. Coach the rule explicitly: "Two minutes of silence. Watch only." Use a visible timer.

For Step 5 (the demo script), have a printed copy of the template at each station. Make sure every camper writes their answers — not in the laptop, on paper. Paper is harder to lose tomorrow, and writing by hand reinforces memory.

Walk the room at the 100-minute mark and look for two things on every laptop: (1) the project saved indicator is current, (2) the AI model URL still loads. These are the two failure modes that ruin Friday morning.