Постоянство

Управляйте постоянными мирами с круглосуточными постоянными онлайн-развёртываниями на Частные флоты.

Многие жанры (MMO, песочницы, социальные игры) используют постоянные миры, чтобы позволить игрокам:

• знакомиться и общаться с новыми друзьями; развивать органичные сообщества игроков,

• исследовать живой открытый мир, наполненный пользовательским контентом, размещённым игроками,

• участвовать в эпических рейдовых битвах, длящихся часами, с большими группами или целыми гильдиями.

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

В качестве альтернативы, см. Развертывания облачная оркестрация для использования дробного ценообразования vCPU.

✔️ Подготовка

Чтобы обеспечить постоянные, непрерывные круглосуточные онлайн-развёртывания:

1. Создайте новую версию приложения (или обновите существующую).

   • В Dashboard — выберите «persistent» вместо указания максимальной продолжительности.

   • В API — укажите "max_duration": -1 в запросе версии приложения.

2. Создайте частный флот в панели управления и запланируйте хосты.

   1. Создание флота бесплатно, сделайте это сначала, чтобы просмотреть локации и детали.

   2. Выберите спецификации Virtual Machines (Performance) или Bare Metal (Overdrive).

   3. Перед планированием хостов вам будет предложено подтвердить итоговую цену.

3. Разворачивайте новые серверы с Браузер серверов или пользовательскими интеграциями.

   1. Server Browser запускает серверы в соответствии с настроенными политиками масштабирования.

   2. Пользовательские интеграции должны запускать серверы, используя API частного флота.

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

Если вам нужна помощь, свяжитесь с нами через Discord. Для поддержки по играм в реальном времени см. нашу систему тикетов.

🔑 Владение сервером

Плюсы и минусы современных и традиционных моделей владения с edge computing.

Хостинг студии

Серверы традиционно управляются студией, а затраты на хостинг окупаются за счёт доходов от игры.

👍 Преимущества

• Без дополнительных платежей для игроков — стоимость хостинга окупается из доходов студии.

• Высокая совместимость клиент/сервер с слабой связанностью клиента/сервера/сервиса.

• Более устойчиво к читерству и злоупотреблениям благодаря закрытому исходному коду игры.

👎 Недостатки

• Ограниченная поддержка моддинга сообщества для обеспечения целостности и честности сервера.

Серверы сообщества

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

👍 Преимущества

• Улучшите поддержку моддинга с помощью отобранных модов и версий.

• Улучшайте игру итеративно через прямое сотрудничество с сообществом.

• Укрепляйте доверие сообщества за счёт повышенной долговечности игры и модели самообслуживания.

👎 Недостатки

• Требуются инвестиции в разработку для поддержки моддинга и совместимости.

• Больше операционных усилий для управления сообществом и платёжными системами.

• Повышенный риск обратной разработки из-за раскрытия внутренностей игры.

🥛 Вместимость и масштабирование

Изучите продвинутые техники для оптимизации стоимости сервера и качества обслуживания.

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

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

Ручного запуска развертываний и вставки URL и портов недостаточно для живой игры.

Автоматизируйте популярные игровые сценарии для Сеансы игроков и масштабирования серверов с помощью одного из следующих вариантов:

Матчмейкинг:

• Соревновательные игры

• Матчи по запросу

• Рейтинг навыка и/или Пользовательские правила

Браузер серверов:

• Постоянные или социальные

• Длительные сессии

• Автораспределение и/или Пользовательский поиск

Пользовательский бэкенд:

• Переносите игры в продакшене

• Развертывайте с API v2

• Отслеживайте вебхуки

Вместимость

Развёртывания не отслеживают и не управляют активными подключениями игроков после того как вы Развертывания чтобы дать вам полный контроль и свободу реализовать любой дизайн.

Внедрите управление ёмкостью, чтобы ваши серверы:

• контролировали стоимость хостинга - проводить бенчмаркинг и оптимизировали использование ресурсов сервера на игрока,

• обеспечивали стабильный опыт — поддерживайте CCU на сервер в безопасном диапазоне.

См. Браузер серверов для автоматизированного управления ёмкостью с нашим управляемым сервисом.

Совет: если вы решите разработать собственный оркестратор сессий и ёмкости.

• Процедура должна предотвращать конкуренцию за ёмкость с одновременными резервированиями.

• Отправляйте частые heartbeat-сообщения вашему оркестратору, чтобы синхронизировать состояние сервера.

• Быстро удаляйте устаревшие, упавшие или остановленные серверы из процесса обнаружения.

• Снимайте резервирование ёмкости по таймауту, если игроки не подключаются в отведённое время.

• Отключайте клиентов и освобождайте ёмкость при обнаружении неактивности игрока.

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

Масштабирование вверх

Умные стратегии масштабирования предотвращают очереди для игроков и минимизируют стоимость простаивающих серверов.

Мы рекомендуем масштабировать ресурсы исходя из числа одновременных игроков, а не загрузки машины (CPU и RAM), поскольку колебания нагрузки могут привести к непредсказуемой доступности.

Масштабирование не требует «примерной оценки» регионального трафика или стоимости сервера. Запланируйте Частные флоты ёмкость для отлива и автоматически переносите нагрузку в облако во время неожиданных пиков трафика.

Включить Активное кэширование в вашей версии приложения для развертывания серверов за считанные секунды.

Масштабирование вниз

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

Надёжно ли вы определяете неактивность / отключение игрока?

• Надёжно ли отсутствие ввода от игрока? Игроки часто используют ботов и макросы, чтобы имитировать активность и избежать кика, что приводит к ожиданию в очереди при повторном подключении.

• Есть ли какие-либо другие индикаторы активности, которые сложнее подделать?

• Есть ли обходное решение в дизайне игры, чтобы смягчить влияние/мотивацию использовать ботов?

Можете ли вы легко и быстро перезапускать серверы без серьёзных откатов?

• Вашему серверу может потребоваться некоторое время, чтобы перезапуститься и восстановить состояние. Влечёт ли восстановление состояния какие-либо дополнительные расходы на передачу данных или сервисы на стороне вашего игрового бэкенда?

• Можете ли вы скрыть загрузку сервера с помощью мини-игры/лобби, чтобы удержать игроков вовлечёнными?

Привязаны ли игроки к конкретным экземплярам серверов или могут легко мигрировать?

• Как подключение к другому серверу влияет на аккаунт игрока, историю покупок, социальный опыт, прогрессию, инвентарь и общую удерживаемость игроков?

• Проверьте ваш Постоянство и убедитесь, что критически важные данные не потеряны.

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

💭 Конфигурация и состояние

Определите параметры seed сервера и надёжно управляйте состоянием игрока/сервера.

Управление конфигурацией

Конфигурация или seed относится к начальным данным, передаваемым серверу при развёртывании:

• внедрённым переменным, зависящим от среды:

  • например, данным о совместимости версий клиента/сервера,

• расположению сервера, портам сервера и другой информации о сервере,

• информации для подбора матчей или пользовательским переменным развёртывания,

• параметрам интеграций сторонних сервисов, ключам и секретам.

Конфигурация неизменяема. Читается при запуске сервера, без изменений во время выполнения.

Управление состоянием

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

• подключение игрока, изменения состояния, управляемые игроком (например, Pawn),

• изменения свойств, содержащиеся в уровне/сцене (например, Actor, Game Object),

• изменения, связанные с режимом игры, состоянием игры, или сценой игры информацией.

Данные состояния часто меняются. Синхронизация происходит много раз в секунду (tick rate).

Частые резервные копии состояния помогают предотвратить потерю данных в случае неожиданных сбоев/проблем:

• асинхронные обновления через API стороннего игрового бэкенда, например Nakama от Heroic Labs,

• периодический heartbeat сервера, передающий сериализованные файлы состояния в облачное объектное хранилище.

У stateful-компонентов обычно есть чётко определённый владелец — либо сервер, либо игрок.

Объекты, принадлежащие серверу

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

Объекты, принадлежащие серверу, могут быть восстановлены заменяющим сервером (миграция состояния). Они обычно не разделяются между одновременно работающими серверами (треб. server meshing).

Объекты, принадлежащие игроку

Объектами, принадлежащими игроку, могут управлять и игроки, и сервер. Назначение владения объектами постоянного мира игрокам может упростить хранение и миграцию состояния.

Создавайте резервные копии объектов, принадлежащих игроку, на устройстве игрока или в игровом бэкенде между сессиями. Шифруйте состояние игрока и/или загружайте контрольные суммы состояния, чтобы обнаруживать несанкционированные изменения.

Цели восстановления

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

Мы настоятельно рекомендуем обсудить следующее внутри вашей команды:

• Категории данных, обрабатываемых вашими игровыми клиентами, серверами и игровым бэкендом.

• Влияние потери данных в каждой категории на ваших игроков и на ваш бизнес.

• Recovery Point Objective — допустимый объём потери данных до серьёзного ущерба.

• Recovery Time Objective — как быстро системе нужно восстановиться.

Ниже рассмотрите наш упрощённый пример оценки целей восстановления:

Категория данных	RPO	RTO
аккаунт, подписка и покупки	🔥 5 мин	🔥 30 мин
прогресс, инвентарь и рейтинг навыка	🔥 5 мин	🔥 60 мин
модерация, производительность и отслеживание ошибок	⚠️ 30 мин	⚠️ 8 ч
социальные функции, история чата, поведенческая аналитика	⏬ 24 ч	⏬ 72 ч

Заранее подготовьте план аварийного восстановления для ваших самых критичных категорий.

Обработка сбоя сервера зависит от вашей политики перезапуска процесса. Состояние сервера может быть потеряно.

👀 Наблюдаемость

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

Подключите свой Хранилище конечной точки чтобы сохранять журналы развертывания, иначе они будут удалены!

Добавьте пользовательские логи и отслеживание ошибок (Sentry, Bugsnag) для устранения частичных сбоев.