Какие вопросы должен задать себе каждый, перед тем, как начать разработку новой игры? Задать вопросы и найти ответы. Эти ответы, будучи задокументированными, образуют фундамент для продуктивной работы над проектом, страхуют от переделок и срывов сроков.
В моем багаже опыта среди прочего, есть два противоположных кейса, по разработке приложения с нуля. Один провальный, второй — нет. В первом случае ни у меня, ни у моих коллег не было опыта подготовительной работы и мы пилили игру, используя эвристический подход, основанный на тематической литературе и здравом смысле. Во втором случае, наученный горьким опытом, я перенял опыт топовой американской компании, чье имя не могу озвучить в рамках договоренностей. Этот подход заключается в качественной подготовительной работе, которая даёт возможность на ранних этапах создать базу для дальнейшей разработки.
Целевая аудитория заметки: stakeholders, product owners, producers, game designers, indie, startups
0. Ожидаемые KPI
Вначале стоит изучить рынок, и понять, чем он дышит. Стоит посмотреть на показатели потенциальных конкурентов: игры топ гроссинга, вновь вышедшие игры — динамику их развития и модель выхода. Имеет смысл понять топовые и средние показатели рынка в разрезе:
- ARPDAU
- pU
- Ret 1D, 7D, 28D
- LT
- CPI
Эти данные в открытом виде практически не возможно получить, если у вас нет инсайда. Я могу посоветовать обратится за помощью к знающим коллегам, например на сайте quora.com. На этом ресурсе собралась такая аудитория, которая готова делиться знаниями. Это происходит не быстро, и первый ответ на вопрос «Какой k-фактор у игр жанра HO?» вы получите в течении 2х — 3х недель.
Также такую информацию можно собирать по крупицам на тематических топовых сайтах, которые висят у меня на сайте в закладках слева.
1. GDD — ранняя версия
Документ, в котором уже на начальном этапе прописывается концепция игры:
- Сеттинг
- Основная игровая механика
- Саб-механики игры
- Обвесы для вовлечения, монетизации, ретеншена и виральности
- Игровая экономика и баланс
На этом этапе GDD не содержит полностью расписанных задач, по реализации механик, подготовки интерфейса или создании диалогов для персонажей — это требование к библии игры. Однако в нём чётко прописана модель дневного бонуса, например. Будет ли это накопительный бонус, будет ли он аннулироваться, и на сколько ценные подарки в нем будут. Ваш Продюсер или Геймдиз должен четко представлять каждый компонент игры, его механику и назначение.
2. User Experience Flow
Этот документ отображает все зависимости, связи, блоки, из которых состоит игра. UXF чаще всего состоит из диаграмм и блок схем. Для реализации требуется полностью представить себе игру в голове, затем перенести все её процессы в алгоритм в виде блок схемы.
В начале вы рисуете основной цикл, не углубляясь в детали: начало — прелоадер — логин — дейли бонус — лобби — игра / IAP / социалка и так далее. Затем каждый компонент вы декомпозируете и создаете для него отдельный алгоритм. Чем больше в вашей игре функционала, тем больше разделов будет в вашем UXF.
Для создания таких алгоритмов я использую cacoo.com и gliffy.com, однако вы можете пользоваться любым удобным сервисом, который позволит вам быстро и комфортно рисовать блок схемы. Если будет вдохновение, напишу отдельную статью о создании UXFlow.
3. UI Wireframes
Это документ который предопределяет работу дизайнера интерфейсов на начальном этапе. Начать стоит с карты экранов, а затем кратко описать каждый из них.. Также не стоит пренебрегать мокапами экранов, они точно лишними не будут и помогут понять как вам, так и дизайнеру общую картину игры.
Почитать о карте экранов и задачах по UI
Для составления документа я использую всё те же cacoo.com, gliffy.com и удобный moqups.com.
4. AERM worksheet
Acquisition, Engagement, Retention and Monetization — компоненты игры, которые должны быть продуманы и прописаны до начала работы над игрой. Каждый из этих компонентов следует расписать в разрезе 3х блоков
- Core Loop
- Metagame
- Social Features
В итоге у вас получится такая таблица:
| Core Loop | Metagame | Social Features | |
|---|---|---|---|
| Acquisition | Как вы приобретаете пользователей при помощи ядра игры? | Как метагейм привлекает игроков? | Как социальные компоненты привлекают игроков? |
| Engagement | Как вы вовлекаете пользователей при помощи игровых циклов? | Что будет мотивом для пользователей оставаться в игре? | Что социальные функции делают для вовлечения игрока в игровой процесс? |
| Retention | Как игра возвращает игроков снова и снова? | Как метагейм возвращает игроков? | Какие социальные компоненты игры направлены на возвращение пользователя? |
| Monetization | Как монетизируется игра? | Что стимулирует пользователя платить? | Как социальные обвесы способствуют монетизации? |
Если у вас нет ответа для какого либо блока из этой таблицы, не стоит начинать работу над проектом, и продолжить ресерч.
5. SDD
На сегодня социальные механики нужны во всех областях разработки: от игр до е-коммерс. Это продиктовано высокой стоимостью трафика, который окупается только при высоком k-факторе, хороших виральных механизмах.
В этом документе следует на базовом уровне расписать:
- сети для коннекта и способ коннекта
- способы приглашений
- способы публикаций
- open graph возможности и рейтинг в facebook
- возможности фан-страницы
- принципы создания ссылок для раздачи подарков
- пуши и уведомления
- e-mail рассылки
6. Prototype plan
План рабочих прототипов должен быть основан на экспертной оценке архитектора приложения. В основу плана закладываем «точки не-возврата» по архитектуре и функционалу. Этот план составляется без дат, так как сроки зависят от состава команды и её квалификации.
Формат плана такой:
- # Code Name
- functional list
- critical
- must have
- additionally
7. Art style guide
Краткий обзор художественного стиля игры в виде скетчей, мокапов и примеров колористики. В ASG следует включить:
- концепт-арт, сеттинг, макеты
- цветовая палитра
- шрифты
- примеры интерфейса и его отдельных элементов (кнопки, рамки…)
- эффекты (арт и программные анимации, тени, прочее)
- стилистика персонажей
- примеры фонов
- примеры игровых значков (иконок)
- mood-board
8. TDD
Техническая информация о приложении: архитектура, информация о используемых технологиях, особенностей платформ и прочая техническая информация изначально заносится в технический док.
- технологии клиент/сервер
- платформы и девайсы
- вес приложения
- использование памяти
- разрешения экранов
- скорость работы/загрузки
На составление такой документации достаточно 2х недель работы компетентного геймдиза, одной недели опытного иллюстратора, и нескольких дней планирования архитектора. Это время, затраченное до активной фазы продакшена поможет выбрать лучший формат команды, сэкономить время в процессе разработки, исключить переделки.
Стартапы и инди разработчики зачастую пренебрегают предварительной фазой разработки, что приводит к неудачам и тупиковым ситуациям. Настоятельно рекомендую адаптировать эти 10 пунктов для проекта, который уже находится в стадии продакшена, это сохранить вам деньги и нервы.
Ссылки из теме:
- cacoo.com — рисовать UXF
- gliffy.com — рисовать карту экранов и диаграммы
- moqups.com — рисовать мокапы
- quora.com — узнать инсайд
