# On-Foot / Ship & Solar System Layer Planning doc for the Stardew-Valley-style on-foot mode: a walkable layer (your ship, solar-system locations, 2 multiplayer hubs) alongside the existing ship-combat game. This is the working doc for turning the item 29 groundwork (see `CLAUDE.md`) into something actually playable. Sections below are meant to get filled in / checked off as decisions land — not a finished spec yet, and the vision itself has already changed shape more than once, so treat this as a living document rather than a locked design. ## Vision Two intertwined layers (current thinking, as of this doc's last edit): 1. **Space combat (multiplayer, existing/live)** — the ship-vs-ship battles already built (`world/world.tscn`, `GameMode` subclasses, matchmaking). This is the money-earning loop: winning/playing matches pays out **RAM**, the in-game currency (named after EVE Online's ISK — 100% separate from `overview/money.md`'s real-world monetization strategy, confirmed, that doc is about pricing the game itself). Balance is **server-authoritative**, tracked in `matchmaking-api` alongside the existing `Player.kills/deaths/wins` stats rather than trusted client-side. 2. **The Stardew side (new, this doc's scope)** — spending RAM and time in a walkable, on-foot layer: - **Your ship, walked around inside** — this is the Stardew *farm* equivalent, and also the **home base** (see "Where does it fit in the flow" below — space combat and hub travel both launch from here). Maintenance is broad, not just crops: growing crops (the hydroponics plant-rack furniture already cropped for `station_hub.tscn` is a natural seed for this), cosmetic decoration, room-based upgrades that matter in combat (see "Ship upgrades = new rooms" below — ties the two layers together mechanically, not just economically), and repairing/ restocking hull, guns, fuel, oxygen, and ammo after combat wear (see "Ship wear, supplies & repair" below). That's 4 systems, not 1 — see the phased plan below for suggested sequencing rather than building all 4 at once. - **2 main hubs** — Belters (ORC) and Military (ISN). Multiplayer: other players' chosen character sprites (from character creation) are visible walking around, same as the ship-combat side. Also where you buy the supplies that repair ship wear (see below) — this is what ties hub visits into the ship-maintenance loop mechanically, not just thematically. - **Solar system locations** — additional single-player/instanced places to explore beyond the 2 hubs. **This is v2, not v1** — see Version Scope below. ## Version scope - **V1** — ship interiors + the 2 main hubs (Belters, Military). Nothing else on foot. This is the whole on-foot surface area for v1: no solar system exploration locations. - **V2** — additional single-player "cool places to explore" solar-system locations, reachable from the in-ship nav table alongside the 2 hubs (see "Where does it fit in the flow" below). Not scoped further than that yet — revisit once v1 is actually playable. ## Multiplayer scope, by location | Location | Multiplayer? | |---|---| | Ship combat (existing) | Yes — already networked | | Your ship interior | No — private, single-player/instanced | | Belters hub (`station_hub.tscn`, ORC) | **Yes** — networked, other players' sprites visible | | Military hub (`military_hub.tscn`, ISN art pending — see phased-plan step 3/4) | **Yes** — same as above | | Solar system locations (v2, not built) | No — single-player/instanced | This means `on_foot_character.gd` needs to grow two separate modes rather than one: a simple local-only controller (ship interior — what exists today, basically) and a properly networked one for the 2 hub locations (`MultiplayerSpawner`, position replication, the same predict/reconcile shape `ship_movement.gd` already has for combat). Worth building the local-only path first regardless (ship interior), then reusing whatever interaction/movement code it establishes for the networked hub pass. **Resolved:** `station_hub.tscn` *is* the first of the 2 main hubs — the **Belters hub** (Outer Rim Collective's home turf, see `overview/racesclasses.md`'s ISN-military/ORC-belters split). Its gritty, industrial, patchwork-metal art direction (see Asset Inventory below) fits ORC's established visual identity directly. A second hub for **the military** (ISN) will be built later — likely wants its own, cleaner/more disciplined tileset+furniture pass to match ISN's gunmetal-gray aesthetic rather than reusing the Belters hub's art wholesale, though the underlying room-building/collider/furniture-placement code (`station_hub.gd`'s approach) should carry over directly. The **ship interior** (the Stardew-farm equivalent) is a separate, new, single-player scene — not `station_hub.tscn`, and not built yet. ## Where does it fit in the flow? **Resolved: the ship is the home base**, and the specific interaction is settled too. `main_menu.gd` gets a new entry point (name TBD, e.g. "MY SHIP") that drops the player into their ship interior. Inside, there's a **navigation table** — Helldivers 2 style: walk up to it, it shows a graph of the solar system, and picking a node is how you travel. For v1 that graph has 3 destinations: space combat (queue/connect, today's QUICK PLAY/SERVER SELECT behavior moves here), the Belters hub, and the Military hub. V2's additional explorable locations (see Version Scope above) are just more nodes on the same graph later — the table doesn't need to change shape, only grow more destinations. This is a real restructure of the existing menu flow, not an addition alongside it — QUICK PLAY/SERVER SELECT's current straight-into-a-match behavior becomes something reached via the nav table, not a main-menu button. `main_menu.gd`'s QUICK PLAY/SERVER SELECT code itself likely stays close to as-is functionally (still queues/connects the same way); what changes is *what calls it* — a nav-table node interaction instead of a nav button. ## Current implementation state Everything below predates the "ship interior + solar system + 2 hubs" framing above — it was built as a generic "station hub" proof of concept (item 29) and then given a real character-creation entry point in a later session, before `station_hub.tscn` was pinned down as specifically the Belters hub (see Vision above). What's actually built and working today (verified via headless screenshot): - **Character creation** (`menu/character_preview.gd`, `menu/character_presets.gd`) — 7 pre-composed archetype sprites (Soldier, Marine, Engineer, Laborer, Scavenger, Officer, Heavy Trooper), each with idle + walk frames, picked on the main-menu PROFILE overlay with a live idle/walk preview loop. Stored in `GameConfig.player_character_index`. This is the *only* piece with a real menu entry point today. - **`world/levels/station_hub.tscn`** — one hand-built 12×9 room (`station_hub.gd`, `class_name StationHub`), procedurally tiled floor + wall ring with a door gap, 4 static furniture pieces (locker, cabinet, hydroponics plant rack, server console), wall colliders auto-built from whatever's painted on the `Walls` `TileMapLayer`. - **`world/levels/on_foot_character.gd`** (`CharacterBody2D`) — 4-directional top-down walker, idle/walk sprite swap + `flip_h`, camera follow. Not networked — single local `CharacterBody2D`, no `MultiplayerSpawner`, no server authority. Loads whichever archetype was chosen at character creation via `CharacterPresets.get_preset(GameConfig.player_character_index)`. - **Not reachable from any menu.** The only way to see this scene today is launching `station_hub.tscn` directly (editor Play, or the `--hub-test` throwaway autopilot used to verify it — deleted after use, not in the repo). - **No NPCs, no interaction, no dialogue, no second room/transition.** - **Ship interior (phased-plan step 2 — done)** — `world/levels/ship_interior.tscn` + `ship_interior.gd` (`class_name ShipInterior`), a new single-player/ local-only scene distinct from `station_hub.tscn` (which stays spoken for as the Belters hub, see Vision above). Reuses `on_foot_character.gd` as-is for the player controller and `station_hub.gd`'s wall-collider pattern, but not that scene's assets wholesale — no dedicated ship-interior art exists yet, so it's built from the same ORC station tileset/furniture as a placeholder (locker, cabinet, server rack; the plant/hydroponics furniture was deliberately left out, since hydroponics is a purchasable room per the decisions log below, not present on the starter ship). A smaller 8×6 room (vs. the hub's 12×9) to read as a personal ship rather than a public hub. Built procedurally in `_ready()` (floor/wall `TileMapLayer.set_cell()` calls, one door gap in the wall ring) rather than hand-authored into the `.tscn`'s `tile_map_data`, since `station_hub.tscn`'s own layout was originally produced the same code-generated way (see item 29) rather than painted in an interactive editor session. Verified via a throwaway autopilot + headless Xvfb screenshot (same technique as item 29): floor tile variety, the wall ring's door gap, all 3 furniture pieces, and wall-collision (player stops cleanly at the east wall instead of clipping through) all confirmed rendering/working correctly; autopilot and its temporary `project.godot` autoload entry were removed after. **Now reachable from the main menu** — see the CONTINUE/NEW entry point below (originally slated for step 3, landed early alongside this step in practice). - **In-ship navigation table (phased-plan step 3 — done)** — `world/levels/nav_table.gd` (`class_name NavTable`, an `Area2D` placed in `ship_interior.tscn`) is a Helldivers-2-style interactable: walking into its range shows a "PRESS E" prompt (new `interact` input action, E key), and pressing it opens `world/levels/nav_table_ui.gd` (`class_name NavTableUI`, `CanvasLayer`, `layer = 20` — same layering convention as `TeamSelect`/`SettingsPanel`) — a graph of 3 nodes (SPACE COMBAT, BELTERS HUB, MILITARY HUB) radiating from a center "YOUR SHIP" marker, connected by `Line2D` routes. A new `GameConfig.nav_table_focused` flag (same pattern as `chat_focused`/`team_select_focused`/ `settings_focused`) gates `OnFootCharacter` movement while it's open. **SPACE COMBAT** is QUICK PLAY's old queue/connect flow, moved here verbatim from `main_menu.gd` (which lost its QUICK PLAY nav button entirely — `NAV_ITEMS` is now just `["OPTIONS", "PROFILE", "QUIT"]`): `NavTableUI` owns the `NetworkManager.connection_succeeded/failed` and `MatchmakingClient.match_found/search_failed` signal wiring and shows queueing/connecting status inline in the graph panel, then swaps to `world.tscn` on success. **BELTERS HUB**/**MILITARY HUB** are straight `change_scene_to_file` calls to `station_hub.tscn`/`military_hub.tscn`. Caught and fixed one real bug via the autopilot verification below: `nav_table_focused` was only ever cleared by `close()`, so picking a destination (which changes scene without closing the panel) left it stuck `true` forever, silently freezing player movement in every future ship visit — all 3 destination handlers now clear the flag before changing scene. - **Military hub is a functional placeholder, not a stub** (see Decisions below) — `world/levels/military_hub.tscn` reuses `station_hub.gd` (`class_name StationHub`, generic — no ORC-specific logic) and the same ORC tileset/furniture art as `station_hub.tscn` outright, as its own distinct scene/instance rather than literally reopening the Belters hub. A real ISN art pass (phased-plan step 4) swaps the art later without touching the nav-table wiring. - **Return paths**: a new reusable `world/levels/exit_zone.gd` (`class_name ExitZone`, `Area2D`, exported `target_scene`) triggers a scene change the instant the player's body enters it — unlike `NavTable`, which needs an explicit interact press, this matches walking through a doorway. Both hub scenes got one positioned at their existing door sprite, routing back to `ship_interior.tscn`. `menu/pause_menu.gd`'s "QUIT TO MENU" became **"QUIT TO SHIP"**, changing scene to `ship_interior.tscn` instead of `main_menu.tscn` (still disconnects via `NetworkManager.disconnect_from_game()` first) — the ship is now the only way out of a match, matching its status as home base. - Verified end-to-end with a throwaway `--navtest`-gated autopilot autoload (removed after use, same technique as this doc's other verification notes): a real headless server was hosted and registered with `matchmaking-api` (confirmed `status: "available"` via `GET /servers`), then a windowed client under Xvfb was driven through the full loop — main menu → ship → open nav table (screenshotted, see below) → Belters hub → back to ship → Military hub → back to ship → Space Combat → real matchmaking + connect → in `world.tscn` → pause menu's quit-to-ship → back in the ship interior — with no errors and the `nav_table_focused` fix confirmed (`focused=false` after each hub return, where it previously stuck `true`). - **RAM currency backend (phased-plan step 1 — done)** — `Player.ram_kb` (BigInteger) in `matchmaking-api`, credited on `POST /matches/report` via a tunable participation/per-kill/win-bonus formula (`app/config.py`, currently 50/15/200 KB — placeholder numbers), returned by `GET /stats/{callsign}`. Client side: `autoload/currency.gd` (`class_name Currency`) formats KB up into KB/MB/GB/TB for display (1000 per step), `MatchmakingClient.get_stats()` fetches a callsign's balance, and the main-menu profile badge shows it live next to rank/level as a working end-to-end proof (verified via real match-report calls + a headless screenshot — a fresh callsign correctly shows nothing until it has a stats row, an existing one rolls over KB→MB→GB correctly at the 1000 boundary). No spend path yet — nothing to spend it on until the ship interior/hubs below exist. See `matchmaking-api/README.md`'s "RAM (in-game currency)" section for the backend details. ## Ship wear, supplies & repair Combat leaves your ship **visibly broken** when you're back in the interior — not just a hidden stat. Two related but distinct systems: - **Repairable damage** — things that break and need fixing: - **Hull** — takes damage in combat, needs repair. - **Guns/weapons** — also take damage in combat, repaired separately from the hull. - **Consumable supplies** — things that deplete through play and need restocking, not "broken" so much as "used up": - **Fuel** - **Oxygen** - **Ammo** Both repairs and supplies are **bought at the hubs with RAM** — no separate "supplies" currency, it's a RAM purchase like anything else there. This is the mechanic that makes hub visits load-bearing rather than optional: you fight → come home with a damaged hull/guns and depleted fuel/oxygen/ammo → go to a hub and spend RAM → return and repair/restock. **Repairing and restocking both take time** — not instant on purchase (consistent with crops also being a wait → harvest loop, see Vision above; the ship interior's whole maintenance layer runs on "spend, then wait" pacing, not "spend, get instantly"). **Damage formula (resolved):** every death in combat randomly drains either the hull or damages the weapons (one or the other per death, picked randomly — not both every time). This accumulates across matches; **50 deaths' worth** of accumulated damage fully depletes that system, at which point RAM has to be spent at a hub to repair it. Purely deaths-driven, not tied to damage-taken or match outcome. Still needs, before it can be built: - How fast fuel/oxygen/ammo deplete (a separate formula from the deaths-based hull/gun one above — not yet specified), and what happens if they run out (blocked from queueing another match? a gameplay penalty mid-match?) This depends on combat generating *some* persistent-across-matches wear/ consumption state, which does not exist today — `ship_movement.gd` currently resets health/state fully on every respawn and between matches, nothing survives to be "broken" or "depleted" afterward, and there's no existing fuel/oxygen/ammo concept in combat at all (weapons currently cost *energy*, which already regenerates freely mid-match per `CLAUDE.md` item 23 — that's a separate system from this new persistent ammo-supply concept, not to be conflated). That plumbing has to be built as part of this, not assumed already there. ## Ship upgrades = new rooms Upgrades aren't menu-purchased stat tweaks — they're **new rooms added onto your ship**, walked into like everything else. This is a meatier build than a flat stat upgrade: it means the ship interior can't be one fixed `station_hub.tscn`-style single room — it needs to support **growing its own floor plan** as rooms get added, which is a real architectural difference from every other on-foot space in this doc (the 2 hubs and any v2 solar-system stops are all still just fixed single rooms/scenes). **Resolved:** - A room's only function is granting access to the system it houses — it's a gate, not also a stacking stat/capacity bonus on top of granting access. - Hydroponics (crops) is not a starter feature. It's a purchasable room like every other upgrade — the plant-rack furniture already cropped for `station_hub.tscn` (see Asset Inventory below) is useful reference art for it, but the starter ship doesn't have it until bought. **Still open:** - What a room being "added" looks like mechanically — a new connected room revealed/unlocked in a pre-built larger ship shell (simpler: author the full possible floor plan up front, gate rooms behind a locked-door-until-purchased flag), vs. actually procedurally attaching/generating new room geometry at purchase time (much harder, and nothing in the codebase does anything like this today — closest analog is `station_hub.gd`'s procedural single-room tile painting, which doesn't generalize to "graft a new room onto an existing layout"). ## Asset inventory Source: `world/levels/spritesheet.png` (a single AI-generated reference sheet — has a `source/` jpeg convention like the race art, see `CLAUDE.md` item 17). Cropped into `assets/images/worldsprites/character/`, `assets/images/worldtiles/`, `assets/images/worldsprites/furniture/`. | Category | Used | Still on the sheet, uncropped | |---|---|---| | Characters | 7 archetypes × (idle+walk) — appears to be the full set the sheet has | — (all 5 character rows are used) | | Floor tiles | 11 variants → padded/cycled to the 14-slot atlas | — (Flooring block fully used) | | Wall tiles | 6 clean panel variants → cycled to 14 | rock/asteroid-wall chunks, 2 blend-mask swatches (not directly usable as tiles as-is) | | Doors | 1 (plain sliding door) | 2 more door variants (open, blast-door), several branded panel doors | | Furniture | 4 (locker, cabinet, plant rack, server console) | bunks (3 variants), desks + chairs, monitor stations, weapon/gear lockers (cage shelving), crates, workbenches, gas canisters, more potted plants, a fish-tank-style prop | | Lighting fixtures | 0 | ~10 wall/ceiling light variants, fully uncropped | Furniture/lighting has a lot of unused headroom for filling out a bigger or second room later — this is not a blocker for anything above, just noting it's there. ## Rough phased plan (v1 = ship interior + 2 hubs, nothing else — see Version Scope) 1. ~~Currency: server-authoritative RAM hookup~~ — **done**, see "Current implementation state" above and `matchmaking-api/README.md`. Payout happens via the existing `POST /matches/report` call (`MatchManager`'s `POST_MATCH` phase, `CLAUDE.md` item 26) rather than a new endpoint. Note this landed ahead of step 2 (ship interior) in practice — reasonable since it has no dependency on the ship existing, just needed *a* balance to exist before anything can spend it later. 2. ~~Ship interior as its own new scene~~ — **done**, see `world/levels/ship_interior.tscn`/`ship_interior.gd` and "Current implementation state" above. Single-player, local-only, no networking — reused `on_foot_character.gd` and `station_hub.gd`'s room-building/ collider approach as the starting pattern (not the `station_hub.tscn` instance itself, which is spoken for as the Belters hub — see Vision above). **Main-menu entry point into the ship (part of step 3, landed early, same "no dependency" reasoning as step 1 landing ahead of step 2) — done.** `main_menu.gd`'s nav gained a dynamic top item, CONTINUE (a callsign/character already exists) or NEW (none yet), replacing the old static `NAV_ITEMS` first slot; both drop the player straight into `ship_interior.tscn` (`_enter_ship()`). NEW reuses the existing PROFILE overlay (`_open_profile()`'s `pending_action` param generalized from the old `pending_quick_play` bool to also carry `"enter_ship"`, alongside the pre-existing `"quick_play"` case) so a fresh player creates their pilot first, then lands in the ship on Save — same forced-open pattern QUICK PLAY already used for a missing callsign, just a second pending action instead of a second overlay. **`SERVER SELECT` was removed from the main-menu nav entirely** (`menu/server_select.gd`/`.tscn` left on disk unreferenced, same precedent as the orphaned `terran/mech/vorg`/ `apex` asset folders from items 17/19) — no replacement entry point for it yet, since server browsing doesn't have a home on the nav table either until that's built next. QUICK PLAY/OPTIONS/PROFILE/QUIT are otherwise unchanged. Verified via a throwaway autopilot driving `main_menu.gd`'s own `_on_continue_pressed()`/`_on_profile_save()` methods directly (same legitimate `_`-prefixed-access technique as prior sessions) plus headless Xvfb screenshots: NEW label + profile overlay opening with an "enter_ship"-specific hint text, landing in the ship on Save, and the label correctly flipping to CONTINUE back on the menu once a callsign exists. 3. ~~Navigation table inside the ship~~ — **done**, see "Current implementation state" above (`world/levels/nav_table.gd`/ `nav_table_ui.gd`). QUICK PLAY's queue/connect logic now lives behind the SPACE COMBAT node; Belters/Military hub nodes are the other two. A real server-browsing entry point to replace the removed SERVER SELECT is still not built — no node claims that slot yet, it just isn't reachable from anywhere right now. 4. Military (ISN) hub — **placeholder done, real art pass still open.** `military_hub.tscn` exists and is reachable today, but reuses the Belters hub's ORC art/tileset outright rather than a dedicated gunmetal-gray/disciplined ISN look (see Vision above) — that art pass, and re-skinning this scene with it, is the remaining work here. The room-building code (`station_hub.gd`) already carries over directly, as expected — no code changes needed once the art exists, just new textures swapped into a cloned `.tscn`. 5. Networked pass on both hubs — `MultiplayerSpawner`, position replication for on-foot characters, reusing whatever the local-only ship-interior controller established in step 2. 6. Ship wear, supplies & repair loop (see dedicated section above) — the mechanic that actually ties hubs into ship maintenance. Needs combat to generate persistent hull/gun-damage and fuel/oxygen/ammo-consumption state first (none of which exists today — and is distinct from the existing per-shot *energy* system, `CLAUDE.md` item 23, which stays as-is), then the broken/depleted states in the ship interior, then repairs/supplies for sale at both hubs, then the wait-time pacing on top. 7. Cosmetic decoration — the one maintenance system that doesn't depend on the room-upgrade architecture (step 8) or the wear loop (step 6). Can be built any time after the ship interior (step 2) exists. 8. Room-based upgrades (see "Ship upgrades = new rooms" above) — the heaviest remaining lift, since it needs the ship interior to support a growable floor plan rather than the fixed-single-room approach every other on-foot scene uses. Do this after the fixed-room approach has already shipped for decoration/hubs, so there's a working baseline before taking on the harder architectural problem. **Crops live here too now**, not as a separate item — hydroponics is a purchasable room like any other upgrade (see "Ship upgrades = new rooms" above), not a starter feature, so it can't ship before the room-upgrade system exists. 9. **V2, not v1:** additional solar-system exploration locations as more nav-table nodes. NPCs/dialogue, if still wanted — needs a minimal dialogue/prompt UI that doesn't exist anywhere in the project yet. ## Decisions log - [x] `station_hub.tscn` is the Belters (ORC) hub, not the ship interior and not a generic solar-system stop. - [x] In-game currency is 100% separate from `overview/money.md`'s real-money monetization. - [x] Currency is named **RAM** (EVE Online ISK-style), server-authoritative in `matchmaking-api`. - [x] Ship is the home base — combat and hub travel launch from inside it, not straight off the main menu, via an in-ship navigation table. - [x] The nav table is a Helldivers-2-style solar-system graph; v1 has 3 destinations (combat, Belters hub, Military hub). - [x] **V1 scope is ship interior + the 2 hubs only.** Solar-system exploration locations are v2. - [x] Ship wear covers hull damage and gun damage (repairable), plus fuel, oxygen, and ammo (consumable supplies) — bought at the hubs, RAM only (no separate supplies currency), and both repairs and restocking take time rather than being instant. - [x] Ship maintenance covers crops + cosmetic decoration + room-based upgrades + repairs/supplies (all 4 planned for v1, sequenced in the phased plan above — not simultaneous, and not blocking the hub/nav-table work). - [x] Upgrades are new rooms added onto the ship, not a stat menu — the ship interior needs a growable floor plan, not a fixed single room (see "Ship upgrades = new rooms" above). - [x] A room's only function is granting access to the system it houses — not also a stacking stat/capacity bonus. - [x] Hydroponics (crops) is a purchasable room, not present on the starter ship — so it's part of the room-upgrade system (phased-plan step 8), not shippable before that system exists. - [x] Hull/gun damage formula: every combat death randomly drains the hull *or* damages the weapons (one or the other, random per death); 50 deaths' worth fully depletes that system and requires a RAM repair at a hub. Purely deaths-driven, not tied to damage taken or match result. - [x] NPCs are deferred past the first playable version. - [x] Military hub is a functional placeholder (its own scene, reusing the Belters hub's ORC art/script wholesale) rather than locked/coming-soon — playable now, real ISN art swapped in later without touching the nav-table wiring. - [x] Belters/Military hub exits and a match's pause-menu quit both route back to `ship_interior.tscn` (not the main menu) — the nav table is a real hub-and-spoke loop, not a one-way trip. Pause menu's "QUIT TO MENU" is now "QUIT TO SHIP". ## Still open - [ ] A dedicated ISN art pass for the Military hub (gunmetal-gray, disciplined, distinct from the Belters hub's gritty patchwork look) — `military_hub.tscn` exists and is playable today but is reusing ORC art as a stand-in (see phased-plan step 4). - [ ] A real server-browsing entry point (the old, now-removed SERVER SELECT) — no nav-table node or other menu surface reaches it yet. - [ ] Fuel/oxygen/ammo depletion rate/formula (separate from the deaths-based hull/gun formula above), and what happens if they run out (blocked from queueing? a mid-match penalty?). - [ ] How a purchased room actually gets added to the ship — pre-built shell with locked-until-bought rooms, vs. real procedural attach/generate at purchase time (see "Ship upgrades = new rooms" above; leaning toward the pre-built/locked-room approach as the cheaper build, not decided). - [ ] Exact list of cosmetic decorations for a first pass — not needed until step 7 of the phased plan. - [ ] Exact list of purchasable rooms beyond hydroponics (armory for ammo/guns? a fuel-tank room? an oxygen/life-support room?) — not needed until step 8 of the phased plan.