A dedicated game host advertising “300 player slots” is telling you about a config file limit, not about capacity. The number that matters is concurrent players, and the ratio between the two is set by the game, the session length, and the timezone spread of your audience. A survival server with 300 slots might see 60 concurrent at peak; a competitive shooter with 300 slots might see 280. Sizing hardware to the slot count instead of the concurrent count is the most common way people buy twice the server they need, or half of it.
Work backwards from the tick. At 20 TPS the server has a 50ms budget per tick; at 30 TPS it has 33.3ms; at 64 TPS (many FPS titles) it has 15.6ms. Everything the server does — entity AI, physics step, chunk generation, network serialisation — must fit inside that window, and if it does not, the tick stretches and every player sees it as rubber-banding.
Before buying, measure one thing: the server-side tick time at your realistic concurrent count, not at slot count. Spin up the map on a trial box, join n simulated clients, and read the tick time from the profiler. On Minecraft with Paper, /tps and the timings report give you the split; on Source-engine titles, stats and net_graph show server frame time. If you cannot get within 30% of a 50ms tick at your target concurrency, the spec is wrong regardless of what the dedicated game server plans label says.
CPU-bound versus RAM-bound
Most game servers are single-thread bound. The main game loop runs on one core, and adding cores past 4–6 does little for a single world; it helps when you run multiple instances or offload world generation to worker threads. That is why a 3.5GHz 6-core often beats a 2.4GHz 16-core for a single Minecraft world, and why an EPYC with 32 cores at 2.8GHz can be a downgrade for a Rust server.
RAM is the other axis, and it is less forgiving. Too little RAM means GC pauses, chunk thrash, or OOM kills; too much is wasted money. The per-player baseline below is a planning figure for a fresh world with default view distance — mods, plugins, and larger view distances multiply it.
| Game family | RAM per concurrent player | Base + OS | Notes |
|---|---|---|---|
| Vanilla Minecraft (16 chunks) | 12–20 MB | 2.5 GB | GC pressure above 60 players |
| Modded Minecraft (200+ mods) | 60–120 MB | 6 GB | Strongly CPU-bound on world gen |
| Rust (vanilla) | 45–70 MB | 8 GB | Tick 30Hz, entity heavy |
| Source-engine FPS (64 tick) | 8–14 MB | 1.5 GB | CPU-bound at ~24 players per core |
| ARK / Conan Exiles | 80–150 MB | 10 GB | Dino/entity count dominates |
| Palworld dedicated | 40–60 MB | 8 GB | Memory grows with base count |
Slots versus concurrency in practice
Assume a 300-slot survival server with a 15% peak concurrency ratio: 45 concurrent players. At 20 MB each that is 900MB of player state plus 2.5GB base, so 4GB of RAM is the floor and 8GB gives headroom for world gen and backups. CPU-wise, one world at 45 players needs roughly two dedicated cores at 3.2GHz or better, plus two for the OS, backups, and any web map.
Now run the same server at 60% concurrency — 180 players, which happens on launch day and after any streamer mentions you — and RAM climbs to 3.6GB of player state, world gen spikes, and the main tick thread saturates. The hardware did not change; the ratio did. Plan for the ratio you will hit on your best day, not the average day.
The 50ms budget, itemised
On a healthy 20 TPS server the 50ms tick is spent roughly like this: entity AI 20–24ms, physics 8–12ms, network serialisation 5–8ms, chunk loading 2–6ms, and the remainder on plugin hooks and I/O. When the entity count doubles, AI and physics scale near-linearly and the tick exceeds 50ms before RAM becomes a problem. This is why a box with 64GB and a slow core performs worse than 32GB and a fast one.
Watch for the tell: TPS drops from 20.0 to 19.4, then 18.2, then a death spiral where the server runs the tick late and player movement desyncs. Check mspt (milliseconds per tick) rather than TPS alone — MSPT at 45ms is warning, 48ms is critical.
Network is usually not the bottleneck
A 64-tick Source server sends about 20–40 KB/s per player; 64 players is under 3 Mbps. Minecraft is similar or lower. You do not need a 10Gbps port for a single game world; you need low jitter and a port that is not congested at peak. The practical requirement is 1Gbps with unmetered or generous transfer, plus a location close to players: 120ms of latency ruins a shooter no matter how fast the CPU is.
Bandwidth becomes relevant when you run many instances, serve mod packs, or host a cluster behind a proxy. Account for mod-pack downloads: a 4GB pack downloaded by 200 new players in an hour is 800GB, which will blow through a metered plan.
Sizing table you can act on
| Concurrent players | Cores (all-core clock) | RAM | Storage |
|---|---|---|---|
| Up to 20 | 2 @ 3.5GHz | 4 GB | 80GB NVMe |
| 20–50 | 4 @ 3.5GHz | 8 GB | 160GB NVMe |
| 50–100 | 6 @ 3.6GHz | 16 GB | 320GB NVMe |
| 100–200 | 8 @ 3.8GHz | 32 GB | 500GB NVMe |
| 200+ (or multi-instance) | 12+ @ 3.8GHz | 64 GB | 1TB NVMe |
What to buy for a single large world
Single world, single instance: prioritise clock speed over core count, buy 2× your measured RAM, and put the world on NVMe with a daily off-box backup. Multi-instance or multi-game: core count matters more, and you want enough RAM to pin each instance without swap. Either way, leave 25% CPU headroom for backups, world saves, and the spike after a content update.
Size from measured MSPT and concurrent players, and the slot count stops mattering. If you need a box that holds a 50ms tick at 150 concurrent, pick hardware by measured tick time rather than by slot count.
Leave a Reply
You must be logged in to post a comment.