Definitions

This page gives educators and learners a shared language for the experience. It supports discussion, troubleshooting, and reflection without turning vocabulary into a separate lesson.

These terms help learners talk more clearly about what they are seeing, building, and improving. When learners understand the language, they are better able to explain their thinking, collaborate with peers, and connect hands-on gameplay to broader engineering and design ideas.

A

  • Animation: A sequence of images or visual changes that makes a sprite or effect look like it is moving over time. For example, a spinning wheel or flashing boost effect uses animation to make the game feel more alive. (Intro to MakeCode Arcade)
  • Arcade: The MakeCode game-building environment students use to create, test, and remix their projects. It combines coding, art, and playtesting in one place so learners can see the result of a change right away. (Intro to MakeCode Arcade)
  • Asset: A reusable game resource such as an image, sound, tile, or animation. Educators can think of assets as the building pieces that give the game its look, feel, and feedback. (Mission Briefing)

B

  • Block: A snap-together coding piece in MakeCode Arcade that represents one command, value, or logic rule. Blocks help students focus on cause and effect without needing to memorize spelling or punctuation first. (Intro to MakeCode Arcade)
  • Bug: A mistake or unexpected behavior in a program that needs to be investigated and fixed. A bug might look like a car moving too fast, a score not changing, or an event never running. (Garage Shakedown)
  • Button Event: A game action that runs when a player presses or releases a controller button. For example, pressing the A button might trigger a boost, an effect, or a menu choice. (Intro to MakeCode Arcade)

C

  • Collision: What happens when one sprite touches another sprite, wall, or obstacle and triggers a result in the game. In this project, a collision can become a useful conversation about risk, control, and performance penalties. (Hit the Track)
  • Condition: A true-or-false check that helps the game decide what should happen next. For example, the code might ask whether the weather is rainy before changing how the car handles. (Setup and Tradeoffs)
  • Controller: The input system that lets a player move a sprite or press buttons to trigger actions. It is one of the most visible ways students learn that input causes immediate changes in a program. (Intro to MakeCode Arcade)
  • Custom Block: A project-specific block that was created to make a game feature easier to reuse or teach. These blocks help students work with meaningful game systems without getting lost in repeated setup code. (Mission Briefing)

D

  • Data: Information collected during gameplay or testing that helps students explain what happened. Examples include score, collisions, speed, and efficiency changes across a run. (Pit Stop Briefings)
  • Debugging: The process of finding, testing, and fixing problems in code. Good debugging is not guessing randomly; it means observing carefully, changing one thing, and checking the result. (Garage Shakedown)
  • Drag and Drop: The action of moving blocks from a toolbox into the workspace to build a program. This physical action supports beginners because the structure of the code is visible as they assemble it. (Intro to MakeCode Arcade)

E

  • Efficiency: How well a car or system uses limited resources, such as fuel, battery, or time, while still performing effectively. In the tutorials, efficiency helps learners see that faster is not always better if it costs too much somewhere else. (Setup and Tradeoffs)
  • Event: An action the game listens for, such as a button press, overlap, or game start. Event-driven code is a key idea in Arcade because it helps students connect a trigger to a visible outcome. (Intro to MakeCode Arcade)

F

  • Feedback: Information the game gives the player through motion, score, sound, or text after an action happens. Strong feedback helps players understand whether a choice was helpful, risky, or unsuccessful. (Reflect and Review)
  • Function: A reusable set of instructions that performs one job when it is called. For example, a function might set up a car, update saved data, or show the same information in several places. (Mission Briefing)

G

  • Game Loop: The repeated cycle in which a game checks inputs, updates objects, and redraws the screen. Students do not always see this loop directly, but they experience it every time the game responds smoothly to movement and changes. (Hit the Track)
  • Goal: The clear outcome a player is trying to reach in a level, challenge, or full activity. A strong goal gives learners a reason to test, revise, and explain their decisions. (Final Challenge)

H

  • Handling: How easily a car responds to movement and turns, especially when speed or weather changes. This is a helpful term for discussing why a car can feel fast but harder to control. (Changing Conditions)
  • Hint: An optional support note that gives extra guidance, definitions, or troubleshooting help. Hints are especially useful when students need one more clue without being shown the full answer. (Intro to MakeCode Arcade)

I

  • Image: Pixel art that represents a sprite, background, icon, or tile in the game. In Arcade, images are small on purpose, which helps students focus on clear design choices instead of visual complexity. (Intro to MakeCode Arcade)
  • Iteration: A cycle of making a change, testing it, and improving it based on what happened. This word is central to the project because it describes how engineers and designers work in real teams. (Garage Shakedown)

K

  • Kind: A label that tells Arcade what type of sprite something is, such as player, enemy, or food. Kinds help the game know which sprites should interact and which rules apply to them. (Intro to MakeCode Arcade)

L

  • Life: A tracked value that can represent health, durability, or another limited resource in the game. In this project, life can also support conversations about efficiency loss or the cost of mistakes. (Hit the Track)
  • Logic: The rules that control how a program makes decisions. When students explain why something happened in the game, they are often describing the program’s logic in their own words. (Intro to MakeCode Arcade)
  • Loop: Code that repeats automatically, either for a set amount of time or as part of the game’s ongoing behavior. Repetition is useful when the game needs to keep checking status, moving objects, or updating conditions. (Intro to MakeCode Arcade)

M

  • Metric: A measured value, such as score, speed, or collisions, that helps teams evaluate performance. Metrics give students evidence they can use in discussion instead of relying on opinions alone. (Pit Stop Briefings)

N

  • Namespace: A named group of related code tools or blocks. In this project, a namespace helps keep the Driven by STEM blocks organized so students can find features by theme. (Mission Briefing)

O

  • Obstacle: Something on the track or screen that blocks movement or creates a challenge for the player. Obstacles matter because they turn movement into a decision-making problem instead of a straight path. (Hit the Track)
  • Overlap: A type of event that happens when two sprites touch and the game detects that contact. Many beginner game mechanics are built from overlaps because they create immediate, visible results. (Hit the Track)

P

  • Parameter: A value you give to a block or function so it can do a job in a specific way. For example, a speed value or efficiency cost can act as a parameter that changes the behavior of the same code. (Setup and Tradeoffs)
  • Performance: How well a car or system achieves its goal under the current conditions. Performance can include speed, control, reliability, and efficient use of resources rather than one number alone. (Setup and Tradeoffs)
  • Pit Stop: A planned moment to pause, review information, and make a better decision before continuing. In the tutorials, pit stop thinking models how teams step back, read the data, and adjust strategy. (Pit Stop Briefings)
  • Pixel Art: A style of digital art built from small colored squares called pixels. Arcade uses pixel art so students can create readable visuals quickly and understand how game images are constructed. (Intro to MakeCode Arcade)
  • Playtest: Trying the game on purpose to see how it feels, what works, and what needs to change. A playtest is more useful when students know what they are checking for before they begin. (Garage Shakedown)
  • Property: A detail about a sprite or object, such as its position, speed, image, or kind. Changing a property changes how that object behaves or appears in the game. (Intro to MakeCode Arcade)
  • Prototype: An early working version of a game or feature used to test ideas before everything is final. Prototypes are meant to teach the team something, not to be perfect. (Mission Briefing)

Q

  • Qualitative Data: Descriptive observations about what happened, such as “the car felt harder to control in the rain” or “the pit stop made the round feel safer.” This kind of evidence complements scores and other numbers when students reflect on performance. (Reflect and Review)
  • Quantitative Data: Measured information that can be counted or compared, such as score, speed, collisions, or efficiency changes. Quantitative data helps students justify a claim with numbers instead of opinion alone. (Pit Stop Briefings)

R

  • Race Profile: Saved setup information for a team or car that can be reused across activities. This helps students see that choices made in one stage can carry forward into later decisions. (Mission Briefing)
  • Resource: Something limited that a team needs to manage carefully, such as time, efficiency, or track position. Resource management is a strong bridge between gameplay decisions and real engineering tradeoffs. (Setup and Tradeoffs)
  • Review: A chance to look back at results, discuss what worked, and decide what to improve next. Review moments help students turn gameplay into evidence-based reflection. (Reflect and Review)
  • Role Lens: A point of view based on a team member’s job, such as strategist or software engineer, used to frame decisions. Role lenses help learners understand that the same situation can look different depending on a person’s responsibility. (Mission Briefing)

S

  • Score: A number the game tracks to show progress, success, or points earned. Score is useful because it gives players immediate evidence that something in the game changed. (Hit the Track)
  • Setup: The starting choices a team makes before testing, such as speed, efficiency, or strategy settings. Setup choices matter because they shape the results students will later need to explain. (Setup and Tradeoffs)
  • Simulator: A program that models part of a real system so students can test ideas in a safe, repeatable way. A simulator lets learners explore engineering decisions without needing a real car or track. (Mission Briefing)
  • Skillmap: A connected set of tutorial activities that guide learners through a sequence of challenges. Each step builds on the one before it, which supports confidence and structured progression. (Intro to MakeCode Arcade)
  • Sprite: A character, car, object, or image in the game that can appear, move, and interact. In many student projects, the sprite is the most important object because it gives the player something visible to control. (Intro to MakeCode Arcade)
  • State: The current stored condition of the game or a system, such as weather, score, or stage. State matters because the program often needs to remember what has already happened. (Mission Briefing)
  • Strategy: A planned choice about when to take risks, conserve resources, or respond to changing conditions. A strong strategy is based on goals and evidence, not just instinct. (Pit Stop Briefings)
  • Sustainability: Designing and operating in a way that uses resources responsibly over time. In this project, sustainability connects directly to efficiency, tradeoffs, and long-term thinking. (Changing Conditions)

T

  • Telemetry: Data collected from a car or system, such as speed, collisions, or performance trends, that helps teams make decisions. Telemetry turns player experience into information the team can read, discuss, and act on. (Pit Stop Briefings)
  • Tilemap: A grid-based game world built from small tiles that creates roads, walls, and track layouts. Tilemaps are helpful because they let students build spaces by combining small repeated pieces. (Hit the Track)
  • Timer: A tool that helps the game wait, count down, or trigger something after a delay. Timers are useful when the challenge depends on pacing, changing conditions, or time-based events. (Changing Conditions)
  • Track: The space where the car moves, turns, and faces challenges during the activity. The track is more than scenery because its layout changes what strategies make sense. (Hit the Track)
  • Tradeoff: A design choice where improving one thing may make another thing harder, weaker, or more costly. This is one of the most important ideas in the project because it connects gameplay balance to real engineering thinking. (Setup and Tradeoffs)
  • Trigger: The specific action or condition that starts a piece of code running. A button press, overlap, or timer finishing can all act as triggers. (Intro to MakeCode Arcade)
  • Tutorial: A guided activity that helps learners build code step by step while seeing the results. Good tutorials do more than give steps; they help students understand why each step matters. (Intro to MakeCode Arcade)

U

  • Unit: A standard label for measurement, such as miles per hour or liters, that helps make data readable. Units matter because numbers are more meaningful when students know what they represent. (Mission Briefing)
  • User Interface: The text, icons, scores, and visual elements a player uses to understand and control the game. A strong interface makes the state of the game easier to read without long explanations. (Reflect and Review)

V

  • Variable: A named container that stores information a program can use and change. For example, a variable might store speed, score, weather, or a team’s chosen setup. (Intro to MakeCode Arcade)
  • Velocity: The speed and direction an object is moving. This term is especially useful when students need to distinguish between how fast something moves and where it is moving. (Hit the Track)

W

  • Weather Condition: An environmental state, such as dry or rainy, that changes how the car behaves on the track. Weather is a clear example of how one outside factor can force new design and strategy choices. (Changing Conditions)
  • Win Condition: The rule that decides when a player has successfully completed the challenge. A win condition helps students understand what the game is asking them to optimize for. (Final Challenge)
  • Workspace: The main coding area in MakeCode Arcade where blocks are assembled. It is the place where students can literally see their ideas taking shape as a program. (Intro to MakeCode Arcade)

X

  • X-Coordinate: The horizontal position of a sprite on the screen. If the x-value increases, the sprite moves to the right; if it decreases, the sprite moves to the left. (Intro to MakeCode Arcade)

Y

  • Y-Coordinate: The vertical position of a sprite on the screen. If the y-value increases, the sprite moves down; if it decreases, the sprite moves up. (Intro to MakeCode Arcade)

Z

  • Zone: A defined part of the track or screen used for a specific purpose, such as a pit stop area, a hazard section, or a scoring region. Zones help students think about how space in a game can trigger different rules. (Pit Stop Briefings)