field notes · june 2026
Lobbies Are Getting Bigger: What a 200-Player Co-Op Game Actually Costs to Host
The co-op lobby cap has been creeping upward for years, from a cozy four, to eight, to thirty-two, sixty-four, and now store pages advertising a hundred or two hundred players in one match. Here is the part the marketing never mentions: the cost of hosting that does not climb in a straight line. A 200-player server is not 25 times an 8-player server. It is usually much worse.
The number on the box keeps going up
Open a co-op store page in 2026 and the player cap is doing a lot of marketing work. For a long time the comfortable default was small: four players, maybe eight, a group of friends sharing a world. That number has been quietly inflating. Survival and extraction games now routinely advertise thirty-two, sixty-four, a hundred. A new co-op roguelike survival game, Minimo, puts up to 200 players in one procedurally generated map to scavenge gear, fight, and gang up on raid-scale bosses. Extraction shooters like ARC Raiders and Marathon stuff large crossplay lobbies into a single contested map. The headline number is climbing because a bigger lobby reads as a bigger, more alive world, and that sells.
From a player's chair, a higher cap is pure upside. From a server's chair, it is a warning label. Because the thing nobody puts on the store page is that the cost and complexity of hosting a session do not rise in step with the player count. They rise faster. Often a lot faster. If you run worlds, or you are deciding which rented box to pay for, the max-player number is one of the most useful cost signals you can read, as long as you know how to read it.
Why hosting cost is not linear
The intuitive model is wrong in a specific, expensive way. The instinct says a 200-player server is roughly 25 times the work of an 8-player server, because 200 is about 25 times 8. If hosting cost scaled per player, a big lobby would just be a bigger bill, predictable and tidy.
It does not scale per player, because players do not exist in isolation, they interact. Every additional player on an authoritative game server is not just one more thing to track. They are one more entity that can see, shoot at, collide with, trade with, build near, and aggro the same world and the same other players. The cost driver is not the count of players, it is the count of interactions between players and between players and the world, and that grows faster than the headcount. Three of your resources feel this at once, and each one bends upward rather than rising in a straight line.
CPU: the tick budget that breaks first
A game server runs a fixed clock. Every tick, typically somewhere between 20 and 60 times a second, it has to simulate the entire world: move every player and AI, resolve physics, advance projectiles, run logic on every active entity, then package up what changed and send it out. The hard constraint is that all of this work has to finish inside one tick window. Blow the budget and the tick rate drops, which is the lag and rubber-banding players feel on a crowded server.
Here is why that budget collapses non-linearly. More players means more AI spawned and active, more projectiles in flight, more physics bodies, more buildings and items in a busier shared world, and more pairwise interactions to check between all of them. Doubling the players does not double the per-tick work, because the new players add entities and interact with everyone already there. A naive collision or interest check between N entities is closer to an N-squared problem than a linear one. Smart engines fight this hard with spatial partitioning so they are not literally checking everything against everything, but the underlying pressure is the same: the simulation cost per tick rises faster than the player count, and it is almost always CPU, not RAM, that gives out first on a busy box.
This is also why single-thread performance matters more than core count for many game servers. A lot of simulation work sits on one main thread that has to finish the tick, so a higher clock speed buys you headroom that extra cores often cannot, because you cannot trivially split one coherent world simulation across many cores without the engine being built for it. To put it in illustrative terms only: if an 8-player world comfortably uses a fraction of one fast core, a 64 or 200-player version of the same simulation can saturate that core and start missing tick deadlines long before you would expect from the player ratio alone.
RAM and the N-squared bandwidth problem
Memory is the gentler of the three, but it still does not sit still. RAM on a game server holds the world state, the loaded map and its entities, plus per-player state for everyone connected. A bigger lobby in a bigger or more densely built world means more loaded entities and more per-player bookkeeping, so memory grows with both world size and player count. It tends to climb closer to linearly than CPU does, but a 200-player persistent survival world with months of accumulated player building is a genuinely large object to keep resident, and it is the reason sizing guides quote very different memory numbers for the same game at different group sizes.
Bandwidth is where the math gets ugly again. In the naive case, every player needs to be told what every other relevant player just did. If each of N players generates state changes that must be replicated to many of the others, the total replication traffic trends toward the square of the player count, not the player count. Eight players replicating to each other is a trickle. Two hundred players in the same space, each one's movement and actions fanning out to many others, is a flood, and it scales like an area, not a line.
This is the single biggest reason large-lobby games invest so heavily in interest management: the server only sends a given player updates about things near enough to matter to them. Done well, it turns that square back toward something manageable, because a player in one corner of the map does not need a packet about every footstep on the far side. But interest management is engineering you are relying on the developer to have built. Where it is weak or absent, bandwidth and the CPU cost of computing who-can-see-what become the real ceiling on lobby size, well before the box runs out of raw horsepower.
How big lobbies actually get hosted
Put those three pressures together and you reach the conclusion the industry reached long ago: you usually do not host a very large lobby on one fat box simulating everyone equally. Authoritative real-time game servers comfortably handle on the order of tens to a few hundred players per process before the tick budget or bandwidth forces a different design. The games that advertise the biggest numbers tend to get there with architecture, not with a bigger single machine.
The practical takeaway is uncomfortable for self-hosters. When a store page says 200, that number is frequently the product of developer-run infrastructure doing one or more of the things in that table. It is not a promise that you can spin up a single rented server and reproduce 200 players at a smooth tick rate. For a lot of the biggest-lobby titles, the realistic self-host story is either a smaller official cap on the dedicated-server build than the marketing number, or a cluster you are not going to stand up on one box, or no first-party dedicated server at all because the whole experience assumes the studio's backend.
The self-hoster's sweet spot
None of this is an argument against big games. It is an argument about where a self-hoster's money is well spent, and the answer has not really changed even as the headline numbers ballooned. The sweet spot for a rented box or a spare mini-PC is still small-to-mid.
A persistent world for a handful of friends, or a community of a couple of dozen, sits comfortably inside the tick budget and bandwidth of a cheap machine. The simulation is small enough that one fast core can keep the clock, the world fits in modest RAM, and the replication traffic is a trickle rather than a flood. This is exactly the band where running your own server is genuinely cheap, reliable, and low-maintenance, the thing it is supposed to be. You can leave it up for months and basically forget about it.
The trouble starts when people see the 200 on the box and assume that is the target. Chasing the maximum advertised lobby on a single rented server is how you end up paying for an oversized box that still stutters, because the bottleneck was never the size of the box, it was the super-linear simulation cost meeting a single-threaded tick deadline. The honest planning number is not the cap on the store page. It is the largest lobby your hardware can simulate at a stable tick rate, and for most communities that number is healthy, satisfying, and a good deal smaller than 200.
Reading the max-player number as a cost signal
So here is the field note, the way this site likes to leave you with something you can use before you spend money.
Treat a game's advertised max-player count as a cost-and-complexity signal, not a target. A low cap, four or eight, is good news for a self-hoster: the dedicated server is almost certainly one cheap process, the sizing is modest, and you will get the full experience on a small box. A mid cap, into the dozens, means pay attention to single-thread CPU and to whether the game has real interest management, because that is the band where a busy world starts pressing the tick budget. A very high cap, into the hundreds, should make you ask a different question entirely: is there even a single-box dedicated server here, or is the headline number a property of the developer's sharded backend that I cannot rent?
Three checks answer most of it before you commit. First, what does the game actually simulate per player, twitchy real-time combat and physics, or a slower survival loop? More simulation per player means the cost curve bends sooner. Second, is the dedicated server one process or a cluster, and does the server build quietly cap lower than the marketing number? Third, what player count does the community actually run in practice, which is almost always below the advertised ceiling for a reason. Those three tell you more about your real hosting bill than the big number on the store page ever will.
The max-player number sells the game. It does not size your server. Hosting cost grows with interactions, not headcount, and the honest planning figure is whatever your box can simulate at a steady tick rate.
Lobbies are going to keep getting bigger, because the number sells. The physics of simulating a shared world are not going to get any kinder. The self-hosters who stay happy through the surge will be the ones who read 200 as a cost warning, found their own hardware's sweet spot somewhere well below it, and ran a world that stayed smooth instead of a world that merely advertised a big number.