Почему сценарии модов разваливаются на середине

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

Но статья всё-таки не про него. Она про то, почему амбициозные сюжетные моды к Fallout, Skyrim или S.T.A.L.K.E.R. так часто начинаются с большими планами, красивыми концептами и огромным количеством идей, а потом постепенно останавливаются где-нибудь на середине.

Вы наверняка видели такую историю. Кто-то анонсирует большой мод, показывает трейлер, несколько концепт-артов, выкладывает пару озвученных диалогов. Через год выходит демо на два квеста. Ещё через год обновлений становится меньше. Потом в комментариях кто-нибудь спрашивает: «А что с модом?»

И получает ответ: проект жив, просто сейчас сложный период.

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

Сценарий перестаёт помещаться в голове.

Проблема не в идеях, а в количестве связей между ними

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

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

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

Это можно посчитать, и счёт получается неприятный. Трое персонажей дают три возможных отношения между ними. Пятеро — уже десять. Дюжина — шестьдесят шесть.

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

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

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

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

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

Поэтому чем дальше продвигается проект, тем меньше помогает просто помнить, как всё устроено.

Сценарий — это не только диалоги

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

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

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

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

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

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

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

Каждую такую ошибку можно исправить. Только сначала её нужно найти.

Мир должен существовать до начала игры

В этом смысле мне нравится пример Disco Elysium.

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

Команда Роберта Курвица сначала развивала этот мир как коллективный проект с элементами настольной ролевой игры. Потом появился роман Sacred and Terrible Air, опубликованный в 2013 году. Роман продался очень небольшим тиражом, после чего команда переключилась на разработку игры.

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

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

Это не значит, что для мода нужно сначала написать роман. Скорее наоборот: речь вообще не об объёме документа.

Важно, чтобы автор сам понимал, что происходило в этом мире до того момента, когда игрок в него пришёл.

Фракция — это не позиция, а люди, которые с ней не вполне согласны

Допустим, у нас есть то самое поселение. В нём фермеры, рейнджеры НКР и караванщики, которые возят воду.

На первый взгляд всё довольно просто. Фермеры хотят, чтобы вода стоила дешевле. Караванщики хотят заработать. Рейнджеры хотят порядка.

Но стоит начать писать квесты, как появляются дополнительные вопросы.

Фермеры могут быть разделены между теми, кто поддерживает НКР, и теми, кто считает, что республика только собирает налоги и ничего не даёт взамен. Караванщики могут зависеть от фермеров, хотя сами их терпеть не могут. Один рейнджер может искренне защищать поселение, а другой считать местных сборищем неблагодарных идиотов.

И вот тогда становится гораздо интереснее. Потому что конкретный человек может не совпадать с позицией своей фракции: фермер ненавидит НКР, но дружит с конкретным рейнджером; караванщик поддерживает одну сторону, но должен денег другой.

Такие противоречия как раз и дают материал для квестов.

В New Vegas подобное устройство мира работает особенно хорошо. НКР, Легион и мистер Хаус преследуют разные интересы в Мохаве, но внутри каждой стороны тоже есть свои проблемы и люди, не вполне согласные с официальной линией. Сама ситуация вокруг Хувер-Дам имеет длинную предысторию: первая битва за плотину произошла в 2277 году, а действие New Vegas — в 2281-м.

Поэтому я бы не стал хранить всё это только в тексте.

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

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

Хронология ломается незаметно

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

Особенно если действие происходит во вселенной с большим количеством уже существующей истории.

В Fallout достаточно одной неудачной фразы, чтобы появился целый набор вопросов. Допустим, персонаж говорит: «Мой отец воевал при Хувер-Дам».

Хорошо. Сколько лет персонажу? Сколько было его отцу в 2277 году? На какой стороне он воевал? Где находился до этого? А если в другом диалоге выясняется, что персонаж родился уже после первой битвы?

Одна маленькая реплика потянула за собой несколько новых проблем.

То же самое происходит внутри самого мода. Персонаж приехал в поселение после какого-то события — значит, не может знать его подробностей. Квест открывается после другого — значит, персонажи не должны ссылаться на его последствия раньше времени. Если человек умирает в четвёртом квесте, он не должен выдавать игроку новый квест в пятом.

Вроде бы очевидные вещи. Но сценарий редко пишется в том порядке, в котором его проходит игрок.

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

Самые дорогие ошибки обычно самые мелкие

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

Ничего страшного. Игрок может даже не заметить.

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

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

Через полгода вы сами пишете этого персонажа иначе

Есть ошибка тоньше предыдущей, и она бьёт сильнее, потому что формально ошибкой не является.

Персонаж может говорить совершенно правильные вещи, но звучать не как он.

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

Противоречия в фактах нет вовсе. Но персонаж распадается.

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

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

Не договоритесь. Точнее, договорённость работает ровно до тех пор, пока все помнят, о чём именно договорились.

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

ИИ здесь полезен как проверяющий, а не как автор

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

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

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

А вот проверять уже написанное — совсем другое дело.

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

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

Я поэтому и сделал в «Столе Писателя» именно такой режим: ИИ читает уже написанный текст и показывает места, которые стоит проверить — с цитатой и ссылкой на сцену, где он их нашёл. Не переписывает сцену и не решает за автора, как должен вести себя персонаж.

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

Поэтому я отношусь к результату как к списку мест для проверки. Не как к списку ошибок. Разница довольно важная.

Нарративная библия не заменяет игровой сценарий

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

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

Для этой части есть свои инструменты, и они хорошие.

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

Ink от Inkle — отдельный язык для интерактивного повествования, рассчитанный как раз на истории с большим количеством ветвлений. Есть редактор Inky, компилятор и интеграции с движками, сам проект открыт под MIT-лицензией.

articy:draft предназначен для более сложных нарративных проектов, где нужно связывать персонажей, диалоги, локации и ветки истории. У articy:draft X есть бесплатная версия с ограничением в 700 объектов на проект, причём коммерческое использование разрешено.

А если говорить именно о Fallout: New Vegas, то в конечном итоге всё равно придётся работать с GECK: диалоги там связаны с топиками, квестами, условиями и скриптами, и это уже не просто написание текста в отдельном редакторе.

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

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

А потом в голове просто заканчивается место

Если вернуться к началу статьи, получается довольно простая картина.

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

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

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

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

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

Пока всё помещается в голове, кажется, что проблем нет.

А потом в голове просто заканчивается место.

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