Хочу в геймдев!

Причиной возникновения фичи не должны быть аналоги у конкурентов или «мне кажется, будет круто». Без анализа «зачем» нельзя понять, насколько реализация необходима. «Повысить Retention», «увеличить конверсию в платящих игроков», «снизить процент отваливающихся через неделю игроков» – хорошие цели, основанные на конкретных метриках. Еще лучше, когда есть объяснение, почему выбрано это решение, а не другое, и почему оно должно понравиться разным категориям игроков. Сюда прилагают результаты опросов, аналитики, любые данные, подтверждающие вашу гипотезу. Этот пункт должен предполагать методы проверки, насколько успешной окажется фича после завершения работы над ней.

КОНЦЕПТ – это общее, короткое описание фичи без технических подробностей, на основании цели. Концепт должен предлагать конкретные решения возможной проблемы, просто описать ее – недостаточно. Гейм-дизайнеру может казаться, что решение всем очевидно, но это часто не так. Этот пункт нужен, чтобы любой человек смог быстро понять, о чем данный документ; названия для этого не всегда достаточно.

К описанию важно прилагать РЕФЕРЕНСЫ. Гифки, видео, картинки помогают понять, о чем идет речь, намного быстрее, чем длинный текст. Когда вы смотрите на готовые решения и видите некоторое количество отличий от собственных предложений, вы можете задуматься, а почему решение реализовано именно так, а не иначе. Ответ на этот вопрос – еще один шаг к проверке собственной идеи.

Можно составить ЮЗЕР-СТОРИ, то есть описать, как игрок будет взаимодействовать с каким-то игровым элементом: как узнает о новой опции, как поймет принцип ее работы и взаимодействия с другими элементами, а также, например, как защититься, если игровые соперники применяют новую опцию против него. Описание самой фичи здесь минимально, все внимание сосредоточено на ходе мыслей игрока, сталкивающегося с ней, с самой первой встречи. Цель – воссоздать эмоции и цепочку возможных рассуждений игрока, сформулировать желаемую мотивацию. Не просто ввести новую фичу, но понять, почему она станет ценной.

Представляя себя на месте игрока, знакомящегося с фичей, вы увидите и сможете с самого начала подметить и исправить слабые стороны предлагаемого решения. Например, у вас есть класс персонажей, которые могут становиться невидимыми. Как вы объясните другим игрокам, что среди них есть невидимка? Что будет происходить на экране? Отвечая на подобные вопросы, вы получите почти полное описание фичи с точки зрения игрока и его ощущений.

Чтобы юзер-стори была полезной, мало предположить действия игрока, нужно обозначить все, что игрок увидит или почувствует на пути к нужному результату: какие всплывающие окна, какие иконки имеют то или иное значение, что игрок услышал от NPC, чтобы сделать тот или иной вывод. Составлять этот раздел ГДД лучше с помощью блок-схем, наглядно показывающих путь игрока: так вы сразу прикинете архитектуру и объем интерфейсов вашей игры. Юзер-стори может отсутствовать в ГДД, но это хороший инструмент для самого гейм-дизайнера, чтобы еще раз проверить свои идеи.

ЮЗЕР-КЕЙСЫ – это примеры конкретных взаимодействий игрока с фичей. Юзер-кейсы должны покрывать весь предлагаемый функционал. Это описание последовательности игровых изменений, зависящих от действий игрока. Например, нажимая на эту красную кнопку, игрок видит такое-то сообщение (всплывающее окно), в верхнем левом углу появляется таймер; когда время заканчивается, таймер начинает пульсировать; по истечении времени он со взрывом исчезает. Важно описать, как система должна реагировать на все возможные варианты действий игроков, включая негативные, когда игрок делает что-то не по плану гейм-дизайнера.

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