View distance и другие настройки анти-лага

MAATRIX GAMES

Сервер лагает, TPS проседает при заполнении, а апгрейд тарифа кажется единственным выходом — но часто хватает одной настройки. Дальность прогрузки мира вокруг игрока — это чаще всего самый жирный потребитель CPU и RAM на игровом сервере, и именно её первой стоит крутить, прежде чем нести деньги за более мощный тариф. Разберём, что это за параметр, чем он отличается от «дальности видимости» в настройках графики клиента, и как найти значение, при котором сервер не захлёбывается, а игроки не жалуются на «стены тумана» в двух шагах.

Что вообще значит «прогрузка мира» для сервера

Когда игрок заходит на сервер, движок не держит в памяти и не считает весь мир целиком — это было бы избыточно даже для небольших карт. Вместо этого сервер работает с зоной вокруг каждого игрока: подгружает нужные куски ландшафта (в Minecraft это чанки 16×16 блоков, в других играх — ячейки сетки, регионы или просто объекты в радиусе), держит их в памяти и на каждом тике пересчитывает всё, что в этой зоне происходит — физику, AI мобов и NPC, рост растений, поведение объектов, сетевые пакеты для клиента.

Ключевой момент: зона считается для *каждого* игрока отдельно, а зоны разных игроков объединяются в общую активную область сервера. Если десять игроков разбрелись по разным уголкам карты, сервер держит в памяти и тикает десять отдельных областей одновременно — это самый частый сценарий, когда небольшой прирост радиуса даёт непропорционально большой рост нагрузки. Площадь круга растёт как квадрат радиуса: увеличение дальности прогрузки с 8 до 12 условных единиц — это не рост на 50%, а рост площади почти в 2,3 раза. Именно поэтому view distance — один из самых эффективных рычагов производительности: маленькое движение ползунка ощутимо разгружает CPU.

View distance и simulation distance — это не одно и то же

Здесь часто путаются даже опытные админы. В играх, где это разделено на два параметра (ярче всего это видно в Minecraft начиная с версии 1.18), речь идёт о двух разных вещах:

• View distance (дальность прогрузки/видимости) — сколько чанков сервер отправляет клиенту для отрисовки. Это в первую очередь нагрузка на сеть и память под хранение данных чанка, а не на CPU напрямую.
• Simulation distance (дальность симуляции) — в каком радиусе сервер реально считает логику: тикает мобов, respawn, рост урожая, работу редстоуна, физику жидкостей. Это и есть основной потребитель CPU.

В server.properties ванильного Minecraft-сервера (и в Paper/Spigot-сборках) это два отдельных параметра:

view-distance=10
simulation-distance=10

Простое, но нередко упускаемое решение: если у вас RAM и сеть не проблема, а «горит» именно CPU (низкий TPS при полном онлайне), можно оставить view-distance повыше ради визуального комфорта, а simulation-distance просадить сильнее — игроки почти не заметят, что мобы чуть дальше от них не тикаются активно, а сервер вздохнёт свободнее. На Paper-сборках это можно тонко настроить ещё точнее — на уровне мира через paper-world-defaults.yml, вплоть до отдельного view-distance по конкретным мирам (например, меньше на нижнем мире/аду, где обычно фармят и толпятся, чем на надмирье). Подробный разбор именно TPS и модов в Minecraft — в отдельной статье про оптимизацию модов и TPS на Minecraft-сервере, здесь мы говорим про общий принцип, применимый шире.

Как это устроено в других играх

Не у всех игр есть настолько явное разделение на два ползунка, но сам принцип «радиус вокруг игрока = нагрузка» работает почти везде, где есть открытый мир и множество игроков.

В играх Arma-family и DayZ дальность прорисовки для клиентов ограничивается именно на стороне сервера — в serverDZ.cfg у DayZ есть параметр viewDistance, который жёстко ограничивает максимальную дальность прорисовки, которую клиент может выставить себе сам. Это одновременно и инструмент анти-чита (не даёт вскрывать снайперов на нечестной дальности через модифицированный клиент), и рычаг производительности — чем больше объектов и террейна видит и симулирует сервер для каждого клиента, тем тяжелее серверу. Точные дефолтные значения и максимумы отличаются от версии к версии, поэтому сверяйтесь с актуальным конфигом своей сборки, а не с цифрами из старых гайдов.

У игр на движках Source и Unreal (CS2, Rust, ARK, 7 Days to Die и подобные) единого параметра «view distance» в конфиге сервера обычно нет — вместо этого нагрузку регулируют через другие рычаги: частоту сетевых обновлений (network update rate), радиус активации AI у мобов/NPC, лимиты на количество одновременно заспавненных существ и объектов, дальность, на которой сервер вообще утруждает себя расчётом физики для брошенного лута или построек. Логика та же самая — «не считай то, что далеко и не важно прямо сейчас», просто реализована россыпью отдельных настроек, а не одним ползунком. Если видите в конфиге своей игры параметры вроде render distance, streaming distance, LOD distance, spawn distance или activation range — это ровно тот же принцип анти-лага, просто под другим именем.

Почему именно этот параметр так сильно влияет на производительность

Три причины, по которым срезание дальности прогрузки — один из первых шагов в оптимизации, а не последний:

1. Квадратичный рост нагрузки. Как уже сказано выше, площадь зоны растёт как квадрат радиуса. Уменьшение радиуса даже на 20-30% ощутимо снижает объём работы для CPU.
2. Умножение на число игроков. Зона считается для каждого игрока отдельно (с пересечением там, где игроки рядом), поэтому эффект от изменения дальности растёт вместе с онлайном — на сервере с 5 игроками экономия не так заметна, как на сервере с 30+.
3. Каскадный эффект на AI и физику. В большой зоне симуляции больше мобов/NPC одновременно активны и «думают» — считают пути, реагируют на игрока, взаимодействуют друг с другом. Отключение или замедление AI за пределами нужного радиуса часто даёт больше прироста TPS, чем можно ожидать от одной цифры в конфиге.

Как подобрать значение — пошагово, без гаданий

Универсального «правильного» числа не существует — оно зависит от типа игры, модпака/плагинов, железа тарифа и вашей аудитории. Рабочая методика:

1. Зафиксируйте точку отсчёта. Запустите мониторинг TPS/лагов (см. отдельную статью про мониторинг TPS и лагов на игровом сервере) при текущих настройках и типичном онлайне — это ваша база для сравнения.
2. Снижайте постепенно, не резко. Шаг вниз на 1-2 единицы (для Minecraft — с 10 до 8, потом до 6), а не сразу в пол. После каждого шага дайте серверу поработать под реальной нагрузкой хотя бы час-два, а не 5 минут в одиночестве.
3. Тестируйте под реальным онлайном, не в одиночку. В пустом мире почти любые настройки покажут отличный TPS — проблема вылезает именно при заполнении сервера, особенно если игроки скучиваются в одной точке (спавн, ивент, база гильдии).
4. Разделяйте, где можно, view и simulation. Если движок позволяет (как Minecraft), не режьте оба параметра одинаково — начните с симуляции, она дороже для CPU, чем чистая прогрузка для отрисовки.
5. Спрашивайте игроков, а не только смотрите на графики. «Стены тумана» и внезапно появляющиеся из ниоткуда мобы/постройки — реальная жалоба игроков, даже если TPS в графиках идеальный. Баланс — это компромисс между метриками сервера и субъективным комфортом.
6. Зафиксируйте финальные значения в конфиге и бэкапе настроек, чтобы не потерять их при следующем обновлении сборки — подробнее о работе с конфигами в статье про работу с конфигурационными файлами игрового сервера.

Соседние настройки анти-лага, о которых стоит знать

View/simulation distance редко работают в одиночку — вот с чем их обычно комбинируют:

Общий смысл всей этой группы настроек один: не тратить процессорное время и память на то, что игрок физически не может увидеть или на что не повлияет прямо сейчас. Если у вас уже настроен базовый анти-лаг через view/simulation distance, но нагрузка всё ещё высокая под пиковым онлайном — посмотрите общий разбор в статье про оптимизацию сервера под высокую нагрузку, там разобраны смежные рычаги вроде лимита тикрейта и распределения потоков.

Типичные ошибки при настройке

• Резать дальность вслепую, ориентируясь на чужие «оптимальные» цифры из интернета. Значение, которое отлично работает на модпаке с 40 модами, может быть избыточно щедрым (или наоборот, слишком жёстким) для вашей сборки — тестируйте на своём конфиге, а не копируйте цифры из чужого гайда.
• Путать серверную настройку с клиентской. У части игр «render distance» в настройках графики клиента — это чисто визуальный параметр, который сервера вообще не касается. Экономию CPU/RAM даёт только серверная сторона (view/simulation distance, activation range и т.д.), а не то, что игрок выставил себе в графике.
• Не пересчитывать лимит игроков после изменения настройки. Снижение дальности прогрузки часто позволяет поднять максимальное число слотов без потери TPS — если вы не пересматриваете лимит после оптимизации, недополучаете выгоду. Как пересчитать разумный лимит под тариф — в статье про лимит игроков на сервере.
• Забывать, что RAM и CPU — разные ресурсы. Уменьшение view distance в первую очередь снижает потребление RAM и сети, а вот главный вклад в CPU-нагрузку даёт именно simulation distance и всё, что с ним завязано (AI, тики). Если у вас упирается конкретно CPU, а не память — не удивляйтесь, что урезание одного view distance почти ничего не дало.
• Менять настройку во время активного онлайна без предупреждения. Резкая смена дальности прогрузки на живом сервере может на несколько секунд подвесить генерацию/подгрузку зон у всех сразу — лучше применять через рестарт по расписанию, а не «на живую».

Частые вопросы