game-networking-guidelisted

# Game networking Guidelines API-agnostic architecture for real-time multiplayer over an unreliable network: how participants are modeled and who owns state, what to put on the wire, and how reliability is layered on UDP. This skill replicates a typed world, see **data-model-guide** for the object/id model, **ecs-guide** for the component model, and **data-oriented-design-guide** for packing wire data. ## Essentials - **Nodes form a graph, topology is data** - Model each participant as a simulation bound to an address; keep client/server-vs-peer and accept/own/replicate as per-node config, not baked-in protocol, see [references/topology-and-authority.md](references/topology-and-authority.md) - **One owner per object** - Exactly one node is the source of truth for a networked object and replicates it; others apply received updates read-only, see [references/topology-and-authority.md](references/topology-and-authority.md) - **Replicate opted-in state** - Replication is a per-component capability plus a per-object flag; the owner watches for changes and sends only to interested nodes, see [references/state-replication.md](references/state-replication.md) - **Guarantee per packet type, over UDP** - Open one-way pipes between nodes; tag every payload with a type that carries its delivery guarantee (unreliable / ordered / reliable), see [references/transport-and-channels.md](references/transport-and-channels.md) ## Replicating world state - **Two-level opt-in** - A component d