Week 2 — Sequence & Events: Making Things Move¶

At a glance


Date	Friday, August 21, 2026
Unit	1 — Think Like a Machine
Big idea	Programs run instructions in order, and events let a program wait for something to happen.
Goal	Every pair builds a playable moving character in MakeCode Arcade and can point to the event that controls it.
Student accounts needed	None. MakeCode autosaves in the browser.
Prep time	5 minutes

Why this lesson looks the way it does¶

Last Friday gave students a tutorial win. Today is the first time they build from a blank Arcade project, so the lesson keeps the game tiny on purpose: one player, one background, one input event. The core distinction is not "blocks are easy"; it is sequence runs now, events run later. That distinction will carry the whole unit.

The age span is handled by asking everyone to build the same moving character, then letting older students inspect the same project in JavaScript. A 5th grader can succeed by arranging blocks correctly. A 10th grader can start noticing that controller.A.onEvent is not magic — it is a named event handler.

Pacing note — this class already knows blocks

Week 1 confirmed it: dragging blocks is not new to these students. Run the build exactly as written and your strongest half finishes Moving Hero in eight minutes and goes quiet. Two adjustments, both free:

Compress the mini-lesson to ~5 minutes. They do not need to watch you hunt for the sprite block. Build the four blocks quickly and spend the recovered time on sequence vs event, which is the part that is actually new.
Raise the floor. Everyone does 🟡 Builder; 🔴 Extender is the expectation for grades 8+. 🟢 Starter becomes a scaffold for whoever needs it, not the target.

Fluency with blocks is not the same as being able to say why an event handler runs later. Press on that — it is where the lesson still has teeth.

CSTA 2026 standards¶

Concept area	Connection
Algorithms & Design	A program can be planned as an ordered set of steps before it is built
Programming	Events trigger code in response to user input
Data & Analysis	Students observe input/output changes as data about whether the program is behaving correctly
Systems & Security	The keyboard/controller is an input system connected to software behavior
Computing & Society	Interactive software responds to people because programmers define those responses

"I can…" objectives¶

By the end of today, students can say:

I can explain why order matters in a program.
I can make a sprite move with the controller.
I can add an event that runs when a button is pressed.
I can switch to JavaScript and find where an event appears in code.

Teacher prep — the 5-minute version¶

Open https://arcade.makecode.com on the projector.
Start a New Project called Week 2 Move so the first clicks are visible.
Write on the board:

Last Friday: Computers follow instructions exactly
Today: Sequence = now · Event = later
Pair rule: Driver touches the keyboard. Navigator catches the plan.
Put students in cross-age pairs from the Week 1 survey if possible. Swap Driver/Navigator at 0:24.
Have one blank sheet ready for Plan B in case the network fails.

Handouts: Teacher run sheet — carries the adjusted timing (5-min mini-lesson, 27-min build) and all four tiers on one page.

Minute-by-minute run sheet¶

0:00–0:04 — Anchor¶

Start with screens half-closed.

"Last Friday we saw that computers do not understand what we meant. They follow exact instructions. Today we add one new idea: some instructions run immediately, and some instructions wait until something happens. Games are built out of both."

Ask one quick vote:

"If I write set background, then make player, then move player, which one happens first? Point to it."

Keep it moving. The point is retrieval after a full week away.

0:04–0:12 — Mini-lesson: sequence now, event later¶

On the projector, build slowly in a new MakeCode Arcade project:

scene set background color
set mySprite to sprite of kind Player
controller move mySprite with buttons
on A button pressed → mySprite say "Hi!" for 500 ms

Think aloud as you drag:

"These first three blocks are the setup. They run once, from top to bottom, when the game starts. But this A-button block is different. The computer reads it and basically says: 'Got it. If A ever happens, I know what to do.' It might run ten times. It might run zero times. That is an event."

Click Blocks → JavaScript for 20 seconds.

"Same project, different language. Older coders, your job today is to peek behind the blocks at least once. Don't live here yet unless you want to — just notice the shape."

0:12–0:36 — Paired build¶

Students create a new project: Moving Hero.

Required build:

Choose a background color or tile color.
Create a player sprite.
Attach controller movement.
Add one button event: A says something, changes speed, or changes the sprite picture.

"Your goal is not a full game yet. Your goal is proof that you can tell the machine: do these setup steps now, then wait for the player."

At 0:24, call the swap:

"Freeze. Driver's hands off. Navigator becomes Driver. If you were explaining, now you are doing. If you were doing, now you are explaining."

Circulation questions

"Which block runs first when the game starts?"
"Which block waits for the player?"
"If I never press A, does that code run?"
"Change one number. What changed on the screen?"

Tiered challenges¶

🟢 Starter (gr 5–6): Change the sprite, background, and movement speed. Add an A-button message.
🟡 Builder (gr 7–8): Add a second button event. Make A speed up and B slow down, or make each button change the sprite in a different way.
🔴 Extender (gr 9–10): Toggle Blocks → JavaScript. Find the controller.A.onEvent code. Change the text or speed in JavaScript, then toggle back to Blocks and confirm it still works.
⚫ If Extender lands early: Delete controller move mySprite with buttons entirely and rebuild movement by hand from four separate button events — up, down, left, right — each one setting vx/vy. Same behaviour, built from parts. It makes the point that the convenience block was hiding four event handlers all along, better than any explanation you could give.

Choose one simple, working project and one interesting broken one.

"Show us the exact event in your project. What has to happen before that code runs?"

If the broken project is missing movement, ask the class:

"Is this a sequence problem or an event problem? What evidence do you see?"

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

"Next Friday we teach the computer to do something again and again without us copying the same block ten times. That is where games start feeling alive."

"Point to one setup instruction and one event. How do you know they are different?"

🤔 Think About This¶

Somewhere this week, notice a machine waiting for an event: a microwave button, a crosswalk button, a game controller, a car sensor, a phone notification.

Ask yourself: what was it doing before the event happened?

🔌 Unplugged Plan B — if the internet is down¶

You can teach the same concept with bodies and index cards.

Time	Activity
0:00–0:04	Same anchor: "Last Friday computers followed exact instructions. Today some instructions wait."
0:04–0:12	Human program demo. Put three cards on the board: `Stand up`, `Turn around`, `Sit down`. One student robot follows them in order. Swap two cards and rerun it. Sequence is visible.
0:12–0:22	Event cards. Add cards that begin with `WHEN`: `When teacher claps, wave`; `When someone says GO, jump once`. Student robot ignores those until the event happens.
0:22–0:34	Pairs write a six-card "classroom game" with three setup cards and three event cards. They must label setup vs event.
0:34–0:41	Trade programs. One pair acts as the robot; the other triggers events. Debug unclear instructions out loud.
0:41–0:45	Same teaser and Think About This.

Keep the rule strict: robots only do what the cards say, not what the writer meant.

Common problems & fixes¶

Problem	Fix
Student opens an old Week 1 project	Fine, but have them create a new project for today's build so the concept is not hidden inside the tutorial.
A pair finishes the required build in 8 minutes	Expected with this class — do not hand them a bigger game. Send them to ⚫ above, or ask the harder question: "If I never press A, does that code exist?" Fluency with blocks is not understanding of events.
Sprite appears but will not move	Check that `controller move mySprite with buttons` uses the same variable as the sprite they created.
Button event works only once	That is normal for `on A button pressed`; explain that it runs once per press, not continuously while held.
Older student takes over the keyboard	Enforce the 0:24 swap. Give the younger student the Driver role for a concrete task like changing speed.
Student thinks JavaScript is a different project	Toggle back and forth on their screen: "Same game, two views."
MakeCode prompts for sign-in	Close or ignore it. Nothing today requires an account.

Vocabulary¶

Sequence — instructions that run in order
Event — something the program waits for, like a button press
Sprite — a character or object the program can control
Input — information coming into the computer from a person or device
Event handler — the code that runs when an event happens

Reflection — fill in after class¶

Which pairs understood setup vs event without prompting?
Which students should be JavaScript Extenders next week?
Did the Driver/Navigator swap actually happen?
What MakeCode friction should be pre-demoed next Friday?

Next week: Week 3 — Loops: Doing It Again Without Repeating Yourself