Front-end design notes: TeslaConsole control code analysis + Steam plan
Findings from TeslaConsole.RedPlanet and L4NET: the pod lifecycle (egg chunks/ACK, RunMission, telemetry, results), the egg as the entire mission definition (NotationFile text incl. pre-rendered plasma name bitmaps), the RPConfig.xml catalog, and the key topology finding - every pod gets the same egg and builds a deterministic full TCP mesh from the ordered pilots list (connect to earlier entries, listen for later). Maps 1:1 onto Steam: lobby owner = console, SteamIDs = pilot addresses, ISteamNetworkingSockets P2P = the mesh, with a NetTransport seam at L4NET mirroring the RIOBase pattern. Implementation options and open decisions listed for signoff. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Claude Fable 5
@@ -0,0 +1,123 @@
|
||||
# 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:
|
||||
|
||||
```ini
|
||||
[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)?
|
||||
Reference in New Issue
Block a user