RP412/docs/RP412-ROADMAP.md

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). Builds clean on VC++ 2008 Express.
• Networking: the engine has a real multiplayer layer — MUNGA/NETWORK.cpp, MUNGA/SOCKET.cpp, MUNGA/HOSTMGR.cpp, interest management (MUNGA/INTEREST.cpp), bound to WinSock2 in 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.