Orion

A self-contained H51 mission-control game about judgment under pressure.

Guide ORION-7 from ignition to safe Earth recovery while balancing power, fuel, oxygen, and hull integrity. Every decision changes the spacecraft's condition, every mission draws a different event sequence, and hesitation triggers an automatic—but costly—contingency.

Play Orion on GitHub Pages

Overview

Orion is a compact browser-based simulation created as an H51 / Area 51 capability-building experiment. It tests whether a small, state-based system can create meaningful choices, tension, and replayability without a backend, accounts, external assets, or production infrastructure.

The current build is a complete playable MVP:

One launch-to-recovery mission lasting approximately 3–7 minutes.
Four critical resources: power, fuel, oxygen, and hull.
Four mission phases with two decisions in each phase.
Sixteen authored events, with eight selected per run.
Two or three consequential choices for every event.
A 20-second response window and event-specific timeout contingencies.
Success, four distinct resource-depletion failures, scoring, ranks, replay, and restart.
A pause-safe in-world Project Dossier containing the supplied charter and roadmap facts.
Device-local settings and aggregate mission history.
Responsive, keyboard-accessible, reduced-motion-aware presentation.

The entire runtime is contained in index.html. It makes no network requests and loads no external code, fonts, images, APIs, or analytics.

Experience at a glance

Attribute	Current implementation
Format	Single-player browser game
Mission	Launch ORION-7, survive system failures, and recover safely on Earth
Typical duration	3–7 minutes
Decisions per run	8
Authored event cards	16
Mission phases	Launch, orbital transfer, Earth approach, re-entry
Managed resources	Power, fuel, oxygen, hull
Default response window	20 seconds per decision
Outcomes	Safe recovery or immediate termination when a resource reaches zero
Persistence	Browser `localStorage` only
Backend	None
Runtime dependencies	None
Deployment	GitHub Pages

How to play

Open the live game.
Review the flight directive and choose whether to keep the 20-second response timer or enable unlimited time.
Authorize launch.
Read each incident and select one command response.
Review the result and its resource changes, then continue the flight.
Keep all four resources above zero through eight decisions.
Reach recovery, inspect the score breakdown, and replay with a new event sequence.

Each run begins with all four resources at 72. Resource values are clamped between 0 and 100. Positive effects can restore a system, while negative effects consume reserves or damage the spacecraft.

If power, fuel, oxygen, or hull reaches 0, the mission ends immediately after the current decision is resolved. A successful mission requires completing all eight decisions with every critical system still viable.

Decision timing

The default response window is 20 seconds. If it expires, the flight computer executes that event's authored contingency. Contingencies are deliberately safe in intent but expensive in resources, so timing changes the strategic cost of a mission without producing a dead end.

The timer stops while:

The mission is paused.
The Project Dossier is open.
A decision result is being reviewed.

Unlimited time is an accessibility preference. It persists on the current device and can be changed from the briefing or pause screen.

Mission structure

Each mission draws exactly two events from each phase. Events are shuffled within their phase and never repeat within one run.

Phase	Decisions	Flight context
Launch	2	Ignition, ascent corridor, and early spacecraft stabilization
Orbital transfer	2	Transfer burn, orbital navigation, and life-support endurance
Earth approach	2	Recovery alignment, communications, and vehicle preparation
Re-entry	2	Heat management, guidance blackout, descent, and recovery

This phase-weighted selection creates a controlled narrative arc while still allowing varied combinations across replays.

Event deck

Orion includes sixteen event cards—four for each phase.

ID	Phase	Event
`L-01`	Launch	Ignition asymmetry
`L-02`	Launch	Primary bus undervoltage
`L-03`	Launch	Cooling loop spike
`L-04`	Launch	Forward hatch pressure decay
`T-01`	Orbital transfer	Solar particle front
`T-02`	Orbital transfer	Scrubber bed saturation
`T-03`	Orbital transfer	Inertial navigation drift
`T-04`	Orbital transfer	Debris crossing
`A-01`	Earth approach	Ground-link blackout
`A-02`	Earth approach	Service-loop coolant leak
`A-03`	Earth approach	Attitude-control desynchronization
`A-04`	Earth approach	Cabin medical alert
`R-01`	Re-entry	Heat-shield telemetry gap
`R-02`	Re-entry	Plasma navigation blackout
`R-03`	Re-entry	Main fuel-line pressure loss
`R-04`	Re-entry	Recovery beacon offline

Every event follows one internal schema:

{
  id: "L-01",
  phase: "launch",
  title: "Ignition asymmetry",
  narrative: "Situation presented to the flight director.",
  choices: [
    {
      label: "Command response",
      detail: "Trade-off shown before selection.",
      deltas: { fuel: -10, power: -2 },
      risk: 0,
      result: "Authored consequence shown after selection."
    }
  ],
  timeout: {
    label: "Automatic contingency",
    deltas: { fuel: -10, oxygen: -5 },
    risk: 0,
    result: "Fallback executed when the response window expires."
  }
}

Scoring and ranks

The final score rewards mission completion first, then remaining systems, response efficiency, and controlled risk.

Component	Calculation
Mission	`1,400` points for recovery; on failure, `100 × decisions completed`
Systems	`6 × average remaining resource level`
Tempo	Timed mode: up to approximately `400` points based on average response time
Tempo	Unlimited-time mode: fixed at `200` points
Controlled risk	`25 × accumulated risk points`

The displayed total is:

mission + systems + tempo + controlled risk

Ranks are awarded only after successful recovery:

Rank	Score
S	2,700 or higher
A	2,350–2,699
B	2,000–2,349
C	1,650–1,999
D	Below 1,650
NO-GO	Mission terminated

Risk points reward deliberate exposure to a more dangerous option; they do not override the primary requirement to complete the mission with viable systems.

Accessibility and controls

Orion is designed for mouse, touch, and keyboard play from phone through desktop.

Keyboard controls

Key	Action
`1`, `2`, `3`	Select the corresponding visible command option
`Enter` or `Space`	Continue after reviewing a decision result
`Escape`	Pause an active mission
`Tab` / `Shift` + `Tab`	Move through interactive controls

Accessibility behavior

Semantic buttons, headings, meters, dialogs, and labels.
Programmatic focus movement when events and mission outcomes appear.
Polite screen-reader status announcements for incidents, consequences, resource changes, and outcomes.
Persistent unlimited-time mode.
Timer suspension during pause and dossier review.
Visible focus styles and keyboard choice shortcuts.
Touch-friendly controls and responsive layouts.
Support for the operating system's prefers-reduced-motion setting.
Text labels supplement color-coded warnings and resource states.

Local data and privacy

Orion has no backend and collects no personal information. No analytics, telemetry, mission history, or settings leave the browser.

The game stores one defensive, versioned record under the localStorage key orion.v1:

{
  onboarded: Boolean,
  unlimitedTime: Boolean,
  missionsStarted: Number,
  missionsCompleted: Number,
  missionsWon: Number,
  replayCount: Number,
  bestScore: Number
}

Missing, malformed, negative, or otherwise invalid stored values are sanitized before use. If browser storage is unavailable, the game remains playable and reports that history could not be saved.

To reset Orion's local history, clear site data for https://hmuyal.github.io in the browser. This removes Orion's local settings and aggregate play history from that device, but it can also clear data stored by other project sites on the same GitHub Pages origin.

Technical design

Orion intentionally uses a minimal delivery architecture:

index.html
├── semantic HTML interface and dialogs
├── responsive CSS visual system
├── inline event definitions
├── mission state and scoring logic
├── local persistence and validation
├── accessibility announcements and focus control
└── Canvas 2D trajectory visualization

Runtime characteristics

Standards-based HTML, CSS, and vanilla JavaScript.
No build step.
No package manager.
No framework or library.
No service worker.
No cookies.
No accounts or authentication.
No external runtime references.
No generated SVG assets.
No server-side execution.

State model

The runtime separates:

Profile state: persistent device-local settings and aggregate history.
Mission state: resources, selected deck, current event, timing, risk, and outcome for the active run.
Authored content: phases, event narratives, choices, resource deltas, consequences, risk values, and timeout contingencies.

Mission decks are generated by filtering events by phase, shuffling each phase, and taking two events from each group. This guarantees eight decisions, four ordered phases, and no repeated card in a run.

Visual system

The interface uses a distinct H51 orbital identity:

Midnight-blue command surfaces.
Telemetry cyan for system information.
Warning amber for decisions and trajectory emphasis.
Red for critical alerts.
Fine grids, scan lines, glows, and telemetry typography.
A responsive Canvas 2D display that draws Earth, orbital rings, the flight path, and ORION-7's current mission progress.

All effects are generated by CSS or Canvas at runtime.

Run locally

No installation or build is required.

Option 1: open the file

Open index.html directly in a modern browser.

Option 2: use a local static server

From the repository root:

python3 -m http.server 8000

Then visit:

http://localhost:8000/

A local server gives the page a stable origin, which makes browser storage behavior consistent across browsers.

Browser requirements

Use a current version of Chrome, Edge, Firefox, or Safari with JavaScript, Canvas 2D, <dialog>, ResizeObserver, and localStorage support.

Validation

The current artifact has been checked for:

Valid document structure and inline JavaScript syntax.
Sixteen distinct event cards.
Two randomly selected events from every mission phase.
Eight non-repeating decisions per run.
Resource changes clamped to the 0–100 range.
Timeout contingency execution.
Timer suspension during pause and dossier review.
Power, fuel, oxygen, and hull failure outcomes.
Successful launch-to-recovery completion.
Score calculation, rank display, replay, and briefing restart.
Recovery from malformed local storage.
Keyboard controls, accessible labels, focus flow, and live announcements.
Reduced-motion and responsive phone, tablet, and desktop layouts.
Absence of external runtime assets, libraries, fonts, APIs, and requests.
Byte-for-byte equivalence between the committed index.html and the live GitHub Pages response.

Deployment

The public site is deployed by .github/workflows/pages.yml.

Every push to main:

Checks out the repository.
Copies only index.html into the deployment artifact.
Uploads the static artifact to GitHub Pages.
Deploys it to https://hmuyal.github.io/Orion/.

The workflow can also be started manually with workflow_dispatch.

Because the game is self-contained, no environment variables, secrets, build commands, or runtime services are required.

Project charter

Intent

Orion is a Market Making / capability-building experiment within H51. It is not initially intended to become a commercial game. Its purpose is to validate rapid product development, lightweight simulation mechanics, replayability, and reusable technical components in a time-boxed 4–6 week validation cycle.

It complements Roswell by testing decision-making, prioritization, and trade-offs under pressure rather than exploration and escape.

Goals

Deliver a complete browser mission simulator that requires only a short onboarding screen.
Create a clear decision loop around limited resources and changing conditions.
Test whether event combinations create enough tension and variety to encourage replay.
Exercise rapid development practices, AI-assisted coding, automated testing, and lightweight telemetry.
Produce reusable event-card, resource-meter, scoring, and persistence patterns for future H51 prototypes.

KPI framework

Metric	Target	Time frame
Time to first playable version	7 working days or less	End of Week 1
MVP delivery	Complete mission with launch, events, resources, outcomes, score, and restart	End of Week 3
User validation	At least 20 test players	End of Week 5
Mission completion	At least 65% complete a full mission, successful or failed	End of Week 5
Replay rate	At least 50% start a second mission	End of Week 5
Comprehension	At least 80% understand the controls after onboarding without help	End of Week 5
User experience	Average clarity and engagement rating of at least 4/5	End of Week 5
Reliability	No known game-blocking defects in the release candidate	Before release
Scenario variety	At least 15 event cards with different consequences or choices	End of Week 3
Learning capture	At least 5 hypotheses documented and 3 validated or rejected	End of Week 6
Reusability	At least 2 reusable components or patterns extracted	End of Week 6

Boundaries

The initial experiment deliberately excludes:

3D graphics and realistic orbital physics.
Multiplayer.
User accounts.
Payments.
Server-side infrastructure.
Personal, sensitive, or customer data collection.
Features that threaten the MVP delivery window.

Technical choices prioritize simplicity, readability, and rapid iteration over simulation realism or platform completeness.

Exit conditions

Decision	Condition
Continue	MVP delivered by Week 3, controls understood independently, and Week 5 replay and engagement targets broadly achieved
Pivot	Simulation works technically but engagement is weak and feedback indicates a stronger audience, scenario, or interaction
Split	Event engine, scenario model, or reusable interface components provide more value than the original game
Succeed	Complete release shipped, measurable evidence produced, and reusable technical or operating patterns documented
Stop	No end-to-end mission by end of Week 2, boundaries exceeded, or continuation requires contradictory infrastructure or complexity

Roadmap and milestones

The authoritative roadmap covers August through early September 2026.

Milestone	Target	Success signal	Owner	Source status
First Playable Mission	August 2026, Week 1	Launch, at least three events, decisions, resource use, and an end state work in a browser	Maya Chen	Not started
MVP Feature Complete	August 2026, Week 3	Complete 3–7 minute mission, onboarding, four resources, at least 15 cards, scoring, restart, and no known blocking defects	Hervé Muyal	Not started
User Validation Complete	September 2026, Week 5	20 testers; 80% comprehension, 65% mission completion, and 50% replay	Priya Nair	Not started
Graduation Decision	September 2026, Week 6	Findings, hypotheses, reusable components, and continue/pivot/split/succeed/stop decision published	Hervé Muyal	Not started

The source roadmap labels these milestones Not started. This README preserves that supplied governance status even though a playable implementation now exists; milestone status should be changed only through the project's formal tracking process.

Dated delivery plan

Deliverable	Target	Owner
Mission loop and game-state specification	31 July 2026	Lucas Bennett
Browser prototype with launch, resources, events, and end state	7 August 2026	Maya Chen
Initial visual system and mission-control interface	10 August 2026	Lucas Bennett
Event engine with at least 15 cards and branching consequences	14 August 2026	Maya Chen
Onboarding, scoring, restart, and local persistence	18 August 2026	Maya Chen
Automated resource and outcome checks	20 August 2026	Priya Nair
Internal MVP release	21 August 2026	Hervé Muyal
Test plan, feedback form, and lightweight telemetry	24 August 2026	Priya Nair
User testing with at least 20 participants	31 August 2026	Priya Nair
Balancing, usability improvements, and release candidate	4 September 2026	Maya Chen
Experiment report and reusable component package	8 September 2026	Hervé Muyal
Graduation review and next-step recommendation	10 September 2026	Hervé Muyal

Extending Orion

Add an event

Add a new object to EVENT_DECK in index.html and preserve the existing schema.

An event should:

Have a unique ID.
Belong to one of the four existing phase IDs.
Present a clear incident and decision.
Offer two or three materially different choices.
Declare resource deltas only for known resources.
Include an authored consequence for every choice.
Assign a deliberate risk value.
Include a conservative timeout contingency.
Avoid any single obviously dominant option.

Adding events does not require changing the selection algorithm. The runtime will continue drawing two cards from each phase.

Change balancing

The main balancing constants are near the start of the inline script:

RESPONSE_SECONDS
STARTING_RESOURCES
Choice and contingency deltas
Choice risk values
Score multipliers and rank thresholds

When changing balance, verify every resource-depletion path, successful recovery, and score tier again.

Add a mission phase

Adding a phase requires coordinated changes to:

PHASES
Event phase values and sufficient cards for selection
Mission progress and phase interface markup
The expected event count used by progress and outcome copy
Test expectations and documentation

Repository structure

Orion/
├── .github/
│   └── workflows/
│       └── pages.yml   # Automatic GitHub Pages deployment
├── README.md           # Project, gameplay, architecture, and roadmap guide
└── index.html          # Entire playable application

License

No license file is currently included. Public availability of the repository does not by itself grant permission to copy, modify, or redistribute the code. Add an explicit LICENSE file before treating Orion as an open-source project.

Name		Name	Last commit message	Last commit date
Latest commit History 5 Commits
.github/workflows		.github/workflows
README.md		README.md
index.html		index.html

Folders and files

Latest commit

History

Repository files navigation