Week 7 — Build Your Own: Design Your Game¶

At a glance


Date	Friday, September 25, 2026
Unit	1 — Think Like a Machine
Big idea	A game is a designed system of rules, objects, inputs, and feedback.
Goal	Students design and begin building an original Arcade game using at least three concepts from Weeks 2–6.
Student accounts needed	None. MakeCode autosaves in the browser; students should use the same device next week if possible.
Prep time	5 minutes

Why this lesson looks the way it does¶

This is where the unit pays off. The students are not following a tutorial today. They are choosing a game idea, trimming it to a 45-minute reality, and building the smallest playable version. The teacher move is not "help everyone make their dream game." The move is scope control.

Because the room spans five grade levels, the design target is shared but the depth is different. Every pair needs a player, a goal, and a rule. Older students can add menus, difficulty, custom variables, or JavaScript edits. Younger students can make a clean coin chase or dodge game and still be doing real design.

CSTA 2026 standards¶

Concept area	Connection
Algorithms & Design	Students plan, prototype, test, and revise an original computational artifact
Programming	Programs combine events, loops, variables, conditionals, and sprite interactions
Data & Analysis	Game feedback uses tracked data such as score, lives, time, or level
Systems & Security	Students consider how input, game engine behavior, and saved browser state affect their project
Computing & Society	Student-created games communicate choices about challenge, fairness, and audience

"I can…" objectives¶

By the end of today, students can say:

I can describe the goal and rules of my own game.
I can choose which coding concepts my game needs.
I can build a small playable prototype instead of an oversized idea.
I can give and use feedback from a partner.

Teacher prep — the 5-minute version¶

Open https://arcade.makecode.com and keep the home page visible.
Write on the board:

Last Friday: Collisions made rules happen
Today: Your own game, not a tutorial
Minimum playable game: player + goal + challenge + feedback
Under that, write the concept menu:

Events · Loops · Variables · Conditionals · Collisions
Prepare three sample scopes you can say quickly: coin chase, dodge game, maze door.
Tell students to use the same device next week if possible because there are no accounts.

Minute-by-minute run sheet¶

0:00–0:04 — Anchor¶

"Last Friday we made rules happen when sprites touched. Over the last five weeks you learned the pieces: sequence, events, loops, variables, conditionals, and collisions. Today you stop building my examples. You design your own game."

Then set the constraint:

"A huge unfinished idea is not the goal. A tiny playable game is the goal."

0:04–0:12 — Mini-lesson: scope like a designer¶

Draw four boxes on the board: Player, Goal, Challenge, Feedback.

Think aloud with a sample:

"Bad scope: 'I am making Minecraft but in space with bosses.' Good scope for today: 'I move a spaceship, collect stars, avoid asteroids, and score goes up.' Same imagination, smaller first version. You can always add after it works."

Show the concept menu:

"Your game must use at least three of these: event, loop, variable, conditional, collision. Most games will use four without trying. But choose on purpose."

No long demo today. Students need build time.

0:12–0:36 — Paired build¶

First 3 minutes: pairs make a tiny plan on paper or a blank note:

Game title
Player
Goal
Challenge
Feedback
Three concepts they will use

Then build in MakeCode Arcade.

"Before you touch blocks, tell your partner the one-sentence game: 'You are ___ trying to ___ while ___.' If you cannot say it in one sentence, it is too big for today."

At 0:24, swap Driver/Navigator.

"Swap. New Driver, your job is not to add a new idea yet. Your job is to make the current idea playable."

Tiered challenges¶

🟢 Starter (gr 5–6): Build a player, one collectible, one score rule, and one way to lose or restart.
🟡 Builder (gr 7–8): Add a loop that changes difficulty over time or spawns obstacles. Include score, lives, or a timer.
🔴 Extender (gr 9–10): Toggle Blocks → JavaScript at least twice. Rename variables clearly, tune one rule in JavaScript, and add either an else branch or a custom sprite kind.

Scope control script

When a student proposes ten features, say:

"Great sequel idea. What is the version we can play in ten minutes? Build that first."

Do not showcase polished games yet. Ask for prototypes.

"Say your one-sentence game. Then tell us which three concepts are already in it."

Let the room give one useful suggestion per project:

"Suggestion rule: no new giant features. Only one small change that would make the game clearer or more fun."

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

"Next Friday is playtest and share day. Your job today is to leave with something that can be played, even if it is rough. The prompt is below."

End-of-class save move

Have students click the project name and make sure it is recognizable. Remind them: same device next week if possible. No accounts means browser autosave is doing the work.

"What is your one-sentence game, and which three coding concepts does it use?"

🤔 Think About This¶

Play or watch any game for two minutes this week — sports, board game, phone game, playground game.

Ask: what is the smallest rule that makes it fun?

🔌 Unplugged Plan B — if the internet is down¶

Design still happens. Build paper games instead of Arcade games.

Time	Activity
0:00–0:04	Anchor: today is original game design, not a tutorial.
0:04–0:12	Mini-lesson with the four boxes: Player, Goal, Challenge, Feedback. Model shrinking an oversized idea.
0:12–0:24	Pairs design a paper prototype using index cards, coins, dice, or drawn grids. They must include at least three concepts: event, loop, variable, conditional, collision.
0:24–0:34	First playtest inside the pair. One student plays; one student changes rules only between rounds.
0:34–0:41	Trade prototypes with another pair. Test whether the rules are understandable without the designers explaining everything.
0:41–0:45	Teaser: next week they will share either Arcade games or refined paper prototypes if needed. Think About This.

Paper prototype rule: if a computer would track it, write it down as a variable.

Common problems & fixes¶

Problem	Fix
Idea is too large	Ask for the 10-minute playable version. Park extra ideas as "sequel features."
Pair argues over theme	Separate theme from mechanics: choose the player art last if needed; build the rule first.
Students keep restarting projects	Set a five-minute decision deadline. After that, they must improve the current project, not abandon it.
No clear goal	Use the sentence frame: "You are ___ trying to ___ while ___." Missing blank reveals the design gap.
Older student dominates design	Assign younger student as audience advocate: "Would a first-time player understand this?" Then swap Driver.
Project may not be available next week	Rename it clearly and use the same device. If possible, download a `.png` project file to the downloads folder, but do not require accounts.

Vocabulary¶

Prototype — an early playable version used for testing ideas
Scope — how big the project is allowed to be right now
Mechanic — a rule or action that makes the game work
Feedback — information the game gives the player, such as score, sound, or message
Playtest — trying a game to learn what should change

Reflection — fill in after class¶

Which games are playable enough for Week 8?
Which pairs need a rescue starter at the beginning of next class?
Did students use at least three concepts, or mostly artwork?
Any projects at risk because of device/autosave issues?

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