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

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

В чем сложности с бинарными обновлениями

Чтобы у игроков сохранялся интерес к Left to Survive, мы выпускаем апдейты разного масштаба примерно раз в один-два месяца. Вероятно, многие знакомы со сложностями релиза новых бинарных версий. Их подготовка, как правило, занимает много времени и требует внимания со стороны разработчиков и команды QA. 

Если закладывать все планируемые Live Ops в бинарник, то это сильно ограничит пространство для возможных маневров. В такой ситуации сложно что-то добавить, заменить, отключить в билде, который пошел в Live. А необходимость в этом, как правило, возникает: например, в Live-версии могут обнаружить баг или у дизайнеров может появиться идея, как скомбинировать разные LiveOps. Также каждый бинарный апдейт вынуждает пользователей скачивать довольно большой билд из стора: в нашем случае — 1 Гб. 

Допустим, мы решили выпустить какое-то крупное обновление. Например, открыть игрокам новый регион с разнообразными локациями, противниками, миссиями, продолжением сюжета. И все это можно добавить без бинарного апдейта — с помощью DLC. 

Downloadable Content дает нам много возможностей. В первую очередь DLC позволяет нам работать с конфигами. Также мы можем менять визуальный контент, левел-дизайн миссий, добавлять врагов — не только рескинить их, но значительно менять модели. Например, мы можем поменять модель в рамках заданного скелета — сместить у врага уязвимую точку с живота на голову. И вот получится новый враг. 

Через DLC мы добавляем новое оружие, персонажей, здания на базе, способности героев. Можем заливать 2D-арт в игру, менять локализацию. Из этого формируются наши ключевые LiveOps. 

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

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

Какие инструменты мы используем 

Мы постоянно стремимся минимизировать проблемы при выпуске DLC. Для этого мы используем ряд инструментов. Один из наиболее важных — всевозможные чекеры конфигов и контента. 

Проверку конфигов обычно можно разделить на два типа:

  • простые, которые выполняются быстро. Например, проверка на null; 

  • сложные, которые занимают до трех минут. Например, проверка последовательности сюжетных миссий. 

Чекеры бывают самыми разными. У нас есть чекеры, которые проверяют наличие ассетов и правильность последующей сборки — они запускаются автоматически при экспорте. Есть чекеры, которые напрямую затрагивают левел-дизайн и используются при редактировании сцены. Например, если персонаж должен бежать из точки в точку, то чекер проверит, где они находятся и не висят ли они в воздухе. А если у вас по сюжету в конкретном месте должны появиться три врага, то чекер проверит, что у всех хватит точек для спавна.

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

  1. если добавил фичу, добавь и чекеры; 

  2. нашел баг — подумай, как его можно исключить в будущем с помощью чекера. 

Так мы стараемся не допускать повторения одних и тех же ошибок. И если мы что-то не можем проверить с помощью чекера, мы добавляем это в чеклисты, за которыми следит QA. 

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

Чтобы добавить контент в билд, художнику достаточно выполнить несколько простых действий: он должен определенным образом назвать ассет, а потом нажать на пару кнопок в Unity и вся нужная структура окажется на своем месте в проекте. И художнику останется только закоммитить результат. 

Еще одна полезная группа — это технические инструменты: SVN хуки, собственные инструменты для сравнения конфигов и бандлов, тулзы для удобной заливки контента и применения его в Live — без перезапуска сервера и без выставления maintenance. То есть это все делается на лету, с минимальными трудностями для игроков. 

Мы используем в разработке LiveOps и Kill Switch для наших фичей. Мы стараемся делать так, чтобы дизайнеры могли без проблем отключать фичи как целиком, так и частично — это позволяет управлять ими в Live и после модифицировать их. 

Также мы стараемся анализировать и по необходимости добавлять настройки для некоторых фичей в зависимости от платформы. Для нас это особенно актуально, потому что Left to Survive есть уже на семи платформах: App Store, Google Play, Galaxy Store, MY.GAMES Store, Steam, AppGallery, Facebook Cloud Gaming. 

Ограничения DLC

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

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

Еще важно учитывать, что релизы DLC требуют дополнительных проверок от QA, причем на каждой заливке. Например, мы точно не хотим, чтобы игроки после незначительной ошибки на TeamCity перекачивали сотни мегабайт контента. А особенно мы не хотим, чтобы это происходило в туториале. 

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

Что дают нам DLC

Из очевидных плюсов использования этой системы, хотелось бы выделить несколько вещей. 

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

Например, для нас стало актуальными включение и выключение offer wall на разных платформах. На одной платформе работает, на другой — нет. Это же и с Rate me: на iOS мы можем переносить поближе, на Android — подальше. И все это происходит в рамках одного конфига для разных платформ.

В-третьих, это дает возможность на лету комбинировать разную функциональность, которая уже находится в Live. Например, в свое время мы добавили в игру функцию мороженщика — это был просто хороший монетизационный механизм без прямой привязки к другим фичам. Но сейчас мы с удовольствием используем его как standalone для сиюминутного поднятия revenue, так и в качестве части более крупных ивентов. Игроки уже ожидают его появления. А с учетом того, что мы можем кастомизировать его 2D-артом, то это очень лаконично смотрится в проекте. И все это хорошо поддерживается AB-тестом и системой сегментации.

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

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

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


За несколько лет жизни проекта мы зарелизили уже около 65 бинарных апдейтов разной важности — мажорные, минорные, баг фиксовые. И за этот же срок сделали около 500 обновлений конфигов и ассет-бандлов. Для себя мы решили, что это удобная система, поэтому не видим причин отказываться от ее возможностей. 

Комментарии (11)


  1. DeXPeriX
    22.06.2022 13:51
    +1

    Также каждый бинарный апдейт вынуждает пользователей скачивать довольно большой билд из стора: в нашем случае — 1 Гб.

    Хм. Стим при обновлении скачивает именно разницу. Epic Store тоже. Почему в Вашем случае получается так много?
    Да и каждое выпущенное DLC видно на странице товара в магазине Steam. Это не мешает?


    1. andreymaxorin
      22.06.2022 21:55

      речь о мобилках же


  1. TheGodfather
    22.06.2022 15:49
    +2

    SVN хуки,


    *Смотрит по сторонам и на часы*. Простите, я правильно понял, что вы используете SVN в 2022 году? Можете, кхм, прокомментировать как-нибудь?


    1. dalerank
      22.06.2022 19:03
      +4

      Если не хватает денег и желания на P4, то сидят на svn, или разных связках svn(content) + git(sources), cvs + git. Как бы нибыл хорош git он ужасен для сырого большого контента, с gitlfs тоже танцев хватает. Да и поддерживать репо в пару терабайт контента с гитом то еще удовольствие


    1. exadmin
      22.06.2022 19:15
      +4

      Не важно какой репозиторий используется, важно что команда с ним эффективна.


    1. xXxVano
      22.06.2022 22:37
      +2

      Особенности национального геймдева.


      У svn есть плюсы перед git-ом и поэтому многие старички не хотят с него слезть. Да и ленятся тратить много времени на изучение не профильной (хотя тут уже можно поспорить) технологией.


      Западные компании используют Perforce (де-факто стандарт в для крупных игровых студий), который ещё старше. У него так же хватает недостатков, но он к тому же платный.


      Но на самом деле можно поднять svn сервер поверх GitLab/Gitea и позволить программистам работать в git, а контент-мейкерам в svn.


    1. Pancir
      23.06.2022 02:21

      Поддержу предыдущие ответы, у нас например код в git а все остальное (файлы блендера, текстуры, референсы, сабстенс пэйнтер и т.д.) в svn. Просто svn с таким контентом лучше и удобнее работает, ИМХО. Но все равно SVN не до конца удобен, я надеюсь у меня когда ни будь хватит сил написать систему контроля версий ориентированную на графику (идеи уже есть) или кто-то мне подскажет какие удобные системы есть сейчас которые можно поднять на своем сервере о которых я не знаю.
      Главная проблема, например проект сабстен пэйнтера для 4к текстуры может спокойно весить 4 гига, и вот делаешь комит в SVN и теперь там эти 4 гига навсегда, даже тогда когда вариант этого файла больше не пригодится никогда, он будет лежать и занимать это место и это только один комит. Хочу систему такую как свн, но с возможностью управлять временем жизни некоторых файлов, например хранить только 10 последних вариантов определенного файла, если для одного из вариантов явно не указанно другое время жизни, то когда он станет 11-ым то он удалится. Что-то среднее получается между системой бэкапов и системой контроля версий (это если вкратце об идеи).


      1. xXxVano
        23.06.2022 13:39

        Svn умеет подрезать историю файлов, что бы как раз такую проблему решать.
        Git в свою очередь умеет это хранить в lfs и можно просто удалять объекты, которые уже не нужны (Ну и поверх можно svn сервер запустить).


        1. Pancir
          23.06.2022 14:09

          Подрезание SVN происходит через дамп и потом обратной загрузки через фильтр, попробуйте например такое проделать с 100 гиговым репозиторием, дамп будет весить в несколько раз больше чем репозиторий. Про lfs знаю, вот только не знаю как удалять оттуда. В любом случае всё это не совсем штатные ситуации для SVN и Git LFS.


          1. xXxVano
            23.06.2022 15:13

            В svn это приходится делать над терабайтным репозиторием. Да, боль, но что поделаешь.
            В LFS достаточно просто удалить файл из кеша. Найти актуальные можно простым скриптиком, пробежав по всем lfs объектам в нужных коммитах. К сожалению встроенный git lfs prune не позволяет удобно указать ренж нужных коммитов/веток и делает это со всеми объектами недоступными из нужного коммита.


  1. vvviperrr
    22.06.2022 18:32
    +4

    правильно. хочет юзер фикс - пусть покупает dlc