Run of Show

This page serves as the play-by-play for the live session. It works best after reviewing the Agenda and then moving into the details inside each time block: what to say, when to pause, what to watch for, and how to keep the room moving without losing the learning.

How to Use This Page

This page is designed for two kinds of use.

• use the quick scan below during live delivery when a fast reminder is more useful than full detail
• use the full run-of-show sections during prep, co-facilitator planning, or debrief

The most important pattern to protect across the session is simple: one clear action, one visible result, and one short explanation of what changed.

Quick Scan

Block	Main goal	Protect this moment	If time tight
Welcome and launch	get everyone into the skillmap quickly	clear partner roles and a short tradeoff explanation	shorten the opening talk before cutting the first build moment
The Garage	reach a first visible success	one prediction before the shakedown and one compare-and-explain pause after it	keep the first test even if other discussion shrinks
On the Road	connect setup choices to pressure, change, and roles	one pause during motion, pit strategy, or changing conditions	keep one evidence-based comparison instead of multiple whole-group stops
The Finish Line	turn the final run into evidence and reflection	one question about what mattered most and one next-test idea	cut longer reflection before cutting interpretation
Remix or replay	let learners act on what they learned	one small change plus one replay or explanation	keep it to one visible revision
Closing	capture learning without losing energy	one choice, one effect, one next step	use a fast verbal share instead of a written close

Before Learners Begin

The room and devices should be ready before students start arriving. The launch should feel immediate.

• open the skillmap on the facilitator device and project the starting view
• confirm that at least one fallback device is ready in case a learner machine stalls
• decide where you want your first compare-and-explain pause to happen
• if devices are shared, post or say the roles clearly: Driver controls, Navigator reads and explains
• keep your opening explanation to under a minute so students reach action quickly

The opening should establish:

• this is a build-test-improve session
• there is not one perfect answer
• the goal is to notice what choices make better or harder

Suggested opening language:

“Today you are not trying to find one perfect answer. You are going to make choices, test them, and decide what those choices made better, harder, faster, safer, or more strategic.”

How to Keep the Whole Audience Involved

This session works best when learners are not just staring at screens waiting for the next instruction. Short, low-pressure participation moves help students predict, notice, compare, and connect.

• use quick partner talk before whole-group discussion so more students rehearse an answer
• ask for a show of hands, thumb vote, or one-word response when you need a fast room read
• invite students to name what they notice before you explain what it means
• use contrasting team examples so students compare strategies instead of waiting for a single correct answer
• keep participation short and frequent rather than saving all discussion for the end

Good whole-group prompts include:

• Which score lens do you think this team improved?
• Did this choice make the run faster, safer, cleaner, or smarter?
• Which team role would care about this result most?
• What should this team test next?

STEM and Career Moves to Weave In

Career and STEM connections are strongest when they come from what students are already doing in the game. A separate mini-lesson is rarely necessary unless the room clearly needs it.

Short connections like these work well:

• when students tune speed, efficiency, or grip, name variables, constraints, and optimization
• when students react to collisions, pit stops, or weather, name data, feedback, and system response
• when students explain a result, name testing, iteration, and evidence-based decision-making
• when students debate which choice is better, name tradeoffs and engineering priorities

Useful career lenses to bring in during discussion:

• Software Engineer: controls, logic, reliability, and how the system responds to events
• Data/Telemetry Analyst: reading results, noticing patterns, and deciding what to change next
• Strategist: timing, risk, consistency, and decision-making under pressure
• UX/Game Designer: clarity, difficulty balance, and how the player experiences the system
• Sustainability Lead: efficiency, resource-aware choices, and long-term performance rather than short-term gain

90-Minute Run of Show

1. Welcome, Device Check, and Team Framing

Goal

Get learners into the activity quickly, reduce uncertainty, and establish how they will work.

Priorities

• welcome learners and point them to the skillmap right away
• confirm everyone can access the activity before giving a longer explanation
• explain tradeoff in plain language: improving one thing can make another thing harder
• assign partner roles if needed and tell learners when roles will rotate
• preview that they will meet different kinds of technical roles through the game, not through a separate lecture

Live moves

• stand at the projector or main display and point to the skillmap path before students begin
• ask students to raise a hand or give a quick signal once they have opened the activity
• if more than a few learners are stuck on access, pause the whole group and solve the launch issue once out loud instead of repeating it table by table
• say when role rotations will happen so shared devices do not become one-person devices
• give the room a simple success target for the first few minutes: open the project, enter the first steps, and get to the first visible build moment

Say

• “You are going to build, test, compare, and improve.”
• “If something does not go the way you expect, that is useful data, not failure.”
• “Your job is not just to finish. Your job is to notice what your choices changed.”

Ask

• Who has ever changed something in a game or app just to see what would happen?
• What do you think engineers do when two good goals compete with each other?
• What might happen if a team only cares about speed and ignores everything else?

Watch for

• learners who are stuck on access before the build even starts
• pairs where only one person is holding the device role
• students waiting for permission instead of entering the first step

Adjust if needed

• shorten the opening talk immediately
• resolve launch issues with a quick demo or pair merge
• keep the first goal simple: get the car on screen and moving

Stretch by experience level

• for students who are new to coding, keep the focus on entering the tutorial, following the step sequence, and reaching a first visible success
• for students with some coding experience, ask them to notice which variables or blocks seem most important before they start changing them
• for students with stronger coding experience, tell them early that there will be chances to tune, compare, and justify more advanced changes once the core path is working

2. Stage 1, The Garage

Goal

Get students to a first visible success, then help them understand that early setup choices will carry forward.

Priorities

• the project starts with a quick on-ramp
• setup values matter because they create tradeoffs
• the first shakedown is not a final judgment; it is a test

Live moves

Opening build steps

• keep students moving through the first steps so they reach a playable state quickly
• do not over-explain every block while learners are still trying to orient themselves
• point out the mission, car setup, and role lens as parts of one connected system

Move

• circulate first to students who are not yet at a visible build step rather than to students who are already experimenting
• if learners ask what every block means, answer only the block they need for the next move
• once several teams have the car and setup on screen, name that as a success out loud so the room feels progress

Ask or involve

• ask for a quick signal when teams reach the first visible build milestone
• invite one team to show the room where they changed a setup value
• ask the room what that choice might improve before the team runs the shakedown

First setup decision

• when students begin tuning values, pause briefly and ask for a prediction
• keep the question short so it supports action rather than replacing it

Ask

• What do you think this setup will help with?
• What might it cost you later?
• If we raise this value, what do you expect to happen on the test run?

Move

• ask for predictions before students run the shakedown, not after
• point to one variable at a time if students seem unsure what is actually changing
• if the room is quiet, ask students to answer the prediction to a partner before taking a whole-group response

Name

• variables as tuning choices
• constraints because one improvement can create a cost
• prediction as part of testing, not guessing blindly

Garage Shakedown

• make sure learners reach the test track instead of staying stuck in setup forever
• use the shakedown as the first compare-and-explain moment
• ask for one thing the result confirmed and one thing it challenged

Ask

• What happened that you expected?
• What happened that you did not expect?
• Which score lens seems easiest to improve right now?
• Which one got harder?

Move

• stop the room only after enough teams have seen a real result to discuss
• ask one team to name the choice they made before you ask what happened
• capture one or two contrasting results publicly so students hear that different setups can produce different tradeoffs

Ask the room

• Which team saw the biggest change from its setup choice?
• What tradeoff showed up most clearly in that test?
• If you were a data analyst, what result would you want to record from that run?

Stretch by experience level

• for students who are new to coding, keep them on the main path and ask them to name one setup choice and one result
• for students with some coding experience, ask them to compare two settings and explain which tradeoff became clearer
• for students with stronger coding experience, invite them to adjust both speed and efficiency or revise the tradeoff rule, then defend why the new balance is better or more extreme

Watch for

• students treating the first result as success or failure instead of as feedback
• learners increasing speed without noticing efficiency or control costs
• groups needing a clearer explanation of what they are supposed to compare

Adjust if needed

• bring everyone back to one shared question: “What did you change, and what happened next?”
• point to one visible variable or score lens, not the whole system at once
• rotate Driver and Navigator roles before moving on if needed

3. Stage 2, On the Road

Goal

Help students feel their earlier decisions in motion and interpret new problems as engineering choices rather than random difficulty.

Priorities

• this is where prior setup decisions start showing consequences
• movement, collisions, pit stops, and weather are all evidence
• strategy is not separate from gameplay; it is part of how the gameplay is read

Live moves

Hit the Track

• let the motion do some of the teaching before you interrupt it with explanation
• once learners have seen one clear obstacle or collision moment, pause briefly

Ask

• Which earlier choice is helping you now?
• Which one is creating a new problem?
• What is the game telling you about your setup?

Move

• wait until students have actually experienced movement, collisions, or rewards before asking for interpretation
• point to one visible moment on the screen when asking a question so the room stays anchored in evidence
• if learners are talking only about whether they won or lost, redirect to the earlier setup choice that influenced the run

Name

• inputs and outputs
• event-driven behavior
• feedback systems that tell the player what the system is doing

Pit Stop Briefings

• use pit stop moments to connect a visible gameplay choice to a real team role
• keep the career connection tied to the decision students are making right then

Ask

• Who on a real team would care most about this moment?
• Is this a performance decision, an efficiency decision, or a strategy decision?
• When is the fastest choice not the smartest choice?

Move

• name the role after students describe the decision, not before
• keep the connection to one sentence if the room is in motion
• if students are engaged, ask two different teams to name two different roles that might care about the same moment

Ask the room

• Which role is most visible in this moment: strategist, software engineer, telemetry analyst, or designer?
• What kind of information would that person care about?
• What would they want the team to do next?

Changing Conditions

• when rain, grip shifts, or other condition changes appear, frame them as system changes the team must respond to
• ask learners to explain how the track changed what counts as a good decision

Ask

• What changed once conditions changed?
• Did the best earlier setup stay the best setup?
• What would a telemetry or strategy team want to notice here?

Move

• pause at the first moment students clearly feel the changed condition rather than waiting until the end of the stage
• ask learners to compare before-rain and after-rain decision-making
• if the room has different results, use that variation as evidence that setup and strategy interact

Name

• systems responding to changing conditions
• data-informed adaptation
• optimization across more than one goal

Ask or involve

• ask students to vote quickly on whether the best decision changed once the weather changed
• invite one team to explain why their earlier choice still helped or stopped helping
• ask another team to disagree or add evidence

Stretch by experience level

• for students who are new to coding, ask them to name one earlier choice that helped or hurt once the track changed
• for students with some coding experience, ask them to compare two runs and explain whether the better result came from speed, control, or strategy
• for students with stronger coding experience, invite them to adjust one reward and one penalty, or modify a weather-related variable, then justify whether the system still feels fair and readable

Watch for

• learners describing events but not connecting them back to a prior choice
• groups focusing only on surviving, without naming the tradeoff under the pressure
• students missing the career connection because it was delivered too abstractly

Adjust if needed

• pause on one visible moment, not the whole stage
• ask students to compare two runs or two teams instead of answering in the abstract
• shorten talk and send them back to action quickly

4. Stage 3, The Finish Line

Goal

Turn the last part of the session into evidence and interpretation, not just completion.

Priorities

• the final challenge is where multiple systems run together
• students should watch performance, efficiency, and strategy together
• the review matters because it turns gameplay into explanation

Live moves

Final Challenge

• frame this as a chance to apply earlier learning, not prove worth
• remind learners that the goal is not perfect performance; it is noticing what their design choices produced
• during the run, keep your prompts minimal so students can stay in the action

Ask

• What are you watching most closely right now?
• Which earlier choice is showing up most clearly in this run?

Move

• give students a few seconds to play before you ask them to interpret anything
• if you pause the room, ask them to name one lens they are watching: performance, efficiency, or strategy
• keep this segment active and avoid turning it into a running commentary from the front

Ask the room

• Which score lens are you watching most right now?
• Which earlier choice seems to be helping the most?
• Is the strongest run also the most balanced run?

Reflect and Review

• after the run, slow the room down just enough to interpret the results
• push learners toward evidence instead of general reactions

Ask

• What choice had the biggest effect on your result?
• Which score lens mattered most by the end?
• What evidence from the run supports that?

Move

• ask for a specific choice before accepting a general opinion about the run
• if students say something was better or worse, follow up with “What in the game tells you that?”
• use one student example to model an evidence-based answer if the room is unsure how to respond

Name

• evidence and feedback
• iteration based on results
• tradeoff analysis rather than single-metric thinking

Ask or involve

• ask the room to identify which score lens mattered most in one example run
• invite one team to make a claim and another to add supporting evidence or a different interpretation
• ask what the team should test next and why

Winners Circle and Closure Inside the Stage

• use the closing screens to connect what happened to a role, a system, or a next-test idea
• keep this concrete and brief rather than turning it into a speech

Ask

• What would you change if you ran it again?
• Which role does your thinking match most closely?
• What should the team test next?

Move

• ask students to complete one sentence stem before moving to the next activity
• if time is short, collect one next-test idea from each pair instead of doing a longer whole-group reflection
• keep the closing connection tied to a real gameplay or code decision, not a generic preference

Ask the room

• Which career connection felt most real in this stage?
• What skill from today matters outside of racing games?
• What did this run teach us about how engineers make decisions?

Stretch by experience level

• for students who are new to coding, ask them to explain one choice and one result using simple evidence from the run
• for students with some coding experience, ask them to explain which score lens mattered most and what they would adjust next
• for students with stronger coding experience, invite them to improve the review, revise the next-test recommendation, or change the closing message so it better reflects the run and the relevant team role

Watch for

• students giving only emotional reactions instead of evidence-based explanations
• groups skipping the review because they think the game is over once the run ends
• learners talking only about score instead of the three-lens model

Adjust if needed

• protect one evidence-based reflection question
• protect one next-step statement
• skip longer written reflection before you skip interpretation altogether

5. Remix, Share, or Replay

Goal

Give learners one more chance to act on what they learned instead of ending with passive discussion alone.

Priorities

• invite one small revision that creates a visible difference quickly
• ask learners to predict before they replay or test again
• if time is tight, let teams explain a remix verbally instead of fully building it
• if the room is energized, use a short compare-two-versions share-out

Live moves

• narrow the remix to one variable, event, reward rule, or message if students are unsure where to start
• ask students to state the change out loud before they build it
• require a quick replay or explanation so the remix does not remain hypothetical
• if experienced coders move faster, direct them to a slightly deeper but still testable change rather than letting them wander too far from the core system

Ask or involve

• have teams briefly present the change they made before showing the result
• ask the audience to predict what will happen before the replay starts
• after the replay, ask the audience whether the remix improved performance, efficiency, strategy, or clarity
• invite one audience member to name the engineering tradeoff the remix created

Ask

• Change one value. What do you think will change?
• Which version feels more balanced?
• What did this remix improve, and what did it make harder?

Ask the room

• Which team changed something different from you?
• Which version seems more fair? Why?
• Which remix rewarded speed, and which one rewarded control or strategy?

Stretch by experience level

• for students who are new to coding, keep the remix to one visible change with one quick test
• for students with some coding experience, ask for a comparison between two versions and a defense of which is stronger
• for students with stronger coding experience, invite a two-part change, such as speed plus efficiency, collision plus reward, or review message plus next-test prompt, and ask them to explain the tradeoff it created

Watch for

• remixes that are too large to test quickly
• teams changing many things at once and losing the cause-and-effect thread
• students needing a narrower prompt rather than more freedom

6. Closing Reflection and Transition

Goal

End with a short, confident reflection that captures learning without draining the room.

Priorities

• ask each team to name one choice and one effect
• invite one or two students to connect a game moment to a team role
• ask what they would test next if they had another round
• reset the room for the next group or transition cleanly to the next activity

Live moves

• decide before the close whether you want a verbal share-out, a quick exit response, or a one-sentence pair reflection
• call on a small number of teams rather than asking for a long open discussion
• end with next-step thinking so the session lands on iteration, not finality
• if another group is coming in, start the transition while students are finishing their last sentence rather than after full silence

Ask the room

• What is one engineering idea you heard today: tradeoff, testing, data, system response, or optimization?
• What is one coding idea you used or noticed: event, variable, condition, or debugging?
• What is one role from today that you want to learn more about?
• What is one thing the next team should watch for when they start?

Close with

• One choice we made was…
• One thing that changed because of it was…
• Next time we would test…
• One role connected to our thinking today was…

Educator Moves That Help Throughout

• point to one variable, block, score lens, or system at a time
• ask learners to predict before they test when possible
• treat unexpected results as useful data
• keep discussions grounded in what the game actually showed
• keep prompts short enough that students can return quickly to action
• invite more than one reasonable answer when students compare strategies
• use career language after the gameplay moment, not far before it
• keep audience participation frequent enough that students alternate between doing, noticing, and explaining
• name the STEM idea after students experience it so the concept attaches to a concrete moment

Best Places to Pause

• after the first setup choice in The Garage
• after the Garage Shakedown result screen
• at the first pit stop or career briefing moment
• when changing conditions force learners to adapt
• right after the final challenge before students move into closure
• during replay or remix if two teams reached clearly different outcomes

Recovery Moves for Live Events

If devices are uneven

• pair students quickly and assign Driver and Navigator roles
• demo one step live while others catch up
• keep the room on the skillmap path instead of opening the full project early

If the room is moving too slowly

• prioritize one complete journey through all three stages
• reduce the number of pause points instead of rushing every prompt
• protect the first test, one compare-and-explain moment, and the closing reflection

If the room is moving too quickly

• add a replay or one focused remix
• ask for evidence-based comparisons between teams
• use stronger extension prompts from the Agenda or Supplementals

If energy drops

• ask a short prediction question and send students back to action
• use one visible team example instead of a broad explanation
• rotate roles to reactivate participation