Читать книгу - "Как делать хорошие игры. От идеи до запуска - Петр Прохоренко"

задержкой по срокам или со значительным люфтом по концепции (о том, как все эти проблемы сказочным образом объединились в одной игре, я рассказывал в комментарии про проект Navy Power). Поэтому будет уместным посвятить еще пару страниц основным этапам разработки игрового проекта.

Истоки именно такой этапности лежат, вероятно, в Nival, а уже в процессе дальнейшей карьеры я ее адаптировал к мобильным проектам, у которых своя специфика. Мобильные игры требуют большей гибкости и более синтетического подхода (то есть элементы игры больше похожи на конструктор для того, чтобы, например, можно было быстро сменить сеттинг или мету проекта). Но в целом и ПК-проекты не станут хуже от большей управляемости. Весь процесс разработки разделен на 5 этапов (у каждого этапа указаны ключевые задачи, которые должны быть реализованы):

1. Preproduction – концепция продукта и команда;

2. First Playable – технология и базовый геймплей;

3. Alpha – экономические циклы и мета;

4. Beta – расширение контента и UI/UX;

5. Release Candidate – полировка и финализация продукта.

Непосредственно к этапу производства относятся 3 стадии: First Playable, Alpha, Beta. Preproduction уже был раскрыт в предыдущем тексте, а Release Candidate относится уже скорее к процессу оперирования, поэтому о нем будет в завершающей части книги.

Повторю еще раз, в чем мы должны удостовериться на каждом из этих этапов:

• First Playable – проект преодолел все возможные технологические риски (то есть он банально стабильно работает на целевой платформе), и проект «играется». То, что мы показываем на этом этапе, должно быть работоспособным и интересным в своем базовом игровом процессе.

• Alpha – на этом этапе добавляются экономика игры и мета-уровень. На этом этапе проект становится кардинально сложнее по своей структуре. Именно поэтому до этого усложнения базовые проблемы с игровым процессом и стабильностью должны быть решены.

• Beta – этап расширения проекта по контенту (то есть вширь, а не вглубь) и начало работы по выведению всех важных элементов игры на необходимый уровень качества. На этом этапе игра уже выглядит почти готовым рыночным продуктом, а часто даже запускается для проверки части гипотез на ограниченной аудитории.

Метаигра, или просто Мета, – в компьютерных и настольных играх представляет собой понятие, описывающее активности вне базового игрового цикла, но влияющие на ее игровой процесс. Нужно понимать, что не существует единого определения метаигры. Под этим понятием может подразумеваться анализ игроками происходящего в отдельных игровых партиях с целью улучшить свои результаты или решить проблемы в последующих. Также процесс подготовки к партии непосредственно не является частью игры и может рассматриваться как метаигра. Помимо этого, под метаигрой может пониматься введение разработчиками дополнительных элементов (достижений, дополнений, экономических циклов), которые не являются частью базового игрового процесса. Типовой пример распространенного элемента мета-игры – «боевой пропуск» (Battle Pass).

На самом деле границы у этих стадий нечеткие, и работа с метой игры, например, может начаться раньше First Playable и продолжаться до Release Candidate включительно. Но при всей нечеткости есть определенные реперные точки, которые позволяют четко отнести проект к той или иной фазе.

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

От альфа-версии мы ожидаем готовых блоков:

• Базовый геймплей – мы должны уже четко видеть по тестам, как играется, что привлекает игрока, что удерживает его краткосрочно (детали могут быть не доделаны, но понимание этого уже должно быть).

• Экономические циклы – особенно ключевые (на которых потом будет строиться монетизация игры).

• Мета-уровень – в принципе, мы должны понимать, на чем его выстраиваем, он обычно к этому моменту не готов, но уже продуман в дизайне.

На практике мета-уровень мы можем корректировать уже после этого этапа. То есть маркером готовности альфа-версии является статус, когда основные элементы игры сложились. По контенту это довольно сложный вопрос, тут важно, чтобы отсутствие контента не мешало получать релевантное впечатление от игры.

Как сделать хорошую игру, Способ № 14: Повторение – мать учения. Я надеюсь, что внимательные читатели уже заметили, что я трижды повторил одни и те же мысли по поводу смысла ключевых этапов разработки. Доносите важные мысли до команды постоянно, регулярно и последовательно. Не страшно прослыть душнилой, которая вдалбливает каждую неделю концепцию проекта всем лидам в головы. Страшно, если лиды не понимают, какую игру они делают…

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

Закрытый бета-тест (ЗБТ) – это, по сути, то же самое, что и «секретный запуск» в мобильных играх (запуск в сторе под «левым» аккаунтом или закрытый запуск по приглашениям). Основной критерий тут удержание игроков, если проект проходит жанровые бенчмарки, то в общем можно открывать игру на несколько территорий (то есть закрытый тест плавно превращать в открытый). На ЗБТ сложно проверить монетизацию, поэтому как самый базовый параметр используется ретеншен (удержание). То есть если ЗБТ выявляет, что очень большой отвал игроков идет в начале воронки, то, скорее всего, это сигнал, что надо проект пересматривать. Обычно к ЗБТ уже есть сформированная бизнес-модель, и команда должна довольно четко понимать, какой ретеншен 1–14 дней нужен, чтобы дальше двигаться.

Что является наиболее важным на каждом из этих этапов и какие критерии сильнее всего влияют на будущие результаты проекта в плюс или в минус?

Важнее всего не пропустить какие-то проблемы на старте воронки удержания, то есть попасть в аудиторию. Потому что базовые проблемы потом руинят все остальные метрики. То есть, например, у игры удержание первого дня меньше 30 %, и дальше все остальное тоже будет, скорее всего, плохо. Тут много деталей, зависящих от конкретного проекта (может быть, это хардкорная игра, которая хорошо монетизирует свою нишевую аудиторию, тогда при R1 ниже нормы у нее с ARPU будет все хорошо), но в целом – чем больше, тем лучше.

ARPU (average revenue per user) – это маркетинговая метрика, которая используется для измерения среднего дохода от каждого пользователя за конкретный период времени. Его можно посчитать, если разделить общий доход от всех потребителей на количество игроков. Не надо путать с метрикой ARPPU, показывающей средний доход только среди платящих пользователей.

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