Как Ares Interactive проводит оперативное управление без ожидания обновлений от клиента

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

Компания Ares Interactive выпускает две совершенно разные игры: Baseball Hits 26 , разработанная командой 7th Inning, и Он Ходячие мертвецы: Последствия Разработано студией Swift Games. Игра Baseball Hits 26 тесно связана с реальным бейсбольным календарем. Ходячие мертвецы: Последствия Игра строит свой сервис на основе жанра roguelite, который может расширяться без нарушения основного игрового процесса.

Мы поговорили с Андре Таубе, руководителем студии 7th Inning, и Карстеном Гранигом, управляющим директором Swift Games Germany. Они рассказали нам, как структурируют системы обслуживания в реальном времени, управляют удаленным контентом и конфигурацией, сокращают циклы итераций и обеспечивают стабильность мобильных релизов по мере дальнейшего развития обеих игр.

Создание операционной системы на основе данных, а не клиентских релизов.

Игра Baseball Hits 26 создана для того, чтобы подарить любителям бейсбола и геймерам незабываемые впечатления от игры, в которую легко начать играть в любое время и в любом месте, как короткими сессиями, так и в течение более длительных стратегических игровых сессий. Такая доступность сочетается с реальными решениями, которые можно принять в бейсболе, прогрессом, живыми событиями, социальными клубами и функциями коммуникации. Поддержание этих систем в актуальном состоянии означает, что к игре нужно относиться как к постоянно меняющемуся процессу, а не как к чему-то, что было выпущено в продажу.

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

«Такой уровень актуальности достигается благодаря оперативным обновлениям серверов на основе данных и способности нашей команды оперативного реагирования быстро подбирать подходящие матчи», — говорит Таубе.

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

В основе системы лежит настраиваемая система доставки контента и удаленной конфигурации, включающая более 50 доменов конфигурации, охватывающих игроков, события, товары в магазине, ящики с наградами, боевые пропуски и другие системы. Команда управляет изменениями через административную панель. Система проверяет изменения перед их принятием, и серверы подхватывают их в течение нескольких секунд без перезапуска.

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

Планирование мероприятий строится на том же фундаменте. Для проведения мероприятий, турниров и проведения ограниченных по времени распродаж установлены определенные периоды начала и окончания. Система сегментации отвечает за таргетинг и обеспечивает A/B-тестирование, позволяя команде тестировать новые предложения или форматы мероприятий на небольшой части аудитории перед более широким внедрением.

На практике это позволяет команде проводить до четырех мероприятий в неделю, таких как мероприятия Prime Club и Tower Club, каждое со своими бонусными игроками и специальными предложениями.

«Владение всем стеком технологий приносит наибольшую выгоду, когда что-то идет не так в середине мероприятия», — говорит Таубе. «Команда может диагностировать проблему, исправить конфигурацию, выплатить компенсацию пострадавшим игрокам и отправить обновление [конфигурации] клиентам — всё это за считанные минуты и из одного места».

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

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

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

Тот же акцент на предсказуемости применяется и к релизам iOS и Android . Команда сводит к минимуму код, специфичный для каждой платформы, и обе платформы имеют общие сроки выполнения этапов и сдачи проектов. Команда ежедневно создает и тестирует сборки для Android и iOS.

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

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

«Что касается игр в режиме реального времени, то по умолчанию каждый запрос к серверу следует рассматривать как ненадежный», — говорит Таубе. «Разработайте клиентскую часть таким образом, чтобы медленный, прерывающийся или не отвечающий сервер никогда не нарушал игровой процесс».

Этот принцип распространяется и на поддержку устройств. Команда использует симулятор устройства для проверки охвата пользовательского интерфейса на всем диапазоне поддерживаемых размеров и разрешений экрана. Инструмент Unity Profiler широко используется для выявления проблем с производительностью во время игрового процесса. Команда также проводит тестирование регрессии производительности на широком спектре физических устройств Android и iOS, как с Wi-Fi, так и без него.

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

«Инвестируйте на ранних этапах в разработку надежного архитектурного плана поддержки устройств, особенно на Android, где фрагментация между аппаратными средствами и версиями OS представляет собой реальный риск».

Создание сериала «Ходячие мертвецы»: Последствия, чтобы работающие системы могли развиваться независимо.

Игра Baseball Hits 26 создана с учетом реального спортивного календаря. Ходячие мертвецы: Последствия Перед разработчиками сервисов с живыми дилерами стоит другая задача: добавление новых способов игры без нарушения базового игрового процесса в жанре roguelite.

Эта ролевая игра в жанре roguelite переносит игроков в мир «Ходячих мертвецов» . Они формируют команды Выживших, в которые входят Рик Граймс, Дэрил Диксон и Мишонн, и сражаются с полчищами ходячих мертвецов и другими врагами в режиме реального времени. В перерывах между игровыми сессиями игроки открывают новых Выживших и снаряжение, повышают их уровень, открывают новые навыки и строят свою базу.

«В основе нашей задумки было создание игры, которая бы передавала постоянную опасность и сложные решения, характерные для The Walking Dead, и в то же время обеспечивала бы высокую реиграбельность и прогресс, которые вы ожидаете от roguelite-игры», — говорит Граниг.

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

«С точки зрения разработки, мы создали игру таким образом, чтобы эти системы могли развиваться независимо друг от друга». Это даёт нам возможность продолжать расширять возможности игры в режиме реального времени, не нарушая основной игровой процесс roguelite».

Сделать десятый полнометражный фильм таким же дешевым в доставке, как и первый.

Компания Swift Games не перестраивала свою платформу для онлайн-сервисов с нуля. Всё началось с предыдущей игры, Heroes vs Hordes . Системы хранения данных, экономики, аутентификации, аналитики, удаленной настройки и облачного сохранения были представлены как проверенные технологии, в то время как новое ядро ​​roguelite было разработано в виде прототипа отдельно, а затем интегрировано в эту основу.

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

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

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

«Именно поэтому десятый полнометражный фильм остается примерно таким же дешевым в производстве, как и первый», — говорит Граниг.

В игре в основном используются GameObjects и NVIDIA PhysX . Entities и Burst зарезервированы для системы поиска пути A*, которая перемещает врагов.

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

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

Команда также разделяет пользовательский интерфейс и логику. Магазин или предложение могут существовать в виде простого класса C#, который можно протестировать без запуска движка, в то время как дизайнеры работают напрямую с конфигурационными ресурсами.

Проведение четкой границы между данными в реальном времени и игровыми ресурсами.

В Ходячие мертвецы: Последствия Addressables отвечают за управление памятью и загрузку, а не за удаленную доставку контента. Двадцать девять групп соответствуют отдельным функциям, и их загрузка и выгрузка происходят практически так же, как и контекст игры.

Для отображения контента в режиме реального времени используется отдельный конвейер, построенный непосредственно на основе API AssetBundles , а не Addressables. Пакеты формируются для каждой платформы, загружаются и извлекаются игрой во время выполнения. Каждый из них включает хеш, контрольную сумму и самую старую совместимую версию клиента.

Правило команды простое: «Если дизайнеры хотят менять это каждую неделю, то это должно быть в одном комплекте». Будь то искусство или код, это должно быть включено в сборку.

В пределах этих границ команда по-прежнему может перемещать события, перераспределять награды, корректировать предложения, включать и выключать функции или поведение покупателей, а также проводить A/B-тесты, не возвращаясь в магазины. Для создания новых графических элементов и нового кода требуется сборка.

«Мы намеренно установили эту границу, чтобы рабочая поверхность оставалась достаточно небольшой, и в случае поломки мы могли определить, что именно изменилось», — говорит Граниг.

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

«Поскольку арены строятся вручную, мы можем учесть все, что может увидеть игрок, и измерить все это, вместо того чтобы просто делать выборочные измерения и надеяться на лучшее».

Сокращение пути от электронной таблицы до реальной игры.

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

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

Результат: Если команда обнаружит проблему в работе системы или в балансировке, она сможет выпустить исправление примерно за 15 минут, вместо того чтобы проходить полный процесс релиза.

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

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

Самой сложной операционной проблемой оказалось разделение среды разработки и рабочей среды. Конфигурация Firebase встроена в файлы сборки, и ключи Firebase, ключи Play Services, конфигурация Facebook, идентификаторы пакетов, имена и значки — всё должно совпадать.

В итоге команда передала ответственность за эти среды в ведение подразделения непрерывной интеграции (CI). В сборках для разработки и для рабочей среды используются разные идентификаторы пакетов, имена и значки, чтобы они могли сосуществовать на одном устройстве. Если тестовая сборка подключается к рабочему серверу, в игре появляется предупреждение. Загрузка не удается, если отсутствует конфигурация, вместо того, чтобы незаметно указывать на неправильную среду.

«Мы переложили ответственность на отдел непрерывного совершенствования, вместо того чтобы оставлять ее на плечи отдельных людей», — говорит Граниг.

Начинайте с малого, проводите тестирование на ранних этапах.

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

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

Для Ходячие мертвецы: Последствия Это означает модульные системы, работающие в режиме реального времени, строго контролируемую конфигурацию и намеренно установленные границы: Контент можно изменять удаленно, в то время как код и графика добавляются в сборку.

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

«Подготовьте контент на один-три дня и запустите его, прежде чем приступать к чему-либо еще». Затем посмотрите, сколько игроков вернутся на следующий день. «Если они не вернутся, никакой контент, добавленный на поздних этапах игры, не сможет их спасти», — объясняет он.

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

Бейсбольный хит 26 и Ходячие мертвецы: Последствия Уже доступны в App Store и Google Play. Больше историй от разработчиков Unity вы найдете в блоге Unity и центре ресурсов Unity.