Структура написания дизайн-документа.

Общая структура дизайн-документа. Эта статья — шпаргалка, как написать диздок и с чего начать.

Предисловие.

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

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

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

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

Идея

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функциональность:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: www.gamedis.ru

#gamedesign #дизайндокумент