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

Итак, с какими документами мы можем иметь дело:

● бриф,

● синопсис/концепт,

● расширенный синопсис,

● сторилайн,

● библия персонажей,

● блок-схемы,

● таблицы,

● википедии,

● поэпизодный план,

● технические задания (ТЗ) для арт-отдела,

● дизайн-документ.

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

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

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

Само понятие синопсиса пришло к нам из античных времен: оно означало краткое изложение, без подробной аргументации и деталей, в общем обзоре одного целого предмета или одной области знаний. И значение свое это слово в целом сохранило.

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

Мы рассмотрим самый распространенный вариант с общими моментами. Итак, в синопсис входят такие элементы, как:

● рабочее название,

● жанр,

● референсы,

● сеттинг,

● персонажи,

● конфликт,

● краткий сюжет.

Мы достаточно подробно останавливались на названии игры в разговоре о концепт-документе (см. главу 3 «С чего начинается создание игры? Первоначальная документация»), поэтому здесь расскажем лишь о некоторых нюансах. При разработке в процессе ведения документации и работы с разными отделами мы можем пользоваться рабочим именем, более коротким и запоминающимся. Например, использовать имя «Небеса», тогда как название в релизе у нас будут «Плачущие небеса», или «Тьма», в то время как игра будет иметь полное название «Круги ада: Повелители тьмы», и т. д. по аналогии. Рабочее название также применяется, когда релизное имя игре еще не придумано. Это связано с удобством работы внутри команды и отдельной серьезной работой по маркетингу игры.

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

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

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

В данном подпункте мы приводим краткое описание места, времени и атмосферы – всех тех характеристик, которые входят в понятие сеттинга, о котором мы уже подробно говорили (см. главу 3 «Сеттинг. Лор игры. Миростроение»).

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

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

Важно вкратце обозначить антагониста (антагонистов) и описать конфликт уже в следующем пункте.

В этом пункте мы прописываем конфликт (конфликты). Это может быть внутренний или внешний конфликт, основной (сквозной) и второстепенные, связанные с остальными персонажами, квестами и миссиями (см. главу 6 «Сюжет в игре. Сценарные инструменты»).

Желательно указать завязку, кульминацию и финал, если сюжет линейный, или основные узлы развилок и финалы, если сюжет разветвленный (см. главу 5 «Сюжет игры. Сценарные инструменты).

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

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

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

Возможно, на пересечении этого исследования лежит нужная концепция истории.

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

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

И тут может возникнуть вопрос: как превратить идею в историю и вызвать эмоциональную вовлеченность игрока? Ответ довольно нестандартен: чем больше дискомфорта, тем сильнее история. Как мы уже говорили ранее, обычно все начинается с той событийной точки, когда героя выдергивают (или это он вынужден сделать сам) из привычного ему мира, из знакомой рутины (см. главу 4 «Персонажи игры»). Как это можно сделать? Понять, что нужно нашему герою, и дать ему совершенно другое.

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

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

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

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

Расширенный синопсис – это более детальная проработка мира, лора и персонажей игры. Обычно он составляет 5–10 страниц. Сюда входят также более детальные пункты развития действия истории (между завязкой и кульминацией). Фактически здесь обозначены ключевые биты сюжета и его повороты, в том числе твисты. Без деталей, но с полным пониманием структуры. Помимо всех тех пунктов, которые описаны в синопсисе, мы можем добавить:

● переменные,

● выборы,

● описание финала (финалов),

● планы на будущие части игры (сезоны),

● особенности нарративного дизайна.

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

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

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

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

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

Бывает, что разработка игры начинается раньше, чем создание истории, так как многие элементы уже придуманы и даже реализованы. Есть уже готовые механики, UI, даже некоторые персонажи, но как это все теперь связать? Нарративным дизайнерам иногда приходится встраивать сюжет поверх игры, когда гейм-дизайнер приходит с техническим заданием и уже готовыми ассетами. Данный подход тоже имеет право на существование, хотя в реализации он может быть труднее по сравнению с разработкой истории с нуля. Это связано и с тем, что мобильные игры сейчас усложняются, и с тем, что формально написание сюжета и его переработка значительно дешевле, чем переработка механик и ассетов. В настоящее время казуальный игрок стал требовательнее, и увлечь его просто механикой становится недостаточно. В таких случаях большие надежды возлагают на разработку истории, которая при правильном использовании сценарных инструментов может удерживать игрока надолго, а клиффхэнгеры и твисты помогут возбуждать его любопытство так, что игрок будет возвращаться снова и снова. И вот тут нарративные дизайнеры имеют дело со сторилайном.

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

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

Оформлять этот документ можно в текстовом формате, в таблице, в виде вики, списка или блок-схемы – тут все зависит от выбора инструментов и методов, с которыми принято работать в вашей компании.

Синопсис (в том числе и расширенный), сторилайн, квесты, миссии, расширения помимо текстового описания обычно дополняется блок-схемой, чтобы гейм-дизайнеры и другие члены команды понимали, как все встраивать в игру.

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

Создавать блок-схемы можно в одной из программ, типа draw.io, Miro, Figma и других (см. главу 11 «Технологии»).

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

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

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

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

Для создания википедий могут использоваться онлайн-программы для их создания, например Google Sites, WordPress и другие похожие инструменты (см. главу 11 «Технологии»).

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

Игровые сценаристы плотно работают не только с гейм-дизайнерами, но и с арт-отделом, для которого важно уметь прописывать понятные и адекватные технические задания (ТЗ). Конечно же, стоит учитывать визуальный стиль игры: это 2D- или 3D-графика, а также микс из обеих. Мы предлагаем лишь экскурс в работу над ТЗ, не погружаясь в детали и ограничения, которые могут выдвигаться с учетом технологий и программ арт-отдела.

ТЗ бывают:

● по персонажам,

● по локациям,

● по кат-сценам,

● по предметам,

● по интерфейсам (UI),

● на другие сущности.

Это, пожалуй, самое трудозатратное, особенно если требуется создать кастомизируемого персонажа с набором разных характеристик – например, раса, внешний вид, одежда. Безусловно, можно обратиться к созданию редактора персонажа, но он требует слишком большого времени и ресурсов.

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

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

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

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

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

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

Это могут быть какие угодно технические задания на стыке нарратива и его визуализации арт-отделом.

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

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

Что может входить в дизайн-документ:

● название и игровой жанр,

● логлайн (кратко, в виде анонса, перечислить основные моменты игры),

● краткий обзор игры, ее философия (что это за игра и зачем она создается),

● сеттинг (время, место, атмосфера в игре),

● визуальный стиль (реализм, фэнтезийный, мультяшный, также 3D-или 2D-игра),

● движок,

● режим (многопользовательский, однопользовательский, кооперативный и т. п.),

● отличие от других игр (преимущества перед референтными играми),

● характеристики (для какой платформы и аудитории планируем выпустить игру),

● время прохождения (приблизительное количество часов или минут на все прохождение в среднем),

● геймплей (что и как контролирует игрок, примерное описание взаимодействия игрока с сущностями игрового мира),

● кор-механика и метагейм,

● игровой мир, карта, локации,

● интерфейс,

● камера (от первого лица, от третьего лица, изометрическая и т. п.),

● персонажи (игровые и NPC, в том числе их свойства, каким образом будет происходить прокачка и изменения, также антагонисты, если есть – боссы и мини-боссы, противники, примерная система боевки),

● сюжет,

● музыка и звуковые эффекты,

● журнал заданий,

● схема переходов между экранами,

● свойства персонажа,

● инвентарь,

● внутриигровые тексты (дневники, свитки, заметки в ноутбуке и т. п.),

● настройки,

● загрузка и сохранение,

● гипотезы (что бы мы хотели протестировать на каких этапах разработки для внедрения в игру).

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