Как за неделю до релиза переобуться и сократить размер билда в 3 раза
Современные AAA-тайтлы уже давно стали весить больше 100 ГБ, а их апдейт еще на 20 ГБ считается обычным делом. Тот же тренд разрастания билда постепенно просачивается в мидкорные и хардкорные мобильные игры. Впрочем, к тому, что уже не удивляет ПК- и консольных юзеров, мобильные геймеры все еще довольно чувствительны.
Размер игры на релизе может оказаться гораздо больше необходимого, такое бывает. И даже тогда, когда кажется, что в билде осталось все только нужное, всегда найдется то, что можно оптимизировать и сократить.
Чем дальше продвигалась разработка War Robots Remastered, тем больше становились вес игрового билда и время сборки. Конечно, об этой проблеме мы начали задумываться еще на начальных этапах. И, помня об опыте современных midcore-игр вроде того же Fortnite, который позволяет себе тянуть на старте 12 ГБ, мы были уверены, что справимся с релизом довольно большого клиента в стор. Тем более, что наши игроки и так уже качали на тот момент около 800–900 МБ — то есть, были подготовленной аудиторией, не ждущей, что наш билд резко сократится до сотни МБ.
Постепенно приближался день релиза. Билд со всеми качествами — ULD (Ultra-Low Definition), LD (Low Definition), HD (High Definition) — под конец стал весить уже 2,3 ГБ.
ULD-пресетLD-пресет
HD-пресет
Несмотря на все внешние тесты в течение года, множества итераций и починок, мы понимали, что все равно на столь масштабном релизе возникнут проблемы, и решили сначала выпускаться на отдельном регионе и так постепенно тестировать сборку на проде. После этого планировалось сделать несколько хотфиксов — и выпустить игру на весь мир.
Восемь хотфиксов, или почему тестовые серверы — совсем не то же, что и глобал-лонч
В App Store, в отличие от Google Play, не такие гибкие возможности раскатки билда, и нельзя, например, выбрать конкретное гео. Поэтому наш план заключался в том, что новую версию игры и все ее хотфиксы мы сначала зарелизим на Android, а когда все отладим там, выложим билд на iOS и на весь мир. На все эти итерации мы выделили около недели, после чего обязаны были принять финальное решение: переводим ли мы весь проект на новый пайплайн разработки или же откатываем изменения и ищем новую дату релиза среди довольно плотного графика на остаток 2020 года. Первый вариант, конечно, нас устраивал больше — тем более, что у нас было обязательство перед Apple выпустить ремастер и договоренности об анонсе его на Apple Event.
На время релиза мы также включили возможность работы тестовых серверов всю неделю и почти каждый день выкатывали туда новый билд для того, чтобы протестировать его вместе с РТК (релизным тест-комплектом) — обычным списком тестов, которые необходимо провести с билдом и сервером перед релизом. Дополнительно для отслеживания текущих технических и маркетинговых показателей мы стали собираться каждое утро для разработки плана хотфикса на день, чтобы двигаться быстро и в нужном направлении.
За день до начала раскатки ремастера в сторы во время РТК обнаружились несколько проблем, включая баги префабов в ремастер-ветке, которые мы меняли еще N лет назад, — напоминание себе, что нужно чаще отслеживать изменения при долгом разделении веток, чтобы потом они не поломали начальную воронку. Было множество проблем по памяти на low-end устройствах. Все это мы вычинивали за день до релиза.
Проблемы пофиксили, так что билд в пятницу был готов. Материалы для стора, отправку в ревью и сам релиз на ограниченное гео мы запланировали на понедельник, 5 октября. Так что утром понедельника все материалы и бинарники были отправлены в релиз. И все — можно выдохнуть и откупорить шампанское?
Но нет: пока нельзя.
Нам приходило множество комментариев и телеметрии с low-end устройств на Android: Vulkan на них работал откровенно плохо. Несмотря на все тесты на большом количестве игроков, реальная ситуация на проде на выбранном гео показала, что устройства, полноценно поддерживающие Vulkan, — это, фактически, только флагманы и известные бренды. Например, Honor и Redmi не завезли полноценной реализации драйверов, из-за чего поддержка Vulkan была только на бумаге, и использование его API падало в различных сценариях.
Тем не менее, оверолл метрики выглядели неплохо. FPS держался на уровне «ванильной» версии, резкого роста крешей тоже не возникло: они аффектили в основном только старые и китайские устройства. Повода для резкого отката не было, а значит — можно продолжать мониторить ситуацию, заготавливая хотфиксы.
Какое-то время мы продолжали работать над хотфиксами:
Выключили Vulkan совсем. Вместо него остановились на OpenGLES 3.0 — что тоже неплохо, хотя мы и рассчитывали на низкоуровневую производительность Vulkan. Но он оказался слишком сырым на устройствах, так что мы решили, что лучше вернемся к нему позже;
Починили упаковку ресурсов, снизив потребление памяти;
Вычинили поведенческую историю, связанную с черным экраном, который показывался игрокам на старте игры: из-за этого бага некоторые из них думали, что игра зависла, и уходили;
Отключили некоторые карты, слишком сильно влияющие на качество игры. В частности, сильную проблему нам создавала карта Rome — из-за того, что она еще не была переработана, иногда срабатывающие на ней новые шейдеры в комбинации со старыми забивали оперативную память, что приводило к крешам;
Улучшили ситуацию с автоскейлером разрешения;
Повысили FPS в ангаре — на главном экране игры;
Решили проблемы с попаданием игроков в отдельный мир — когда они оказывались одни на карте.
В целом, от версии к версии наша техничка сильно улучшалась, нерешаемых проблем не было. Мы также видели улучшение воронки боев.
Уменьшаем размер билда: выкидываем все, что можно выкинуть
В четверг, на четвертый день после релиза, пришли внезапные новости от маркетинга: билд оказался слишком большой. При первом релизе мы видели просадки по конверсии игроков из рекламы в игру, но думали, что это краткосрочное явление. Однако уже вечером в среду было понятно, что мы не справляемся с закупкой на такой большой размер приложения:
График конверсии из закупки в установку на первом релизе ремастера
Нужно было срочно что-то делать с размером, причем делать радикально.
Технический директор собрал всех причастных лидов для обсуждения ситуации. Мы понимали, что если за день ничего не решить, то ремастер придется откатывать, а это был уж очень нежелательный сценарий, принимая во внимание обещания Apple. Напомним, что на момент релиза билд игры весил 2,3 ГБ против прежних 800 МБ.
В процессе обсуждения рождается множество идей. Где-то подрезать текстуры, где-то оптимизировать размер другого контента. Отказаться от некоторых карт. И, конечно, — убрать HD-качество из билда. Это экономило нам 1 ГБ.
Такое решение далось нелегко, ведь основная цель всего мероприятия — дать нашим игрокам современную красивую графику для топовых устройств. Однако, взвесив все «за» и «против», лиды принимают решение двигаться дальше итерационно.
HD — быть, но чуть позже.
На тот же момент — сделать можно было многое по разным направлениям. В тот день запустилась операция и одноименная релизная ветка Barbie Size.
Первое, что мы делаем — выпиливаем ассеты новостей из билда. Они все еще останутся к игре, но будут докачиваться через CDN. Это решение и так было в клиенте, просто до этого закешировано. Теперь же мы решаем, что предварительный кеш не нужен: пользователь скачает необходимые новости в тот момент, когда они ему понадобятся.
Так мы сократили размер еще на 150 МБ.
Проходимся по всем текстурам проекта, изменяем их размеры, параметры сжатия.
Форматы сжатия текстур для разных пресетов графики
Отдельно идем по UI-текстурам, применяем к ним crunched формат, добиваясь большего сжатия без сильной потери качества. Перенастраиваем автоматические импортеры текстур. Экономим еще около 200 МБ.
Но самая сложная доработка была еще впереди.
Как мы писали в предыдущих статьях, для упрощения разделения контента наша система делит ресурсы по качествам:
В блок Main попадают ресурсы, необходимые для всех качеств;
Отдельно от Main существуют блоки ULD, LD, HD.
Система устроена так, что нельзя разместить одни и те же ресурсы по-разному: если ресурс входит в одно качество — например, LD, — то и все его зависимости уходят в это качество. Таким образом, все, что касалось игрового контента — мехов, пушек, карт, — дублировалось внутри группы. Ресурсы, которые требовались для двух качеств сразу, тоже дублировались. Соответственно, чтобы избежать дублей, нужны были изменения как в конфигах ресурсной системы, которые настраивают клиентские программисты, так и в коде ресурсной системы как таковой.
До начала работы размер каждого из качеств выглядел следующим образом:
Команда, занимающаяся ресурсной системой, буквально за одну ночь решила проблему объединения конфигов: вместо отдельных групп LD и ULD мы получили единую LD_ULD, в которой вынесли дубликаты в отдельные ассет-бандлы, так что они стали занимать место в билде только один раз.
Первая же итерация дала следующие результаты:
Размер Main почти не изменился, зато поменялась сумма ULD + LD: раньше она была 383 МБ + 272 МБ = 655 МБ, а стала 426 МБ! То есть, мы выиграли себе еще дополнительные 220 МБ.
Эта версия сразу же была отправлена на тестирование. Во время него обнаруживались критичные проблемы с загрузкой ресурсов, однако все они были починены в оперативном режиме, поскольку были связаны именно с привязкой групп друг к другу.
К вечеру пятницы у нас уже был протестирован и отправлен на ревью новый билд. По результатам всех работ размеры билдов на Google Play выглядели таким образом:
Билд весом 776 МБ не сильно превышал размер «ванильной» версии, а потому устраивал всех. Это же показали метрики маркетинга, которые начали потихоньку исправляться: воронка конверсии вернулась в прежнее русло, а местами даже улучшилась.
График конверсии из закупки в установку после последнего хотфикса
Так, операция Barbie Size пришла к своему логическому завершению. Основные метрики были восстановлены, пользователям нравилась обновленная графика даже без HD, а впереди нас ждали последующие оптимизации и улучшения уже в спокойном режиме. Хоть версия HD ушла на доработку, ничего критического не произошло. В первую очередь мы хотели донести до пользователей реальные улучшения и перевести весь наш проект на новые рельсы, чтобы разработка нового контента продолжалась уже на них.
Для того, чтобы HD все-таки оказался в релизе, мы решили вернуть в скоуп запланированную и обрезанную ранее фичу под названием Delivery System. Она позволяет докачивать ресурсы игре из стора и CDN, а также потенциально разделять контент на уровни и выливать хотфиксы контента без релиза версии в сторе. Подробнее о ней мы расскажем в следующий раз. Улучшения ремастера на этом не заканчиваются, и он продолжает жить своей насыщенной жизнью.
Подводя итоги
Нужно очень тщательно следить за размерами билда в сторе: это важный показатель, который варьируется от проекта к проекту и очень сильно зависит от вашей аудитории. Если Fortnite можно докачивать 10 ГБ на блокирующем игру экране, вовсе не значит, что это подойдет и вашему проекту. Обязательно нужны исследования. Можно попробовать искусственно увеличить размер билда, даже просто вставив заполненные мусором файлики, и последить за метриками.
Важно понимать, что основной контент в играх — это почти всегда текстуры. Нужно особым образом следить за ними, их размерами и сжатием, чтобы они не критично увеличивали вес билда. Автоматизировать их импорт. Всегда исходить из того, чтобы отбрасывать лишнее.
Отдельно хочется упомянуть Vulkan. Мы долго ставили на эту технологию: изначально она давала очень хороший буст по графическому перформансу. Но получилось так, что с ее реальной поддержкой в мире оказалось довольно плачевно. Мы не теряем надежд воспользоваться ей в будущем, но пока приостановили эти работы.
Что еще важно, и, пожалуй, наиболее важно — это командная работа. То, в какой обстановке происходил релиз, нельзя описать словами. С одной стороны, может показаться, что релизы с такими изменениями очень опасны, и подрыв метрик столь крупного проекта — это не просто рискованная, но фатальная затея. Тем не менее, все, вплоть до директоров, понимали, насколько важно донести до пользователей эти изменения и насколько важно изменить процессы в отведенное под релиз ремастера время. Все помогали со своей стороны как могли и поддерживали команду разработки. И в этот момент не ощущалось давления, напротив — появлялось чувство, что ты работаешь в одной сплоченной команде с огромным количеством очень крутых специалистов, которые готовы найти решение любой проблемы. Командная работа в итоге привела релиз к успеху, пусть и спустя 8 хотфиксов.
