Project Zomboid для постоянной группы: настройки мира и безопасные обновления

Представьте мир Project Zomboid, который живёт уже несколько месяцев. В Малдро есть заколоченный гараж с запасом бензина, в подвале на окраине стоит генератор, а у одного из игроков в рюкзаке лежит книга, которую он так и не дочитал. Встречи группы бывают раз в неделю, иногда реже, и между ними мир стоит на паузе вместе со всеми своими договорённостями. Вопрос «как настроить сервер» в таком мире быстро превращается в другой: как сделать так, чтобы к следующему вечеру всё это оказалось на своих местах и работало так, как все привыкли.

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

Настройки мира начинаются с разговора, а не с файла

Прежде чем открывать любые конфигурационные файлы, полезно устроить короткое обсуждение в чате группы. Серверные настройки Project Zomboid описывают, как мир будет вести себя по отношению к игрокам: насколько быстро он давит, как долго даёт передышку, насколько прощает ошибки. Одну и ту же сборку можно превратить и в напряжённый хоррор на выживание, и в неспешное строительство базы с редкими стычками. Поэтому выбирать значения стоит, отталкиваясь от вопросов о стиле игры, а не от желания «покрутить побольше».

Вот вопросы, которые стоит задать группе до первого запуска и вернуться к ним перед каждым серьёзным изменением:

• Сколько длится одна встреча и как часто вы собираетесь? Если игра раз в неделю по два-три часа, мир, который быстро выматывает ресурсы, начнёт наказывать не за ошибки, а за расписание. Темп событий должен соотноситься с тем, сколько реального времени у людей есть.
• Что происходит, пока никого нет на сервере? Группе нужно решить, должен ли мир оставаться «замороженным» между встречами или двигаться без игроков. От этого зависит, вернётесь ли вы к тем же запасам и той же обстановке или к чему-то заметно другому.
• Как относитесь к смерти персонажа? Для кого-то это конец истории, для кого-то повод начать новую линию. Если в группе есть люди с разным отношением, лучше договориться заранее, чем спорить после первого же провала.
• Играют ли друг против друга? Будет ли у вас кооператив без конфликтов между людьми или допустимы столкновения, воровство и территориальные споры. Это влияет и на правила, и на то, что вы вообще включаете на сервере.
• Кто имеет право менять настройки? Хороший ответ: один человек вносит правки, остальные видят, что поменялось и зачем.

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

Запишите причину рядом со значением

У долгоживущего сервера есть неприятное свойство: через три месяца никто не помнит, почему выбрано именно такое значение. Заведите простой текстовый журнал настроек. Одна строка на изменение: что поменяли, дата, причина и кто предложил. Через месяц это спасёт от споров «а почему у нас так», а при подозрении, что мир стал вести себя иначе, позволит быстро проверить, не вы ли сами что-то изменили.

Новые настройки и уже существующая территория — не одно и то же

Одна из самых частых ошибок, когда группа меняет параметры в живом мире: ожидание, что правка применится ко всему сразу. Нужно различать две вещи. Одни настройки определяют, как мир ведёт себя дальше: правила, которые действуют здесь и сейчас. Другие связаны с тем, как мир создаётся: то, что формирует территорию при первом её появлении. Если часть карты уже сгенерирована и сохранена, изменение параметров генерации не перепишет то, что игроки уже видели и где успели обжиться.

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

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

Версия игры — часть договора группы

Project Zomboid переживает крупный переход между ветками. По сообщению разработчика, сохранения Build 41 несовместимы с Build 42, а прежняя ветка остаётся доступной, чтобы игроки могли дойти до конца своей игры; при этом ветка клиента и сервера входит в план обновления (заметка разработчика). Для постоянной группы это не новость из мира технологий, а практическая развилка. Обновление, которое для одиночного игрока выглядит как новая игра с интересными возможностями, для вашей общей истории может означать, что мир остаётся в прошлом.

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

1. На какой ветке вы сейчас играете, и это записано в журнале настроек.
2. Как каждый участник фиксирует эту ветку у себя в клиенте и не даёт ей смениться случайно.
3. Что вы считаете достаточным основанием для переезда на новую ветку: хотите ли вы дожить текущую историю до финала или готовы начать новую кампанию.

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

Моды: порядок, зависимости и согласованность

Моды главный источник сюрпризов при любом обновлении. В описании возможностей Build 42 упомянут менеджер модов с порядком загрузки, зависимостями, пометками конфликтов и сохраняемыми наборами; там же отмечено, что серверные инвентарь и действия требуют согласованного состояния клиента и сервера (обзор возможностей Build 42). Для группы это означает две вещи: набор модов нужно считать частью версии игры, а не приложением к ней, и расхождение между тем, что стоит у вас и у сервера, может проявиться не как красивая ошибка, а как странное поведение вещей и действий.

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

• название и откуда он берётся;
• зачем он у вас: какую часть игры он меняет и кто из игроков на него полагается;
• что от него зависит и что от него зависит у других модов;
• положение в порядке загрузки, если вы его настраивали.

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

Сохраняемые наборы как договорённость

Возможность сохранять наборы модов хороша тем, что превращает «у меня стоит примерно то же самое» в проверяемую вещь. Если у группы есть именованный набор, его легче сравнивать между участниками. Но сама по себе функция не заменяет разговора: кто-то должен отвечать за то, чтобы набор менялся только по общему согласию, а изменения попадали в журнал. Один мод, добавленный «потому что красивый», способен вечером сорвать всем игру.

Что на самом деле происходит с сохранением при обновлении

Теперь главный вопрос: какова судьба вашего мира, когда вы что-то меняете? Здесь полезно развести три разных события, которые в разговоре часто смешиваются.

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

Сам по себе файл сохранения это просто данные на диске, поэтому копирование проще и надёжнее выполнять на остановленном сервере: так вы не рискуете получить половину файлов от одного момента времени, а половину от другого. Какие именно каталоги нужно включить, зависит от вашей установки; проверьте это на своём сервере и убедитесь, что восстановление из копии действительно поднимает мир, а не просто лежит где-то архивом. Копия, из которой ни разу не пробовали стартовать, остаётся предположением.

Репетиция обновления: второй сервер на один вечер

Идея репетиции проста: прежде чем трогать живой мир, вы поднимаете его двойника и проводите над ним все планируемые изменения. Для этого нужна отдельная среда, где можно спокойно ошибаться. Если сервер у вас на VPS, это удобно делать на втором экземпляре или во втором каталоге с другими портами. Ресурсов у такого теста потребуется немного: достаточно, чтобы мир запустился и один-два человека смогли зайти и пройтись по ключевым местам.

Про ресурсы стоит сказать отдельно. Отправная точка для теста может быть скромной: например, конфигурация вроде Uab с 2 vCPU, 4 ГБ памяти и 80 ГБ NVMe или Heka с 4 vCPU, 8 ГБ и 160 ГБ. Это не обещание, что на ней вместится определённое число игроков или модов: сколько реально потребуется вашей группе с вашим набором модов, показывает только замер на вашей нагрузке. Тарифная сетка нужна, чтобы выбрать, с чего начинать, а не чтобы заменить проверку. Если репетиция идёт на отдельной машине, диск с запасом пригодится: копия мира и несколько версий резервных архивов занимают место быстрее, чем кажется.

Если вы хотите держать рабочий сервер и стенд на отдельном VPS, у MAATRIX есть root-доступ, диски NVMe и процессоры AMD EPYC; по публичному предложению, виртуальная машина создаётся автоматически через пару минут после оплаты. Выбор локации (в предложении перечислены UK, US, RU и FR) стоит делать исходя из того, где живут игроки: для сетевой игры задержка до сервера заметнее, чем разница в процессорах. Подробнее о тарифах можно узнать на странице аренды VPS MAATRIX, а перед запуском проверьте, как ваш сервер ведёт себя на выбранной конфигурации.

Что проверять на репетиции

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

1. Запускается ли сервер на копии с планируемыми изменениями и принимает ли он подключения?
2. Заходят ли все игроки с теми версиями клиента, которые у них стоят?
3. Что с мирами и модами: нет ли предупреждений о конфликтах или отсутствующих зависимостях?
4. Совпадает ли поведение инвентаря и действий с тем, что вы ожидаете?
5. Остались ли на месте ключевые для группы вещи?

Последний пункт самый показательный, и о нём подробнее ниже.

Когда вносить изменения: окно между встречами

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

Разумный порядок выглядит так. Сразу после окончания встречи вы останавливаете сервер и делаете копию мира. Дальше на копии прогоняете репетицию. Если она прошла хорошо, решаете, применять ли изменения на живом сервере, и делаете это тоже заранее, а не в день игры. Между применением и следующей встречей у вас остаётся запас, за который можно проверить результат и при необходимости вернуться к копии. Хорошо, если за один раз меняется что-то одно: тогда в случае проблемы понятно, что именно её вызвало.

Заранее договоритесь и о критерии отката. Это просто: что именно должно произойти, чтобы вы отказались от изменений и вернули сохранённую копию? Например, не заходит хотя бы один игрок, пропали ключевые вещи, сервер стартует с ошибками. Запишите условия до начала работ. Решение, принятое в спокойном состоянии, почти всегда лучше решения, принятого в три часа ночи, когда хочется, чтобы «ещё одна попытка» всё починила.

Возвращение к миру: проверка персонажей и ключевых мест

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

Вот как это может выглядеть в нашем условном примере с Малдро:

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

Этот пример условный и нужен лишь затем, чтобы показать принцип: список для проверки составляется из того, что вы бы не простили миру потерять. У каждой группы он свой. Одним важнее база, другим персонажи с прокачанными навыками, третьим особая территория, где случилось что-то памятное. Главное, чтобы список существовал заранее, был коротким и проверялся до встречи, а не во время неё.

Если что-то не сошлось

Бывает, что проверка показывает расхождение. Тогда важно не пытаться чинить всё на живом мире. Остановите сервер, верните сохранённую копию, убедитесь, что она поднимается, и вернитесь к репетиции, чтобы разобраться, что пошло не так. Потерянный вечер на разбирательство обходится дешевле, чем потерянный мир, а группа, которая видит, что за её историей бережно следят, охотнее соглашается на будущие изменения.

Сетевая часть: кто может заходить на сервер

Раз уж сервер долгоживущий и в нём лежит общая история, стоит подумать, кто может до него добраться. Игровой сервер, открытый всему интернету, привлекает не только друзей. Если у группы есть возможность закрыть доступ так, чтобы к управляющим сервисам подключались только свои, это снижает число поводов для неприятных сюрпризов. Подход с группами доступа и правилами между участниками описан в материале о настройке ACL и групп доступа в Netbird. Для вашей задачи он нужен прежде всего как идея: управление сервером и игровой порт это разные вещи, и открывать их нужно по-разному.

Как это складывается в одну историю

Если собрать всё сказанное, получается небольшой цикл, который группа повторяет при каждом изменении. Сначала обсуждается, зачем нужна правка и как она связана со стилем игры. Затем фиксируются ветка и набор модов, чтобы клиент и сервер говорили на одном языке. После встречи делается копия мира и на ней проходит репетиция. Результат проверяется по списку ключевых персонажей и мест. И только после этого изменения попадают на живой сервер, с заранее известным условием отката.

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