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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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