If you compare everyone against everyone to work out who can see whom, 10 times the players means 100 times the computation.
Why Every character’s distance is checked against every other character, or, even with a grid, hundreds of players crowd around one cell → Effect About 10,000 comparisons for 100 players, about 1 million for 1,000 → On screen Ticks spike where crowds gather, such as world bosses and sieges: slow motion, stutter
Split the world into a grid or regions and compare only nearby entities, update distant entities less often, cap how many players one player can see.
Ballpark numbers
If a distance check plus the update to the visible and not-visible lists takes 0.1 µs (one ten-millionth of a second) per pair of players, 1,000 players (about 1 million pairs) cost 100 ms per tick. That’s twice the 20-tick budget (50 ms).
On the graph
Rises with load · Server tick time, players gathered in one place
Where to look
Player count and tick time per zone/channel on the same graph, plus the time spent on AOI calculation within the tick, measured separately. Without a separate measurement, per-function CPU share of the game process from perf top -p
Confirmed if
When the number of players in one place doubles, tick time grows nearly 4 times, and view range and distance functions take most of the CPU time
Ruled out if
Tick time grows in proportion to player count, or send and serialization functions take a large share: points to “Broadcast fan-out overload” or serialization and compression cost
Replication Graph in Unreal EngineEpic Games The default approach of checking every connection for each actor becomes a server CPU bottleneck with many players and actors; MMORPGs and similar games split the world into a grid and reuse per-cell lists