Зачем прототипу дизайн-документ?
В больших студиях дизайн-документ растёт вместе с проектом и со временем занимает сотни страниц. Перед первым прототипом нужно другое: несколько страниц, которые каждый участник прочитает за один раз и сможет по ним принимать решения. Главная задача документа — не дать прототипу превратиться в уменьшенную копию полной игры. Если функции, уровня или графики нет в документе, их пока не делают.
Пишите для тех, кто будет делать и проверять прототип: геймдизайнера, программиста, художника, который готовит временную графику, и человека, который проведёт игровые сессии. Если прототип будет делать внешняя команда — например, по услуге разработка игр на заказ, — тот же документ станет брифом, по которому команда оценивает и ведёт работу. Расплывчатый бриф даёт расплывчатый прототип и длинный список вопросов в первую же неделю.
Документ должен жить, но оставаться маленьким. Когда меняется решение, обновите текст, запишите дату и причину и не добавляйте разделы «на будущее». Идеи для полной версии игры ведите отдельным списком: так они не потеряются, но и не будут спорить с текущим тестом.
Что включить в дизайн-документ игры?
Начните с одного абзаца, который описывает игру глазами игрока: что он видит, что делает и почему захочет сделать это ещё раз. Затем распишите основной цикл по шагам: действие, ответ игры, награда или продвижение и то, что тянет игрока в следующий раунд. Подробно о том, как сделать прототип игры вокруг этого цикла, — в отдельной статье. Если цикл не удаётся описать в нескольких коротких предложениях, прототипировать его рано.
Дальше — управление. Перечислите все действия игрока на каждом целевом устройстве: касания и свайпы, мышь и клавиатура, геймпад. Отметьте, что происходит при неожиданном вводе — двойном касании или удержании кнопки. Именно на управлении проваливаются многие ранние прототипы, а описать его точно на бумаге почти ничего не стоит.
Потом — ограничения платформы: размер и ориентация экрана, длина обычной игровой сессии, нужна ли работа без интернета, производительность самого слабого устройства, которое вы хотите поддерживать, и правила магазина или платформы. Эти рамки определяют содержание прототипа задолго до того, как кто-то откроет движок.
И наконец, объём. Назовите уровни, персонажей, механики и экраны, которые входят в прототип, и так же явно — то, что сознательно оставлено за бортом: меню, прогрессию, монетизацию, сюжет, финальную графику и звук. Короткий список «в эту сборку не входит» избавляет от большего числа споров, чем любой другой раздел.
На какой вопрос должен ответить тест?
Прототип — это эксперимент, поэтому в документе должно быть написано, что именно проверяется. Сформулируйте главный вопрос одним предложением: понимают ли игроки управление без подсказок, остаётся ли основное действие интересным после нескольких раундов, правильно ли выставлена сложность? Добавьте, за чем вы будете следить во время сессий и какой результат означает «продолжаем», «меняем» или «останавливаемся».
Опишите сами игровые сессии: кто играет, на каких устройствах, сколько длится сессия и кто ведёт записи. Договоритесь, как фиксировать замечания, — с номером сборки рядом с каждой заметкой, чтобы потом было понятно, к какому изменению относится комментарий.
В конце заведите короткий журнал решений. Каждый раз, когда тест отвечает на вопрос, записывайте, что решили и почему. Именно этот журнал превращает прототип в основу для планирования производства, и для следующего этапа он полезнее любой красивой презентации. А когда документ готов, по нему удобно составить бриф на разработку проекта, если прототип вы хотите поручить команде.
Насколько подробным он должен быть?
Настолько, чтобы два человека, прочитав его, собрали один и тот же прототип, — и не подробнее. Точные формулировки важнее всего для основного цикла, управления и тестового вопроса, остальное может быть коротким. Если какой-то раздел всё время разрастается, обычно это значит, что прототип пытается ответить сразу на несколько вопросов.
Там, где рисунок быстрее слов, рисуйте: набросок экрана, расположение кнопок, путь игрока по уровню. На этом этапе вполне подойдут фотографии бумажных набросков. Важно, чтобы у команды была одна общая картина сборки, а не чтобы документ выглядел законченным.
Частые ошибки
- Описывать всю игру. Документ со всеми задуманными функциями подталкивает команду их делать. Для прототипа описывайте только то, что нужно тесту, а остальное ведите отдельным списком идей.
- Размытый тестовый вопрос. На вопрос «проверим, интересно ли» ответить нельзя. Назовите, что именно хотите узнать и за чем будете следить во время сессий.
- Пропускать управление. Часто описывают, что происходит в игре, но не то, как игрок этого добивается. А ощущение «что-то не так» в ранних сборках чаще всего рождается именно в управлении.
- Не обновлять документ. Документ, написанный один раз и забытый, перестаёт быть опорой. Записывайте решения по мере их принятия вместе со сборкой, к которой они относятся.
Шаблон дизайн-документа для прототипа
Шаблон, который можно адаптировать под ваш проект.
| Раздел | Что написать |
|---|---|
| Описание в одном абзаце | Что игрок видит и делает и почему возвращается. |
| Основной цикл | Действие, ответ игры, награда и следующий раунд — в нескольких предложениях. |
| Управление | Все действия игрока на каждом устройстве и реакция на неожиданный ввод. |
| Ограничения платформы | Экран, ориентация, длина сессии, игра без сети, слабое устройство, правила магазина. |
| Объём | Что входит в эту сборку и отдельный список того, что не входит. |
| Тестовый вопрос | Один вопрос, что наблюдаем и какой результат означает «продолжаем», «меняем» или «стоп». |
| Журнал решений | Дата, решение, причина и сборка, на которой оно основано. |
Чек-лист: дизайн-документ игры
- Опишите игру одним абзацем, а основной цикл — несколькими предложениями.
- Перечислите управление для каждого устройства, включая неожиданный ввод.
- Запишите ограничения платформы до выбора функций.
- Ведите явный список того, что не входит в прототип.
- Сформулируйте тестовый вопрос и критерии «продолжаем», «меняем» или «стоп».
- Записывайте каждое решение вместе со сборкой, на которой оно основано.
Пример: документ для прототипа головоломки
Команда хочет проверить головоломку для телефонов. В первом черновике документа — карта мира, магазин, ежедневные награды и несколько режимов. Ничто из этого не отвечает на настоящий вопрос: приятно ли сдвигать фишки и очищать поле на маленьком сенсорном экране?
Исправленный документ умещается на нескольких страницах. В нём описаны основной цикл, управление свайпами и реакция на ошибочный свайп, сборка ограничена несколькими полями с временной графикой, а всё остальное перенесено в список «в эту сборку не входит». Тестовый вопрос — проходят ли новые игроки первые поля без объяснений. Именно это команда и собирает, и проверяет на игровых сессиях.
