Why some multiplayer worlds can handle 100 players while others struggle with 20

You won't learn much about a server's behaviour from the player cap that appears on its listing. With a hundred players crammed into a single map, a battle royale match can go along without a hitch for twenty minutes. A survival world with twenty friends can start stuttering once someone builds a huge automated farm. It has nothing to do with the amount of participants. What matters is the server's workload, how fast it gets through it, and how much of the result each player actually needs.

The server is running a loop

A multiplayer server runs a simple loop. It collects input from everyone connected and moves the world forward by one step. It then sends out the new state. For the duration of the server's uptime, that loop occurs several times every second. The more people who join, the heavier each stage becomes.

The outgoing side gets heavier fastest. If each player has to know about every other player, there won't be a straight line link between the number of updates and the size of the population. With twenty people, there are 380 updates from player to player every step. A hundred players means 9,900. There are five times as many people and about twenty-six times as much traffic, and that's not even counting the mobs, projectiles, and falling blocks.

Genre picks the network model

In a turn-based game, a fraction of a second can pass between actions and no one will notice. A strategy game where attacks resolve while the defender is offline barely needs a live connection at all. Since the outcome of a battle can be determined in the fraction of a second, a shooter is the polar opposite.

Studios with big live catalogues plan for this from day one. Browse the online games by Plarium and you'll find mostly turn-based battles and strategy builds, the kind of design that lets one world hold a very large community without straining the servers. Faster genres are a different story. Fast physics and quick aiming make every player expensive for the server, while turn order and timers cost almost nothing. Before anyone rents a machine to run it, the genre has already decided the networking method.

What the world is doing matters more than who is in it

Players typically don't have to do any heavy lifting in sandbox servers. Everything they have created and abandoned does it for them. Things like monsters moving through caves, crops growing, hoppers moving goods, water seeping into a hole that was just dug, and piles of dropped items that were never picked up. Twenty people running twenty automatic farms can put more stress on a server than one hundred people waiting in queue.

Minecraft gives each tick 50 milliseconds, enough for 20 ticks a second. Go over that budget and the game can't keep up. The world slows down for everyone at the same time. Players get pulled back to where they stood a second ago. It takes a while for blocks to break, and monsters move very slowly.

Experienced hosts start with the config, not the machine. They pick the server software, RAM, view distance and simulation distance before the first player joins. There are times when a few chunks less simulation distance is better than double the memory because less of the map stays active around each person.

From lockstep to client-server

P2P lockstep was the initial method for networked games. All the machines were running the same simulation, and the only data transmitted over the network were the commands given by each player. All machines had to wait for the slowest one to finish processing before moving on to the next stage, and bandwidth remained modest. Due to the large number of units involved (often thousands) and the difficulty of synchronising them individually, this method is still commonly used in real-time strategy games.

That kind of delay is just not feasible for action games. On a local network, Doom ran smoothly, but when played online, even a single slow connection would slow everyone down. Quake changed direction in 1996 by moving to a client-server model. Each player now only depended on their own connection to the server, and people could join or leave a match in progress, which lockstep makes very difficult.

Concentration is the price tag for that design. The entire simulation is now executed by a single machine that receives all inputs and responds to all clients. The actual cap on players is whatever it can do in one tick.

How large servers avoid sending everything to everyone

Large multiplayer games survive by being picky. The main technique is interest management: the server only tells each player about things near them or relevant to them. A hundred players spread over a big map might each care about five or six others at a time, which shrinks that squared curve back down. On a small, dense world, this advantage goes away completely. Everyone is important to everyone else when twenty players are squished into one base.

The second tool is the update rate. Every time an input comes, the server doesn't need to provide a new snapshot. It can handle inputs on a predetermined timetable and let clients fill in the blanks by drawing other players slightly in the past and smoothing out known positions. A delay of about 100 ms on other players usually goes unnoticed. Combine that with client-side prediction for your own character, and the game feels lightning fast even though the server is moving at a more leisurely speed.

The third method involves dividing the population. So that no one process is responsible for handling the entire world, shards, instances, zones, and region servers all work together to divide the load. The player perceives it as a singular location. Multiple machines are working together behind the scenes.

Why small private servers fall over

Hobby servers often fail for the opposite reasons. There are a lot of mods and plugins that make every tick more work, and interest management isn't used very often. They run on general hosting with the default settings. A lot of people also raise the view distance because they think it looks good.

Hardware still matters, just not the way most people think. Many game servers do most of their work on one main thread, so a fast processor with quick memory access often beats a machine with more cores. A small computer with a modern CPU and a light modpack will usually do better than a large computer with a heavy modpack.

Count the farms before you count the players

Identify the chunks and entities that consume the greatest time. Instead of counting how many are online, you should count what they have made. Trim the simulation, be stricter about what gets sent to whom, and a server that struggled with twenty people can often carry far more without anyone noticing.