Week 8 — Playtest & Share: Ship It to the Class¶

At a glance


Date	Friday, October 2, 2026
Unit	1 — Think Like a Machine
Big idea	Shipping software means letting other people use it, noticing what happens, and making one focused improvement.
Goal	Students playtest classmates' original games, make one revision, and share what their program does.
Student accounts needed	None. Use existing browser autosaves or rebuilt prototypes.
Prep time	5 minutes

Why this lesson looks the way it does¶

The temptation on a share day is to turn it into presentations. For this age span, playtesting is better. It keeps everyone active, gives younger students a real audience, and gives older students a reason to explain design choices without performing a speech.

The key teaching move is limiting revision to one focused improvement. Students will discover a dozen issues when someone else plays their game. That is normal. Shipping does not mean perfect; it means playable, understandable, and improved because of feedback.

CSTA 2026 standards¶

Concept area	Connection
Algorithms & Design	Students test, evaluate, and refine a computational artifact based on user feedback
Programming	Students explain how their code combines events, loops, variables, conditionals, and collisions
Data & Analysis	Playtest observations are evidence used to choose a revision
Systems & Security	Students manage local browser-saved projects and understand the limits of no-account storage
Computing & Society	Designers consider the experience of other users, not just their own intent

"I can…" objectives¶

By the end of today, students can say:

I can playtest someone else's game respectfully and give useful feedback.
I can use feedback to choose one improvement.
I can explain the main rule my program uses.
I can name one coding concept I used in my original game.

Teacher prep — the 5-minute version¶

Open https://arcade.makecode.com on the projector.
Write on the board:

Last Friday: You designed your own game
Today: Playtest → Improve → Share
Feedback sentence: I noticed ___, so I suggest ___
Under that, write the revision limit:

One improvement only: clearer, fairer, or more fun
Prepare a simple rotation: pairs trade with the nearest pair, then one more pair if time allows.
Remind students at the door: use the same device if possible.

Minute-by-minute run sheet¶

0:00–0:04 — Anchor¶

"Last Friday you started original games — not tutorials. Today you do what real developers do: you let someone else try it. They will misunderstand something. They will find something broken. That is not embarrassing. That is the point of playtesting."

Set the norm:

"The designer's job is to watch first, explain second. If you rescue the player immediately, you learn less."

0:04–0:12 — Mini-lesson: useful feedback¶

Model bad and good feedback on the board.

Bad:

"It's confusing."

Better:

"I noticed I didn't know which sprite was dangerous, so I suggest making the enemy a different color."

Say:

"Feedback is not a review score. Feedback is evidence. What did you notice? What small change would help?"

If a project is missing because autosave failed, give the recovery path immediately:

"If your project is gone, you are not out. Rebuild the smallest version: player, goal, challenge, feedback. You can still playtest today."

0:12–0:36 — Paired build: playtest and revision¶

Round 1, 0:12–0:22:

Pair A plays Pair B's game for three minutes.
Pair B watches silently for the first minute.
Player gives one feedback sentence.
Switch.

Round 2, 0:22–0:30:

Optional second trade if the room is ready, or repeat with the same pair.

Revision, 0:30–0:36:

Each pair chooses one improvement.
They implement only that improvement.

"Choose one: clearer, fairer, or more fun. If you try to fix everything, you will ship nothing."

Tiered challenges¶

🟢 Starter (gr 5–6): Make one thing clearer for the player: instructions, sprite art, score, or win/lose message.
🟡 Builder (gr 7–8): Tune one gameplay number based on feedback: speed, spawn timing, points, lives, or threshold.
🔴 Extender (gr 9–10): Toggle Blocks → JavaScript. Make the revision in code if practical, then explain to the tester what changed and why it improved the experience.

When students over-explain

Say quietly:

"Let them play for one minute without help. Watch their hands. The confusion is data."

Choose 3–4 pairs, prioritizing variety over polish.

Each pair answers:

What is your game?
What feedback did you get?
What one improvement did you make?

"We are not voting for best game. We are noticing best revision. What changed because another human tried it?"

0:42–0:45 — Teaser + prompt¶

"This wraps Unit 1. You have now built with the core ideas programmers use constantly: events, loops, variables, conditionals, and collisions. After the flex week, we shift from games to AI and ask what machines can and cannot actually understand. The prompt is below."

"What did a playtester notice, and what one change did you make because of it?"

🤔 Think About This¶

Notice one product this week that was clearly improved because people tested it: a game tutorial, a checkout screen, a door handle, a lunch line, a sports rule.

Ask: what problem did a designer probably see before changing it?

🔌 Unplugged Plan B — if the internet is down¶

Run a paper prototype playtest and share day.

Time	Activity
0:00–0:04	Anchor: last week original games; today playtest, improve, share.
0:04–0:12	Mini-lesson on feedback sentence: "I noticed *, so I suggest* ." Model one bad and one useful example.
0:12–0:24	Pairs rebuild their game as a paper prototype: grid, cards, counters, dice, or body movement. Must include player, goal, challenge, feedback.
0:24–0:34	Trade prototypes. Designers watch silently for one minute, then collect one feedback sentence.
0:34–0:40	Make one paper-rule revision: clearer instruction, fairer number, simpler win condition, or better feedback.
0:40–0:45	Share 3–4 revisions and close Unit 1.

This is not a lesser version. Paper playtesting often reveals design problems faster than code does.

Common problems & fixes¶

Problem	Fix
Project is missing from browser autosave	Rebuild the smallest playable version or use a paper prototype. Do not spend the share day searching accounts that do not exist.
Playtester gives vague feedback	Point to the board sentence: "I noticed *, so I suggest* ." Make them name an observation.
Designer explains constantly	Ask them to watch silently for one minute. Confusion is evidence.
Pair tries to add a giant new feature	Limit them to one improvement: clearer, fairer, or more fun.
Younger student feels their game is less advanced	Highlight revision quality, not feature count. A clear small game is a shipped game.
Older student wants to keep coding through share-out	Give them the role of explaining one technical choice in JavaScript during share-out.

Vocabulary¶

Playtest — trying a game to learn how it works for another person
Feedback — information that helps improve the design
Revision — a change made after testing
Ship — to release a playable version, even if it is not perfect
User — the person using or playing what you built

Reflection — fill in after class¶

Which games were most understandable to first-time players?
What feedback sentence should be reused later in the year?
Did students value revision over polish?
Who showed readiness for text coding in Unit 3?

Next week: Week 9 — What Is AI, Really?