RP412/docs/RP412-FRONTEND-DESIGN.md

RP412 Front End & Steam Multiplayer — Design Notes

Findings from reading TeslaConsole's Red Planet control code (TeslaSuite/Console/TeslaConsole.RedPlanet/) against the game side (MUNGA_L4/L4NET.CPP, MUNGA/NETWORK.cpp), and how a Steam front end maps onto it. Written 2026-07-12 for the implement-decision.

1. What the console actually does

TeslaConsole is four things, and RP412's front end must absorb all four:

a) Pod control channel (Munga.Net, TCP console port)

Per-pod state machine (RPGame.cs): take ownership of a pod, watch its app state, and drive the lifecycle:

WaitingForEgg   --egg chunks-->   (ACK, 5s retry)
WaitingForLaunch --RunMissionMessage-->
RunningMission   --telemetry-->   EndMission (final scores)
                 --AbortMissionMessage--> reset

The egg is sent as EggFileMessage chunks of 1000 bytes with an AcknowledgeEggFileMessage reply from the pod.

b) The mission egg (the ENTIRE mission definition)

A NotationFile-format text file (RPMission.ToEggString()), newline→NUL:

[mission]      adventure=Red Planet, scenario, map, time, weather,
               temperature, compression, length (seconds)
[pilots]       ordered pilot=<host address> list (players, then cameras)
[<address>]    per participant: hostType, dropzone, name, bitmapindex,
               loadzones, vehicle, color, badge (+ team/position in football)
[largebitmap]  player names PRE-RENDERED as 1bpp bitmaps for the plasma
[smallbitmap]  glass (128x32 and 64x16), generated by the console
[ordinals]     1st-4th place plasma graphics (hardcoded art)

The game already loads a local egg with -egg <file> (standalone mode) — the same text format. Building an egg locally = the whole single-player front end problem.

c) The catalog (RedPlanet/RPConfig.xml)

Two scenarios — Martian Death Race and Martian Football (2-color teams, crusher/blocker/runner positions) — 11 maps, ~30 vehicles (sharing a handful of models), 9 colors, 11 badges, day/night, 3 weather levels, with per-scenario exclusion lists. Clean data file; reusable as-is.

d) Results & telemetry

During the mission the pods stream VTVBooster/Damaged/Killed/Scored/ ScoreUpdate and EndMission(finalScore) to the console host, which records them (RPMissionRecorder) into RPMissionResults and prints score sheets. The consumer version wants this as a post-race results screen (and, later, Steam leaderboards/achievements fed from the same events).

2. How the pods network with each other (the key finding)

The console does NOT relay gameplay. Every pod receives the same egg, and L4NetworkManager::StartConnecting builds a deterministic full TCP mesh from the ordered [pilots] list:

• Resolve each address (ip[:port], default = game port).
• Entries before your own: open a TCP connection to them.
• Entries after your own: listen for their incoming connection.
• No entry matching a local address → single-user mode, immediate load.
• Egg-from-network (SlaveMode) → ACK the egg, wait for mesh completion.

So the "lobby protocol" is simply: agree on an ordered participant list, then everyone meshes. This is an exceptionally good fit for Steam.

3. Steam mapping (plan)

Arcade concept	Steam concept
TeslaConsole operator	Lobby owner (host player)
Pod list / Site Management	ISteamMatchmaking lobby members
Pilot config dialog	In-lobby cockpit UI; member data (name/vehicle/color/badge) via lobby member data
Egg delivery + ACK	Owner builds the canonical egg, distributes via lobby data or reliable P2P channel; same ACK semantics
[pilots] host addresses	Ordered SteamID list — same list, different address type
TCP mesh (StartConnecting)	ISteamNetworkingSockets P2P mesh over SDR: ConnectP2P to earlier entries, accept later ones — the connect/listen ordering ports 1:1
Console telemetry sink	Lobby owner doubles as the console host (results collection); results screen replaces the printout
Site network / fixed IPs	NAT traversal + IP privacy for free via Steam Datagram Relay

Transport seam: mirror the RIOBase pattern at the L4NET layer — a NetTransport interface with the existing WinSock TCP implementation (LAN/dev, keeps working today) and a Steam-sockets implementation (retail). L4Host keeps its identity/queue role; only connect/listen/send/recv move behind the interface.

4. Implementation options (decide here)

A. In-engine front end (recommended). Port the egg builder (~300 lines: RPMission/RPPlayer.ToEggString + the plasma name-bitmap generator) to C++ inside RP_L4. New application state before WaitingForEgg: a menu that renders on the cockpit displays we just built — scenario/map/weather/length on the viewscreen, selections driven by the MFD buttons and map presets (the cockpit IS the menu — maximally pod-authentic). Single player works immediately: build egg → hand to the existing egg-load path. Multiplayer then layers the Steam lobby under the same UI (owner builds the egg, distributes, mesh over Steam sockets).

B. Standalone launcher app (C#, reuse TeslaConsole code nearly verbatim, drive the game via -net + console port like the arcade). Fastest to stand up, but a second process, not cockpit-feel, and awkward under Steam (overlay, launch flow, no in-game rejoin). Useful as a dev tool, not the product.

C. Hybrid: in-engine UI, but mission/egg logic in a small shared C++ library so a dev console tool and the game share one egg builder.

Open decisions

1. Front end location — Option A (in-engine, cockpit-rendered) confirmed?
2. v1 scenario scope — Death Race only, or Football (needs teams UI) too?
3. Results screen — post-race on the cockpit displays (replaces printout)?
4. Steam model — lobby-owner-as-console confirmed? (Implies owner migration handling later; the egg re-issue path makes host migration plausible.)
5. Pilot identity — Steam persona as pilot name; vehicle/color/badge persisted per player (Steam Cloud later)?