В первой части статьи мы остановились на шаге 8 (Напомню, звучал он как “Формализация и дизайн”). Давайте с него и начнем: разделим этот шаг на несколько и распишем, что же происходит дальше, когда канва игровой идеи и список референсов у вас уже имеется.

Подчеркну, что в разных командах и в работе над разными играми (мобилки, ААА, браузерные платформеры, VR и т.п.) эти пункты могут отличаться. Сказывается как особенности платформы, для которой пишется игрушка, так и специфика жанра и аудитории. Могут появляться дополнительные шаги, что-то поменяется местами или вовсе будет пропущено. Поэтому не воспринимайте это как 100% руководство к действию, скорее как совет при ответе на вопрос “А что делать дальше?”. Надеюсь, многим из вас это действительно будет полезно=)

Итак, давайте попробуем сформулировать названия следующих шагов. Пусть они звучат как:

8. Доработка пути пользователя по игре

9. Разработка документации 

10. Дизайн и иллюстрации

11. Создание прототипа

12. Плей-тесты

13. Доработка контента

14. Логирование/ настройка аналитики

15. Публикация и запуск

16. Сбор данных, анализ, доработки, update и так по кругу в погоне за совершенством

В крупных компаниях эти этапы обычно проводят параллельно, так как ими занимаются разные отделы и разные специалисты. Но если ваша команда небольшая или вы делаете игру в одиночку, можете идти по заданному мной порядку или поменять какие-то пункты местами на свое усмотрение. Создание игры — это всё же творческий процесс, поэтому четкое следование правилам иногда может слишком ограничивать или даже мешать. Так что вместо того, чтобы следовать, можете смело задавать свои=)

А мы продолжим и разберем, что же происходит на каждом из шагов.

8. Доработка пути пользователя по игре

Если у вас был ивент-шторминг, можете пропустить данный этап. Скорее всего вы уже и так знаете, что должно быть в вашей игре и как с ней будет взаимодействовать пользователь. Если же нет — этот шаг поможет вам в будущем при разработке документации, дизайне и создании прототипа. Здесь мы составляем пошаговую схему взаимодействия с продуктом, начиная от самого первого клика. При этом желательно не просто описать действия будущего игрока и каждый из экранов/событий, но также представить себе те чувства и эмоции, которые игрок будет испытывать. 

Для понятности приведу фрагмент простой схемы (в реальности она будет намного больше и должна охватывать все экраны, все события игры и действия игрока) 

Когда схема пути пользователя будет готова, можете перенести ее (или ссылку на нее) в диздок, чтобы все было собрано в одном месте. 

9. Разработка документации 

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

В дизайн-документ собираем все материалы, все ссылки, важные для продукта. Там же расписываем кор-механики и мету, задаем нарратив (подробно об этом можно почитать на Манжетах гейм-дизайнера. Там же можно найти отличные статьи о том, как собирать диздок и писать грамотное ТЗ.) 

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

10. Дизайн и иллюстрации

Если диздок пишется, то дизайн “рисуется”))) Вот и вся разница. Берем наш диздок и прорабатываем все, что в нем было схематично изображено или написано текстом. Все окна меню, все игровые сущности, локации, интерфейсы и т.п. Рисуем уровни на грейбоксах, продумываем арт и общий стиль иллюстраций. 

11. Создание прототипа

Прототип — это минимальная игровая единица, где все работает, есть иллюстрации и может даже звук. Его можно дать поиграть другим или попробовать пройти самому.

Ваш прототип может быть собран на движке, как и будущая игра, а может это кликабельный прототип в Figma (есть и другие простые инструменты для этого) или вовсе собственноручно написанное приложение. Все зависит только от ваших возможностей, умений и желания. Лично я работала со всеми перечисленными видами прототипов. Даже с браузерным, написанном на php и html+css с подключенными js-скриптами (простите за тавтологию).

Неплохая статья о разработке прототипов (чел делится своим первым опытом и рассказывает о том, какие ошибки совершал), если вы вообще не представляете, что это за зверь. 

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

Подробно почитать про то, какой бывает баланс, как его считать и на что он влияет, можно здесь. 

12. Плей-тесты

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

Для удобства можете придерживаться этого плана при подготовке и проведении тестов:

1. Формирование гипотез и вопросов (Сформулируйте все свои предположения относительно самой игры и опыта игрока в ней, составьте список вопросов, по которым будете идти в ходе теста и после него).

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

3. Вопросы после теста (Опросите игравших по составленному ранее списку. Старайтесь избегать простых вопросов, на которые можно ответить только да и нет. Уточняйте, что именно понравилось/не понравилось, что можно было бы добавить/что лишнее, что было сложно и так далее).

4. Проанализируйте получившиеся результаты и сделайте выводы (Взгляните на гипотезы, которые формулировали вначале. Удалось ли вам их проверить? Запишите, какие выводы вы сделали в ходе тестов и поделитесь ими с командой).

Чтобы тесты дали как можно более объективные результаты, пусть каждый из участников команды проведет их со своими знакомыми, а затем вы поделитесь друг с другом какими-то интересными выводами и забавными случаями (обычно когда игру проходит кто-то знакомый, забавных казусов бывает достаточно, так что поделиться будет чем=))

13. Доработка контента

Тут все должно быть понятно. Берете результаты плей-тестов, а также в целом все, что у вас было по плану (диздоку и ТЗ) и собираете воедино. Дорабатываете игру до того состаяния, чтобы ее не стыдно было показывать широкой аудитории. Наполняете ее красивыми иллюстрациями, анимациями, озвучкой, добавляете VFX, SFX, какие-то доп. функции и фичи. Все, что считаете нужным. 

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

14. Логирование/ настройка аналитики

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

Большинство современных площадок дают почти неограниченные возможности аналитики, однако за их подключение скорее всего придется доплатить. Изучите заранее все условия, функции и ограничения (некоторые плюшки сейчас могут быть недоступны для РФ и придется заморочиться, чтобы обойти все запреты). 

Если игровая аналитика для вас темный лес, рекомендую прочитать книгу Василия Сабирова “Игра в цифры. Как аналитика позволяет видеоиграм жить лучше” и пару тематических статей. 

15. Публикация и запуск

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

16. Сбор данных, анализ, доработки, update и так по кругу в погоне за совершенством

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

Искренне желаю удачи в этом непростом деле! Помните, истинное стремление к цели стирает все преграды на пути! Не сдавайтесь, пробуйте и у вас обязательно все получится=)