Three features from the proposals list, built and deployed: the wreck log, diegetic instruments, and the launch card. All three are live as clickable prototypes on the production domain, all data is validated, and the module tests pass.
Live prototypes
- Wreck log — tick pod upgrades to see what becomes reachable, collect fragments, decode them, read the log.
- Launch card generator — the end-of-run image, drawn live on canvas. Download or share.
- Diegetic instruments — the HUD deleted. Drag power down and the pod actually gets darker; drag damage up and the readouts flicker.
1. The wreck log
Sixteen fragments across five acts, written as data rather than code so the story can be revised without touching the game. The premise: the player is the surviving technician of the survey hauler Meridian Ascent, contracted to Halcyon Deep Ventures. The log reveals that the ship was not carrying what the crew was told, that the cargo is the same unknown material in the planet’s caves, and that the descent was not an accident — the course correction came from outside the ship and the captain’s nineteen override attempts were all rejected.
The structural point: fragments are found in whatever order the world allows, but they are always presented in story order, so the narrative reads correctly no matter how chaotically it was salvaged. Act 1 is completely ungated and sits in the starting zone, so the story starts in the first minute of play. Nothing is mandatory — launching having decoded none of it is a valid, quieter ending.
Total decode cost is 2,630 compute-seconds: roughly 44 minutes of analysis at base rate, 24 minutes once the research upgrade is built. That gives the onboard computer something to do across an entire playthrough rather than a single evening.
2. Diegetic instruments
Four readouts, all drawn as objects in the world instead of screen overlays: oxygen on the suit forearm (the only readout that leaves the pod), an analogue temperature gauge bolted by the hatch, power as a lamp that returns its own light radius so low power literally darkens the room, and the computer screen that is the only place the wreck log and research progress are ever shown.
Two rules baked in: colour is never the only signal (needle angle and literal text carry it too, which keeps it readable on a phone and for colour-blind players), and damaged hardware flickers deterministically, so instruments degrade instead of just reporting damage.
3. The launch card
A 1200×630 image rendered at 2× on canvas at the end of a run — no server, no image assets. Shows the choice made at launch, days survived, how much of the log was recovered, how much of the pod was restored, distance walked, depth reached, storms weathered, and the run seed. The starfield is seeded from the run seed, so the same run always produces the same sky. On mobile it goes through the native share sheet, with a download fallback everywhere else.
Validation — and a bug worth recording
A new validator cross-checks the fragment data against the pod upgrade tables: every requirement must name an upgrade tier or recipe that actually exists, story ordering must be a clean permutation with no gaps, every act must be completable, and no fragment may become decodable before the zone it lies in can be entered.
The first version of that validator passed, which was wrong. It was reading a requires field on climate zones, but the pod tables express zone access as a gate expression such as item:cave_lamp AND upgrade:navigation >= 1. Finding nothing to check, it reported success. Once the gate expressions were parsed properly it immediately caught a real fault: the Pod 2 locator beacon lies on the ice shelf and was gated only behind the drone bay, so a player with drones but without life support tier 2 would have seen it listed as ready to analyse while having no way to reach it. Now fixed.
Lesson for future data checks: a validator that cannot fail is worse than no validator, because it manufactures confidence. Every new check should be tested against a deliberately broken input before it is trusted.
State of the tests
- 123 assertions on the fragment log — gating, decode purity, story ordering, ending unlocks, and a full progression sweep proving all 16 fragments become decodable by the end of the tech tree and that the count never goes backwards mid-game.
- Existing pod data tests still green, including the simulated 14-tier playthrough.
- Both validators pass, with only the intentional launch-systems cost warning.
- Fixed a latent fault in the older test file: it loaded its data by relative path, so it only ran from inside one directory. Now resolved relative to the module.
Deployed
Uploaded to orbit2d.co/data/ and orbit2d.co/demo/ — both new directories, nothing overwritten, and the built game bundle untouched. All three prototypes were then loaded in a real browser to confirm they render and run without console errors against the live files.
Open items
- The modules cannot join the actual game until there is a repo or a source tree — the live site is Vite build output only.
- Seven orphaned bundles (~10 MB) are still sitting in
/assets/from earlier deploys; the deploy step adds without pruning. - Decode costs and the 41-day recovery-team timer are first-pass numbers and need playtesting.
- Ending hooks are recorded in the data but not implemented — they belong with Phase 4’s launch sequence.
Logged by Sean