[Torment: Tides of Numenera] Разработка диалогов (страница 1)

Некоторое время назад я воспользовался перерывом в своём плотном графике и расспросил Адама Гейне о том, как использовать один из ключевых инструментов, применяемых нами уже довольно длительное время — инструментарий разработки диалогов Obsidian. Этот инструментарий — настоящая находка для людей, не имеющих навыков программирования, таких как я. Он даёт возможность писать диалог и изменять его структуру, синхронизируясь с текущей сборкой на движке Unity. Будучи запущенным одновременно с игрой, инструментарий позволяет вносить изменения в реальном времени, и оценивать их, просто перезапуская диалог с персонажем снова и снова.

Для такой насыщенной диалогами игры как Torment: Tides of Numenera, очень важен хороший инструментарий их разработки. Главной задачей на этапе подготовки к полноценной разработке стала выработка собственных стандартов взаимодействия персонажей и улучшения и без того великолепного инструментария Obsidian. Я хотел бы поделиться с вами основами работы с ним, чтобы вы в дальнейшем понимали, о чём идёт речь.

Начнём с двух основных понятий: узлы и связи. Узлы содержат текст, который вы видите в игре, сама структура диалога состоит из связанных друг с другом узлов.

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

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

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

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

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

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

Вот пример того, как Колин использует дополняющий узел для передачи игроку информации о Джонте в зависимости от значения восприятия его персонажа. Если персонаж игрока соответствует требованиям, текст из узла 1 будет дополнен текстом узла 23.

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

В примере ниже, игрок в первый раз видит узел 42, а задав вопрос, в ответ получает узел 45. Проходя по диалогу несколько раз, вместо узла 42 он увидит 43, а на свой вопрос получит ответ из узла 46. Развёрнутый ответ узла 45 будет выглядеть странно для того, кто уже услышал его однажды, в то время как 46 выглядит более естественно (кстати, игрок в любое время может заглянуть в запись диалога и увидеть сказанное ими ранее).

Диалоговый инструментарий уже имеет функции последовательных вопросов и не требует создания дополнительных видов узлов, однако такой подход упрощает работу сценаристов, помогая им быстрее писать диалоги. Дополняющие и последовательные узлы улучшили функциональность инструментария Obsidian, за что мы выражаем благодарность нашему талантливому программисту Паоле Риццо [Paola Rizzo].

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

Сценарист присваивает узлу значение «выполнение задачи», устанавливает её сложность, используя некоторое абстрактное значение, которое будет использовано в процессе расчёта баланса, характеристику, запас которой будет израсходован на Усилие, и список навыков, которые облегчат её выполнение. Затем инструментарий отмечает последующие узлы как результаты выполнения задачи: успех, провал, критический успех, критический провал.

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

Что мешает игроку пытаться выполнить задачу до тех пор, пока у него не получится? Каждый узел наделяется параметром «живучести». Многие узлы, в том числе и с задачами, имеют значение живучести, равное «единожды», то есть появляются всего лишь раз. Разумеется, существуют такие задачи, для которых параметр живучести не определён, поэтому игрок может пытаться выполнить их до тех пор, пока не преуспеет. Тем не менее, если попытка выполнения задачи была уже однажды провалена, вы должны будете заплатить стоимость повторной попытки (то есть приложить большее Усилие).

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

Источник: Kickstarter.