Destination
A Network PRD (docs/project/network-prd.md) that locks the decisions to move MakaMek from today's LAN-only peer-host to a cloud relay-hub model enabling internet + web multiplayer at minimal cost — ready to hand to /to-issues. Planning only; no code is written during this effort.
Notes
Domain. Command-based client-server: ServerGame owns authoritative state, ClientGame mirrors it; state changes travel only as serialized command DTOs. The wire is abstracted behind Sanet.Transport's ITransportPublisher (RX for local play, SignalR for LAN today). Clients only process server-originated commands; the server only processes client commands (GameOriginId filtering). See docs/architecture/Game-(Protocol)-High-Level-Architecture.md and docs/architecture/game-shutdown-lifecycle.md.
Chosen direction (settled while charting).
- The cloud holds only a dumb relay hub — a WebSocket fan-out with no game logic. The authoritative
ServerGame runs on a participant's machine; every party (server-logic host and clients alike) dials the hub outbound. This sidesteps NAT traversal and the browser's inability to accept inbound connections.
- Symmetric hosting: any platform, including WASM/browser, may be the server-logic host.
- Cost ceiling: a few $/month for the hub is acceptable.
- Identity: anonymous; player IDs preserved only within a single game. Centralized identity comes later.
Skills to consult each session: grilling, domain-modeling, research, navigate-docs; sanet-mvvm for GameManager/DI wiring.
Decisions so far
Not yet specified
Out of scope
- Persistent / centralized accounts & authentication — later effort.
- Server-side game persistence / surviving authoritative-host loss beyond reconnect — later; workarounds acceptable.
- Spectators.
- In-game chat — integrate with Discord instead (permanently out).
Destination
A Network PRD (
docs/project/network-prd.md) that locks the decisions to move MakaMek from today's LAN-only peer-host to a cloud relay-hub model enabling internet + web multiplayer at minimal cost — ready to hand to/to-issues. Planning only; no code is written during this effort.Notes
Domain. Command-based client-server:
ServerGameowns authoritative state,ClientGamemirrors it; state changes travel only as serialized command DTOs. The wire is abstracted behindSanet.Transport'sITransportPublisher(RX for local play, SignalR for LAN today). Clients only process server-originated commands; the server only processes client commands (GameOriginIdfiltering). Seedocs/architecture/Game-(Protocol)-High-Level-Architecture.mdanddocs/architecture/game-shutdown-lifecycle.md.Chosen direction (settled while charting).
ServerGameruns on a participant's machine; every party (server-logic host and clients alike) dials the hub outbound. This sidesteps NAT traversal and the browser's inability to accept inbound connections.Skills to consult each session:
grilling,domain-modeling,research,navigate-docs;sanet-mvvmforGameManager/DI wiring.Decisions so far
ServerGame.Start()is an idle await-loop, real work is synchronous inHandleCommand; single-threaded browser-wasm is fine for turn-based bursts. Keep single-threaded (no<WasmEnableThreads>). Real work = adding an outbound relay-client publisher to the browser head (todayDummyNetworkHostService,CanStart => false).WebSockets+SkipNegotiation); groups=rooms, free reconnect/keepalive/backpressure/ordering/scale-out; pure-WS would reinvent it worse; WASM client works overwsswith a query-string token. (Decision Decide the relay transport (SignalR vs pure WebSockets) #1229 remains open, HITL.)Not yet specified
docs/project/network-prd.md(settled direction + research findings; open decisions marked proposed and linked to their tickets). Firms up into the final handoff as Relay hub contract: rooms, join flow, role establishment, message envelope #1225/Decide the relay transport (SignalR vs pure WebSockets) #1229/Matchmaking & game discovery #1230/Connection resilience: reconnection, state resync, and host loss #1231/Trust & authority model for a dumb relay #1232 resolve.Out of scope