This page makes the intended student outcomes explicit before facilitation begins. It provides a clearer sense of what learners should understand, do, and talk about by the end of the experience.
These goals are not a script and they are not a checklist to rush through. They are a planning anchor for keeping the session focused on the outcomes that matter most: visible cause and effect, meaningful tradeoffs, evidence-based explanation, and a stronger sense of belonging in STEM.
Learning Goals
By the end of the experience, learners should be able to:
- describe how a code or setup change affected what happened in the game
- explain at least one engineering tradeoff involving speed, control, efficiency, strategy, or sustainability
- make a prediction, test it, and revise their thinking based on evidence
- connect a gameplay moment to a real role in software, testing, data, strategy, design, operations, or sustainability
- leave with a stronger sense that engineering and technology are fields they can belong in
Computer Science and STEM Goals
This section aligns most directly with middle school CSTA concept areas, especially Algorithms and Programming and Data and Analysis. The goal is not to turn the session into a standards lesson. The goal is to make these ideas visible through play, prediction, testing, and discussion.
- Inputs, outputs, and events: learners see that a button press, overlap, or condition change causes a clear system response, which supports event-driven thinking in CSTA Algorithms and Programming.
- Variables and program behavior: learners adjust visible setup values and observe how those changes affect movement, efficiency, score, or control, which supports CSTA expectations around using variables to influence program behavior.
- Testing, debugging, and iteration: learners make a change, test it, notice what happened, and revise, which supports CSTA goals around iterative program development and debugging.
- Data and evidence-based decisions: learners use score, collisions, handling, and other feedback signals as evidence when explaining what happened and what to change next, which supports CSTA Data and Analysis.
- Constraints and optimization: learners see that there is no single perfect setup because improving one outcome can create a cost elsewhere, which supports computational problem-solving and engineering reasoning under constraints.
Facilitation Goals
Educators running the session should aim to:
- get students into action quickly instead of front-loading explanation
- keep the focus on a small number of visible decisions or variables at a time
- normalize debugging, weak results, and revision as part of the process
- use discussion to connect gameplay outcomes with engineering reasoning
- make career connections feel natural and grounded in what students just did
Belonging and Accessibility Goals
The project is also trying to do something relational, not just technical. Students should leave with the sense that thoughtful observation, communication, and persistence are real strengths in STEM spaces.
The room is moving in the right direction when it communicates these messages:
- there are many valid ways to approach a problem
- technical work is not only for students who already see themselves as “the coding kid”
- careful reasoning and calm adaptation matter as much as speed or confidence
- accessible design is part of strong design, not an optional extra
Evidence of Success
The session is on track when learners can do most of the following in simple language:
- say what changed
- explain what happened next
- name one tradeoff they noticed
- identify a role that would care about that kind of decision
- describe what they would test next if they had another round