Multiplayer: survive a dropped or reconnecting player

[CubeB]

From the ROADMAP: "Reconnect / drop handling instead of hard failure." A network game should not end for everyone when one player's connection drops.

Background. The sim is lockstep: peers exchange commands, not state (CLAUDE.md, "Determinism"). A tick cannot advance without every peer's commands for it, so a lost peer stalls everyone.

Needed

1. Detect a peer that has stopped sending, with a timeout, and show the others a "waiting for player" state rather than a freeze.
2. Drop the player after the timeout (or on a vote), so the rest carry on. Decide what their units do: in TA a departed player's units stay on the map. Dropping has to happen on the same tick on every remaining peer, or it is a desync.
3. Rejoin, the harder half. The full-state save (save_util, hash-validated round trip) can serialise the game at a tick boundary. A returning peer could load that, then replay the commands buffered since, and rejoin the lockstep.

Where. GameNetworkService, proto/network.proto, and the launcher's game-server. Split 1+2 from 3.

Done when killing one peer's process mid-game leaves the others playing after the timeout, and with 3, the killed peer can come back.

🤖 Generated with Claude Code

https://claude.ai/code/session_018moxVoyHDBoHqkw8uqS3HX

[HectorBailey]

Questions before starting on 1 and 2:

1. What the sim does on the drop tick. GameNetworkService has no timeout or keepalive today; a silent peer stalls the tick. Dropping has to be a command every remaining peer applies on the same tick, so I'd add a PlayerDroppedCommand to the protocol that the host issues after the timeout and everyone applies through the ordinary command stream. Their units then stay on the map, as in TA. Do you want them frozen (no orders, weapons still return fire) or handed to the AI, or literally left as they are with their standing orders and fire mode?
2. Who decides. Host-decided timeout (simplest, and the host is the one lobby already trusts), or a vote among the remaining peers as the issue mentions? A vote needs its own messages and a tie-break; a host timeout needs the host not to be the one who dropped. I'd do host timeout first and leave the vote out unless you want it.
3. The timeout value and the waiting state. TA's own "waiting for player" appears after a few seconds. Is a fixed value in rwe.cfg (say 10 s) acceptable for the first cut, with the waiting overlay shown after the first missed tick? Or should the overlay be the existing pause path with a caption?
4. Rejoin (3). The save round-trip gives a state at a tick boundary, and the commands since are in every peer's buffers. The open question is the transfer: through the game-server (which then needs to hold saves and command logs), or peer to peer from the host over the existing UDP path (which needs a reliable-transfer layer that does not exist)? Which direction do you prefer? This decides whether 3 is a week of launcher work or a week of engine work.

[CubeB]

1. Leave them as they are, with their standing orders and fire mode. That's the least new behaviour, and it's what "their units stay on the map" means. Handing them to the AI can be its own issue later. A PlayerDroppedCommand through the ordinary command stream is the right shape.
2. Host timeout first, and no vote.
3. A fixed rwe.cfg value is fine for the first cut; 10 s is fine. Show the waiting state only once a stall has lasted about a second, so ordinary jitter doesn't flash it. Reuse the pause presentation, with a caption naming the player and a countdown to the drop.
4. Go through the game-server. Every launcher already holds a reliable connection to it for the lobby, so this avoids writing a reliable layer over UDP. The host's engine hands the save and the command log since it to its launcher over the bridge, and the server relays them. Do 1 and 2 first, and open 3 as its own issue when you get there.

🤖 Generated with Claude Code

https://claude.ai/code/session_018moxVoyHDBoHqkw8uqS3HX