Просмотр кода страницы За Façade: модель диалогов в играх


[[{{ns:6}}: 1941ea.jpg]]

Это перевод статьи [[Автор::Эмили Шорт]] от [[Дата::12.05.2009]].

* [http://www.gamesetwatch.com/2009/05/column_homer_in_silicon_the_co_1.php Ссылка на оригинал]
* [https://ifhub.club/2015/03/06/za-faade-model-dialogov-v-igrah.html Ссылка на перевод]

В прошлом году Брент Эллисон опубликовал статью о системах построения диалогов на сайте Gamasutra. Чуть позже Джонатан Блоу открыл в своем блоге дискуссию о создании диалогов между персонажами в играх. Затем в феврале Кристиан Мажевски написал о диалогах в Emerald City Confidential, размышляя о трудностях представления казуальным игрокам диалогов со множеством решений.

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

В частности, большинство существующих анализов объединяют в одно пользовательский интерфейс (как представлены пункты диалога? как они появляются на экране? предлагается ли игроку полный текст его реплики или же ее обрезанная версия?) и лежащую в его основе модель (как игра решает, какие реплики будут доступны в следующий момент? как ограничить варианты для игрока или наоборот сделать их доступными? что влияет на то, когда и что NPC [неигровые персонажи] говорят сами по себе?)

Пользовательский интерфейс — наиболее видимая часть из этих двух и, как следствие, более понятая. Легко играть в игру и видеть, как представлены пункты диалога, но намного труднее угадать, что за код скрывается за ними.

Однако лежащая в основе модель значит очень много.

На практике уже существует множество различных моделей общения между персонажами, работающих в коммерческих и инди разработках. Нельзя сказать, что мир диалогов в играх разделен между "Façade" и «все остальное», и иногда необъяснимо более эффектные игры эффектны как раз из-за того, что они основываются на логике, которая не слишком подвергалась изучению сообществом.

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

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

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

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

== Структура беседы ==
Эллисон определяет два наиболее распространенных типа разработки диалогов, которые он называет «Ветвление» и «Узел-и-лучи». Он пишет:

«Хотя в итоге Узел-и-лучи является вариантом Ветвления, диалог, основанный на Узле-и-лучах, создает очень отличный от Ветвления вид беседы. Игрок слушает реплики NPC, а затем делает свой выбор из главного „узла“ диалога… После получения отклика NPC на свою реплику игрок либо возвращается на главный узел, откуда он может задать тот же вопрос еще раз или перейти к другой теме, либо уходит на более глубокий узел, с большим количеством вариантов выбора.»

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

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

 Узел
   Топик о происхождении вервольфов
     -> автоматический возврат на Узел
   Топик о волчьем лыке
     -> автоматический возврат на Узел
   Топик о Лорде Когтеклыке
     Топик о невесте Когтеклыка
       Топик о приготовлении торта на свадьбу
         -> автоматический возврат на Узел
       Топик о свадебном реестре
         -> автоматический возврат на Узел
       Возврат на Узел
     Топик о замке Когтеклыка
       Топик о согласии штурмовать замок с вилами наперевес
         -> автоматический возврат на Узел
       Топик о несогласии штурмовать замок с вилами наперевес
         -> автоматический возврат на Узел
       Возврат на Узел

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

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

Например:

'''Топик о происхождении вервольфов'''<br>
'''темы:''' Когтеклык<br>
'''предпосылки:''' нет

'''Топик о волчьем лыке'''<br>
'''темы:''' Когтеклык<br>
'''предпосылки:''' NPC доверяет игроку

'''Топик о невесте Когтеклыка'''<br>
'''темы:''' свадьба, Когтеклык<br>
'''предпосылки:''' игрок видел приглашение на свадьбу

'''Топик о приготовлении торта на свадьбу'''<br>
'''темы:''' свадьба, Когтеклык<br>
'''предпосылки:''' следует сразу за топиком о невесте Когтеклыка

'''Топик о свадебном реестре'''<br>
'''темы:''' свадьба, Когтеклык<br>
'''предпосылки:''' следует за топиком о невесте Когтеклыка, необязательно сразу

Теперь мы предлагаем игроку те топики, которые одновременно релевантны последней теме (темам) беседы, а также доступны (согласно правилам предпосылок). Проговаривание топика с темами «свадьба, Когтеклык» может привести к другим топикам о свадьбе и другим топикам о Когтеклыке. 

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


== Ограничение выбора в Атомной модели ==
Конечно, будут случаи, когда нужно немного ограничить диалог, например, если мы хотим попросить игрока решиться на какой-то конкретный вариант действий (штурмовать замок или нет?) И если нам надо, вполне можно реализовать строгость древовидной модели с помощью предпосылки, что данные топики немедленно следуют за другим топиком, а также определив для исходного топика ограничения того, что за ним самим может следовать:

'''Топик о замке Когтеклыка'''<br>
'''темы:''' Когтеклык<br>
'''предпосылки:''' нет<br>
'''далее:''' только топики, которые немедленно следуют за этим

'''Топик о согласии штурмовать замок с вилами наперевес'''<br>
'''темы:''' Когтеклык<br>
'''предпосылки:''' немедленно следует за топиком о замке Когтеклыка

'''Топик о несогласии штурмовать замок с вилами наперевес'''<br>
'''темы:''' Когтеклык<br>
'''предпосылки:''' немедленно следует за топиком о замке Когтеклыка

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

Это все еще оставляет вопросы о том, что увидит игрок, когда он только начинает общение с определенным NPC или когда он исчерпает определенную тему в беседе, так что не останется естественного перехода к другой.

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

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

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

Но у нас все еще остаются варианты, как поступать с топиками, которые игрок уже однажды выбрал:

* убрать их из игры, так что они больше не будут видны (хорошо, если это решения, которые надо принять; не слишком хорошо, если они содержат важную информацию, к которой игрок захочет вернуться, если только эта информация не записана во внутриигровой журнал);
* оставить их на месте, чтобы их можно было выбрать еще раз (неуклюже и нереалистично);
* предоставить альтернативные «повторительные» версии диалога, так что при последующих попытках выбрать этот топик NPC покажет знание того, что игрок повторяется (удваивает [или еще хуже] количество текста и озвучки);
* удалить их, но предложить общий объединяющий топик на тему, так что игрок сможет сказать что-то вроде «напомни мне, что ты говорил про свадьбу Когтеклыка?», и получить краткое изложение уже сказанного ранее (требует динамической генерации обобщающих реплик; может вообще быть несовместимо с озвучкой).

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

== Имитация инициативы NPC ==
Часть того, что делает NPC неглубокими и «нечеловеческими» — это недостаток инициативы с их стороны.

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

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

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

В реальном диалоге люди передают очень много не только посредством того, что говорят, но и посредством разговорной прагматики. Настаивают ли они на том, чтобы за ними осталось последнее слово? Постоянно перебивают? Возвращаются снова и снова к одним и тем же избитым темам? Избегают отвечать на вопросы?

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

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

Это делает переходы от темы к теме гораздо более естественными, нежели заставлять игрока выбирать возврат обратно к “узлу” беседы. Это также позволяет системе диалогов моделировать различные типы характерного поведения. Нахальный NPC может быть одержим и надоедать одной и той же темой. Взбалмошный NPC может ежеминутно менять предмет обсуждения. Сдержанный может менее охотно делиться информацией самостоятельно, нежели другие.

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

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

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

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

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

== Модальность ==
Обсуждения системы разговоров в Façade чаще всего касаются интерфейса (разбор введенных команд) и управления лежащей в основе игры драмой, но гораздо меньше внимания уделяют тому факту, что в игре отсутствует отдельный режим для разговора. Речь свободно смешивается с другими типами действий, доступных игроку, такими как движение к и от других персонажей, объятия и манипуляции объектами.

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

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

Однако когда это получается, данный метод делает очень много для того, чтобы поднять NPC от статуса объектов до статуса равноправных участников во внутриигровом мире.

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

Обратите внимание, к примеру, на огромное допущение, с которого я начала: что топик — это неделимая единица, объединяющая реплику персонажа игрока и ответ NPC. Это совершенно не обязательно должно быть так — как показывает Façade — но работа с моделью, в которой ввод и вывод жестко не связаны друг с другом, сильно усложняет схему, в то время как достоинства для повествования и геймплея не слишком очевидны.

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

Перевод [[Антон Жучков|Антона Жучкова]], вычитка и коррекция [[Кирилл Петуховский|Кирилла Петуховского]]

[[Категория:Для разработчиков игр]]