Перейти к содержимому

How my MMO can do 300,000 players in a single chunk on a single core by doing nothing

Ygg Engine

0:00 / 0:00

How my MMO can do 300,000 players in a single chunk on a single core by doing nothing

817 просмотров · 2 месяца назад
Ygg Engine
141 подписчик
817 просмотров · 2 месяца назад
I have utterly defeated O(N^2) by doing nothing. A treatise in the discipline of not doing unnecessary work . Dense is a high-density multiplayer state engine (one host, one process, one simulation thread, no sharding, no distributed workers) C/C++ 100 ticks for 10,000 players at 20hz in 50ms and 10% of 1 Ryzen 5600x Core Python binding 100 ticks for 10,000 players at 20hz in 96ms and 10% of 1 Ryzen 5600x Core Repo: Dense / libdense_sim / DenseDB https://github.com/libdense/libdense Book: Dense-Region MMO Server Architecture https://www.amazon.com/dp/B0H86L5Y1B The goal is not to do bad work faster. The goal is to stop doing unnecessary work. The basic fanout formula: updates_per_second * receivers_per_update = delivered_messages_per_second For dense player movement, receivers scale with density, so: players * update_rate * nearby_receivers = delivered_messages_per_second And in a dense region, nearby_receivers is approximately players, which is how you arrive at the quadratic: delivered_messages_per_second ~= players^2 * update_rate The example that should scare you 100 players * 20 updates/sec * 100 receivers = 200,000 delivered updates/sec Two hundred thousand deliveries per second is already serious, but it is achiev- able. Now scale the crowd by five: 500 players * 20 updates/sec * 500 receivers = 5,000,000 delivered updates/sec Five hundred dense players is not merely 5x harder than one hundred dense players. Under naive replication it is closer to 25x harder, because both the number of producers and the number of receivers grew together. Every doubling of crowd size quadruples the delivery workload. This is the single most important piece of arithmetic in MMO server design.