RP412: fork from RP411 — Steam + internet-multiplayer line

Consumer port of Red Planet: sellable on Steam, internet multiplayer,
playable without cockpit hardware. Adds the project README and
docs/RP412-ROADMAP.md covering the three workstreams (vRIO-derived
input/display, TeslaConsole-derived session UI, Steamworks networking)
and the Steam logistics assessment.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/RP412-ROADMAP.md

@@ -0,0 +1,105 @@
+# RP 4.12 Roadmap — Steam + Internet Multiplayer
+
+Working plan for turning the 4.11 arcade/cockpit build into a consumer Steam
+title. Status: initial assessment (2026-07-12). Items marked **[investigate]**
+need code archaeology before they become concrete tasks.
+
+## Where 4.11 stands
+
+- **Game**: `rpl4opt.exe`, 32-bit Win32, DirectX 9, VS2005/2008-era `.vcproj`
+  projects ([BUILD.md](../BUILD.md)). Builds clean on VC++ 2008 Express.
+- **Networking**: the engine has a real multiplayer layer —
+  [MUNGA/NETWORK.cpp](../MUNGA/NETWORK.cpp), [MUNGA/SOCKET.cpp](../MUNGA/SOCKET.cpp),
+  [MUNGA/HOSTMGR.cpp](../MUNGA/HOSTMGR.cpp), interest management
+  ([MUNGA/INTEREST.cpp](../MUNGA/INTEREST.cpp)), bound to WinSock2 in
+  [MUNGA_L4/L4NET.CPP](../MUNGA_L4/L4NET.CPP) (TCP; the 2007 WinSock port of the
+  1995 code). It was built for pods on a dedicated LAN.
+- **Input/output**: the pod's controls are a **RIO** serial board (buttons,
+  five analog axes, lamps) and a **plasma display** (128×32 dot-matrix on COM2,
+  driven by `MUNGA_L4/L4PLASMA.CPP`). No cockpit, no controls.
+- **Session control**: races are configured and launched from the outside by
+  **TeslaConsole** over the Munga control protocol (TCP 1501, via `Munga Net.dll`),
+  with TeslaLauncher (TCP 53290) handling app lifecycle on each pod.
+
+## Workstream A — Play without the cockpit (from vRIO)
+
+vRIO already solved the "no hardware" problem once, from the outside: it speaks
+the RIO serial protocol as the device, with a complete **keyboard + XInput
+bindings model** (deflect/rate/deadzone/invert per axis, bindings file), and
+vPLASMA renders the display's recovered command grammar
+(`VPlasma.Core/Protocol/PlasmaProtocol.cs`, grammar recovered from
+`L4PLASMA.CPP` itself). For 4.12 that logic moves *inside* the game:
+
+- Replace the RIO serial path in the L4 layer with a native input layer
+  (keyboard / mouse / XInput, later Steam Input). Port vRIO's binding model —
+  its axis-travel semantics (throttle ratchet, spring-back pedals, ±80 stick)
+  are exactly what the game expects. **[investigate]** where the L4 layer reads
+  RIO input, and whether an abstraction seam already exists.
+- Render the plasma display in-game (HUD overlay) instead of streaming
+  `ESC P` graphics to COM2 — `L4PLASMA.CPP` already composes the frame into a
+  local 1bpp buffer before serializing, so the seam is likely right there.
+- Lamp feedback (button lighting) maps to on-screen highlight / controller
+  rumble / RGB later; low priority.
+- vRIO itself stays useful as a dev harness against unmodified builds.
+
+## Workstream B — In-game sessions (from TeslaConsole)
+
+Consumer players get no operator. The create/configure/launch flow that
+TeslaConsole drives over TCP 1501 becomes in-game UI:
+
+- Front-end menus: pilot setup, race/mission select, create/join session.
+  **[investigate]** how much of the mission-launch handshake lives in the game
+  (`MUNGA` mission/host code) vs. in the console — TeslaSuite's `Contract/` and
+  the console's Munga-protocol client are the reference implementation.
+- **vPOD** (TeslaSuite) impersonates both the game client and launcher — a
+  ready-made test double while the launch flow is being internalized.
+- TeslaLauncher's responsibilities (install, watchdog, auto-login) disappear —
+  Steam owns install/update/launch.
+
+## Workstream C — Steam + internet multiplayer logistics
+
+### Networking
+
+- The engine's LAN TCP assumptions need auditing before anything else:
+  **[investigate]** what `HOSTMGR`/`NETWORK` actually synchronize (state
+  replication vs. lockstep), tick/latency assumptions, and who is authoritative.
+  A LAN design that tolerates ~1 ms RTT may need prediction/interpolation work
+  for 50–100 ms internet RTTs; the existing interest manager is a good sign.
+- Transport: **Steam Networking Sockets** (`ISteamNetworkingSockets`) is the
+  target — it gives NAT traversal + Steam Datagram Relay for free, hides IPs,
+  and offers reliable + unreliable channels. Plan: introduce a transport
+  abstraction under `L4NET` so raw-socket LAN play (dev) and Steam sockets
+  (retail) coexist.
+- Topology: player-hosted (listen server / P2P over SDR) is the low-cost
+  default for a pod-count-sized race; dedicated servers are a later option.
+- Matchmaking: Steam **lobbies** (`ISteamMatchmaking`) for create/join/invite;
+  friends-list invites come nearly free once lobbies work.
+
+### Steamworks integration
+
+- Steamworks partner account + app credit (Steam Direct, $100/app), appid,
+  depot layout via SteamPipe. The old `Setup1/` installer project retires —
+  Steam delivers files; OpenAL / libsndfile runtime DLLs ship in the depot.
+- `steam_api.dll` supports 32-bit Win32, so Steam does not *force* a 64-bit
+  port. It does require init/callback pumping in the main loop and the
+  overlay hooking D3D9 (works, but test early — old-engine present() paths
+  sometimes fight the overlay).
+- Steam client requires Windows 10+ now, which **frees 4.12 from the XP-era
+  constraints** that shaped the 4.11/TeslaSuite line.
+
+### Toolchain
+
+- Shipping a Steam title from VC++ 2008 Express is untenable long-term
+  (no modern CRT, no Steamworks-era toolchain testing, painful CI). Early
+  task: upgrade `.vcproj` → `.vcxproj` on a branch (VS2022, `v143` toolset,
+  still Win32/DX9) and burn down the warning list. This is a prerequisite for
+  comfortable Steamworks SDK linkage.
+
+## Suggested order
+
+1. Toolchain upgrade to VS2022 (unblocks everything, no design risk).
+2. Workstream A input layer (makes the game *playable* on a desktop — also the
+   fastest path to a demoable build).
+3. Networking audit (**C**), then transport abstraction + Steam sockets.
+4. Workstream B session UI, using vPOD as the test double.
+5. Steamworks bring-up (appid, overlay, lobbies), SteamPipe packaging.