Written responses
An open response lets learners explain a decision in their own words. It also exposes assumptions that a fixed answer might leave hidden.
A browser-based Mars mission where students explain a decision using scientific evidence.
Next.js · React Three Fiber · Rapier · NASA MEDA · OpenAI Responses API
The Problem
The idea came from science museums and NASA visitor centers, where I had found well-presented, reliable material. A complete mission, played rather than read, seemed like a way to give beginners the same entry point. I chose Mars because it is familiar enough to feel real; a less known destination would have read as science fiction.
The player takes the role of the systems engineer on duty during a dust-and-power warning. Solar input is falling, and crew members are outside the habitat. The scenario assumes a fifteen-minute one-way communication delay with Earth.
I used that constraint to give the learner a reason to examine the available information before acting. Environmental readings describe conditions outside. Power and communications records help establish what the habitat can support.
The written response asks learners to explain which observations influenced their plan. This gives the debrief something specific to address.
What I Built
The intended mission length is 8–10 minutes.
A skippable opening and briefing introduce the warning, crew activity, and communication delay.
Environmental, Power, and Communications stations contain interactive consoles. Pause and position recovery are available throughout exploration.
Each panel explains a reading and identifies its category. Learners choose which records to add to their mission log.
At Central Command, the learner proposes an action and explains the supporting evidence.
The debrief examines the plan's assumptions and use of evidence, including its resource trade-offs. The mission allows up to three assessments.
Sources & Methods documents the references, data transformations, fictional conditions, and AI use.
Evidence Design
Real observations and fictional conditions appear in the same habitat, which is the same mix that makes films misleading. I wanted learners to see what each number represented while deciding how to use it.
The data methodology documents selected pressure, air-temperature, and wind records from NASA's Mars 2020 MEDA archive. The comparison covers two Martian days around the January 2022 Jezero dust storm.
| Label | What it represents | Example in the mission |
|---|---|---|
| NASA observation | Values calculated from reviewed MEDA records, with documented sources and transformations | Mean atmospheric pressure |
| Scientific reference | Published scientific or mission context | Dust optical depth reported in research |
| Derived rule | A documented teaching abstraction | A fictional 20% reduction in solar input |
| Simulated telemetry | Conditions created for Aster-9 | Remaining power reserve |
The solar-input reduction creates a power-conservation decision within the mission. Its label identifies it as a teaching rule so learners can distinguish it from a measured observation.
During visual review, a styling change had reduced the measurements to ordinary body-text size. I asked for the readings to regain prominence. Codex implemented the correction and added a browser check for the same regression. The review record documents that change.
My Role
Signal Delay was built in collaboration with AI; the design decisions, content, and direction are mine.
I defined the audience and learning goal, developed the scenario, and decided how the evidence categories should appear. Reviewing the playable builds also meant deciding whether a reading was legible and whether the feedback addressed the learner's actual response.
The implementation was produced with the following tools:
| Collaborator | Contribution |
|---|---|
| OpenAI Codex | Primary implementation of the application, procedural habitat, data pipeline, evaluation integration, tests, and development documentation |
| Claude Code | Execution prompts, implementation review, and corrections, including cinematic and browser-test stabilization |
| GPT-5.6 | Early work-package prompts and evaluation of learners' written plans in the finished prototype |
The repository preserves the execution prompts alongside session records.
Design Decisions
An open response lets learners explain a decision in their own words. It also exposes assumptions that a fixed answer might leave hidden.
The application includes a versioned set of evidence records. Gameplay therefore uses a consistent dataset and does not depend on a live NASA archive request.
Code-generated geometry and cel shading establish the environment without downloaded 3D assets. Cyan identifies interactions, amber signals power warnings, and blue-white identifies communications. ASTER's AI-generated voice lines have captions.
I kept the scope to one habitat and one scenario so the prototype could include the path from exploration through revision. Additional missions and multiplayer remained outside this version.
The mission uses keyboard and mouse controls in desktop Chrome or Edge. HTML overlays present the evidence above the 3D scene. Full mobile controls were outside the project's scope.
A failed evaluation preserves the learner's plan and mission log. The learner can retry or choose labeled local contingency guidance, which uses simpler rules than the live model.
Technical Guardrails
GPT-5.6 evaluates the plan using the scenario's evidence and available actions. Application checks validate its output before the result becomes a debrief.
The evaluation follows five steps:
Submit the plan and identifiers for inspected evidence.
Load the trusted scenario and evidence records.
Request a structured assessment from the model.
Check the proposed actions, references, outcomes, and resource limits.
Present the validated assessment.
An early playthrough exposed a problem with this process. A plan suggesting “close the windows and doors” produced a validation error because that action was unavailable in the scenario.
The learner still needed an explanation. My correction request asked the evaluator to acknowledge the idea, explain its feasibility, and suggest an available alternative. Codex revised the handling, and a follow-up live check confirmed that this example could reach the debrief.
Review
Development ran from July 16 to July 20, 2026. Each work package included a recorded prompt and acceptance checks. Automated tests used fixed data, while separate browser checks and selected live-model checks examined the mission flow. The testing documentation records their coverage and limitations.
The next evaluation should involve learners completing the mission. I would examine whether they can distinguish observations from teaching rules, then compare their first and revised plans to see how they use the evidence after receiving feedback.
Signal Delay is intended for educational use.
Play Signal Delay in desktop Chrome or Edge, or explore the source and development records.