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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://blog.playfab.com/blog/introducing-ab-testing-in-playfab

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

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

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

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

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

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