multiplayer-networkinglisted

# Multiplayer Networking ## Purpose Networked gameplay is constrained by three facts that cannot be engineered away: latency exists, bandwidth is finite, and clients are not trustworthy. Every design decision here is a trade between responsiveness, consistency and security. The most expensive mistake is architectural and made early: building single-player and adding multiplayer later. Authority has to be designed in from the start, because retrofitting it is close to a rewrite. ## When to use - Adding multiplayer to a game, or designing one from the start. - Networked movement, combat or interaction feels laggy, rubber-bandy, or unfair. - Clients disagree about game state. - Bandwidth or server cost is too high. - Choosing a topology: dedicated server, listen server, or peer-to-peer. ## When NOT to use - Local or split-screen multiplayer, which has none of these problems. - Pure security auditing of an existing implementation. Use `client-server-trust` and the `security` agent. - Turn-based games with no latency sensitivity, where a much simpler request/response model is sufficient and this complexity is unwarranted. ## Required context | Fact | Why it matters | |---|---| | Topology | Determines where authority can live and what is attackable | | Player count per session | Two and sixty-four are different problems | | Latency-sensitivity of the core loop | A shooter and a strategy game need different techniques | | Whether the game is competitive | Competition me