# 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: **Design principle — recreate the cockpit's feel on screen.** The 4.12 screen layout places the RIO panel controls *around* the displays in the same physical arrangement as the pod: MFD button clusters framing the screens, board columns and keypads where they sit in the cockpit, the plasma glass in its place above. vRIO's panel layout data (`VRio.Core`, the five MFD clusters / four board columns / two keypads / encoder-gauge strip) is the geometry reference — it is already the faithful software copy of the physical panel. On-screen buttons light with the same lamp states the game commands, so press-feedback works like the real button field. - 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 - ✅ **Done (2026-07-12)** — the solution builds on **VS2022 (v143)** with the Windows 11 SDK; see [BUILD.md](../BUILD.md) §3 for what changed and why. Runtime-verified equivalent to the VC9 baseline (including RIO init against vRIO). Remaining cleanups called out there: un-`/Zp1` the Windows-header boundary, port `stdext::hash_map` → `std::unordered_map`, single-TU the duplicated globals so `/FORCE:MULTIPLE` can go away. - ⚠️ Known pre-existing crash (both toolchains): standalone mission load AVs in `d3d_OBJECT::LoadTexture` (`L4D3D.cpp:262`) — first debugging target now that the v143 build has full PDBs (BUILD.md §4). ## 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.