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>
This commit is contained in:
Claude Fable 5
@@ -0,0 +1,37 @@
|
||||
# Red Planet 4.12
|
||||
|
||||
**Red Planet** is the VWE pod-racing game built on the in-house **MUNGA** engine
|
||||
(Win32 / DirectX 9, `MUNGA_L4` platform layer). The **4.12** line is the
|
||||
consumer port: a version of Red Planet that can be **sold on Steam** and played
|
||||
over **internet multiplayer**, without cockpit-pod hardware.
|
||||
|
||||
Forked from [RP411](https://gitea.mysticmachines.com/VWE/RP411.git)
|
||||
(the arcade/cockpit 4.11 line) with full history preserved.
|
||||
|
||||
## Goals
|
||||
|
||||
1. **Steam distribution** — Steamworks integration, SteamPipe builds, store-ready packaging.
|
||||
2. **Internet multiplayer** — take the engine's LAN-era WinSock networking online
|
||||
(NAT traversal, matchmaking, latency tolerance).
|
||||
3. **No cockpit required** — keyboard / mouse / gamepad input and on-screen
|
||||
replacements for the pod's RIO panel and plasma display, drawing on
|
||||
[vRIO](https://gitea.mysticmachines.com/VWE/VRIO.git).
|
||||
4. **Self-hosted sessions** — in-game race setup/join replacing the operator-driven
|
||||
[TeslaConsole](https://gitea.mysticmachines.com/VWE/TeslaSuite.git) flow.
|
||||
|
||||
See [docs/RP412-ROADMAP.md](docs/RP412-ROADMAP.md) for the plan and the
|
||||
Steam-multiplayer logistics.
|
||||
|
||||
## Building
|
||||
|
||||
Unchanged from 4.11 for now — see [BUILD.md](BUILD.md)
|
||||
(VS 2005/2008 + DirectX SDK June 2010, `Release|Win32`, output `Release\rpl4opt.exe`).
|
||||
Toolchain modernization is a roadmap item.
|
||||
|
||||
## Related repositories
|
||||
|
||||
| Repo | Role |
|
||||
|------|------|
|
||||
| [RP411](https://gitea.mysticmachines.com/VWE/RP411.git) | Upstream arcade source (this repo's base) |
|
||||
| [VRIO](https://gitea.mysticmachines.com/VWE/VRIO.git) | Virtual RIO panel + vPLASMA display — input bindings and display emulation to fold in |
|
||||
| [TeslaSuite](https://gitea.mysticmachines.com/VWE/TeslaSuite.git) | TeslaConsole / Launcher / vPOD — the arcade session-control stack 4.12 replaces (and a reference for the Munga control protocol, TCP 1501) |
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user