Project Zomboid лагает на большом открытом мире

MAATRIX GAMES

Полгода назад сервер держал шестерых игроков без единой просадки, а сейчас с теми же четырьмя онлайн периодически подвисает на секунду-другую, особенно когда кто-то телепортируется домой или заходит после долгого отсутствия. Первая мысль — "мало ресурсов", но апгрейд тарифа часто не решает проблему, потому что дело не в количестве людей, а в том, сколько карты они успели разведать и насколько далеко раскидали свои базы. Разберём, почему это работает именно так, и что реально можно подкрутить, прежде чем нести деньги за более мощный VPS.

Почему разведанная территория весит больше, чем онлайн

Project Zomboid не считает весь остров целиком каждый тик — это было бы бессмысленно тяжело даже для одиночной игры. Вместо этого сервер держит "горячими" только клетки карты (сетка примерно 300×300 тайлов), которые хотя бы раз попадали в зону видимости игрока: там симулируются зомби как полноценные сущности, считается физика, обрабатываются звуковые события, которые могут привлечь толпу.

Проблема не в самом факте разведки, а в том, как она распределена. Если четверо игроков сидят компактно в одном городке, сервер держит одну активную зону, пусть и с довольно широким радиусом. Если те же четверо разъехались на машинах в разные стороны острова и обустроили базы за десятки клеток друг от друга — сервер вынужден одновременно тикать четыре независимые зоны вместо одной, причём движок Zomboid в критичных для симуляции местах (обработка зомби, звук, AI) работает по сути в один поток. Больше разрозненных активных зон — больше последовательной работы на каждый тик, и апгрейд числа ядер тут почти не помогает, в отличие от роста тактовой частоты.

Отдельно стоит различать два симптома, которые легко перепутать:

• Плавное проседание TPS весь день — это обычно про суммарный объём разведанной и посещаемой территории, накопленный за недели игры.
• Резкий фриз на секунду-две в конкретный момент — почти всегда про загрузку конкретной удалённой клетки при телепортации, быстром перемещении на машине или заходе игрока рядом с давно не посещённой базой.

Про то, как вообще устроена загрузка мира вокруг игрока и почему радиус так сильно бьёт по CPU — общий принцип разобран в статье про view distance и другие настройки анти-лага; в Zomboid он проявляется не через отдельный ползунок, а через саму механику клеток и популяции зомби.

PlayerSafehouse и разброс баз по карте

Клейм безопасного дома (Claim в меню строительства, требует прожитых на сервере дней и обычно ключ или журнал в зависимости от настроек) сам по себе не бесплатен для производительности — это отдельная зона, которую сервер обязан держать активной и защищённой от респавна зомби внутри периметра, пока клейм жив.

Логика в SandboxVars.lua завязана на несколько связанных переменных:

PlayerSafehouse = true              -- разрешить клейм безопасных домов игроками
SafehouseAllowTrepass = false       -- пускать ли чужих внутрь периметра
SafehouseAllowFire = false
SafehouseAllowLoot = false
SafehouseDaySurvivedToClaim = 1     -- сколько дней прожить перед клеймом

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

Практический вывод для админа: если компания жалуется на лаги и при этом каждый застолбил себе отдельный домик за пределами общей базы — предложите объединиться в один-два компаунда вместо восьми одиночных точек. Это не запрет, а разговор с игроками: сервер физически легче тянет одну плотную зону, чем россыпь далёких друг от друга форпостов, даже при одинаковом общем онлайне. Заброшенные сейфхаусы игроков, которые давно не заходят, тоже стоит периодически освобождать через админ-команду /releasesafehouse — иначе они продолжают числиться заклеймленными и путают статистику по разведанной территории.

WorkshopItems: моды расширяют не только контент, но и территорию

Отдельный источник разброса активных зон — моды с новыми картами и локациями (крупные оверхолы вроде добавления новых городов или регионов). Каждая такая точка интереса на модовой карте — это ещё одна зона, которую игроки рано или поздно разведают и застолбят, и сервер обязан её тянуть так же, как ванильную территорию.

Список модов задаётся в servertest.ini:

WorkshopItems=2727579637;2694001598
Mods=BrutalHordes;TrueMusicMod

Подробно про синтаксис WorkshopItems/Mods, синхронизацию ID и типичные ошибки при подключении разобрано в статье про установку модов через Steam Workshop — здесь важнее сам принцип: если сервер начал заметнее лагать после того, как компания распробовала недавно добавленный мод с новой картой, проблема может быть не в самом моде как коде, а в том, что игроки резко расширили географию своих вылазок. Проверить гипотезу просто — на время отключите доступ к новой локации (или временно уберите тяжёлый map-мод из WorkshopItems/Mods и перезапустите сервер) и сравните поведение TPS за пару дней. Если полегчало — дело в территории, а не в скриптах самого мода.

Зомби и предметы в проблемных клетках

Даже без разброса баз отдельные клетки могут стать "тяжёлыми" сами по себе — обычно это места с высокой плотностью зомби (крупный город, торговый центр) или места, где компания годами складывает лут на пол вместо контейнеров.

Плотность зомби регулируется в том же SandboxVars.lua:

ZombieConfig = {
    Population = 3,   -- ниже значение — меньше зомби, которых сервер тикает как полноценные сущности
}

RespawnHours = 72          -- как часто пересоздаётся популяция в клетках без игроков
RespawnUnseenHours = 16    -- порог "давно не видели" перед пересозданием

Если весь остров играть тяжело для одной проблемной локации типа большого города — жёстко снижать Population глобально не обязательно, можно временно почистить конкретную орду вручную через RCON или консоль сервера командой /players и точечными действиями администратора рядом с проблемной точкой, а не трогать баланс для всей карты.

Второй источник нагрузки в конкретных клетках — накопление предметов. Формального ползунка "MaxItems" в базовых SandboxVars нет, но это реальная и хорошо знакомая админам Zomboid проблема: если компания годами складывает добычу на пол одной комнаты вместо того, чтобы раскладывать по контейнерам, движок вынужден просчитывать и рендерить огромный список объектов каждый раз, когда эта клетка загружается заново — и именно такие тайлы чаще всего дают тот самый секундный фриз при заходе в дом. Рабочее решение здесь не техническое, а организационное: заведите на базе несколько отдельных контейнеров (шкафы, ящики, полки) вместо одной кучи на полу, и периодически сжигайте явный хлам в бочке — это не магия конфига, а обычная гигиена базы, которая заметно снижает вес самой тяжёлой клетки на карте.

CPU важнее числа ядер: что реально имеет смысл апгрейдить

Раз симуляция зомби, звука и физики в Zomboid критично завязана на один поток, добавление ядер VPS почти не ускоряет именно эту часть — сервер просто не умеет параллелить одну игровую сессию по ядрам так, как это делают некоторые другие движки. Больше смысла в тактовой частоте одного ядра: два быстрых ядра почти всегда лучше восьми медленных для одного мира Zomboid.

Ориентир, когда стоит задуматься об апгрейде именно под разросшуюся карту, а не под новых игроков:

Общие принципы подготовки сервера к нагрузке — лимиты ОС, сетевые буферы, баланс автосохранений — подробно разобраны в статье про оптимизацию сервера под высокую нагрузку; для Zomboid они применимы без изменений, разве что приоритет по железу смещён в сторону частоты CPU, а не количества ядер.

Как отличить это от других причин лага

Прежде чем что-то трогать, стоит убедиться, что причина именно в территории, а не в чём-то более прозаичном — сетевых проблемах у конкретного игрока, нехватке RAM или тяжёлом моде-скрипте, который лагает независимо от карты.

Быстрая проверка через htop на сервере покажет, упирается ли процесс ProjectZomboid64 в CPU (колонка %CPU стабильно у потолка одного ядра) или в память (растущий RES, см. отдельный разбор в статье про переполнение памяти сервера Project Zomboid, если картина больше похожа на постепенный рост RAM, а не на CPU-затык при телепортации).

Практический тест на территорию: попросите всех игроков временно собраться в одной точке (например, на общей базе) и понаблюдайте за поведением сервера полчаса. Если лаги заметно утихли по сравнению с тем, что было при разъезде по разным углам карты — гипотеза подтверждена, дальше работайте именно с разбросом баз и проблемными клетками, а не гоняйтесь за призрачной "утечкой" в коде. Более системный подход к диагностике TPS и лагов, включая разграничение сетевых проблем и серверных, — в статье про мониторинг TPS и лагов на игровом сервере.

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