Mutant Mayhem, in development. Footage courtesy of KamJam Games.
---
## Multiplayer Network Topologies: How to Choose
URL: https://www.kinematicsoup.com/blog/multiplayer-network-topologies-how-to-choose
Date: 2026-07-09
Summary: Dedicated server, listen server, peer-to-peer, relay, or a plain web backend: how each multiplayer topology works, which games they fit, and the constraints that make the choice for you.
Every multiplayer game has a network topology: an answer to the question of whose machine runs the simulation and how everyone else's machine hears about it. If you have never chosen one deliberately, you still chose one. It was the default of whatever framework you started with, and defaults are decisions someone else made without knowing your game.
A wrong choice costs more than most technical decisions because it surfaces late. A topology is a decision about where authority lives, and every system built afterwards, movement, combat, spawning, persistence, assumes that answer. Teams usually find the mismatch at one of three moments: the first playtest with strangers, when host advantage or cheating stops being theoretical; the port to a platform the topology cannot support, which for client-hosted games is mobile; or launch, when the server bill or the session-size ceiling arrives. By then the fix is not a setting but a rewrite of the layer everything else was built on, at the point in the project with the least time for it.
The good news is that choosing well is less about taste than it looks. Most of the option space gets eliminated by constraints your game already has, before preference enters into it. This guide walks through the topologies in use today, how each one works, and then the constraints that do the choosing.
## Dedicated server
A server process owned by the game's developer runs the simulation. Every client connects to it, sends inputs, and receives state updates. The server is the single source of truth: it validates what clients claim, resolves conflicts, and decides the outcome of every interaction. Clients render that state, usually with prediction layered on top to hide the round trip.
This is the strongest position on cheating and fairness. No player's machine holds authority, so no player has a latency or information advantage built into the architecture, and claims like "I hit you" are checked by hardware nobody in the match controls. Performance is predictable because the simulation runs on known hardware rather than whatever laptop the host happens to own. Dedicated comes with an operational cost: someone has to run and pay for the servers for as long as the game is alive. We wrote about what that costs, self-run and managed, in the [multiplayer cost series](/blog/how-much-does-it-cost-to-build-and-run-a-multiplayer-game/).
Two variations are worth knowing about. Large or persistent worlds are usually built as clusters of dedicated servers, with the world sharded across rooms or regions and players handed between them; that is an architecture built on top of this topology rather than a different topology. And some games run a dedicated server but grant clients authority over their own movement to save server CPU, accepting the potential cheat surface in exchange. You will meet that hybrid in the wild, usually in games that later wish they had not shipped it in ranked modes, but sometimes in games where the compromise was deemed acceptable for another benefit.
You will find dedicated servers under most competitive shooters, MMOs, battle royales, and physics-heavy games. Tools in this space include Reactor (our engine), Photon Fusion 2 in server mode, Unity's Netcode for GameObjects or Mirror deployed to dedicated hosts, and coherence with its cloud simulators. We compared several of these in [our engines guide](/blog/best-unity-multiplayer-engine/).
### Games that fit
Should use it: competitive shooters and battle royales, MMOs and any persistent world, physics-heavy games where the simulation must be shared, and anything where ranking, money, or an economy rides on the outcome. Also any real-time game shipping on mobile, where client hosting is not an option.
Could use it: co-op games that want drop-in sessions that outlive the host, or a platform mix that includes mobile or consoles with strict networking rules.
Where it competes: against a listen server for small co-op, choose dedicated when mobile is a target, when sessions must survive the host leaving, or when you can budget for servers; choose the listen server when hosting cost has to be zero and the players are friends. Against lockstep for strategy games, choose dedicated when you cannot guarantee determinism or when maphacks matter; lockstep wins when unit counts are in the thousands and command delay is acceptable.
## Listen server (client-hosted)
One player's machine runs both the game and the server; the other players connect to it. Authority works like the dedicated case, except the authority lives on a player's hardware and shares resources with their frame rate.
That grants the host an inherent advantage, since their inputs reach the authority with zero latency, and it makes the session host-dependent: when the host quits, crashes, or loses connectivity, the session dies with them unless the game implements host migration. Migration is genuinely hard to do well, because it means promoting another peer to host mid-session, handing off authoritative state, resolving actions that were in flight, and hoping the new host's connection can carry the room. Many games that advertise host migration ship a version that works in the demo and disappoints in the wild.
The binding resource is the host's upload bandwidth. Residential connections are built for downloading, and the host must upload state to every other player, so the session size ceiling is set by the worst upstream connection in the lobby, not by anyone's download speed. This sets a lower limit on both the amount of data the game cause use per connection as well as the number of players a single host can accomodate.
The reward for accepting all of this is that hosting costs the developer nothing, which is why the topology carries co-op games, small-lobby games, and most games where cheating is a social problem rather than an economic one. Tools here include Netcode for GameObjects and Mirror in their default host modes, Photon Fusion 2 in host or shared mode, Reactor in client-authority mode (ours), which works much like Fusion 2's shared mode with clients driving the objects they own while the server brokers ownership, and the session APIs in Steamworks and Epic Online Services.
### Games that fit
Should use it: co-op games for up to about eight players on PC and console, party games played among friends, and prototypes or playtests where standing up servers is premature.
Could use it: casual competitive games where the host's latency advantage is tolerable, and games with a small budget that still need a public lobby.
Where it competes: against a dedicated server, the listen server loses as soon as cheating has economic stakes, the game ships on mobile, or sessions need to outlive the host. Against a relay, there is no contest: a listen server shipping today should run over a relay, since the relay solves the NAT and privacy problems without moving authority.
## Peer-to-peer with deterministic lockstep
No server at all. Every player runs the full simulation locally and exchanges only inputs with every other player. For this to work, the simulation must be bit-for-bit deterministic: the same inputs must produce the same state on every machine, every time, across hardware and platforms. Each tick waits until every player's input for that tick has arrived, so the game advances in lockstep and feels as responsive as the slowest client in the session.
The bandwidth profile is remarkable, which is why real-time strategy invented the technique: a thousand units cost no more to network than ten, because only the players' commands cross the wire. The liabilities are equally structural. A single divergence between simulations is unrecoverable without resync machinery, determinism rules out most off-the-shelf physics engines, and every client holds the complete game state, so maphacks are an architectural property rather than a bug to patch.
RTS games are the home genre, and the approach persists anywhere unit counts are enormous and inputs are small. Photon Quantum is the notable engine offering determinism as a product; the classic implementations are custom, and the RTS community's postmortems on them are some of the best networking literature there is.
### Games that fit
Should use it: real-time strategy with large unit counts, tower defense and auto-battlers with many entities, and simulations where every player must see the same world and input latency can hide behind a command delay.
Could use it: sports and fighting games, which used lockstep historically; most have since moved to rollback.
Where it competes: against rollback, lockstep wins when unit counts are huge and a few frames of input delay are acceptable; rollback wins when feel matters and player counts are small. Against a dedicated server, lockstep wins on bandwidth for large entity counts, and loses when determinism cannot be guaranteed, when maphacks matter, or when the platform mix makes peer connections unreliable.
## Peer-to-peer with rollback
The same input-exchange idea, with the waiting removed. Instead of stalling until remote inputs arrive, each client predicts them, usually by assuming the other player repeated their last input, and keeps simulating. When the real input arrives and disagrees, the client rewinds to the last confirmed state, applies what really happened, and re-simulates forward to the present, all inside one frame.
Done well, local inputs feel instant and the corrections are invisible, which is why fighting games consider rollback the gold standard for online play. The cost is engineering discipline: the simulation must be deterministic like lockstep, and additionally serializable and fast enough to re-run several frames in a single frame's budget. That constrains scope in practice to games with small player counts and lean simulations.
GGPO made the technique famous and open source; its descendants power most modern fighting games, and Photon Quantum brings the same rollback-on-determinism model to Unity teams that do not want to build it from scratch.
### Games that fit
Should use it: fighting games, platform fighters, and other one-on-one or two-on-two games where instant input response is the product.
Could use it: small co-op action games with lean, deterministic simulations, and sports games with a handful of controlled entities.
Where it competes: against lockstep, rollback wins on feel and loses on scale, since re-simulating several frames per frame is affordable only for small simulations. Against a dedicated server, rollback wins on latency for two players and loses when the game has more than a few players, when the physics engine is not deterministic, or when the platform mix includes mobile.
## Relay-assisted sessions
A relay is less a topology than a modifier on one. A lightweight server in the middle forwards packets between players but runs no game logic, which solves the two problems that kill direct connections: NAT traversal, since everyone connects outward to the relay instead of accepting inbound traffic through a home router, and IP privacy, since players never learn each other's addresses. Authority stays wherever the base topology put it, on a player host or spread across peers.
The cost profile sits between free and dedicated. Relays only move bytes, so they are cheap to operate per player, and platform vendors now provide them as a service: Steam Datagram Relay, Unity Relay, Epic Online Services, and the console platforms' equivalents. The latency cost of the detour through the relay is usually modest and often negative against a bad direct route, since relay networks tend to run on better backbones than consumer ISPs peer over.
In practice, most games described as client-hosted today are client-hosted over a relay. If you are shipping a listen-server game in the 2020s, this is almost certainly the form it should take.
### Games that fit
Should use it: any client-hosted game shipping to the public, since a relay removes port forwarding and hides players' addresses, and any peer-to-peer game (lockstep or rollback) that needs reliable connectivity between strangers.
Could use it: shared-authority models where each client owns its objects and the relay carries everything, and mobile games where a phone hosts through the relay, with the caveat that the host is still the least reliable machine in the session.
Where it competes: against a dedicated server, the relay wins on cost, since it runs no game logic, and loses when authority needs to be neutral, when sessions must outlive the host, or when the game is real-time on mobile, where a dedicated server is the reliable choice.
## Asynchronous backend
Not real-time at all. Clients talk to an ordinary web backend over HTTPS; the backend stores moves, resolves turns, and notifies opponents, often through a push notification. There are no persistent connections, no tick rate, and no NAT concerns, because nothing about the architecture differs from any other online application.
This is the correct topology for a whole class of games, and it is included here because choosing a real-time stack for a turn-based game is a common and expensive mistake. If your game's pace is measured in "your turn" moments rather than milliseconds, a real-time topology buys you permanent infrastructure cost and complexity for nothing. Word games, board games, and most social and idle games live here happily. Purpose-built backends like Nakama and PlayFab cover the game-shaped parts, and a plain web stack works fine too.
### Games that fit
Should use it: turn-based strategy, word and board games, gacha and idle games, social simulations, and asynchronous competition such as ghost races and leaderboards.
Could use it: slow real-time games, such as some 4X titles, where a turn or a tick takes seconds and a request per action is fine.
Where it competes: against every real-time topology, the backend wins whenever outcomes resolve in turns rather than ticks. Many games need both: a real-time topology for the match and a backend for the meta layer around it, such as accounts, progression, and matchmaking. That is a pairing, not a choice.
## How to choose: elimination first
Run these checks in order, and strike topologies as they fail. What survives is your real option space; the "games that fit" notes above cover the overlaps.
1. **Is the game real-time at all?** If outcomes resolve in turns rather than ticks, use an asynchronous backend and stop reading. Everything else on this list is overkill.
2. **Does it ship on mobile?** If yes, client-hosted topologies are out. A host's address must stay stable for the whole session, and mobile networks do not offer that: devices hop between Wi-Fi and cellular as players move, and carrier-grade NAT reassigns addresses without notice. A real-time mobile game connects to something with a stable address, which means a dedicated server or a relay. This single constraint eliminates half the option space for a large share of games, and it is far cheaper to learn before building than during the port.
3. **Can you commit to determinism?** Lockstep and rollback require bit-identical simulation everywhere, which rules out most off-the-shelf physics engines and any codebase that treats floating point casually. If you cannot make that commitment, both peer-to-peer models are out.
4. **Does money or ranking ride on outcomes?** Competitive integrity requires authority on hardware players do not control. Host advantage and peer-to-peer's open state are architectural properties; they cannot be patched out after launch. Ranked, wagered, or economy-bearing games point at dedicated servers.
5. **How many players per session, and how big is the world?** Host upload bandwidth caps listen servers, and input exchange scales poorly past a handful of peers. Large sessions and persistent worlds push toward dedicated servers, sharded when one machine stops being enough.
6. **Who pays for infrastructure?** If the answer must be nobody, you are choosing among listen servers, relays, and peer-to-peer, and accepting their limits knowingly. That is a legitimate choice for a great many games; the failure mode is making it by accident.
## The mistakes worth avoiding
Each of these is a rule from the checklist, learned in production instead:
- **Building a turn-based game on a real-time stack.** The infrastructure bill arrives monthly forever, purchasing nothing the game needed.
- **Shipping client-hosted on PC and then porting to mobile.** The game ports; the topology does not. Games have re-architected their networking mid-life over this.
- **Prototyping with client authority in a competitive game.** Server authority is not a feature you bolt on later; it changes where the simulation lives. If the endgame is ranked play, build toward authority from the start.
- **Sizing a listen server by download speed.** The host uploads to everyone. Upstream is the limit, and residential upstream is usually a tenth of the number on the ISP's ad.
Choose by elimination, and the topology decision mostly makes itself. The engineering that follows is substantial in any direction, but it is far better spent building on the right foundation than migrating off the wrong one.
*Reactor, our multiplayer engine for Unity, ships with managed dedicated hosting behind it. If your elimination pass landed on dedicated servers, the [engine tour](/reactor/) is the place to start.*
---
## How We Synced 5,000 Enemies in a Multiplayer Survivors Game
URL: https://www.kinematicsoup.com/blog/multiplayer-survivors-5000-enemies
Date: 2026-06-24
Summary: A multiplayer survivors-like with 5,000 to 6,000 networked enemies, built in a week on Reactor. The numbers behind syncing that many server-authoritative entities at 50 to 70 KB/s with no network LOD.
We build games on Reactor as a way to dogfood our own engine, and the latest one is a multiplayer survivors-like. The genre had a recent hit in Megabonk, and the appeal is familiar: you stand in a rising tide of enemies and cut them down in swaths. Our twist is that it is multiplayer, and there are far more enemies. A typical match has 5,000 to 6,000 of them on the field at once, and clearing a crowd that size has a particular cathartic pull to it.
The gameplay loop was never the hard part. The question we cared about was whether we could keep 5,000-plus server-authoritative enemies synced to every player without the bandwidth or the frame rate falling apart. Here is how it held up.