Planetary Vertical Slice

Issue #14: One landing-site experiment

Status: Proposed design, not implemented or performance-verified.

Source baseline: main at 78fdc5db83d195ce1909c0b302c0bfe3dbe7b175, inspected 17 October 2026. Unmerged editor work is not assumed available. No code changes or tests accompanied this design.

1. Playable scope

Use a disposable world with two test pilots and one small marked landing site on existing Verdant. The site is a 512 × 512 m curved surface patch centered directly below the existing planet-approach point. It contains a landing marker, a walking marker 30 m away and one existing 8 × 8 × 8 m crate, using the current protocol dimensions.

The proposed player journey is:

1. Leave Junction in the existing small starter hull and fly normally through Verdant’s atmosphere to the landing site.
2. Brake, make ground contact and stop.
3. Disembark at a marked, collision-checked point outside the landed hull.
4. Walk to the marker, place one crate, move it and walk around it.
5. Reconnect while on foot and confirm the avatar, ship and crate remain.
6. Return to the boarding marker, board, take off and fly back above the atmosphere.

The second pilot observes the first pilot’s ship/avatar and the shared crate. They can place their own crate but cannot move or delete the first pilot’s.

All travel remains in one world and one authority. No new planet, procedural terrain, planetary warp, physical ship interior, terrain deformation, construction economy or distributed handoff is needed. Ship-to-ship and avatar-to-avatar collision are excluded; ground, static hull and prop collision are included. These exclusions must be visible in the experiment description.

Existing spherical flight contact and persistent surface props provide a starting point, not proof of this journey. Current surface walking does not exist; existing walking is restricted to docked station spaces.

Sources: surface rules, station walking, current flight and surface boundaries.

2. Coordinates and scale transitions

Keep authoritative position and velocity in existing system-space f64 meters. Preserve protocol planet center C = [0, -6,120,000, 0], radius R = 6,000,000 m and atmosphere height 60,000 m. The site center is A = [0, -120,000, 0].

For this single site, use fixed orthonormal axes:

• East E = [1, 0, 0]
• Up U = [0, 1, 0]
• North N = [0, 0, 1]

A site point (e, n, h) maps to system space as:

P = C + normalize(R·U + e·E + n·N)·(R + h)

For the inverse, let d = normalize(P − C). Then h = |P − C| − R, e = R·dot(d,E)/dot(d,U) and n = R·dot(d,N)/dot(d,U). Reject points outside the patch or with an invalid denominator. This is a bounded local chart, not a whole-planet coordinate system.

Do not rescale or rewrite authoritative coordinates when crossing the atmosphere, loading detailed tiles or changing camera mode. Derive local headings from the surface tangent plane. Keep the ship’s existing normalized system-space quaternion; changing presentation must not change orientation, velocity or ownership.

Preserve the current renderer conversion: render_position = f32((P − origin)/100). One render unit remains 100 m. Choose the nearby origin in double precision and apply a new origin atomically to camera, geometry, picking and interpolation. Keep authoritative/interpolated samples in system space so an origin change cannot replay movement. On-foot near clipping should target 0.1 m, equivalent to 0.001 render units; use a separate distant-planet pass if needed for depth precision.

Proposed numerical checks: position round-trip error ≤1 mm within the patch; ≤1 cm when adding an 8 AU test offset before nearby-origin subtraction; a forced origin change causes ≤1 pixel screen displacement for a stationary nearby marker at the recorded viewport. Atmosphere/detail crossings must not introduce a position or velocity discontinuity.

Sources: protocol geometry, render conversion, display-only motion.

3. Loading and proposed budgets

Divide the patch into sixteen 128 × 128 m tiles. Use the existing analytic sphere outside it. Begin tile prefetch below 10 km altitude while within 2 km horizontally of the site; release detailed tiles only after leaving 12 km altitude or 3 km horizontally. This hysteresis prevents threshold churn.

Load nearest tiles first, with at most two decode jobs and four queued/in-flight tiles. Each tile has a fixed ID, content version and declared allocation bounds. Discard results from obsolete load generations. Keep the analytic ground available independently of render tiles; collision cannot disappear when graphics unload.

Initial experiment targets, not measured engine capabilities:

• At most sixteen resident tiles.
• At most 4 MiB CPU and 4 MiB GPU allocation per tile: 128 MiB total resident tile allocation.
• At most 32 MiB transient decode/upload staging.
• At most 256 MiB total incremental client allocation for the experiment, including tiles, staging, collision, props and cache overhead.
• At most 16 MiB incremental server allocation for site collision/state.
• Main-thread streaming work ≤2 ms per frame; uploads ≤4 MiB per frame.
• At the fixed test settings, p95 frame time ≤33.3 ms, p99 ≤50 ms, with no streaming-attributable stall >100 ms.
• Site-related authoritative work p95 ≤5 ms per server tick with two pilots and the existing maximum of 256 props.

Instrument tracked allocations and separately record whole-process memory and GPU memory where available. If GPU memory cannot be measured directly, label allocation accounting as an estimate.

Register actual hardware, OS, renderer, resolution and optimized build before comparing runs. Start with native 1080p and browser 720p; report them independently. Do not generalize a pass to unspecified machines.

When an allocation would exceed the cap, cancel optional detail and retain coarse ground. If mandatory landing/exit collision data is unavailable, disable disembarkation and show why; never open an empty walkable world. No synchronous retry loop on the render thread.

4. Collision and mode changes

Maintain distinct authoritative modes: flying, landed/aboard and surface/on-foot. Add a surface avatar state rather than repurposing station-local coordinates or treating the planet as Location::Docked.

Retain oriented hull support against the spherical ground. Add swept movement against site prop collision for the experiment; endpoint-only checks are insufficient for thin obstacles. Sweeps run in meters, using stable collider IDs and ordered resolution. Contact removes inward velocity without bounce or damage.

Allow disembarkation only when the ship:

• Is inside the site, with ground clearance ≤0.1 m.
• Has speed ≤0.1 m/s and angular speed ≤0.01 rad/s.
• Has remained stable for one second.
• Has a clear exterior exit point and clear avatar capsule.

Define the exit marker from the existing hull bounds plus capsule clearance. It is an experiment marker, not a claimed canonical door or ship specification.

Use a surface capsule of proposed radius 0.3 m and height 1.8 m, with 4 m/s bounded movement and a 500 ms input lease. Surface movement stays grounded; no jumping or climbing is needed. Sweep/slide against hull and props and constrain the avatar within 200 m of the site center. Reject prop placement/movement intersecting any avatar, landed hull, another prop or reserved boarding clearance.

On foot, the ship is held stationary and all flight, warp, docking and delegated-control requests for that ship are rejected, including requests from another session. Boarding requires proximity ≤2 m to the marker and a clear path. Boarding atomically removes the surface avatar and returns control to the ship; it does not duplicate a pilot or move the ship.

5. Multiplayer authority and ownership

Use the existing single server writer. Clients submit bounded movement intent and requested edits, never final positions. The server decides landing, collision, boarding, ownership and limits.

Retain current prop owner identity, stable IDs and the 32-per-owner/256-world limits. In this experiment, on-foot editing additionally requires the prop and requested destination to be within 10 m of the avatar and inside the site. The existing ship-distance checks alone are insufficient for walking.

No shared editing, ownership transfer or remote operation of another pilot’s avatar is introduced. Apply competing edits serially against current authoritative state, validating each command at execution time. A later valid edit may replace an earlier edit; this experiment does not add prop-level optimistic revision checks. An invalid edit receives authoritative current state.

Add a control-session generation and monotonic input sequence for the surface controller. Only one session controls a pilot at a time; explicit takeover invalidates earlier generations. Every mode-changing request carries its expected mode revision. Reject stale revisions so delayed disembark/board commands cannot reverse a newer state. A lost response requires a fresh snapshot before another mode request.

Use fixed movement substeps no larger than 25 ms, stable collider ordering and versioned geometry. Identical inputs and timestamps on the same build must reproduce the same decisions. Cross-platform floating-point lockstep is not promised: the server is authoritative and clients reconcile.

6. Save, disconnect and restart

Commit mode changes, avatar pose, ship pose and prop changes through the existing world transaction. Persist system/planet/site IDs, geometry version, mode revision, avatar pose/heading and stable entity identities. Do not persist active input leases or depend on streamed meshes.

On disconnect or lease expiry, stop avatar movement. Keep the avatar and locked landed ship in place. On restart, clear all control leases and resume no movement automatically.

Reconnect must authenticate, receive the current mode revision and complete site readiness before enabling controls. Clear old interpolation/input queues. Never replay pending movement or automatically retry a prop creation whose response was lost; inspect the returned authoritative prop list first. Existing generic commands have no idempotency keys.

If a geometry update invalidates a saved avatar position, choose the nearest valid point from an ordered set of reserved recovery markers and report relocation. If none is clear, preserve the save and refuse entry with a recoverable error. Unknown save/geometry versions fail safely without rewriting the world.

A crash during a transaction restores either the previous or new complete mode, never half an avatar/ship transition. These changes do not award resources or alter the economic ledger. The economic verifier remains an economy verifier, not a physical simulation replay.

Source: current persistence, authority and retry boundaries.

7. Implementation acceptance protocol

Record exact source/build identity and retain logs, timings and screenshots/video where useful. These tests are proposed and have not been run:

1. Coordinates: verify both transform directions, patch corners, large-offset precision, orientation continuity and forced origin changes.
2. Journey: complete the flight–land–walk–edit–reconnect–board–return sequence with two clients. Both must see matching entity IDs, ownership and mode changes.
3. Collision: attempt high-speed descent, oblique hull contact, walking into each prop, diagonal sliding, blocked exit/boarding and edits through occupied space. No accepted final overlap beyond 1 cm tolerance; no tunneling through static obstacles.
4. Authority: reject non-finite/out-of-range inputs, another pilot’s edits, out-of-range edits, second-session stale inputs and flight while on foot. Rejected commands must leave world state unchanged.
5. Interrupted state: disconnect before/after each mode-change commit, lose the response, reconnect, restart and inject a write failure. Confirm one pilot, one ship, no duplicate prop and no stuck control lease.
6. Streaming/performance: run ten complete approach/retreat cycles with cold and warm cache, delayed/failed tile loads and the 256-prop stress case. Seed that fixture with at least eight saved owners under the retained 32-per-owner limit; only two pilots need active sessions. Meet the stated budgets; cache/allocation counts must return to their bounded steady state. Report timing percentiles and maxima, not average FPS alone.
7. Compatibility: load an older disposable world without surface avatars, verify preserved economic balances/ledger, and confirm station walking remains separate and unchanged.

Scope and delivery boundary

This document defines the small playable vertical slice requested by #14. It does not implement or verify the experiment.

Implementation, native/browser testing and performance evidence remain future work, dependent on #45 and #36. The experiment remains outside public-release blockers. A completed design is not shipped seamless planetary gameplay.