The deep-space museum: endless corridor, zero gravity, per-room streaming, multiplayer presence. · Rendered from docs/SPACE-MUSEUM-DIRECTION.md in the project repository · view as Markdown

Inception Space — Deep-Space Museum Product Direction

• Status: owner product direction, recorded 2026-08-01. Core implemented same day at index.html?world=museum (Three.js-first per the benchmark evidence; engine ADR still open): procedural deterministic starfield skybox (NASA SVS swap-in pending download approval), endless glass corridor with air walls and portals on both side walls (2 open rooms + 4 sealed slots), per-room streaming (load at 9 m, unload at 22 m, only the occupied room's six faces repaint), zero-g flight with first/third-person toggle (V), the original Lucas Academy Baby Astronaut avatar (GLB Idle/Walk/Float/Dive loops, mannequin fallback), and the desktop-2/mobile-1 DPI policy (?dpr= override). Multiplayer (§10) and all [FUTURE] items remain design-only. Owner QA revision (same day): rooms are now fully DETACHED pocket spaces — the portal teleports (touch the membrane) instead of being a physical doorway, the corridor glass is sealed (no wall crossing by construction), nothing of a room renders or loads until entry, a return portal floats inside each room, portals sit at glass-segment midpoints (never on seams), the third-person camera is clamped inside the current space, and flight feel was tuned +20% accel / −20% damping.
• Scope: refines the world/visual/interaction direction on top of docs/INCEPTION-SPACE-EXECUTION-PLAN.zh-en.md. The plan's privacy layers, .lpr pipeline, provenance policy, and decision gates all still apply.
• Legend: [BUILD] = active direction for upcoming phases. [FUTURE] = recorded now, explicitly NOT executed yet.
• Team split (owner 2026-08-01): CC owns the main program/architecture; Codex owns art-side polish and parameter/visual fine-tuning. Structural changes, protocols, and data formats stay with CC; shader/material/color tweaking passes belong to Codex.

1. Theme — an art museum in deep space [BUILD]

The museum floats in deep space: a minimal, futuristic, non-photoreal station whose rooms hold the students' living artworks. This replaces the generic "future sci-fi museum" phrasing with a concrete setting; identity safety, curation, and the three authorization layers are unchanged.

[FUTURE — record only] Gameplay expansion on top of the museum (exploration objectives, light game mechanics). Not designed or built yet.

2. Deep-space backdrop — real imagery is available [BUILD]

Real public-domain / free-license deep-space imagery exists and fits the provenance policy (plan §4.4), so owner-generated art is a fallback, not a requirement:

Notes: single telescope photos are narrow-FOV flats — they work as vista planes/portal art, not as a full sky; the SVS star map is the only source here that wraps correctly as a skybox. Every downloaded file gets a content/inception/assets/PROVENANCE.md entry (source URL, date, license snapshot, sha256) like the Quaternius entries. Composite skybox (SVS stars + a few nebula sprites) is Codex-tunable later.

3. The endless corridor [BUILD]

• The corridor has no visible beginning or end — it reads as extending to infinity in both directions. Invisible air walls clamp movement well before the visual limit, so players can never reach or see a terminus.
• Portals open along BOTH side walls, not at the ends. Each portal leads to one art room; new rooms extend the corridor sideways indefinitely. (The current bake-off slice has an end-wall portal — that layout is superseded for the product world.)
• Corridor material: sci-fi glass — transparent/translucent panels with emissive tech trim, so deep space is visible through the walls, floor, and ceiling. Implementation sketch: skybox + transparent PBR/standard material with fresnel-ish rim (Codex tunes), repeated corridor segments + distance fog/fade to fake infinity cheaply.

4. Per-room independent loading [BUILD]

Each room loads independently when entered (portal = loading boundary) and unloads/pauses when left, so total resources stay bounded no matter how many rooms the class adds:

• Room = self-contained bundle: geometry manifest + props + artwork surfaces (.lpr packages later) + provenance. Props are solid: their footprints become world AABBs and the flight step pushes the body out along the shallowest axis (low props can be landed on, tall ones block).
• Entering a portal streams that room in; leaving disposes GPU resources (plan Phase 3 disposal rules) and fully stops its Live Painting work (frame-budget scheduler, plan §5.4).
• The corridor itself stays tiny: glass shell + portals + skybox.
• This maps 1:1 onto the multiplayer sharding model (§10).

5. Scale and resolution strategy [BUILD]

• Avatar much smaller relative to the space; rooms larger. The point is spatial grandeur — museum halls, not domestic rooms. Concrete ratios are Codex-tunable; the manifest keeps avatar physical size ~1.8 m and scales the architecture up instead, so real-world proportions stay believable.
• Artwork texture density: 1024² per face is the default (owner QA 2026-08-02: sharp and smooth on both desktop and iPad). On a 16 m wall that is 64 px/m. The Menu's graphics switch offers High (1024², dpr ≤2) and Low (512², dpr 1) as a safety valve on weaker devices; the choice persists in localStorage and ?arttex= still overrides for experiments.
• Device pixel ratio policy: desktop renders at high DPI (dpr up to 2); iPad and phones render at low DPI (dpr 1). Phones are treated the same as iPad — no phone-specific rendering optimization work beyond that.

6. Zero gravity and free view [BUILD, controls to be prototyped]

• Physics: zero-gravity movement — the avatar floats and drifts with damping instead of walking on a floor plane.
• Camera: free view with a first-person / third-person toggle.
• Control scheme (owner-specified 2026-08-01 QA r2, IMPLEMENTED):
• Desktop look: FPS-style pointer lock — click captures the mouse (cursor stays centered), Esc releases it so the mouse can click UI. No drag-look.
• Desktop move: WASD/arrows move in the horizontal plane and combine with the vertical control. Space floats upward by default; when the avatar reaches the ceiling during the same press, Space switches to diving until released. The next press starts upward again.
• iPad/touch: left virtual joystick = horizontal move; touch-drag anywhere else = look; dedicated Float and Dive buttons combine with the joystick; Menu pauses and frees the screen for taps. On desktop, Esc opens the same Menu.
• The default Baby Astronaut GLB now carries purpose-built Idle_Loop, Walk_Loop, Float_Loop, and Dive_Loop clips. The renderer blends by actual horizontal/vertical motion, so a blocked control does not leave the avatar in the wrong pose. Quaternius remains a retained benchmark asset.
• [FUTURE — record only] Per-character flight tuning (owner 2026-08-01): acceleration/damping/max-speed could vary by avatar/character so different bodies feel different in zero-g. Not implemented; revisit when avatar variety lands.
• Bench/scripted-tour logic must grow a 3D waypoint mode when this lands.

6b. Free web editors for models and collision volumes [research, owner question 2026-08-02]

No purchase needed; the practical split is models vs scene/collision:

Recommendation: keep museum.js as the source of truth and add a small importer that converts an exported scene's collider_* boxes into manifest volumes. That keeps the declarative-data boundary (AGENTS.md: no runtime code from authored content) while giving a visual editing loop. Nothing is built yet — this is the recorded answer, not a commitment.

For future student-edited avatars, the recommended path is Nomad Sculpt or Blender Sculpt for shape -> Blender for retopology, UV/material cleanup, rigging, the four named loops, and GLB export -> teacher review -> import. Current Pilot acceptance limits are at most 20,000 triangles, at most 80 joints, at most three reviewed embedded textures, Y-up meter scale, feet at the origin, and the named clips Idle_Loop, Walk_Loop, Float_Loop, and Dive_Loop. A student may stylize and recolor a fictional character, but a public model must not embed a face photo, realistic face scan, private identity, arbitrary script, or unreviewed third-party asset.

7. Division of labor [BUILD — process note]

CC (Claude Code): main program — architecture, world/room/loading systems, protocols, data formats, tests, benchmarks. Codex: art effects and parameter micro-tuning (materials, colors, glass/fresnel, fog, skybox composition, scale ratios). Codex edits should stay inside clearly marked tunable-parameter surfaces; structural refactors route through CC.

8. Avatar poses [BUILD + FUTURE]

The Baby Astronaut now ships and blends four core states: idle, horizontal walk, upward float, and downward dive. Richer vocabulary (sit, crouch, gestures, viewing-art idle variants…) remains future work; the blending infrastructure is ready, but those clips are not scheduled yet.

9. "PropHunt" branch idea [FUTURE — record only, needs 3D modeling]

A sibling experience to Painterly Chameleon with the same hide-and-seek objective, but no painting: hiders practice 3D modeling by building a prop that blends in among a room full of props, then hide as it. Requires the kid-facing 3D modeling toolchain (Blockbench-class) and prop libraries; park until the museum core ships. Related plan hooks: §4.4 asset policy and the Phase 4 editor.

10. Multiplayer server — WebSocket, multiple players [BUILD direction; implementation gated]

The server must support WebSocket multiplayer: several students share the museum live (see each other's avatars move through corridor and rooms).

• Presence model: avatar transform + zone + recolor state only. No open chat, no free text — consistent with the Pilot safety rules in AGENTS.md.
• Room state joined this channel on 2026-08-06 (owner): a room's floor belongs to the room, so it is voted on rather than taken. A client may send one enum — which of three floors it wants — and the server owns the tally, the minute-long clock and the result, telling every arrival what the room stands on. Still no free text: a vote is one of three known words. Personal choices (Space Travel, graphics, gravity) stay personal and never travel.
• A vote names its TOPIC from 2026-08-29 (owner): The Manifold's orb asks the same way about the Golden Funnel's paint and about which of the two reviewed black holes it ends at. One enum per question, each question's answers its own whitelist and disjoint from every other's, and an absent topic still means the floor — so an older client and an older server both keep working. The server owns each tally exactly as it owns the floor's; until it does, a client's unanswered ask falls back to deciding alone.
• Sharding: one logical channel per room + one for the corridor, matching §4's per-room loading; a client only subscribes to the space it occupies.
• Candidate stacks (decision deferred to the backend ADR, plan Phase 5):

1. Cloudflare Durable Objects — fits the repo's existing Worker/wrangler stack; one DO per room is the textbook pattern; no new infra vendor.
2. Colyseus on Node — the team already runs it in snake-lab/crew-lab; strong room semantics, but adds a second hosting model to this product.

• Authorization: room membership checks on socket join (personal_draft / class_shared boundaries hold in realtime too).
• Constraint unchanged: no cloud resources are created until the owner approves the backend data model (AGENTS.md); until then multiplayer is designed, not deployed. Local wrangler dev can host a DO prototype without any remote resource.

What this changes vs. the current bake-off slice

The Phase 1 slice (corridor→end portal→cube room, gravity walking, 20 props) remains the engine-comparison artifact and stays as-is. The items above reshape the Phase 3 "final world foundation": endless glass corridor + side portals, deep-space skybox, per-room streaming, zero-g controller, bigger rooms/smaller avatar, DPI policy, and the multiplayer presence layer. .lpr (Phase 2) is untouched by this direction and remains the next engineering phase.

Explicitly not doing now

• No gameplay mechanics (§1 future), no extra poses (§8), no PropHunt (§9).
• No more benchmarking for now (owner 2026-08-01); the engine ADR waits — current MacBook data leans Three.js (see docs/benchmarks/ENGINE-BAKEOFF.md), and the product-shaped scene above is a better final test bed than the current slice.
• No cloud resources, no deployment, no real student data.