Sons of the Forest: лагает при большой базе/поселении игроков

MAATRIX GAMES

Первую пару часов на новом сервере Sons of the Forest всё летает: пара срубленных деревьев, шалаш, костёр. А потом проходит неделя игры, база разрастается в полноценный форт с частоколом, ловушками и десятками построек — и внезапно появляются рывки, задержка при открытии инвентаря, подтормаживание анимаций врагов рядом с базой. Это не баг конкретно у вас — это то, как движок игры реагирует на накопленный объём построенного и живого мира вокруг. Разберём, что именно жрёт тик сервера при большой базе и что с этим реально можно сделать.

Почему база, а не карта, становится узким местом

В отличие от Minecraft или Rust, где нагрузку принято мерить чанками карты или количеством игроков, в Sons of the Forest основной вклад в просадку производительности даёт не открытый мир сам по себе (он статичен и заранее просчитан), а то, что игроки добавляют поверх него: постройки, ловушки, срубленные и лежащие брёвна, трупы врагов и животных, брошенный лут. Каждый такой объект — это не просто модель на экране, а физическое тело, которое движок должен учитывать в расчётах коллизий и симуляции даже тогда, когда с ним никто не взаимодействует.

Чем плотнее застроена база, тем больше таких объектов одновременно активны в зоне, где находятся игроки. Частокол из полусотни брёвен, десяток ловушек-ям, стены и полы форта, сваленные в кучу срубленные стволы у лесопилки — всё это держится в памяти и участвует в пересчёте физики каждый кадр серверной симуляции. В играх на Unity (а Sons of the Forest построена на Unity) такая физика по умолчанию считается на одном потоке, и он же отвечает за игровую логику — здесь та же история single-thread-узкого места, что и в большинстве survival-серверов на этом движке.

Важная честная оговорка: у Sons of the Forest, в отличие от Minecraft с его view-distance или Rust с конфигурируемыми лимитами объектов, нет официального «ползунка», который бы напрямую регулировал плотность построек или количество активных физических тел. Endnight Games не документируют публично внутренний бюджет объектов на зону — поэтому дальше в статье не будет точных цифр вроде «после 200 брёвен начинаются лаги»: таких проверенных чисел нет, и любой, кто их вам назовёт, скорее всего гадает так же, как и все.

Что конкретно накапливается и создаёт нагрузку

Если разложить типичную большую базу на составляющие, нагрузку дают в первую очередь:

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

Отдельно стоит сказать про сохранения: чем больше объектов в мире, тем больше и «весит» файл сохранения, и тем дольше сервер обрабатывает его запись на диск при автосейве — об этом ниже отдельным разделом, потому что именно моменты сохранения часто совпадают с самыми заметными рывками.

Автосейв: почему рывки часто происходят именно в этот момент

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

Интервал автосохранения задаётся в dedicatedserver.cfg полем AutoSaveInterval (в секундах):

{
  "AutoSaveInterval": 300
}

По умолчанию многие держат значение в районе 60 секунд — это разумно для маленькой базы на старте, но на разросшемся поселении каждую минуту гонять запись большого сейва на диск — сомнительная идея: диск и так занят, а пауза при записи ощущается игроками как микрофриз. Что стоит сделать:

• Увеличить интервал до 180-300 секунд на активно застроенном сервере — это снижает частоту пауз ценой немного большего риска потерять прогресс при внезапном падении процесса (сервер обычно не крашится настолько часто, чтобы это было критично).
• Следить за диском. Если сервер стоит на HDD или на медленном сетевом хранилище — это первое, что стоит поменять на SSD/NVMe. Разница в длительности записи большого сейва между HDD и SSD ощутима, хотя точных цифр без замера на конкретном железе я приводить не буду — слишком зависит от размера сейва и конкретного накопителя.
• Не паниковать из-за самой паузы при сейве. Короткая заминка на секунду-другую в момент записи большого мира — нормальное поведение, не признак поломки сервера.

Что не решается настройками — и что решается

Здесь стоит быть честным: у игры нет встроенных серверных настроек для управления плотностью построек, дальностью прорисовки физики или лимитом активных объектов — в отличие от того же Minecraft, где view-distance и simulation-distance в server.properties напрямую режут нагрузку. В Sons of the Forest таких рычагов в конфиге просто нет.

Реально влияющие на производительность настройки в dedicatedserver.cfg ограничены базовыми вещами:

{
  "MaxPlayers": 6,
  "AutoSaveInterval": 240,
  "SaveSlot": 1
}

MaxPlayers напрямую влияет на нагрузку — каждый дополнительный игрок это не только его собственная симуляция, но и обычно больше строительной активности суммарно на сервере. Снижать лимит игроков ради стабильности не самое приятное решение, но иногда честнее держать 4-5 игроков стабильно, чем 8 с рывками каждую минуту.

Раз официальных лимитов построек нет, основные рычаги — это железо под нагрузку и дисциплина самих игроков в организации базы. Разберём оба пункта.

CPU и RAM: что реально нужно под большую базу

Как и в большинстве survival-игр на Unity, у Sons of the Forest узкое место — это скорость одного ядра, а не их количество. Симуляция физики построек и логика мира считаются в основном на одном потоке, поэтому сервер с 8 слабыми ядрами проиграет серверу с 4 ядрами повыше частотой. Подробнее про то, почему так устроено у большинства игровых движков, — в статье про выбор количества ядер под тикрейт.

Ориентировочные уровни (это не измеренные бенчмарки, а разумные отправные точки для планирования тарифа):

Память растёт из-за того, что движок держит в оперативке состояние всех построек, срубленных деревьев и убитых NPC в загруженных зонах — это накопительный эффект, который не откатывается сам по себе, даже если игроки временно не в сети. Если видите, что потребление RAM у процесса сервера стабильно ползёт вверх от недели к неделе — это ожидаемое поведение при активной стройке, а не утечка памяти как таковая (хотя длительные running-сессии без рестарта иногда всё же накапливают лишнее — см. следующий раздел).

Диагностировать, где именно упирается сервер — в CPU, RAM или диск при автосейве — проще всего по методичке из статьи про мониторинг TPS и лагов: смотрите загрузку конкретного ядра, а не средний CPU по всем ядрам, потому что игра физически не размажет нагрузку по всем потокам ровным слоем.

Регулярный рестарт сервера как профилактика

Простая, но недооценённая мера — плановый рестарт процесса сервера раз в 1-3 дня, а не бесконечный uptime без перезапуска. У Unity-приложений, которые долго держат в памяти растущее число активных физических объектов, со временем накапливается некоторая деградация производительности — частично из-за фрагментации памяти, частично из-за накопленного количества «мусорных» объектов (обрубки деревьев, разлетевшийся мелкий лут), которые никто не убрал вручную.

Практическая схема:

1. Предупредить игроков заранее (внутриигровым чатом или в Discord сервера) о времени рестарта.
2. Дождаться автосейва или форсировать сохранение перед остановкой.
3. Остановить процесс SonsOfTheForestDS.exe (через службу NSSM или Task Scheduler, если настроены по инструкции запуска сервера).
4. Запустить заново — служба с настроенным автозапуском поднимет процесс с чистым состоянием памяти, но с сохранённым миром из последнего сейва.

Рестарт не решает проблему физически накопленных построек (они как были в мире, так и останутся после перезапуска — это не Rust с его вайпами карты), но снимает часть накопленной за дни аптайма деградации самого процесса.

Дисциплина стройки: что реально помогает без потери прогресса

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

• Перерабатывайте лишние брёвна, а не складируйте их горами про запас. Куча из полусотни неиспользованных брёвен — это полсотни лишних физических тел, которые можно было пустить в стройку или просто не рубить заранее.
• Убирайте трупы врагов вручную или сжигайте их после отбитых атак на базу, а не оставляйте гнить рядом с частоколом — это заодно и эстетически приятнее, и снижает число активных объектов у самого людного места на сервере.
• Собирайте выброшенный лут или договоритесь с командой не разбрасывать вещи бездумно при чистке инвентаря.
• Стройте компактнее, а не растягивайте частокол на весь периметр видимости — чем плотнее сгруппирована застройка, тем меньше отдельных зон с активной физикой одновременно попадает в поле обсчёта, когда игроки перемещаются по базе.
• Не злоупотребляйте ловушками сверх необходимого. Десяток ям и растяжек по периметру решают задачу защиты не хуже полусотни — а нагрузку от постоянных проверок срабатывания дают ощутимо ниже.

Ничего из этого не требует жертвовать прогрессом — это скорее вопрос привычки играть чуть аккуратнее, зная, как устроена нагрузка на сервер изнутри.

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