Отличие MMO от синглплеерных игр в том, что при правильном подходе к оперированию такие проекты могут существовать долгие годы, сохраняя и даже наращивая крепкую базу лояльных игроков. Это долгоиграющий продукт, работа над которым ведется постоянно, тем самым позволяя ему всегда оставаться актуальным.
Идея GaaS — Game as a Service — неразрывно связана с понятием MMO. Именно по этому принципу мы оперируем своим мобильным PvP-шутером War Robots: такие игры с обновлениями получают постоянный поток нового контента и фичей на основе обратной связи с комьюнити. Это позволяет игре оперативно учитывать пожелания игроков и задавать новые тренды. В то же время модель GaaS усложняет внедрение в игру глобальных изменений, таких как ремастеринг графики — ведь продукт не прекращает жить своей жизнью, пока вы год готовите обновление. Тем не менее, такие изменения необходимы, когда речь идет об играх-«долгожителях».
War Robots исполнилось семь лет. Это немало и для «большого» ПК-проекта, а в случае мобилок и вовсе ломает представления о типичной продолжительности их жизни. Когда игра только вышла, рынок был наводнен match 3 и фермами, и входить на него с mid-core шутером было весьма рисково. Но вот мы здесь: рынок давно изменился, а War Robots все еще остается лидером в своем сегменте.
Чтобы сохранять позиции, мы постоянно актуализируем игру, что становится все сложнее делать с графикой семилетней давности. Так мы пришли к мысли, что настало время и ее подогнать под стандарты современных устройств, тем самым задавая планку себе и другим — и вдыхая в проект новую жизнь.
Ремастер ― фича или проект со своей командой?
Итак, мы решили делать ремастер. Понятие это не новое, но к мобильным играм до этого не применявшееся. Но мы решили принять этот челлендж.
В первую очередь стоит пояснить, что же такое ремастер. В разрезе видеоигр это переработка графики без изменения кор-геймплея игры.
Первым делом возник вопрос, как мы хотим реализовать эту идею. Как большую, комплексную фичу? При таком подходе она будет в постоянном конфликте с другими фичами с более коротким time-to-market и более четким business value. Как следствие, команде будет некогда ей заниматься, и сроки будут постоянно сдвигаться. Так себе сценарий, которого хотелось бы избежать, если мы задались целью выпустить обновление графики в обозримом будущем, а не когда-нибудь через несколько лет.
В результате удалось убедить руководство студии и инициировать War Robots Remastered как отдельный проект со своей командой и целью:
«Привлечь новую аудиторию к продукту War Robots, вернуть старую и повысить вовлечение текущей базы игроков. Для этого подготовить Remastered-версию продукта и раскатать релиз в продакшн на мобильных платформах App Store and Google Play до конца Q3 2020».
С целью проекта определились. Можно начинать собирать команду и приступать к оценке скоупа работ.
Как оценить объем работы, которую раньше никто не делал
Нужно было определить, что вообще нужно реализовать в рамках ремастера. Точного ответа у нас не было: мы не могли опираться на релевантный опыт коллег, и никто до нас не делал ничего подобного — раньше успешных мобильных ремастеров такого размаха не было. В самом начале мы не знали, какой объем работ нас ждет. Суть современного ремастера в том, что ты не можешь просто сделать крутую текстуру и использовать ее на старых моделях — тебе нужны новые рельсы пайплайна создания контента.
Почему? Нельзя из старых технологий выжать крутую картинку на высоких FPS. Чтобы сделать level-up продукта, необходимо совершить апгрейд технологической базы. Невозможно создавать новых мехов с текстурами высокого разрешения и кучей полигонов на старой базе: ведь робот постоянно передвигается, ведет бой, на карте их 12 — по 6 в каждой из соперничающих команд, — и девайс должен просчитывать все их действия, эффекты и партиклы сражения. Если делать так, как описано выше, на выходе будет очень низкий фреймрейт даже на топовых девайсах — то же самое, как если попытаться запустить на GeForce GTX 750 игру 2020 года.
Кроме того, у нас было запланировано несколько пресетов графики взамен единственного, что был на тот период. Прогресс процессоров за 7 лет существования проекта шел экспоненциально, а потому нельзя использовать одни и те же ассеты для топовых и лоу-энд девайсов. Например, на самых старых устройствах даже карту нормалей — всего-то дополнительную текстуру для освещения! — добавить было уже сложно. Да и треугольников рендерить они могут в кадре гораздо меньше. Поэтому потребовалось разделение на качества не только по количеству графических эффектов и качеству шейдеров, но и по самим ассетам.
Чтобы при ремастеринге меха не создавать трех разных роботов — по одному на каждый пресет качества, — нужно было изменить пайплайн, с помощью которого роботов в HD-качестве просто даунскейлить до MD и LD. А ведь таких роботов у нас 81 штука, не говоря уже дополнительно о 109 пушках и 83 элементах снаряжения. Мы хотим, чтобы наши игроки могли продолжить играть в War Robots — а для этого нужно, чтобы на их текущих девайсах игра выглядела круто, и не было сильной просадки FPS. Мы довольно быстро стали понимать, что для этого нам необходим технологический стек, тянущий на AAA.
В результате нам нужно было проделать следующее:
Создание трех пресетов качества: LD — низкое качество для low-end девайсов, MD — среднее, HD — высокое;
Рефакторинг роботов, пушек, карт и системы эффектов: переход на новый пайплайн создания и перевод единиц контента для разных пресетов качества;
Ремастеринг роботов, пушек и карт: пересборка всех существующих и создаваемых единиц контента в игре для каждого пресета качества, в том числе анимаций; полное пересоздание 4 из 13 карт, а впоследствии и остальных;
Освещение на старых картах: обновление технологий освещения и тюнинг оставшихся карт;
Оптимизация UI: рефакторинг UI-ассетов, интеграция упрощенных UI шейдеров;
Новые атласы текстур: рефакторинг атласов, реорганизация директорий в проекте;
Новые визуальные эффекты: создание новых VFX для пушек, мехов и карт, разные эффекты для разных пресетов качества; для VFX — еще и новый движок;
Перепаковка всех ресурсов проекта для использования других механизмов дистрибуции продукта из сторов к игрокам;
Графический кодинг: внедрение стека новых технологий и выполнение работ по созданию и оптимизации крутого графония на экране как мобильного устройства, так и ПК; сердце всего ремастера.
Как оценить время, которое займет выбранный объем работ
С объемом задач разобрались. Но как оценить то, что до этого никто из нас не делал — и вообще никто не делал? Трудоемкость работ, размер команды? Не сможем сделать это правильно — рискуем не уложиться в срок и либо выкатить сырой продукт, либо нарваться на перенос.
Можно ли оценить весь ремастер на старте?
На самом деле, измерить можно все. Это зависит от целей и решений, для принятия которых требуется оценка. Но всегда удобнее оперировать менее комплексными сущностями.
Сначала мы определяем блоки работ, из которых будет состоять проект, и что мы хотим получить на выходе. После чего производим декомпозицию этих блоков на верхнеуровневые эпики и оцениваем их, а затем делим все это на задачи и подзадачи. Но на старте такая декомпозиция невозможна, не нужна и даже вредна.
Поэтому действуем по следующей схеме:
Решаем, что мы хотим сделать и что получить на выходе;
Декомпозируем;
Оцениваем результат эмпирически и с помощью экспертной оценки лидов, которые закреплены за конкретными блоками работ;
Накладываем буферы неопределенности и помним: все, что может пойти не так, наверняка пойдет не так, и придется корректировать оценки.
Допустим, после первичной оценки вы пересобрали на пробу 10 мехов, отлогировали время, аппроксимировали его. И…. не попали в общую оценку.
Причиной тому могут быть, к примеру, постоянные изменения в технологическом стеке, в который то и дело добавляется что-то новое, в связи с чем ваш «залитый в бетон» план теряет свою релевантность.
Какое решение? Идти путем итераций.
Мы выбрали однонедельный интервал итераций, который завершался внешним тестированием пересобранного контента: так наглядно было видно, сколько еще нужно пересобрать мехов и пушек, наши слабые места, на чем сделать акцент, если мы хотим завершить определенные блоки работ вовремя. Некий burn-down для мехов, пушек и эквипа.
Но даже действуя таким образом, всегда можно промахнуться с оценкой. Поэтому нужно учитывать возможные риски, закладывать буфер на неопределенность — и быть готовым, даже этого может не хватить, особенно если речь идет о чем-то с высокой степенью уникальном.
Риск-менеджмент, или как вырабатывать меры раньше, чем придется тушить пожары
Зная, с чем нам предстоит работать, мы примерно можем представить, с какими проблемами можно столкнуться. Пока ни одной из этих проблем не произошло, это риски, которые мы в состоянии учесть и сделать все возможное, чтобы их предотвратить или уменьшить негативное влияние на проект.
Риск — это будущее вероятностное событие, на случай которого можно составить стратегии по:
уклонению;
уменьшению его вероятности или последствий в случае, если событие все-таки произойдет;
передаче третьей стороне;
принятию (активному или пассивному).
В этом его отличие от проблемы, на которую уже не выработаешь никакой меры: ее нужно решать здесь и сейчас. Обычно это дороже и оборачивается куда более критичными последствиями.
Матрицу рисков стоит составить еще на этапе инициации проекта, а затем постоянно актуализировать. В нее вносятся все возможные будущие события, степень их влияния на проект, стратегии реагирования, а также лица, ответственные за реализацию выработанных мер:
Что делать, если со своим объемом работ вы не вписываетесь в заданный дедлайн
Легко попасть в ситуацию, когда планы монументальные, хотелок много, а времени мало. Что же делать в таком случае?
Например, учиться от чего-то отказываться.
Если ты хочешь уложиться в назначенные сроки — либо изменяй скоуп работ, либо увеличивай пропускную способность команды и набирай больше людей.
У нас было и так, и так: когда-то мы планово увеличивали команду, когда-то меняли сам скоуп. Можно привлекать людей вне команды на время, чтобы увеличить ее пропускную способность для решения конкретных краткосрочных задач.
Еще один способ увеличения пропускной способности команды — кранчи, но стоит помнить, что это обоюдоострый инструмент, который почти всегда означает последующее падение перформанса команды, а при злоупотреблении — еще и выгорание. Это постоянная работа: ты не можешь все запланировать заранее и действовать строго в соответствии с первоначальным планом. Он не залит в бетон, и нужно быть готовым к его постоянной балансировке и актуализации.
Установка правильного контекста. Как постоянно менять план и не шокировать этим команду
Чтобы команда чувствовала себя комфортно и не фрустрировала от постоянных изменений, нужно правильно доносить до нее информацию — устанавливать контекст. Это как улица с двухсторонним движением с точки зрения менеджмента. В то время, как менеджер полагается на команду, что она выберет наилучшее техническое решение, команда полагается на менеджера, что он будет снабжать ее необходимой и своевременной информацией, в том числе об изменениях в плане работ. Как UI-дизайнеру узнать, что ему не нужно создавать какие-то иконки, или художнику — конкретные пропсы на такой-то карте? Задача хорошего менеджера — своевременно уведомлять команду об изменениях, которые для них важны, но не перегружать информацией.
Так, мы не планировали делать Ultra Low-пресет качества, но были вынуждены к нему прибегнуть, потому что тесты показали, что текущие лоу-энд девайсы не тянут даже LD. Новый пресет качества — отдельная работа. Невозможно впихнуть ее в те же сроки, что и раньше. Что делать в таких случаях? Мы делаем этот пресет, но отказываемся от какой-то другой работы. Нужно изначально быть готовым к тому, что при всей точности оценок — а это мало достижимо со 100% точностью, — границы между обязанностями двух команд одного продукта могут размыться и требовать постоянного уточнения. При этом изменения в roadmap одного проекта будут влиять на roadmap другого.
В правильном контексте хорошо информированная команда может сосредоточить большую часть своего времени и энергии на создании лучших продуктов. В свою очередь, его установление — неотъемлемая обязанность менеджмента.
Подводя итоги: что стоит учитывать на этапе предпродакшена
Необходимо закладывать буфер на неизвестность на старте.
Лучше идти итерациями, постоянно тестируя результаты своей работы по мере готовности и актуализируя первоначальную оценку.
Уметь признавать ошибки и быть готовыми к изменениям вместо того, чтобы упорно следовать первоначальному плану.
Управлять рисками на стадии препрода еще при инициации проекта и продолжать на последующих этапах продакшн.
Стоит выделить одного ответственного человека за каждый фронт работ.
Постоянно устанавливать правильный контекст, чтобы команда была в курсе того, что происходит.
Автор материала ― Дмитрий Осипов, ведущий руководитель проектов War Robots и War Robots Remastered
