{"id":3974,"url":"\/distributions\/3974\/click?bit=1&hash=89c074744adc3963d1ee90e1903467ac5be17774d44e7968801238b3c2d5ae12","title":"\u0427\u0442\u043e \u0434\u0435\u043b\u0430\u0442\u044c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0443 \u043d\u0430 \u0437\u0430\u0432\u043e\u0434\u0435? ","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"6ac5a19e-df76-5b67-a8ea-a69df4167a4d","isPaidAndBannersEnabled":false}

Путеводитель по геймдеву. Ускоряем разработку и выход обновлений. Об автоматизации, A/B и доставке контента на пальцах

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

Что это и для кого это нужно?

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

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

Итак, для начала определимся, что нам нужно?

  • Ускорить процесс тестирования обновлений игры и нового контента;
  • Ускорить доставку контента до конечного пользователя, тем самым обходя длинные модерации даже в маленьких апдейтах игры;
  • Дать возможность оперативного A/B тестирования компонентов игры;
  • Автоматизировать процессы сборок билдов и обновления контента;

Как это должно работать?

  • Разработчики создают новый контент и передают его в автоматизированном режиме в отдел тестирования / либо для всех желающих в команде;
  • После тестирования билда, если все хорошо - он автоматизированно собирается под нашу платформу, в качестве новой ревизии или дополнительного контента;
  • Новый билд / дополнительный контент доставляется пользователю, а разработчики и менеджеры смотрят на реакцию в билде;
  • При наличии A/B тестирования - можно подкрутить настройки в обновлении;
  • Цикл повторяется, либо обновление откатывается;

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

Автоматизация процессов сборки

Первым делом - мы можем сократить процесс сборки и доставки обновления, как для конечного пользователя, так и для группы тестирования (внутренней или внешней). Для этого существует масса инструментов, однако в начале можно остановиться на банальной связке Unity Cloud Build + Git.

Для начала, первое что мы можем сделать - это разделить наш Git на три ветки:

  • Ветка Develop - нужна для разработки наших обновлений контента / билдов игры;
  • Ветка Testing - нужна чтобы не прекращать процесс разработки во время тестирования. Мы можем слить небольшой апдейт в эту ветку для внутреннего тестирования и будущих билдов;
  • Ветка Main (Master) - нужна для дальнейшей сборки под продакшн;

Если вам нужно немного больше о Git и его Flow, а также некоторых подводных камнях при работе с Unity - можете посмотреть небольшую лекцию одного из менторов в нашем инкубаторе:

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

Переводить мануал по Cloud Build нет смысла, да и настройка там проводится простым способом. Для этого я просто укажу ссылку на документацию.

Единственное, что можно здесь отметить - нужно дать сервисам доступ к своему репозиторию, если он приватный:

Также полезным будет настроить хук, который отправляет уведомления в Discord (или Slack или чем там вы пользуетесь) при появлении проблем со сборкой, новых сборках и др. Это здорово сэкономит время без необходимости постоянно мониторить сервисы.

Вы можете добавить интеграцию в настройках вашего проекта:

Таким образом - мы можем создавать автоматические сборки в облаке при обновлении репозитория Testing или Master, а также получить об этом уведомления в наш рабочий мессенджер.

Доставка контента до конечного пользователя

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

Первый вариант - это работа с билдами. Он достаточно прост. Мы автоматически делаем сборку способом, который был указан выше - на выходе получаем apk или набор бандлов и выгружаем его в наш стор. Этот процесс также можно автоматизировать при помощи того же Unity Cloud - он поддерживает автоматическую публикацию сразу на несколько платформ.

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

После того, как мы выгрузили билд на ограниченную группу пользователей - мы получаем два варианта:

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

А что если нам нужно публиковать не билды, а грузить небольшие обновления (к примеру контент-паки) без прохождения модераций и прочего?

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

Как правило эта система использует наборы бандлов или же новый вариант - Addressables.

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

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

Вы можете хранить манифесты на своем сервере, либо же вводить переменные для работы с версиями на каком-то стороннем сервере. К примеру, на PlayFab, если у вас уже построена там какая-либо логика игры:

Итак, логика того, как это может работать:

  • Клиент запрашивает манифест обновлений у сервера (его также можно распределить по группам пользователей для A/B тестирования);
  • Если же обновления есть - мы догружаем их при помощи менеджера контента и в дальнейшем отдаем новый контент по запросу игровых менеджеров;
  • Автоматизирование процесса выгрузки можно также настроить при помощи Jenkins или других сервисов, либо же написать на своем сервере хук, который будет по REST API связываться с сервером нашего GIT и проверять обновления бандлов.

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

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

Возможности A/B тестирования

Иногда, возникают потребности в проверке гипотезы в процессе тестирования нового обновления. И здесь мы можем разделить новый контент на дополнительное A/B тестирование и проверить, какая из подверсий будет работать лучше.

Для чего это может пригодиться? Приведем пример:

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

В этом случае нам может пригодиться дополнительное тестирование. Вы должны вшить его возможность на этапе производства контента, к примеру добавив облачные переменные (в том же Unity Cloud или PlayFab), которые будут отвечать за цвет материала плаща или его текстуру.

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

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

Для A/B тестирования могут быть полезны сервисы:

Итого

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

Мне это не нужно - скажете вы?

Приведу пример. Вы выходите в Google Play с демо-версией вашей игры, чтобы показать её издателям, или же к примеру, вашим друзьям, либо для участия в конкурсе. И в этот момент - ваша игра попадает в подборку Google Play - как новый инди-хит современности. Новые пользователи прибывают с каждым днем, а контента в игре не хватает, либо он оказался проблемным. В итоге вы теряете пользователей, роняете свой рейтинг и, возможно, на основе этих факторов, ваша игра будет очень очень плохо воспринята пользователями в дальнейшем, какой крутой она бы не была в планах.

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

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

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

0
7 комментариев
Написать комментарий...
sedd

Извините, но статья напоминает известный мем "как нарисовать сову".

Хотелось бы больше приземленой конкретики и желательно с примерами. Особенно интересут эта часть:

"В таком случае, все несколько сложнее, поскольку у нас должен быть настроен сервер по доставке контента (CDN) и желательно свой. Для этого у нас должна быть система обновлений, вшитая в игру." И далее...

Ответить
Развернуть ветку
Илья Сергеич
Автор

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

Ответить
Развернуть ветку
Илья Сергеич
Автор

Если все сейчас в одну статью просто запихну, то это будет километровая портянка, так что я разделю на несколько этапов и по частям распишу. Спасибо за замечание

Ответить
Развернуть ветку
Алексей Раевский

CDN не для инди... Просто почитай скольку инди влетело на очень серьезные деньги. В гугле такого много.

Ответить
Развернуть ветку
Илья Сергеич
Автор

Ну если это будет свой cdn не факт. Мы разворачивали свой сервер купленный за 40,000₽ + 3,500 в месяц на обслуживание. Около 20,000 dau держало нормально. Опять же инди бывают разные

Ответить
Развернуть ветку
Михаил Мирошниченко

Интересно для тех, кто в девелопменте, спасибо.
Раз уж упомянули Дженкис со товарищи, еще стоит отметить, что и у Git есть свой CI сервис: GitHub Actions. А для упрощения выполнения большого числа команд при сборке можно использовать Fastlane.

И раз пошло такое дело, то еще будет интересно рассказать, а как тестировать ваши приложения в CI среде. Например, если вы делаете приложение под мобилки, а к далекому CI серверу в облаке тестовый девайс так просто не приделаешь. И тут на помощь могут прийти облачные фермы устройств, но это совсем другая история =)

Ответить
Развернуть ветку
Илья Сергеич
Автор

Я хочу в будущем задеть подробнее эту тему, надеюсь смогу охватить всё. Спасибо за дополнения!

Ответить
Развернуть ветку
Читать все 7 комментариев
null