Препродакшн игровых проектов: как оценить объем работ на старте и не сгореть к дедлайну

Отличие 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.

Так выглядели скриншоты Work in Progress
Так выглядели скриншоты Work in Progress

В результате нам нужно было проделать следующее:

  • Создание трех пресетов качества: 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

 

Источник

, ,

Читайте также

Меню