Comitting lobby code without testing.

Project_Roadmap.md

@@ -75,7 +75,45 @@ The most architecturally significant pending system. This blocks the Phase 2 tow
 - 4-connected, no diagonals (matches existing maze validation)
 - Re-pathing on tower placement/removal events. Fire on: `TowerInstance` spawn/despawn, construction-start, construction-finish, shelved-tower despawn.
 
-### 1.7 Terrain architecture
+### 1.7 Lobby & Connection (CURRENT)
+
+Replaces the current bare "Start Host" button with a proper main menu → lobby → match flow.
+Lobby is its own scene; players gather, pick races, ready up, and the host starts the match.
+
+**v1 scope (Direct IP, Option A host-leaves-closes-lobby):**
+
+- `MainMenu` scene — Host / Join (with IP+port field) / Quit
+- `Lobby` scene — player list, per-player race picker, ready toggle, host-only Start button, Leave button
+- `LobbyService` `NetworkBehaviour` scene singleton — Start Match RPC, Return to Lobby RPC
+- `NetworkBootstrap` static — wraps `UnityTransport` host/join/disconnect. Designed for the Steam swap-out below: same call sites, different transport.
+- `PlayerMatchState` extended with `IsReady` NetworkVariable and `SetReadyRpc` / `SetRaceRpc` for client → server submissions
+- Match-end overlay extended: **Retry** (back to lobby) AND **Return to Main Menu** (this player only)
+- Host leaves → server raises a "lobby closed" RPC; all clients shutdown + return to main menu. Same applies if the host clicks "Return to Main Menu" after a match — session ends for everyone, each player returns independently to their own main menu.
+
+### 1.7-Future Steam Lobby Migration (Option C — DEFERRED)
+
+When the Steam SDK is integrated (post-1.7, before 1.8 or in parallel), the Direct IP backend is replaced with a Steam-backed lobby provider. **The lobby UI and gameplay code do not change.** The migration touches only `NetworkBootstrap` and adds a `LobbyProvider` abstraction behind it.
+
+**What changes:**
+
+- Add `Facepunch.Steamworks` (recommended) or `Steamworks.NET` to the project
+- Use Steam app ID **480 (Spacewar)** during development; switch to the actual app ID once Steam page is provisioned
+- Replace `UnityTransport` with `SteamNetworkingSocketsTransport` (community-maintained NGO transport)
+- Refactor `NetworkBootstrap` from static helpers into an `IConnectionProvider` interface with two implementations:
+  - `DirectIpConnectionProvider` (existing behavior, kept for LAN testing and DRM-free distribution)
+  - `SteamConnectionProvider` (Steam lobby create/join, friend invite via Steam overlay, Steam P2P sockets)
+- Add lobby browser UI to `MainMenu` scene (currently just Host/Join buttons)
+- Friend-invite flow: handled by Steam overlay (Shift+Tab → invite friend); join request lands in the existing Lobby scene
+- Host-leaves behavior upgrades from Option A → Option C: Steam lobbies persist independently of the game host, so a new host can be elected from remaining members rather than tearing the lobby down. **This is the deferred behavioral upgrade flagged for migration time.**
+
+**Notes for the migration:**
+
+- Lobby code already factored to read player state from `PlayerMatchState` (carries across scene loads) and lobby-wide state from `LobbyService` — no UI rewrite needed
+- The `IConnectionProvider` abstraction is the single seam between gameplay and transport; everything else stays put
+- Both providers should coexist in the codebase so DRM-free builds (itch.io, direct distribution) can still ship without Steam
+- Steam Direct fee ($100 USD) is required to publish on Steam but NOT for development — Spacewar app ID 480 is free to use
+
+### 1.7.5 Terrain architecture
 
 Decision deferred per existing context document; Builder code is already terrain-agnostic. Recommend deciding after the character pipeline mini-session and before Phase 2 begins (the visual prototype will look very different on Unity Terrain vs mesh-based terrain).
 
@@ -100,6 +138,59 @@ Flagged for revisit; not blocking anything.
 - Center-on-builder hotkey (e.g., Space)
 - Initial camera position taking race or match phase into account
 
+### 1.10 Tower Customization & Meta-Progression (DEFERRED — DESIGN CAPTURED)
+
+Long-term cross-match progression loop. Recorded here so Phase 1.8 race-system design and Phase 2 visual prototype work can anticipate the customization data model when they're scheduled. Not blocking Phase 1 exit criteria — a single match is fully playable without it.
+
+**Core concept**
+
+- Every player starts each match with the same **base tower set** — a small fixed roster (universal or per-race; see open question below).
+- **End of match awards a customization reward**, drawn from a Warhammer-themed pool. Win and loss draw from **different pools** — winning unlocks higher-tier / rarer rewards, losing still progresses at a slower rate so no match is truly wasted.
+- Reward types:
+  - **Paint color** (e.g. Macragge Blue, Mephiston Red, Caliban Green) — applied to tower visuals, can carry gameplay effects (see below)
+  - **Sticker decal** — chapter badges, regimental icons, faction sigils
+  - Other Warhammer-aligned customizations: transfers, weathering, base styles, freehand-style elements
+- Customizations are **persistent across matches** via a player profile / save system.
+- Applied via a **customization menu** (does not exist yet) reachable from the main menu, showing owned customizations and per-tower application slots.
+
+**Gameplay enhancements via customization**
+
+Cosmetics double as upgrades. The pattern mirrors the real-world Warhammer hobby loop (collect → paint → customize) translated into mechanical progression:
+
+- **Stat modifiers** — extended range, increased damage, faster fire rate, larger splash radius
+- **Damage-type changes** — applying a particular paint scheme grants Fire / Cold / Poison damage to an otherwise basic tower
+- **Special effects** — chain hits, slow effects, DoT — driven by specific decal or paint combinations
+- **Layering / set bonuses** — applying multiple customizations from the same "faction" might unlock additional effects (e.g. full Salamanders paint kit + chapter decal grants a flamer-style damage profile)
+
+**Required systems (none exist yet)**
+
+- **Player profile / persistence** — local save for now, account-bound later. Tracks owned customizations + per-tower application state.
+- **`CustomizationDefinition` ScriptableObject** — stat-delta fields, visual asset references (decal texture, color values), rarity tier, reward-pool tags.
+- **Tower stat modifier stack** — extend `TowerDefinition` (currently flat fields) to accept a layered modifier stack from applied customizations. Affects targeting, damage, range, fire rate at runtime.
+- **End-of-match reward roll** — server-authoritative draw from win/loss pool, replicated to the relevant player. Anti-cheat: server owns the roll, not the client.
+- **Customization menu UI** — main-menu-accessible. Browse owned, browse locked, apply / remove per tower in the base set.
+- **Networked applied-customization state during a match** — towers must visually reflect each owner's applied customizations on every peer, AND stat modifiers must be authoritative on the server.
+
+**Open question — interaction with the Phase 1.8 race system**
+
+Phase 1.8 currently assumes **race-driven tower rosters** (each race has its own distinct set of towers). This new direction suggests a flatter, customization-driven model. The two systems need reconciliation before either ships:
+
+- **Option A:** Race remains the primary tower-set distinction. Customizations layer on top of race-specific towers. Each race owns its own customization pool.
+- **Option B:** Race becomes one customization category among many. Tower set is universal across players; "race" identity emerges from the player's chosen paint scheme / decal kit.
+- **Option C:** Hybrid — small universal base set + larger race-locked roster, both customizable. Customizations affect both.
+
+Decision deferred until both 1.8 and 1.10 are actively scheduled. The choice has significant implications for content scope: Option A means N races × M customizations each; Option B means one tower set × (M customizations × N "factions"). Option B is dramatically less art work per tower.
+
+**Why this is deferred**
+
+- Not required for Phase 1 exit criteria (a single match plays fine without cross-match progression).
+- Phase 2 visual prototype doesn't depend on this — the painted-miniature aesthetic provides the visual scaffolding customization will eventually exploit, but the prototype tower's paint scheme can be hard-coded for the demo.
+- The data model interaction with Phase 1.8 needs to be resolved first (see open question above).
+
+**When to schedule**
+
+Earliest reasonable slot: after Phase 1 exit criteria are met and Phase 1.8 race-system design has the customization-interaction question resolved. Could run in parallel with Phase 2 (no overlap with visual prototype scope) or after Phase 2 if visual direction needs to prove out first.
+
 ### Phase 1 exit criteria
 
 A complete match is playable end-to-end: race pick → builder spawn → tower placement and construction → wave spawning → enemies path through the maze → towers shoot enemies → enemies die or leak → match concludes. Visuals are placeholder. All systems in this section are functional.