Этапы разработки игры для мобильных платформ

Ананькин Сергей, продюсер компании Pixonic, написал вводную статью, описывающую этапы разработки мобильной free-to-play игры. С разрешения автора мы публикуем ее на страницах App2Top.ru. В будущем Сергей планирует написать целый цикл материалов, посвященный созданию мобильных игр.

1. Этапы разработки проекта

На схеме ниже отражены этапы разработки проекта с их характерными длительностями и размерами команды, а также события, отделяющие эти этапы.

При разработке проекта «от и до» могут быть выделены следующие этапы:

• Этап «Альфа». Продюсер проекта получает задачу от руководства (иногда — принимает участие в её формировании), разрабатывает концепцию (т. е. начальное описание) нового проекта и собирает начальную (альфа-) команду для его реализации;
• Этап «Пре-продакшен». Альфа-команда выявляет потенциальные риски для проекта и либо устраняет их, либо демонстрирует способность устранить их в будущем. Продюсер составляет план производства проекта, формирует полную команду разработки. Пишется проектная документация. Разрабатывается прототип проекта.
• Этап «Софт-ланч». Прототип проекта расширяется командой разработки до полноценной версии игры в соответствии с составленным планом и проектной документацией. Этап заканчивается выпуском ранней версии игры для выбранного рынка. Обычно такая версия содержит 30–50% от полного количества игрового контента и отличается от предыдущих технических версий большой стабильностью работы и малым количеством ошибок.
• Этап «Хард-ланч». Собирается статистика по ранней версии игры, с учётом этой статистики игра приводится к поздней версии, выпускаемой на все выбранные рынки. Выбирается маркетинговая стратегия, формируется план дальнейшего улучшения игры.
• Этап «Поддержка». Формируется команда поддержки (как правило, это часть команды разработки) для выпуска последовательных обновлений с учётом статистики. Продюсер продолжает работу на проекте в качестве консультанта, перекладывая основные задачи на гейм-дизайнером команды поддержки.

2. Этап «Альфа»

• Начало этапа. Продюсер получает от руководства (или помогает сформировать) первичную задачу — то есть набор условий для старта проекта и список предъявляемых к проекту требований. В качестве условий обычно выступают: желаемый масштаб проекта (например, маленький или наоборот — масштабный долгострой), требуемые сроки разработки (например, не более полугода), условия финансирования (к примеру, не более $300 тыс. на всё), заранее выбранные технологии и свойства команды (например, компания хочет делать проект на Unity из-за наличия своих адаптаций движка и опытных в работе с Unity программистов). Требованиями являются показатели проекта в вопросах удержания, привлечения и монетизации входящего траффика (например, игра должна обеспечивать 50% входа игроков на седьмой день игры и зарабатывать в день не менее ста тысяч долларов).

Часто, однако, проект начинается не с чётко сформулированной задачи, а с предложения продюсера. Так, начиная разработку одного из наших проектов — игры Renaissance — мы для начала сформировали идею несколькими словами: тактический mid-core шутер-survival в сеттинге пост-аппокалипсиса. На альфа-этапе руководство помогло нам сформировать концепцию проекта с учётом пожеланий компании.

• Цель этапа. Продюсеру необходимо получить и утвердить у руководства концепцию проекта и состав альфа-команды.
• Течение этапа. Продюсер формирует концепцию проекта — т. е. любое описание, дающее информацию о том, как в заданных условиях проект удовлетворит предъявленным к нему требованиям. Концепция обычно включает описание целевой аудитории, сеттинга и жанра игры, ключевых (возможно, уникальных) особенностей геймплея, методик разработки, инструментария и технологических решений, рынков сбыта, поддерживаемых платформ, сроков и стоимостей реализации, требований к команде разработки. Одним из ключевых факторов успеха на данном этапе является анализ текущей ситуации на рынке — отслеживание существующих трендов, обозрение наиболее успешных проектов, выбор новых инструментов разработки для освоения и т. д.

Утверждение концепции — это почти всегда итерационный процесс. Для утверждения концепции игры Renaissance (в силу запланированной масштабности проекта) нам понадобилась дюжина совещаний с привлечением большинства продюсеров компании, причём не только с мобильного направления. По итогам каждого совещания концепция претерпевала изменения, иногда существенные.

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

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

• Длительность этапа. Как правило, проработка первого варианта концепции укладывается в одну или две недели. В случае несоответствия концепции требованиям руководства возможно итерационное улучшение концепции. Каждая последующая итерация занимает неделю, а общее количество итераций (включая первую) составляет 3–4. Таким образом, этап «Альфа» занимает от двух до пяти недель.

При определении срока этого этапа следует, как мне кажется, исходить из масштабности и сложности (в каком бы то ни было смысле) предлагаемого проекта. Если проект выполняется в принципиально новом жанре или обладает уникальным геймплеем, то это также накладывает отпечаток на время разработки и утверждения концепции. Так для утверждения концепции Renaissance нам потребовалось два месяца, в то время как концепция проекта Lost it Baliboo была утверждена менее чем за неделю.

3. Этап «Пре-продакшен»

• Начало этапа. Продюсер и альфа-команда выявляют наиболее существенные потенциальные риски для проекта. Риски могут порождаться игрой (будет ли интересен геймплей? соответствует ли графика целевой аудитории? пойдёт ли игра на выбранном девайсе?), менеджментом (успеем ли мы сделать описанную игру за отведённый срок? сколько мы потратим денег?) или командой (справится ли команда со сроками, сможет ли исчерпать все риски?).

Набор выявляемых рисков сильно зависит от проекта. Например, в нашем текущем проекте Lost in Baliboo основным риском для минимизации было качество графики, поскольку механика и технические решения проект наследовал от своего предшественника Robinson Island.

• Цель этапа: минимизация найденных рисков путём проектирования прототипа игры, разработки и детализации проектной документации, составления плана разработки на следующие этапы.
• Течение этапа. Риски, предъявляемые к игре, минимизируются с помощью создания прототипа (начальной версии игры, содержащей примеры функционала, графики или других рисковых аспектов). Риски менеджмента минимизируются путём составления продюсерского плана (т. е. описания процесса разработки с привязкой ко времени) и требований к команде разработки (размер, структура, свойства участников). Риски команды минимизируются выбором уже освоенных технологий, а также команд, имеющих опыт выпуска похожих проектов, либо использования этих технологий.

Разработка прототипа может быть также итерационным процессом, если того требует проект. В Lost in Baliboo (проекте с минимальными рисками) прототип был продемонстрирован и утверждён лишь в конце этапа, в то время как в выпускаемом в данный момент Walking War Robots геймплей и управление демонстрировались всему офису каждую неделю, чтобы убедиться в удачности проектных решений.

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

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

4. Этап «Софт-ланч»

• Начало этапа. Продюсер и команда разработки решают оставшиеся вопросы по методикам разработки, организации рабочего процесса, инструментарию и т. д. Затем начинается процесс разработки по утверждённому продюсерскому плану.

Говоря о разработке по продюсерскому плану, можно выделить набирающий обороты на западе подход с названием Global Oriented Roadmap, который используется нами в находящихся в разработки проектах Renaissance и Caribbia. В таком плане этапы разработки (soft launch и hard launch) делятся на под-этапы. Для каждого из таких под-этапов определяется дата демонстрации, ключевые фичи, реализуемые на этапе, и сформулированная одним предложением цель этапа. Такой roadmap позволяет держать процесс разработки «гибким» в деталях, иметь локальную цель для команды, а также делает процесс разработки лёгким для контроля руководством компании.

• Цель этапа заключается в разработке первой полноценной версии игры, которая будет выпущена для небольшой начальной аудитории, чтобы собрать статистику и увидеть потенциал проекта.

Контр-примером может выступать проект Robinson, который не проходил этап soft-launch и был выпущен для широкой аудитории сразу с обширной рекламной кампанией (см. hard launch). Такая парадигма заранее была определена маркетинговым отделом кампании из-за факторов вроде дешевизны и сжатых сроков разработки проекта.

• Течение этапа. Команда работает над получением так называемой soft-launch-версии — первой версии игры, которая станет доступна выбранному множеству игроков (как правило, это множество — определённый сегмент определённого рынка). Обычно существует список требований, которые компания предъявляет к такой версии. Эти требования формулируются как определённые статистические показатели, которых должна достигнуть игра в определённые сроки после своего выпуска: retention (т. е. способность игры задержать игрока в игре на 1, 2 и т. д. дней), конвертация (т. е. доля игроков, которые совершают платежи внутри игры), средний чек (размер среднего платежа) и средняя частота платежей. Все эти параметры являются ключевыми при расчёте так называемого life time value — среднего заработка с одного игрока за всё время его пребывания в игре.
• Окончание этапа. Когда статистическая картина проекта после запуска уже видна, руководство принимает решение о дальшей судьбе проекта. В худшем случае это закрытие проекта как не имеющего потенциала, а в лучшем — переход к следующему этапу.

Выпуск игры на рынок является рубежом этапа soft launch, но не его формальным окончанием. Проект может проходить несколько итераций доработок, прежде чем можно будет принять решение о его развитии (т. е. о переходе к следующему этапу). Проект Soccer Tactics претерпел целый ряд обновлений (суммарно, за два месяца) после раннего выпуска, прежде чем состоялся его релиз для широкой аудитории.

• Длительность этапа: в зависимости от критериев, предъявляемых к open beta, этап может занимать от 40 до 80 процентов времени, оставшегося с момента окончания пре-продакшена до мирового релиза. К примеру, для проекта общей продолжительностью в шесть месяцев из оставшихся после пре-продакшена пяти месяцев софт-ланч может занять от двух до четырёх месяцев. Если компания хочет выпустить совсем раннюю версию, чтобы начать собирать статистику как можно раньше, это будет случай с двумя месяцами, а если сбор статистики предполагается на этапе почти законченной игры — это будет случай с четырьмя месяцами.

Как и всегда, возможны варианты. Как было описано выше, проект Robinson вообще не имел этого этапа. Доходы от первых рекламных кампаний показали необходимость наращивать рекламные обороты без доработок проекта.

5. Этап «Хард-ланч»

• Начало этапа. Когда статистическая картина soft-launch-версии удовлетворяет поставленным критериям, команда разработки начинает готовить более полную версию игры для запуска на все возможные рынки. Список дополнений и изменений в проекте состоит как из запланированных заранее работ, так и из выявленных по результатам сбора статистики.

Например, изначальная статистика soft launch-версии проекта Soccer Tactics показала проблемы совсем не в тех местах, в которых они ожидались командой. Из-за этого после soft launch список предполагаемых доработок проекта к hard launch был существенно переформирован.

• Цель этапа: подготовить версию игры для мирового релиза, т. е. выпуска на все запланированные рынки и аудитории.
• Течение этапа. Все изменения, как правило, вносятся в игру постепенно, пока она продолжает быть доступной для скачивания аудитории софт-ланча. Каждое такое изменение меняет статистику проекта, что может отразиться на списке задач.

Проект Soccer Tactics разрабатывался с чётким учётом статистической картины софт-ланч версии. Так из-за большого оттока игроков на ранних этапах игры (что отразилось в так называемых воронках — показывающих, когда игроки уходят из игры) команде пришлось свернуть все остальные работы и сосредоточиться исключительно на правках первой игровой сессии, туториала и начального userflow.

• Окончание этапа: Когда статистическая картина текущей версии игры удовлетворительна, происходит т. н. хард-ланч — т. е. запуск полноценной версии игры для всех выбранных рынков. Статистическая картина проекта после этого определяет судьбу проекта. Как правило, этап «хард-ланч» проходит несколько одинаковых циклов, на каждом из которых текущая статистика определяет фронт работ для команды разработки и влияет на выбор маркетинговой стратегии.

Здесь необходимо понимать, что soft-launch и hard-launch — не чёрное и белое. Размер рекламного бюджета определяется (в том числе) текущими показателями игры и не обязан быть минимальными или максимальным. Robinson Island начал релиз с малым рекламным бюджетом, но показал столь хорошую отдачу, что бюджет мгновенно вырос во много раз (поэтому мы по сути и говорим только о hard-launch’е этого проекта).

• Длительность этапа: всё оставшееся время до мирового релиза. В случае раннего софт-ланча это — 60 процентов от времени между окончанием пре-продакшена и мировым релизом, а в случае позднего софт-ланча — 20 процентов.

Процентное соотношение длительностей soft- и hard-launch’а определяется проектом и опытом команды и компании. Lost in Baliboo, из-за минимума рисков и своего малого масштаба, был выпущен уже через три месяца разработки, в то время как софт-ланч проекта Dwarves Tale был состоялся спустя 9 месяцев. При этом Baliboo вышел с минимальным функционалом, а Dwarves (несмотря на неудачу софт-ланч версии) содержал большую часть игровых механик и контента.

6. Этап «Поддержка»

• Начало этапа. Если статистика проекта стабилизируется на удовлетворительной отметке, и проект перестаёт требовать существенных доработок и расширений, он отдаётся «на поддержку». Перед этим выбирается команда поддержки, которая часто является частью команды разработки.

При разработке Dwarves Tale судьбу проекта решила именно стоимость его поддержки. Жизненный цикл проекта оказался недолгим из-за большого размера команды, требуемой для поддержки. В то же время поддержка проекта Baliboo относительна дёшева, потому как осуществляется небольшой командой.

• Цель этапа: минимальными средствами поддерживать приемленый уровень дохода с проекта вплоть до момента, когда такой уровень становится объективно недостижимым.
• Течение этапа. Команда поддержки итеративно улучшает игру с помощью небольших дополнений (это либо контентные расширения, либо устранения ошибок, либо функциональные нововведения). Такие итерации с улучшениями могут продолжаться до тех пор, пока поддержка игры оправдана с точки зрения руководства.

Как правило, на этапе поддержки мы выпускаем контентные обновления. Для Baliboo и Robinson’а это прежде всего квест-паки, новые острова для освоения, новые персонажи. Новые механики вводятся редко и только за тем, чтобы исправить проблемы проекта, которые показывает статистика.

• Окончание этапа. Если дальнейшее обслуживание проекта становится по каким-либо причинам неоправданным, проект считается закрытым. При этом он может оставаться доступным для конечного пользователя, если это целесообразно и не требует участия команды поддержки.
• Длительность этапа во многом определяется свойствами проекта. Приемлемый срок целесообразной поддержки проекта равен году, тогда как два-три года можно оценить как очень хороший результат.

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

От редакции App2Top.ru: другие статьи компании Pixonic можно прочесть в разделе компании на нашем сайте.