7 Days to Die лагает при большой орде зомби

MAATRIX GAMES

Весь день сервер держит стабильный тик, а как только на седьмую ночь приходит орда — начинается: движения зомби подтормаживают, выстрелы регистрируются с задержкой, игроков подкидывает на месте. Знакомая картина почти для любого сервера 7 Days to Die с активным онлайном. Хорошая новость — это не значит, что тариф пора менять на более мощный. Почти всегда дело в паре параметров serverconfig.xml, которые никто не трогал со времён первого запуска, и в железе, которое просто не заточено под то, как эта игра считает AI.

Почему именно Blood Moon кладёт сервер

В обычную ночь зомби спавнятся по одному-два в зоне видимости игрока, бродят, иногда агрятся на шум. Во время кровавой луны логика меняется полностью: игра включает специальный режим спавна, который целенаправленно гонит толпу зомби к каждому игроку, причём независимо для каждого — если на сервере восемь человек разбрелись по карте, движок ведёт восемь параллельных орд одновременно, и это восемь наборов pathfinding-расчётов, восемь зон агро, восемь очередей спавна.

Хуже того, орда не просто идёт по прямой — на каждом шаге для каждого зомби пересчитывается путь до цели с учётом рельефа, построек и препятствий, которые вы сами же настроили в базе. Чем сложнее геометрия базы (лабиринты из блоков, ловушки, множество уровней), тем больше вариантов пути движок перебирает. Это CPU-нагрузка в чистом виде, и она растёт не линейно, а гораздо резче — удвоение числа одновременно активных зомби на практике ощущается сервером как рост нагрузки в разы, а не в два раза.

Отсюда практический вывод: чинить лаги на Blood Moon нужно с трёх сторон одновременно — сколько зомби спавнится, как быстро они двигаются и на каком железе всё это считается. По отдельности каждая мера даёт скромный эффект, вместе — обычно хватает, чтобы orda перестала укладывать тикрейт.

BloodMoonEnemyCount: сколько зомби спавнить на игрока

Ключевой параметр — BloodMoonEnemyCount в serverconfig.xml. Он задаёт максимум одновременно живых зомби орды *на одного игрока*, по умолчанию — 8:

<property name="BloodMoonEnemyCount" value="8"/>

Если на сервере регулярно играет 6-8 человек одновременно, дефолтные 8 зомби на игрока в пике дают полсотни-под-сотню активных мобов разом — и это без учёта обычного фонового спавна и животных. Для серверов, где производительность важнее плотности орды, разумно снизить значение до 4-6: волна станет заметно реже по плотности, но не потеряет смысл как испытание. Держать больше 10-12 стоит только если у вас действительно мощное железо и небольшой онлайн — рост нагрузки от этого параметра практически экспоненциальный, а не пропорциональный.

Важно: BloodMoonEnemyCount можно менять между сессиями без вайпа мира — правите XML и перезапускаете сервис, значение подхватится к следующей орде.

MaxSpawnedZombies и MaxSpawnedAnimals — общий потолок сервера

Отдельно от per-player лимита орды есть глобальный потолок — MaxSpawnedZombies, по умолчанию 64. Это максимум зомби, которые вообще могут существовать на сервере одновременно, включая и обычный фоновый спавн, и орду Blood Moon:

<property name="MaxSpawnedZombies" value="64"/>
<property name="MaxSpawnedAnimals" value="50"/>

На время орды именно этот параметр часто оказывается узким местом сильнее, чем BloodMoonEnemyCount — даже если каждому игроку выделено немного зомби, суммарно по всей карте счётчик легко упирается в 64 и выше. Для серверов, где производительность в приоритете, снижайте MaxSpawnedZombies до 40-50 — разница в ощущениях от игры минимальна, а нагрузка на CPU падает заметно.

MaxSpawnedAnimals напрямую с ордой не связан, но животные тоже считаются каждый тик — на время активной орды лишние 40-50 волков и кабанов на карте только добавляют работы движку. Если сервер и так на пределе, снизьте до 25-30.

Оба параметра требуют перезапуска сервера, применяются сразу и мир не трогают.

Скорость зомби: ZombieBMMove и остальные параметры движения

В serverconfig.xml (и через игровое меню Game Settings) скорость передвижения зомби задаётся отдельно для разных ситуаций: ZombieMove — днём, ZombieMoveNight — ночью вне орды, ZombieFeralMove — для ферального состояния, и ZombieBMMove — конкретно для орды Blood Moon. Шкала одинаковая для всех: 0 — Walk (шаркающая ходьба), 1 — Jog, 2 — Run, 3 — Sprint, 4 — Nightmare (постоянный бег).

<property name="ZombieMove" value="0"/>
<property name="ZombieMoveNight" value="3"/>
<property name="ZombieFeralMove" value="3"/>
<property name="ZombieBMMove" value="3"/>

По умолчанию ZombieBMMove стоит на Sprint (3) — орда бежит на игрока максимально агрессивно. С точки зрения нагрузки бегущий зомби пересчитывает путь к цели чаще, чем идущий: больше движения за тик — больше пересчётов pathfinding на единицу времени. Разница между Sprint и Nightmare для CPU не критична (оба уже максимально активны), а вот откат с 3 на 2 (Run) или даже 1 (Jog) реально снимает часть нагрузки, хоть и меняет ощущение орды — она станет менее пугающей, но управляемой на слабом железе.

Это тонкая настройка баланса: для хардкорных серверов трогать ZombieBMMove обычно не хотят, а вот ZombieMoveNight можно смело снижать без потери духа игры — фоновая ночная активность не должна быть такой же интенсивной, как сама орда.

Частота CPU важнее числа ядер

Здесь кроется главная причина, почему апгрейд тарифа не всегда решает проблему Blood Moon. AI-логика зомби в 7 Days to Die — pathfinding, агро, поведение — считается преимущественно в один поток на объект, и большая часть этой работы упирается в один физический поток исполнения, а не распределяется равномерно по всем ядрам. Восемь виртуальных ядер по 2.4 ГГц в моменте орды часто проигрывают четырём ядрам по 3.8-4.2 ГГц — потому что игре важна скорость выполнения одного потока, а не количество параллельных.

При выборе VPS или выделенного сервера под 7 Days to Die (особенно если планируете держать активные орды на 8+ игроков) смотрите в характеристиках хостинга именно на тактовую частоту CPU, а не только на число vCPU в тарифе. Современные серверные Xeon с частотой 2.0-2.5 ГГц под высокую многопоточность неплохи для веб-нагрузки, но для 7 Days to Die выгоднее платформы на базе десктопных или полу-серверных чипов с частотой от 3.5 ГГц и разумной турбо-частотой под нагрузкой на одно ядро.

RAM для 7 Days to Die тоже важна (базово от 6 ГБ на небольшой сервер), но именно на пике Blood Moon первым упирается в потолок процессор, а не память — если во время орды растёт именно latency и просадки тика, а не своп по RAM, вы почти наверняка упёрлись в частоту CPU.

Что ещё снять с сервера на время орды

Кроме самих настроек зомби, есть операционные меры, которые снимают пиковую нагрузку:

• Дальность прогрузки мира. ServerMaxAllowedViewDistance по умолчанию 12 (диапазон 6-12) — на время орды каждый лишний прогруженный чанк это ещё и лишние объекты, которые нужно тикать. Снижение до 8-10 не убивает картинку, но заметно разгружает CPU в комплексе с настройками зомби — подробнее про этот параметр и его аналоги в других играх разбирали в статье про view distance и настройки анти-лага.
• Плановый рестарт перед ордой. Запланируйте перезапуск сервиса за пару часов до наступления Blood Moon (частота задаётся BloodMoonFrequency, по умолчанию раз в 7 дней) — это сбрасывает накопленные утечки памяти и кэши, с которыми сервер спокойнее переживает пиковую нагрузку.
• Простая геометрия баз. Лабиринты и многоуровневые ловушки увеличивают число вариантов пути для pathfinding каждого зомби. Открытая площадка с одним узким проходом — тот же challenge для игроков, но заметно легче для сервера, чем город из коридоров.
• Overhaul-моды считают тяжелее ванили. Если сервер работает на моде вроде Darkness Falls с расширенным бестиарием и AI, лимиты выше нужно снижать активнее — сравнение нагрузки от популярных сборок смотрите в статье про overhaul-моды для 7 Days to Die.
• Меняйте по одному параметру за раз. Если сразу сбросить и BloodMoonEnemyCount, и MaxSpawnedZombies, и ZombieBMMove — не поймёте, что именно помогло. Правьте один пункт, смотрите на следующей орде, при необходимости идёте дальше. Для честной диагностики, где именно сервер упирается — в CPU, в сеть или конкретно в тик — пригодится общий разбор из статьи про мониторинг TPS и лагов.

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