Просмотр кода страницы Три вида повествовательных структур в качестве альтернативы ветвлению

'''Автор:''' [[Эмили Шорт]], [https://emshort.wordpress.com/2016/04/12/beyond-branching-quality-based-and-salience-based-narrative-structures/ оригинал статьи]

'''Перевод:''' [http://www.progamer.ru/dev/beyond-branching.htm Progamer.ru]

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

Есть немало хороших статей о том, как сделать ветвящиеся сюжеты тематически насыщенными, внедрить в них переменные, [[Как написать длинную интерактивную повесть|избежать комбинаторного взрыва]] и просто [http://gdcvault.com/play/1023072/All-Choice-No-Consequence-Efficiently минимизировать ветвление относительно доступных выборов]. [http://gdcvault.com/play/1023095/The-Shapes-in-Your-Story Джей Тейлор-Лейрд (Jay Taylor-Laird) рассказывал о ветвящихся структурах на GDC 2016], и среди прочего там рассматривалась карта ''Heavy Rain.'' И, касаясь данной темы, я не могу не ссылаться на знаменитый [[Стандартные структуры в играх на основе выбора|текст Сэма Кабо Эшвелла]] (Sam Kabo Ashwell) о [[CYOA]]-структурах.

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

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

Здесь я постараюсь подобрать такое решение, которое предложит игроку умеренно-высокую степень контроля над тем, к чему приведёт история, [https://emshort.wordpress.com/2015/05/24/framed-invisible-parties-and-the-world-plot-interface/ а не над тем,] [https://emshort.wordpress.com/2015/01/14/games-of-co-authorship/ как она будет рассказываться.]

Ещё я бы не связывалась с комплексной симуляцией, поскольку подобные вещи – от ''Dwarf Fortress'' до [[ifwiki-en:Façade|''Façade'']] – зачастую требуют пристального внимания к своим особенностям, и изначально вообще не предназначаются для такого применения. Отметив эти предостережения, начинаем…

[https://emshort.wordpress.com/category/quality-based-narrative/ Повествование на основе качеств] ([[quality-based narrative]], QBN) – этот термин введён Failbetter Games для обозначения [http://www.failbettergames.com/tag/narrative-engineering/ интерактивных историй, завязанных на «сторилетах», открывающихся посредством качеств.]¹ Сторилет – это один-два абзаца текста с последующим выбором (где каждый вариант Failbetter называют ветвью) и текстовым описанием результата выбора. Качества – это числовые переменные, которые могут расти или сокращаться по ходу игры и олицетворять всё что угодно, от инвентаря (сколько у вас бутылок лаудариума?) и навыков (какого уровня ваша Опасность?) до прогресса истории (как далеко вы продвинулись в отношениях с тётушкой?). QBN реализованы в [[ifwiki-en:StoryNexus|StoryNexus]]; имелись они в своё время и в [[ifwiki-en:Varytale|Varytale]], правда в гибридной форме, позволявшей сторилетам содержать собственные [[CYOA]]-сегменты.

Главное преимущество QBN в том, что они позволяют множеству коротких историй объединяться интересным образом. [[ifwiki-en:Fallen London|Fallen London]], типичный образец повествования на основе качеств, содержит необычайное количество сюжетных арок о персонажах и ситуациях, разбросанных по всему городу. Некоторые из них длиной всего в один сторилет: что-то произошло, вы отреагировали, получили результат, конец. Ваши навыки могут определять успешность конкретных действий, а результатом может быть изменение характеристик, при этом в плане сюжета мало что изменится. Другие арки могут быть гораздо длиннее, особенно «Исключительные истории», доступные при оплате премиум-контента: моя история [https://emshort.wordpress.com/2016/02/25/new-release-the-frequently-deceased/ «The Frequently Deceased»] состоит примерно из сотни ответвлений.

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

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

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

QBN довольно сложно масштабировать как с начала, так и с конца. Начинающим авторам будет непросто работать с [[ifwiki-en:StoryNexus|StoryNexus]], поскольку контент остаётся неинтересным, пока не накопится определённое количество сторилетов; поэтому, чтобы почувствовать какую-то отдачу, придётся провести в конструкторе немало времени. И наоборот, когда контента становится очень много, игрок может потеряться в списке доступных сторилетов. В последних обновлениях [[ifwiki-en:Fallen London|FL]] с этой проблемой понемногу борются: упорядочивание сторилетов согласно авторству, разные цвета для важных сторилетов и т.д. В любой длинной истории выделение таких элементов становится отдельной проблемой.

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

Ещё это намного лучше [[CYOA]]-структур в плане представления игроку, скажем, трёх сюжетных фрагментов в любой последовательности. Простое ветвящееся повествование для этого будет нуждаться в массе неприглядных повторений:

* определяем орудие убийства
:* затем определяем мотив
::* затем определяем возможность
:* затем определяем возможность
::* затем определяем мотив
* определяем мотив
:* затем определяем орудие убийства
::* затем определяем возможность
:* затем определяем возможность
::* затем определяем орудие убийства
* определяем возможность
:* затем определяем орудие убийства
::* затем определяем мотив
:* затем определяем мотив
::* затем определяем орудие убийства

QBN позволит сделать то же самое с помощью четырёх сторилетов, один из которых откроется по завершении остальных:

* Определяем орудие убийства
* Определяем мотив
* Определяем возможность
* Обвиняем убийцу (если качества демонстрируют, что мы завершили 1-3)

Конечно, многие системы ветвящихся повествований позволяют пользоваться для этого циклами и переменными: к примеру, [[ChoiceScript]] даёт возможность перенаправлять игрока в место сбора улик, пока все они не будут найдены. Но в [[ChoiceScript]] точка повторного входа – исключительный случай, тогда как в QBN подобные вещи – норма.

Ещё одна хитрость QBN (по крайней мере, так работает [[StoryNexus]]): они требуют от автора отслеживать прогресс истории вручную. Если у вас есть костяк сюжета – происходит A, потом что-то ещё в случайном порядке, потом B, ещё больше событий в любом порядке, потом C – вам придётся вручную определять качество, необходимое для открытия A, потом определить значение, знаменующее завершение A, затем другое значение для открытия B, значение для его завершения… ну вы поняли. Придётся повозиться с обеспечением функциональности, которая работает автоматически во многих других системах согласно способу написания кода (думаю, проблема возникла из-за того, что арки со множеством сторилетов не были обычным делом на заре [[Fallen London]]).

Исходя из описания скульптурного гипертекста [http://www.eastgate.com/storyspace/ Storyspace 3], его тоже можно отнести к QBN, хотя сама я этим инструментом не пользовалась.

¹: Сами Failbetter уже полностью отказались от этого термина, поскольку он двусмысленно намекает на «некачественность» других типов повествования; я придерживаюсь его в отсутствие чего-то более подходящего. [[Алексис Кеннеди]] (Alexis Kennedy) предлагает вариант «плавучие льдины». Боюсь, что это будет наводить людей на мысли об [http://ifdb.tads.org/viewgame?id=pu8btwofyvja347d интерактивных историях Кевина Сноу] (Kevin Snow), но если вам эта фраза нравится больше, можете популяризировать именно её.

===== Повествование на основе совпадений ===== 

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

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

К примеру, если у нас имеется диалог с такими метками:

    (локация = кухня) «Эй, кто-нибудь хочет есть?»

    (локация = кухня, кладовая = пусто) «Эх, похоже, кто-то смёл всё подчистую».

    (локация = кухня, печь = горит) «Дай мне свой факел, я его зажгу».

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

Отличным примером здесь послужит [http://www.gdcvault.com/play/1015528/AI-driven-Dynamic-Dialog-through диалоговая система Элана Раскина (Elan Ruskin) из Left 4 Dead], а из недавних игр её [http://www.slate.com/articles/arts/gaming/2016/02/the_video_game_firewatch_and_its_origins_in_1980s_text_adventures.html переняла Firewatch.] Обе игры позволяют исследовать трёхмерное окружение, что приводит к различным ситуациям, так что необходимо выдавать игроку диалоги, тесно связанные с конкретной ситуацией.

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

Оба упомянутых мной применения совпадений не случайно созданы под специфичное срабатывание диалогов и управляются со слоем повествования, наложенным поверх исследуемого окружения. Я могу сделать вывод, что в Firewatch таится множество флагов, но игра также во многом полагается на позицию персонажа игрока и близлежащих объектов, что открывает простор для немалого количества индивидуально моделируемых состояний мира (в отличие от такого подхода, в QBN-системе качество – уже само по себе состояние мира. Даже локация – своего рода качество, а в отдельно взятый момент времени игрок может находиться только в одной локации).

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

Если говорить о парсерных играх, это напоминает реагирующих NPC, вроде рыбы из [[A Day for Fresh Sushi]]: персонажей, комментирующих поступки игрока, не делая упор на разговоре как основной части взаимодействия. Это может быть довольно эффективным способом добавить эмоциональный слой, реагирующий на все предыдущие действия игрока.

Куда более ярким примером служит [http://web.archive.org/web/20040404061317/www.channelzilch.com/doug/battle.htm The King of Chicago] Дага Шарпа (Doug Sharp). Там не только генерируются подходящие диалоги, но и на основании всего, что уже произошло, определяется, какая из набора возможных сюжетных сцен должна идти следующей. Совпадения вычисляются посредством не логических, а числовых переменных состояния.

Формирование сюжета таким способом предполагает очевидную уязвимость в плане дизайна. В ''Left 4 Dead'' и ''Firewatch'' имеются геймплейные арки без проверки на совпадения. Таким образом создаётся контекст и формируются общие очертания всех вещей. Если вы действительно связываете все игровые события в последовательность, представьте, как игрок спокойно проходит один-два акта, а потом оказывается, что он выполнил все условия для расправы бандитов над его персонажем: плохая концовка может быть эффективной, если размещается автором в подходящем месте, и она не всегда будет удачно работать, срабатывая при совпадениях. Точно не знаю, предусмотрены ли в ''TKoC'' решения этой проблемы (попробовать ремейк пока не довелось), но думаю, можно обойти её, если драматичные моменты будут сильнее влиять на определённый ряд переменных.

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

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

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

===== Повествование с путевыми точками =====

Это тоже придуманный мной термин, но он совпадает с методом, что я использовала в [[ifwiki-en:Glass|Glass]]. Интерактивность в [[ifwiki-en:Glass|Glass]] представляет собой разговор, тему которого могут менять и [[NPC]], и игрок, при этом есть темы, которые продвигают историю вперёд.

Некоторые строки диалогов связаны не столько с темой, сколько с ''переходом между темами'' – так, [[NPC]] может поменять тему со «Знати» на «Бога», например – и можно перебираться между темами, предполагая, где именно расположен переход. Допустим, схема разговора выглядит так:

[[{{ns:6}}:Waypoint12.jpg]]

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

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

[[{{ns:6}}:Waypoint22.jpg]]

На первом ходу NPC двигаются «Люди» -> «Бог» -> «Знать» и произносят реплики, связанные с переходом «Люди» -> «Бог». Однако, игрок на своём ходу возвращает тему к «Людям».

[[{{ns:6}}:Waypoint32.jpg]]

NPC уже пользовались переходом «Люди» -> «Бог», так что его приоритет при выборе пути снижен. Сохраняя стабильность системы, мы сделаем для него некий стандартный текст, но NPC не пойдут по этому пути, если у них будут другие варианты. Поэтому, чтобы продвинуться к «Знати», они идут через «Правительство»:

[[{{ns:6}}:Waypoint42.jpg]]

В процессе они упоминают «Народные волнения». Это подсказка для игрока, что он может перейти к теме «Опасность революции» и получить таким образом альтернативную сцену.

[[{{ns:6}}:Waypoint52.jpg]]

Однако, если игрок не вмешается, [[NPC]] пойдут через переход «Королевские советники» и завершат сцену обычным способом на «Знати».

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

Система спланирована так, чтобы вы думали, будто [[NPC]] меняют реплики, реагируя на ваши слова, но при этом главная задача по продвижению сюжета лежала на них, а не на игроке. К тому же, это ставит протагониста в противостоящую позицию – что-то интересное произойдёт, если вы будете упоминать темы, о которых [[NPC]] говорить не стремятся: ваша роль – сидеть и вылавливать подтекст в диалоге. А иногда будет тактически выгодно подождать пару ходов, позволяя [[NPC]] говорить, чтобы потом начать диалог с новой начальной точки.

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

Это своего рода противоположность [[комбинаторный взрыв|комбинаторного взрыва]] в ветвящемся повествовании, где вы как автор получаете наказание за добавление нового контента в виде необходимости создавать ''ещё больше контента''. В [[Glass]] сюжетный движок постоянно стремится уравновесить историю, двигаясь от вредоносных действий игрока в сторону авторского замысла. Чем больше контента я создам, тем больше будет способов пройти через тему и тем эффективнее и отзывчивее будет балансирование истории.

В [[ifwiki-en:Glass|Glass]] речь идёт о темах разговора; другим применением структуры будет сюжет с сильным влиянием рассказчика или же рассказчиком, который что-то скрывает: игрок может прямо указать на желаемое продолжение диалога, а рассказчик отреагирует шуткой и вернётся к теме, которую сам предпочитает. В общем, я думаю, такая модель подходит для сюжетов, представляющих собой борьбу игрока и рассказчика.

----

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

----

Естественно, есть множество других вариантов, помимо упомянутых мной – включая знакомый формат на основе карты ([[80 Days]]; или же парсерные игры с блокирующими головоломками); анализ базы данных, как в [[ifwiki-en:Her Story|Her Story]] или [[ifwiki-en:Analogue: A Hate Story|Analogue: A Hate Story]]; игры с [https://emshort.wordpress.com/2012/09/15/the-holographic-story/ голографической моделью сюжета], где текст расширяется, изменяется или переписывается для углубления в тонкости истории, и иногда целая сюжетная арка на виду с самого начала; и игры с повествованием на основе карточной колоды, где порядок карт выбирает игрок.

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