Category: Build log

  • Phase 2.5 spec, revision 2 — night, semi-idle, climate zones, save integrity

    Backfilled entry covering the work that came before the build log above, recorded here so the project history is in one place.

    Phase 2.5 — The Pod Reborn

    The landing pod was a recharge station. The plan is to turn it into a home, then a base, then a command centre, then a spacecraft — with the launch as the game’s actual ending. Specced in full: seven upgrade lines plus launch systems, a fabricator progression, comms beats running from OFFLINE to UNKNOWN TRANSMISSION, four exterior damage states, and a walkable interior entered through the side hatch.

    Deliberately excluded: sleep. The pod is a survival and technology hub, not a bed.

    What the second revision added

    • Night is pod time — the replacement for sleep. Eight-minute days, four-minute nights, with a dusk warning. At night the surface is genuinely hostile: colder, low visibility, faster oxygen drain, a chance of storms. The pod is where you want to be. Critically, station speed is not improved at night — the moment night is mechanically optimal, players start waiting for it, and that is sleep with extra steps.
    • Semi-idle stations — the fabricator works a queue, the computer analyses samples, the ice extractor fills reserves, comms listens, drones mine. None of it runs while the game is closed: this is pacing, not an idle clicker.
    • Climate zones as honest gates — crash basin, ice shelf, day-side flats, deep caves, each gated by an upgrade or a crafted item. Life support tier 2 unlocks a place, not a bigger number.
    • Save durability — the real risk of shipping in a browser. Browser storage vanishes silently: cleared site data, private windows, storage eviction, and iOS discarding IndexedDB for sites unvisited for seven days. The save layer uses IndexedDB with persistent-storage request, versioned schema with forward-only migrations, three rolling backups rotated before the live slot is touched, copy-on-write staging, a recovery chain, player-owned export and import, and autosave on visibility change — the only reliable “the app is going away” signal on mobile.

    Two soft-locks caught by validation

    Both were in the first pass of the upgrade tables, and both would have been discovered by a player rather than a developer.

    • The salvaged antenna sat in the day-side flats, behind a thermal suit, behind fabricator tier 2 — but the comms array it unlocks arrives seventh of fifteen upgrades. Unreachable when needed. It now lies at the end of the descent debris trail in the starting zone: ungated, a long walk, and better fiction, since it snapped off on the way down.
    • Metal and the first unknown crystal were required by the power core and early storage, but every zone that supplies them unlocked later. The crash basin now holds finite salvage plating — 42 units, against the 34 needed to reach the fabricator — and one shallow crystal seam yielding exactly the two required. After that you smelt rock, which is what makes the smelter feel earned.

    Lessons taken from The Blockheads

    Researched properly, because Orbit2D is modelled on it. It did not fade because of content or competition — the hosted servers were shut down in August 2022 over cost and maintenance burden, having already been moved behind a paid purchase. The lesson is that a solo sandbox dies at the hosting bill, so any social layer here must cost approximately nothing to run: seeds, exported world files, asynchronous artefacts.

    What players actually loved was the semi-idle pacing, the climate and seasons, the soundtrack, and the low-combat mood — not the block breaking. What they hated was time-skip purchases and lost save data. And the most requested feature that never fully shipped was automated crafting, which is now on the roadmap as a deliberate late-game reward.

    The one thing not to copy: Blockheads had no ending. Orbit2D does. That is the single biggest advantage over it, and every feature decision is filtered against whether it protects the launch.

    Logged by Sean

  • Build log — wreck log, diegetic instruments, launch card

    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