Every multiplayer game has to answer the same question: whose machine decides what happened in a match? The answer shapes cheating, fairness, what happens when a player leaves, and what the game costs to run.

This guide summarizes and compares the five main potential setups developers can choose between, what each one fits, and when to consider another setup.

For a deeper look at the network models themselves, see Edgegap’s guide to authoritative servers, relays and peer-to-peer.

The Five Setups at a Glance

All five share one shape, client-server: every player connects to one copy of the game that decides what happened. What changes is who runs that copy, a player’s game or a server, and how much it does. In peer-to-peer and relays, the “server” is the host player’s game, a model often called host-client.

1. Peer-to-Peer

What it is: In most games that ship it, peer-to-peer means host-client. One player’s game holds the match state and acts as the server while that player plays, and everyone else connects to them. A smaller family of games, mostly strategy and fighting games, runs every simulation on every machine and exchanges only inputs, in lockstep or with rollback.

Fits: Prototypes, game jams, non-commercial releases, local or LAN-style play, and small sessions among friends.

Benefits:

• No hosting bill: Players supply the hardware and the bandwidth.

• Quick to start: Most engines support a host mode, often called a listen server.

Limits:

• Connections fail: Most players sit behind a router doing network address translation (NAT). Hole punching often fails on strict routers and carrier-grade NAT, common on mobile networks.

• The host can cheat: Whoever holds the match state can change it, by editing values in memory, lag-switching or reporting a result that never happened.

• Players see each other’s IP addresses: That exposes them to denial-of-service attacks from the players they’re matched with (P2P’s hidden costs).

• The host leaves, the match ends: Unless the game builds host migration. Highwire Games estimated host migration for Six Days in Fallujah at one extra developer and one extra tester, around $15,000 a month (Live Service Game Summit talk, September 2024).

Peer-to-peer can also cost latency, because the direct route between players isn’t always the shortest. In a 2020 analysis of 122,000 peer-to-peer matches from a 1v1 console game, routing each match through a server placed between the two players lowered average round-trip time by 23% in 70% of matches (1v1 report).

Consider another setup when: Players report they can’t join each other. That is the problem a relay was built for.

2. Shared Relay Service (e.g., Steam, Epic Online Services, Unity Relay)

What it is: A relay server forwards traffic between players who can’t reach each other directly. Every player connects out to the relay, which passes packets between the host and the guests. A shared relay service is one run by a platform for every game on it.

Fits: A network solution for connections that fail, in a game already built host-client.

Benefits:

• Avoids most NAT issues: Nobody has to accept an incoming connection, so NAT and firewalls stop blocking players.

• Secure, hides player IP addresses: Players connect to the relay, not to each other.

• Little to integrate: Platform SDKs often bundle the relay with lobbies.

Limits:

• The game is still player-hosted: The relay runs no game logic. The host can still cheat, still plays with no network delay, and still ends the match by leaving.

• Every guest takes two hops: Guest to relay to host, then back. Where the relay sits sets each guest’s latency, and the more players are far from a relay location, the less fair the match. Web games feel it most: browsers using WebSockets can’t connect player to player at all, so every packet of every match goes through the relay, and WebRTC falls back to a relay, a TURN server, whenever a direct connection fails (relay server).

• One provider’s network sets the route and uptime: Evaluating Epic Online Services’ free relays, Michal Buras of Highwire Games found “absolutely no control over how those players are routed” (Live Service Game Summit talk, September 2024). He also showed lobby data on that setup read in plain text with a common debugging tool. The route and its uptime are tied to that provider’s network.

Consider another setup when: You want the route, the locations and the code on the relay to be your call.

3. Extensible Relay (e.g., LightNet)

What it is: A relay you run on a dedicated server, with the option to extend it by adding game logic. Add game logic and it becomes a multi-room dedicated server with relay-like resource efficiency. Out of the box, it is a relay first: it forwards traffic, and the host’s game owns the match. Edgegap’s LightNet relay guide runs one for host-client Unity games, with players hosting and joining through a room code.

Fits: Players who trust each other: co-op, friends and private rooms. Within that, mobile and hybrid-casual games, TCGs and realtime PvP without server logic.

Benefits:

• Secure, hides player IP addresses: Everyone connects out to the relay, which closes the door on attacks on a player’s connection, such as flooding the host.

• Avoids most NAT issues: No port forwarding, including on mobile networks.

• Your route, your locations: You deploy the relay where your players are.

• A network serving only your game, on many clouds: A routing change or outage on another relay network doesn’t reach it. On a multi-cloud platform such as Edgegap, with 17+ providers, a new relay can start on another provider if a location fails.

• Your own code: Shared relay services don’t let you add code. On your own relay, you can add logic such as room passwords or player checks, rate limits, kick and ban, room data, telemetry, or hooks to your lobby. None of it ships in the sample, so each one is yours to write.

• Can stop cheating once you add game logic: As shipped, the host’s game holds the match state, so a cheater can still ruin a match for everyone. Adding gameplay validation gives it server authority on the same code and deployment, as described below.

• No rewrite to start: Your host-client netcode stays as it is, and one relay serves many rooms at once.

Limits, as shipped:

• The match ends when the host leaves: Host migration isn’t built in, so the game has to provide it. In the LightNet sample, the relay also closes the room.

• It doesn’t encrypt traffic: The LightNet sample’s transports are plain TCP and UDP.

• No matchmaking or scaling on its own: Players share room codes, and you choose where relays run.

Where the line sits: Logic that isn’t gameplay, such as passwords, rate limits or telemetry, keeps it a relay. Validating gameplay, such as hits, results or an economy, turns it into a multi-room game server, the next step. As Michal Buras put it, “If you’re computing, it’s not a relay server anymore.” That move is possible, but it is real work: the relay only sees raw netcode traffic, so it has to learn to read your game’s messages before it can check them.

Hosting: Edge Cloud suits on-demand use, development, playtests and pre-production. At scale, Private Fleets are usually more cost-effective for relays that run around the clock: reserved hosts in 58 locations, with 6 TB of egress included per host. On either, recycling relays regularly is best practice.

Consider another setup when: Your players start meeting strangers, or you want the server to decide what happened.

4. Multi-Room Game Server

What it is: A multi-room game server is one server process that hosts many matches at once, each in its own room with its own state and players. The process’s fixed costs, such as the engine and loaded game data, are paid once and shared across every room. It is also where an extensible relay lands once you add gameplay validation to it.

Fits: Games that can share a process: turn-based, card, puzzle and casual games, RTS games, which often run in lockstep, MOBAs, which have no heavy physics but need an authoritative server, and many sports and racing games, plus lobbies and social spaces.

Benefits:

• Stops host cheating: The server owns the logic and decides what happened.

• Secure, hides player IP addresses, and avoids most NAT issues: Every player connects out to the server.

• No host migration needed: The match survives anyone leaving.

• Many matches per process: Room-based frameworks such as Colyseus and Nakama do it by design, and Mirror can give each match its own subscene. Edgegap sets no process limit: a deployment runs as many processes and rooms as its CPU and memory allow.

• Flexible sizing: On a service like Edgegap, servers start at 0.25 vCPU and go up to a 14.7 vCPU Private Fleet host. You size by rooms per vCPU, measured in a profiled build, rather than by match.

• Simple scaling: A matchmaker backfills players into an open room, or deploys a new server when no room fits.

Limits:

• Likely a central location: A multi-room server’s location is chosen once, at start, and it often runs centrally, where players are dense. If the central model is used, players far from it get worse latency and fairness than players close to it.

• Rooms must be kept apart in code: Converting a single-match server means shared state, from singletons to physics, has to become per room. Unreal usually runs one match per process.

Consider another setup when: Each match needs its own server near its players, or the world has to persist while players come and go.

5. Dedicated Server

What it is: A dedicated server runs one session per deployment, on a server no player controls. It takes over the host’s role, so for a game built host-client, the host’s logic can often run as a headless build. A light match and a full simulation run on the same kind of server; what changes is how much CPU it needs, which usually starts high and comes down as the team optimizes. A dedicated server sized for a light match is sometimes called a small dedicated server.

It comes in two variants, best compared by how they behave rather than by genre:

Fits:

• Session-based: Shooters, battle royales, realtime PvP, competitive and ranked modes, fighting games, VR and XR, Web3, co-op with strangers, and mobile and hybrid-casual PvP.

• Persistent: MMOs, survival and sandbox worlds, and social hubs.

Benefits:

• Stops host cheating: Clients send inputs and the server decides outcomes, which closes the cheats that rely on a player owning the game state. Server authority doesn’t stop aimbots or wallhacks on its own, since those run on the player’s machine, so server-side checks sit alongside client-side anti-cheat.

• Reliable connections, no dependence on host availability: Every player connects to a server no player controls, which hides player IPs and avoids most NAT issues. No host can leave, so no host migration is needed.

• Placed for the players in the session: Each session-based server starts where it best serves that match’s players. Independent replays of a studio’s live traffic measured a 58% average latency reduction for dedicated server placement against public-cloud relay placement (platform data, 18 September 2026).

• Scales with the game: Fractional vCPU sizing starts at 0.25 vCPU for a light match. At the other end, a full simulation runs physics, movement and hit detection at a fixed tick rate for 2 to 100 or more players, and persistent worlds and MMOs run the same way: The Isle, Afterthought LLC’s open-world dinosaur survival game with 100+ players per server, runs its persistent servers on Edgegap, and Loftia, Qloud Games’ cozy MMO, scaled hundreds of game servers, including hubs of up to 100 simultaneous players, through its closed beta.

Limits:

• One session per deployment: Each session-based match starts and stops its own server, so it relies on an orchestrator that starts servers quickly and places them by player.

• Resource use grows with the simulation: A card game hosted like a battle royale overpays; light games often fit better on a multi-room server.

Hosting: Session-based games often run a hybrid: a reserved fleet for a cost-effective share of overall traffic, and on-demand capacity for everything above it. Persistent worlds suit Private Fleets.

Bloody Bastards, a mobile game with more than 40 million downloads, moved from host-trusted peer-to-peer, where its studio describes cheats as rampant, to authoritative servers and a matchmaker, with “zero cheaters since” (Edgegap blog, 2026).

Which Setup Fits Each Game Genre and Mode?

Many games combine two setups: private rooms on a relay, public matches on a server. Where a multi-room server runs centrally, players far from it get worse latency and fairness than players close to it.

Next: How Players Reach the Server

Choosing where the match runs is half the setup. The other half is how players get into it. An extensible relay, a multi-room server and a dedicated server can each use either option below; the choice depends on game design: does a rule decide, or does the player pick?

• A matchmaker: Rule-based. It groups players by rules such as skill and latency, then backfills them into an open room or starts a new server when none fits. It suits session-based games where strangers meet. Edgegap’s matchmaker deploys the server near the players it matched.

• A server browser: The player picks. It lists running servers or rooms with open slots, as in a lobby. It suits persistent and community games.

Many games use both, and the choice is worth making alongside the server tier rather than after it.

Start From Who Your Players Trust

Teams have often picked peer-to-peer and relays because a server per match used to cost too much, rarely because a relay makes a better match. That gap has narrowed: a multi-room server shares a process across many matches, and a dedicated server can start at a fraction of a vCPU.

A useful check before choosing: list who your players will play with. If the answer is only friends, an extensible relay fixes connections, keeps IP addresses private and leaves room for code of your own. If strangers meet anywhere in your game, casual or ranked, give those matches to a server, sized to what it has to decide.

Ready to give the match to a server? Start with the guide for your engine: Unreal Engine, Unity, Godot or browser games.