ЛЕГКИЙ СПОСОБ НАПИСАТЬ ДИЗАЙН-ДОКУМЕНТ

labyrinth

Картинка: фильм «Labyrinth»  by Disney, 1986

Предисловие

Нет, конечно это никакой не легкий способ, а я — не Аллен Карр. Написать полноценный и подробный диздок — это адов труд и требует огромной концентрации, усидчивости и упорства.

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

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

 

Последовательность

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

 

 

Light-Bulb-3

Идея

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

 

 

mediat-list-icon

Список основных фич игры  и USP

Каждая игра включает в себя набор каких-то фич, которые формируют геймплей. Среди этих фич есть самые-самые, называемые USP — Unique Selling Points. Как сказал кто-то, уже не помню кто, но что мне запомнилось и очень понравилось: «USP — это то, что можно привести в пример во время рассказа об игре одним игроком другому. Например, рассказывая о Prince of Persia: The Two Thrones, он может сказать: «у героя есть там такой хлыст, состоящий из лезвий, которым он всех красиво рвет на клочки!» — и собеседник сразу же живо это представит (или моментально поймет, о какой игре идет речь).

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

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

 

 

a_unknown

Определение ЦА (целевой аудитории) игры

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

Просто запишите тут, кто ваш основной игрок, если получилось его выделить. Ответ «Все!» не подходит. Описание ЦА может выглядеть так:

Мужчины в возрасте 25-50 лет, увлекающиеся военной тематикой и периодом Великой Отечественной Войны, а также любители шутеров, мужчины от 14 до 20 лет. И те, и другие — обладатели приставки Х.

Это описание может быть немного более подробным, особенно если игра сочетает в себе несколько жанров, или для широкой аудитории. Если вы не знаете, какова ваша ЦА, то обязательно нужно провести небольшое исследование и попытаться понять, какой тип игроков предпочитает выбранный вами жанр и сеттинг.

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

 

 

1_Оглавление 2

Дизайн-документ — оглавление

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

  1. Объектная Модель
  2. Функциональная спецификация
  3. Контент игры
  4. Интерфейс
  5. Монетизация
  6. Виральность (если предусматривается)
  7. Техническая спецификация
  8. База знаний (ссылки)

1. Объектная модель описывает каждую игровую сущность, ее параметры и то, что она может делать (как очень точно выразился один из моих программистов, «глаголы сущности»). Подробнее о том, как писать Объектную Модель и зачем она нужна можно прочитать в этой моей статье.

Например, вот так выглядит описание сущности Equipment из одного моего рабочего проекта:

Члены типа Equipment
Описание
Тип
Имя
Прочность максимальная int DurabilityMax
Прочность текущая int DurabilityCurrent
Тип доспехов (влияет на то, может ли тот или иной класс использовать этот предмет, или может но с пенальти или наоборот, с бонусами) ArmorTypes ArmorType
Апгрейд (уровень апгрейда) int UpgradeLevel
Модификатор урона float ModDam
Модификатор ХП float ModHP
Модификатор регенерации ХП float ModHPregen
Модификатор маны float ModEP
Модификатор регенерации маны float ModEPregen
Модификатор скорости бега float ModMove
Модификатор скорости атаки float ModAttackSpeed
Модификатор скорости парирования float ModParrySpeed
Модификатор скорости защит щитом float ModShieldSpeed
Свойство (бафф, который вешается на персонажа когда предмет одет на персонажа) ItemAffects ItemAffect
 Функциональность
  • Может быть одета на персонажа или снята
  • Одевается только в предназначенный ей слот (определяется типом одежды)
  • Может быть куплена/продана в магазине
  • Может быть потеряна при смерти
  • Может терять прочность
  • Ломается, когда прочность достигает 0
  • Когда сломана, параметры одежды становятся единицами (0 то они до единиц не повышаются)
  • Может быть починена, при этом максимальная прочность снижается перманентно
  • Может быть улучшена, при этом определенные параметры повышаются (зависит от улучшения), улучшения перманентные
  • Может иметь баф, который влияет на параметры персонажа когда предмет одет
  • Может иметь набор особых свойств (ItemAffect). Например, привязка при взятии, привязка при одевании, проклятое, благословенное и другие


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

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

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

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

5. Монетизация описывает то, как будет зарабатывать ваша игра. Если это подписка, то сколько она стоит, какие будут скидки, какие будут специальные акции и так далее. Если это ф2п (что наиболее вероятно), то тут должны быть описаны все статьи монетизации, как они работают, на кого нацелены и, может быть, какой вклад в общий доход игры они внесут (в процентном соотношении) Описать монетизацию имеет смысл наиболее подробно, поверьте — в будущем это вам пригодится и потребуется не один раз. Если, конечно, вы не работаете в русской госструктуре или министерстве обороны и у вас совсем иные задачи при разработке игры.

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

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

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

8. База знаний — раздел для хранения всего полезного. Статей, ссылок, референсов, статистических данных, видео, контактов и так далее. Полезно всем, кто работает с проектом.

Детализация оглавления

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

 

 

1_birds-flying-silhouette-clip-art

Описание (питч)

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

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

Есть много литературы о том, как это делать правильно, а вот замечательный ресурс Gamepitches, на котором можно прочитать огромное количество питчей и посмотреть, как это делают профессионалы из игровой индустрии.

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

 

 

1_microscopes

Детализация диздока

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

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

При первоначальном написании «мяса» я делаю 3-4 быстрых прохода по всем разделам. В первый я описываю все в общих чертах на уровне концепций. Во второй я добавляю деталей, делаю все более четко, дорабатываю те моменты, которые были непонятны. В третий проход я убираю лишнее и делаю текст более лаконичным и кратким, дорабатывая детали и нюансы. Но даже сейчас диздок еще далек от финала, потому что не создана объектная модель.

 

 

1_skeleton

Объектная модель

Объектную модель я уже пишу в вики. Из всех вики (я изучил около пятидесяти разных), мне больше всего подошла Atlassian Confluence. Лицензия до 10 человек стоит около 300 рублей в месяц, но и даже для одного человека (геймдиза) оно того стоит.

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

Напишите правильную объектную модель ДО того, как начнется разработка вашей игры, и ваши программисты будут вас любить до конца жизни (или, по крайней мере, у них будет причина для этого). Я считаю, что правильная ОМ значительно повышает шансы того, что игра будет сделана.

 

 

689322_120500217

Проработка разделов и перенос их в вики

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

 

 

1_vision

Подробный вижен для команды

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

Затем, ради интереса (и если вы добрались до этого этапа), можете сравнить этот вижен и вашу первоначальную идею, с которой все начиналось.

gamedis.ru