Stage 10: Polish and Demo
Keep building in the workspace on the right.
This stage is part of the same Python Arcade project you started in Setup. Type each new code block into the Trinket rail and keep building on the last stage.
on-screen instructions, a clean ending, and a demo script
the difference between a game that runs and a game someone else can play
a parent-demo-ready arcade game
The big idea
For nine stages, you've been writing a game for yourself. You know how to play it because you wrote it — the arrow keys are obvious, the score makes sense, you know exactly when the round ends and why. Today the game has to work for someone who has none of that context.
Stage 1–9: YOUR game, on YOUR screen, with YOU at the keyboard
Stage 10: Hand your game to a parent.
Don't speak.
Watch.
Did they get it?
That single test is what this stage prepares the game for. The new ideas today aren't programming concepts — they're craft. Polish means doing the last 10% of work that takes the game from "it runs" to "it's a game." Onboarding means the game teaches a brand-new player how to play it, without you in the room. A demo script is the tiny rehearsed narrative that lets you walk a parent through your game in under a minute.
Most of today is small additions to code you already wrote. None of it is hard. All of it is what people will remember.
Think of Stage 10 as your capstone — not a new programming concept, but the craft of turning code that runs into a game someone else can play. The work shifts from building to finishing, and that's exactly the point.
Your game should be playable from start to finish — score, lives, timer, win and lose screens, difficulty ramp.
Build it
Optional — Confirm the sprite polish
If you used the Python Arcade sprite pack, do one final filename check before the demo. A polished game should either load every GIF cleanly or fall back to the original square and circle shapes without crashing.
These are optional visual skins for the square cannon and circle aliens. The filenames must match exactly inside Trinket.
Step 1 — Teach the controls on screen
A stranger doesn't know that arrow keys move the cannon. They don't know space fires. They certainly don't know about the timer. We put a small instruction line at the bottom of the screen so the game introduces itself.
Write this before the game loop:
Who is this for?
Why should instructions be drawn by the game instead of explained by you every time?
Check your thinking
Because a new player should be able to understand the controls without the programmer standing next to them.
instruction_writer = turtle.Turtle()
instruction_writer.hideturtle()
instruction_writer.penup()
instruction_writer.color("white")
instruction_writer.setposition(0, BOTTOM + 15)
instruction_writer.write("Arrow keys move | Space fires | Survive the timer",
align="center",
font=("Arial", 12, "normal"))
Notice we don't redraw this writer in the game loop — instructions don't change, so they only get written once. Put them low on the screen (BOTTOM + 15) so they're visible but stay out of the action.
Step 2 — Make the ending feel complete
Right now your ending shows result (either GAME OVER or YOU WIN) — but there might be a few lasers still mid-flight and one or two aliens still on screen when the loop exits. That looks unfinished. We also want to show the final score so the player has something to compare to next time.
Find your end-of-game code from Stage 7 and replace it with this. First, hide every live object so the screen is clean:
for laser in lasers:
laser.hideturtle()
for alien in aliens:
alien.hideturtle()
screen.update()
Then improve the final screen — move the result up, add the final score below it:
score_writer.clear()
score_writer.setposition(0, 20)
score_writer.write(result, align="center", font=("Arial", 28, "bold"))
score_writer.setposition(0, -20)
score_writer.write("Final score: {}".format(score), align="center", font=("Arial", 18, "normal"))
(0, 20) and (0, -20) stack the two lines neatly around the center of the screen. Run the game to both endings (win and lose) and confirm the final card looks polished.
File order checkpoint
By the end of Stage 10, the final shape of your file is:
- Setup code, constants, writers, helper functions, key bindings, and first draw calls
- The
while game_running:game loop - Cleanup after the loop: hide remaining lasers and aliens
- Final result and score text
screen.update()andturtle.done()
Step 3 — Do a real bug pass
You've been playing your own game all week — but you've also been forgiving of it. Today you stress-test it on purpose. Play three full rounds:
- Try to win. Survive the full minute by playing well.
- Try to lose fast. Stand still and let aliens drift down.
- Try to break it. Mash every key. Hold space. Fire right as a new fleet appears. Press
qmid-round.
Each round, watch for one thing: does anything look wrong? Old text overlapping new text. Aliens off-screen. Score going negative. A frozen frame. A crash. Write down anything off, fix it, run again. A demo-ready game survives all three rounds without weirdness.
Step 4 — Write your demo script
Tomorrow (or today) a parent is going to ask "so what does your game do?" You don't want to make it up in the moment. Write three short sentences now:
My game is called __________________________.
The player controls a __________ and tries to __________.
The hardest part to code was __________ because __________.
Practice saying it out loud while your game is open and running. Thirty seconds, max. The point isn't to sound impressive — it's to give the parent something to look at while you talk. A working game in the background plus a calm one-paragraph explanation is the whole demo.
Understand it
Stages 1–9 were 90% of the code. This stage is the 10% that makes the difference. Game developers call this polish, and they spend more time on it than any other phase. The same is true of websites, products, school presentations — anything someone else will encounter. The shape of making something always ends with making it understandable.
The instruction line you added in Step 1 might feel almost embarrassing — "of course the arrows move." But that's because you wrote it. A first-time player has none of your knowledge. The single most common mistake any new game designer makes is assuming the player will figure out what they figured out while building. Write the controls. Always write the controls.
The bug pass in Step 3 is the closest thing this course has to quality assurance. Real software has whole teams of people whose only job is to try to break things on purpose. They don't try to play well — they try to find the weird edge. You just spent fifteen minutes doing the same job, and your game is sturdier for it.
The demo script feels like a small ask compared to building the game itself — but it's the part the parent will remember. The game is the artifact; the script is what makes someone outside the room understand what they're looking at. Code creates the thing. Words frame it.
Try this
Try this
Three short experiments. Predict before you run, then test your guess.
Imagine you hand your laptop to a parent right now, no instruction line, no demo script, and you don't speak. Predict the very first wrong thing they would do. (WASD instead of arrows? Click the screen? Hit Enter to start?) Watch a sibling or coach play once if you can — were you right?
Comment out the instruction_writer.write(...) line and run your game. Time how long it takes you to forget that instructions are missing — you already know the controls. Now uncomment it. The instruction line is invisible to you and obvious to anyone new. That gap is what polish is.
You finished the course. Look back through Stages 1–9. Which stage's idea (named edges, event handlers, the list pattern, the game loop, collision, game state, the timer, tuning) felt hardest when you first learned it? Which one feels obvious now? The gap between those two answers is what learning looks like.
Test your finished game
Stuck? Compare carefully
required Stage 10 code
Where it goes: Compare this with your Stage 10 polish: instruction writer before the loop, cleanup immediately after the loop exits, and final result/score text after cleanup.
Use this only after checking your own ending cleanup and final score display.
instruction_writer = turtle.Turtle()
instruction_writer.hideturtle()
instruction_writer.penup()
instruction_writer.color("white")
instruction_writer.setposition(0, BOTTOM + 15)
instruction_writer.write("Arrow keys move | Space fires | Survive the timer",
align="center",
font=("Arial", 12, "normal"))
# The game loop stays here.
for laser in lasers:
laser.hideturtle()
for alien in aliens:
alien.hideturtle()
screen.update()
score_writer.clear()
score_writer.setposition(0, 20)
score_writer.write(result, align="center", font=("Arial", 28, "bold"))
score_writer.setposition(0, -20)
score_writer.write("Final score: {}".format(score), align="center", font=("Arial", 18, "normal"))
turtle.done()
- The game starts cleanly and the instruction line is visible from the first frame.
- Arrow keys move the cannon. Space fires.
qquits. - Score, lives, and timer are all visible the whole game.
- You can win by surviving the timer.
- You can lose by letting aliens reach the cannon.
- When the round ends, all aliens and lasers disappear cleanly and the final card shows the result and the final score.
- You played three bug-pass rounds and fixed anything you found.
- You can recite your three demo sentences without reading them.
- Optional sprite polish: uploaded GIFs load with exact filenames, or the game falls back to the square cannon and circle aliens.
- Design check. Hand the keyboard to a peer for one minute without saying a word. Did they figure out the game?
If it breaks (during the demo)
This section is different from the others — it's not about debugging code. It's about what to do when something goes wrong while a parent is watching. These things happen. Here's the rule: keep talking, fix calmly.
- The game doesn't start. Open Trinket, find your project, hit Run. While it loads, say "give me one second" and use the demo script to introduce the game. Then play.
- An obvious bug appears mid-demo. Don't panic. Say "that's actually a known thing I haven't fixed yet" — every real developer says this. Then either restart the round or move on.
- You forget your demo script. That's fine. Just point at the screen and say "watch what happens when I shoot one of these." Action beats narration.
- A parent asks a question you don't know. "Good question — let me show you the code," and open the Trinket. Half the time the answer is right there.
- The game crashes. Refresh the Trinket. While it loads, the demo script bridges the gap.
The thing nobody tells you about demos: parents don't expect a perfect product. They want to see that their kid built something. The game running is enough. Talking about it confidently is the rest.