Разработка игры

9 пунктов, которые надо сделать до начала разработки игры

  • Facebook
  • Twitter
  • VKontakte
  • LinkedIn
  • Email
  • RSS

Какие вопросы должен задать себе каждый, перед тем, как начать разработку новой игры? Задать вопросы и найти ответы. Эти ответы, будучи задокументированными, образуют фундамент для продуктивной работы над проектом, страхуют от переделок и срывов сроков.

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

Целевая аудитория заметки: 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 — узнать инсайд