Как написать хороший дизайн-документ?

Недавно я прочитала отличную статью Джеймса Светмана (James Sweatman) под названием «Смерть геймдизайн-документа». Она заставила меня задуматься о моем собственном опыте создания диздока.

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

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

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

Этот процесс тесно связан с опытом пользователя, о котором я и Мартин Дарби (Martin Darby) говорили в ходе нашей беседы на конференции разработчиков (Develop conference) в этом году, и материал о котором я публиковала до того в своем блоге.

Итак, ключ к удобному диздоку в следующем:

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

В первом приближении ваш геймдизайн-документ должен включать следующее:

Общее описание игры

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

Описание «ядра» игры

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

Цикл должен описывать каждую включенную в нее фичу и объяснять, для чего она нужна. Лучше всего, если это будут краткие описания, каждое не более половины страницы. Вам, скорее всего, необходимо будет включить в него дополнительные циклы, прикрепленные к каждому элементу. Они объяснят ваши идеи куда лучше, чем текст.

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

Элементы игры

Это секция, в которой будут подробно описаны все фичи, и вот тут-то и нужно будет добавить деталей.

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

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

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

Возможно, вы не захотите показывать эту часть ГДД акционерам компании: она в основном для внутреннего пользования, поскольку объясняет, как именно сделана игра.

Подводим итоги

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

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

Источник: http://www.develop-online.net

Фото: http://www.toothpastefordinner.com