Game Server Slot Planning: Tick-Time Cliffs, Working-Set Growth and Network Fan-Out

Slot count is the number game server operators quote and the number they least understand. A 100-slot Rust server and a 100-slot Minecraft server consume hardware in completely different proportions, and both behave differently at 30 players than at 90. This article works through the three pressure points that actually decide how many players a box holds — the tick-time cliff, the growing working set, and network fan-out — with the measurements you can take to find each one on your own hardware.

The Three Budgets Every Slot Depends On

Every multiplayer server has a CPU budget, a memory budget, and a network fan-out budget. Slots are capped by whichever runs out first, and that changes as the server fills: a server CPU-bound at 40 players may become memory-bound at 60 and network-bound at 80. Sizing by the vendor’s advertised slot count is guesswork; sizing by the binding constraint at your expected peak is engineering. Write down all three numbers at 25%, 50%, 75%, and 100% of target players — the load test below produces them in one evening.

Tick-Time Cliffs: Why Load Is Not Linear

Tick time does not rise smoothly with player count. It stays nearly flat through low and moderate load, then rises steeply once a threshold is crossed. The mechanism differs by engine but the shape is consistent: somewhere around 60–75% of the theoretical maximum, the work per tick starts to include contention — lock waits, garbage collector pressure, entity-list scans that cross a cache boundary, or network send queues that no longer drain within the tick window.

Two consequences follow. Headroom is not proportional to capacity: a server at 40% tick utilisation can take 20% more players, while one at 80% may collapse with five more. And the cliff moves — adding a mod, enabling a plugin, or growing the world shifts the threshold downward, which is why a server that held 60 players last month may struggle at 45 today. Measure it by recording tick duration at each player milestone during a load test and plotting it; the point where the slope turns steep is your practical slot ceiling, not the point where the server crashes.

Working-Set Growth and the Memory Plateau

Memory is the budget most often misread, because working set grows with players for reasons unrelated to leaks: per-player structures, entity tracking tables, chat buffers, and anti-cheat state all scale with count. A healthy server rises with players then plateaus; a leak keeps climbing after the count stabilises. If memory plateaus at 6 GB with 80 players on an 8 GB instance, you have 2 GB for the OS, file cache, and save peaks — thin but workable. If it climbs 200 MB per hour regardless of players, more RAM only delays the restart.

For Java-based servers, set a heap ceiling and watch the relationship between heap used after GC and players online. For native servers such as Rust and CS2, sample the process working set and private bytes from PerfMon or Get-Process on a one-minute interval. For ARK, expect substantially higher per-player memory than the others; it is the outlier in this comparison and should be sized separately.

Game	Primary slot constraint	Typical per-player CPU	Notes
Minecraft Java	Single-thread tick time	Moderate, spiky with chunk loads	Heap ceiling and GC pauses dominate late-game
Rust	Entity AI + memory	High during raids and large bases	Wipe size materially changes the cliff
ARK	Memory, then CPU	High	Dino and structure counts compound
CS2	Bandwidth and tick	Low per player	Fan-out, not CPU, is usually binding

Network Fan-Out: The Quadratic Part

Network cost scales with the square of player count, not linearly. Each player’s state must reach every other player in view range, so doubling the population roughly quadruples aggregate outbound volume. That is why a CS2 server can saturate a gigabit NIC long before its CPU is busy.

The practical numbers: a 64-tick CS2 server with 20 players uses a modest fraction of a gigabit link, but at 100 players the outbound traffic and packet rate climb steeply, and the per-packet overhead starts to matter as much as payload. For survival games the rate is lower but the update size larger. Measure egress in Mbps and packets per second, not just total monthly bandwidth — a provider that meters only monthly transfer will happily sell you a link that saturates under load.

Fan-out is also where tickrate and bandwidth interact: doubling the rate from 64 to 128 roughly doubles update frequency, and the CPU may cope while the link does not. Check both before promising a higher rate.

Planning Slots From Measurements

1. Run a staged load test at 50%, 75%, and 100% of target players with a realistic world and mod set.
2. Record tick time, working set, CPU per core, egress Mbps, and packets per second at each stage.
3. Find the tick-time knee and take 75% of that player count as your advertised slot ceiling.
4. Confirm the working set at that count leaves at least 20% of RAM free for OS and save peaks.
5. Confirm egress at that count leaves 40% of the link unused for DDoS scrubbing and bursts.
6. Re-test after every major content update, because the cliff moves with content.

Selling 100 slots because the engine supports 100 and the RAM calculator said so is how operators end up refunding subscriptions in month two. Selling 75 slots on a server that stays smooth at 90 is how they keep them. The hosting team can review throughput and link characteristics for your plan if the fan-out calculation is close to the edge.

What Changes When You Scale Up

Moving from a 40-slot to a 120-slot server is not a matter of adding RAM. The tick-time cliff means per-core clock matters more than core count, and most game engines do not parallelise the main simulation loop. A CPU with fewer, faster cores frequently outperforms one with many slow cores for this workload, which is the opposite of the choice you would make for a web server.

Beyond a single box, the standard escape hatch is sharding: separate worlds or map instances on separate processes, each with its own tick loop, connected through a proxy. This trades global interaction for linear scaling and is the right answer for large communities running multiple maps. It also raises the operational cost of backups and player transfers, so it is worth doing only after a single well-tuned instance genuinely hits its ceiling.

The Summary Numbers

For rough capacity planning, treat these as starting points and verify with your own load test: a single Minecraft instance at 20–40 players on 4 dedicated vCPU threads with 8 GB RAM; Rust at 80–150 players on a high-clock 6–8 core node with 16–32 GB; ARK at 20–50 players per map with memory ahead of CPU; CS2 at 20–40 players per instance at 128 tick, limited more by fan-out than by compute. Everything above that is sharding.

Hardware that suits the first three numbers lives on a dedicated game server platform with high clock speeds, where per-core performance and a non-contended network path are the two specs that decide whether the cliff arrives at 70 players or at 45.