Ремастер для MMO: параллельная разработка двух проектов при одном общем продукте

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

Ремастер для MMO: параллельная разработка двух проектов при одном общем продукте

Но прежде, чем приступить к описанию того, как происходила работа над ремастером, стоит упомянуть о его специфике.

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

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

Выстраиваем процессы коммуникации

Итак, у нас были:

  • проект ремастера со своей командой;
  • оригинальная игра с командой оперирования (10+ релизов в год), которую мы стали нежно называть «ванилькой» — так вообще часто называют оригинальные/изначальные версии ПО.

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

Ремастер для MMO: параллельная разработка двух проектов при одном общем продукте

Но самое важное — это общение.

Необходима регулярная коммуникация двух команд. Но собирать их все вместе — безумие, ведь суммарно у нас получалось в пике порядка 40 человек на ремастере и более 80 на «ванильной» версии. Поэтому в основном построение коммуникаций и участие в различных совещаниях строилось по принципу вертикальной передачи информации по ролям: в таком случае общий для двух проектов руководитель выполняет функции интеграции, а лиды — трансляции информации в команду и вопросов из команды.

В результате каждую неделю у нас были:

  • общий синк участников Remastered: присутствие лидов — обязательно, остальные могут присоединиться и задать вопросы опционально;
  • 3 синка core-команды для тех, кто занимается кодингом или техническим пайплайном War Robots Remastered;
  • синк-апы лидов двух проектов.

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

Построение пайплайнов продакшена

Коммуникации — не единственная особенность работы над двумя проектами с единым продуктом.

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

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

Какую еще специфику приходилось учитывать?

Из-за постоянных изменений технологической базы, готовность которой на старте тоже не имела явно выраженного майлстоуна, вытекала проблема в последовательности и взаимосвязи блоков работ, а именно — в возможности вести их параллельно. Лучше делать так, что сначала вы заканчиваете один блок, внедряете технологии, а потом на базе новых технологий создаете контент. Это правильно с точки зрения переработки тех же карт. Но тогда работа над проектом заняла бы не 11 месяцев, а несколько лет.

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

Работа над одной картой с учетом всех переделок может занимать до 8 месяцев
Работа над одной картой с учетом всех переделок может занимать до 8 месяцев

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

Как выглядели карты раньше и как стали выглядеть в ремастере

Что мы в результате внедрили

В рамках проекта мы:

  • переделали полностью 81 робота, 10 дронов и 109 пушек: у всех, даже самых старых предметов экипировки, теперь современные модели;
  • пересобрали с нуля 4 карты;
  • провели оптимизацию проекта, удалив ~400 дублей и неиспользуемых текстур и реорганизовав 14 UI-атласов;
  • создали 500+ новых текстур;
  • интегрировали физически корректный рендеринг (PBR), чтобы роботы и карты выглядели реалистичнее, — а это 30+ PBR-шейдеров;
  • переработали архитектуру визуальных эффектов: они стали красивее, но при этом менее требовательны к устройствам. И создали 300+ новых эффектов;
  • Провели более 20 внешних тестов.

Помимо этого, внедрили в проект стек технологий:

  • Metal API — с ним производительность игры может повыситься до 30% на современных устройствах Apple, FPS становится стабильней, а расход аккумулятора — экономнее;
  • Vulkan API — нужен в HD-пресете для повышения производительности на Android-устройствах и более плавного фреймрейта;
  • Custom SRP (Scriptable Render Pipeline) — позволяет пропустить ненужные этапы рендеринга и освободить ресурсы для эффективного улучшения качества изображения;
  • SRP batching для оптимизации производительности;
  • HDR (High Dynamic Range Rendering) для реалистичной и насыщенной картинки;
  • Lightmap/Lightprobe baking для симуляции достоверного освещения на больших открытых локациях;
  • Image post-processing для эффектов кинематографического уровня;
  • PBR (Physically based rendering) для создания реалистичных текстур;
  • Гибридные тени как компромисс визуального восприятия и производительности;
  • ECS (Entity Component System) для игровой логики и симуляции работы оружия, более устойчивой к изменяющейся частоте кадров;
  • Новый Quality Manager — менеджер качества, способный динамически определять настройки графики, оптимальные для конкретного устройства; помимо этого, дает возможность ручного выбора пресета графики.
  • Prefab Variants — технология вариантов шаблонов сборки контента для быстрого создания контента в нескольких качествах.
PBR, HDR и улучшенное освещение обеспечивают реалистичные отражения от поверхностей
PBR, HDR и улучшенное освещение обеспечивают реалистичные отражения от поверхностей

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

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

Пиковое значение аудитории внешних тестов — 10 тысяч игроков. Мы понимали, что когда мы выйдем в прод, аудитория может вырасти до 5 миллионов MAU (активной аудитории в месяц). А значит, есть вероятность того, что когда мы зарелизим ремастер в сторы, мы увидим картину, отличную от той, что мониторили на внешних тестах.

А потому мы решили раскатывать релиз в формате OpenBeta, что и анонсировали в своих комьюнити-каналах. Такая раскатка происходит на ограниченном количестве стран и помогает не зааффектить всю аудиторию — иначе, если на проде что-то идет не так, пострадают все игроки.

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

Итак, в первый день мы раскатали первую версию в Google Play на Россию. Почему именно Google Play? Это один из наших основных мобильных сторов наравне с AppStore. Но, в отличие от AppStore, на GP есть возможность раскатки обновления по ограниченному количеству стран и пользователей — допустим, на 5% российских пользователей. В AppStore тоже есть поэтапная раскатка, но устроена она по-другому — без возможности выбора конкретной страны.

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

По крайней мере, мы предполагали, что они будут. И не ошиблись.

После сбора данных мы подготовили новый апдейт и выкатили его в сторы на следующий день. Раскатали уже, помимо России, на 11 стран СНГ. И на основе получаемых данных c ежедневных апдейтов проводили анализ, обсуждали, приоритезировали и готовили решения по фиксам и оптимизациям.

Ремастер для MMO: параллельная разработка двух проектов при одном общем продукте

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

Разумеется, мы заранее знали, что размер игры в сторах существенно увеличится, и понимали, что это может стать критичным. Поэтому мы выработали на этот риск меру реагирования — создание Delivery System. Это система дистрибьюции продукта, с помощью которой можно подкачать необходимые пресеты качества к изначальному «тонкому» билду в сторах. Но с ее разработкой возникли сложности, и мы не успевали довести эту фичу в надлежащем качестве в установленный срок. Тогда следующей мерой должны были стать A/B-тесты для оценки влияния размера билда и времени установки игры на различные метрики. Но в процессе внутренних согласований мы пришли к тому, что отдел маркетинга сможет оптимизировать UA-кампании. И все же это не сработало. После раскатки на первые страны мы увидели резкое падение конверсии в установку: новых игроков отпугивал больший размер билда. Эффективность маркетинговых кампаний оказалась под угрозой.

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

Ремастер для MMO: параллельная разработка двух проектов при одном общем продукте

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

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

Ремастер показал, что это очень крутая практика, так что с тех пор мы используем поэтапную (Stage Rollout) раскатку для всех серьезных изменений продукта.

Как подготовиться к Apple Event, не отрываясь от основного продакшена

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

За два месяца до релиза часть core-команды ремастера стала заниматься сайд-активностью, связанной с возможной демонстрацией War Robots Remastered на ежегодной презентации Apple. На тот момент всего один продукт, созданный российской командой, смог добиться подобного. Шанс, который выпадает раз в жизни, и предложение, от которого нельзя отказаться — тем более, что вначале это выглядело так:

— Выделите мне двух разработчиков на три дня.
— Окей, но я не верю, что три дня вам хватит.
— Обещали, что на три дня.

Что было в результате:

Ремастер для MMO: параллельная разработка двух проектов при одном общем продукте

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

Ремастер для MMO: параллельная разработка двух проектов при одном общем продукте

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

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

Подводя итоги: какие практики хороши на этапе продакшена

  • Выстраивать процессы коммуникации с оптимальным временем участия членов команд, транслировать информацию из команды и в команду при помощи лидов и менеджеров.
  • Продумать заранее и согласовать с командами четкие правила мерджа ремастера и оригинальной версии, чтобы поддерживать в стабильном состоянии продукт.
  • Двойная работа по разработке ремастера при смене технологической базы в ограниченный срок — это нормально, нужно быть к ней заранее готовым и учитывать в планах.
  • Раскатка релиза в формате Stage Rollout — отличная практика, позволяющая отладить продукт прежде, чем раскатывать его на весь мир.
  • Активности, связанные с биздевом, маркетингом и PR, сложно запланировать на ранних стадиях, и лучше оставлять на них некий буфер, чтобы учесть влияние на основной продакшн.
  • Стоит реализовывать выработанные меры реагирования на идентифицированные риски, нежели полагаться на то, что решите проблему на лету, если она возникнет.

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

Ведущий менеджер проектов War Robots и War Robots Remastered
3333
29 комментариев

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

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

5

Спасибо за комментарий :) Оба этих скриншота уже после ремастера, но хорошая идея - добавили еще пару скриншотов, иллюстрирующую до/после.

2

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

4

А ведь дальше мы пишем, что сами свели количество обязательных синков к необходимому минимуму. И - по секрету - не провели во время разработки ремастера ни одной ретроспективы :)

6

Кайф, очень интересно. Прочитал обе статьи залпом.

3

Очень полезный материал - для профессионалов.

2

для начинающих, разве что, профессионалов. Но всё равно занимательно. Заафектили, но при этом раскатали.