Как создать ИИ-библию сеттинга без потери сюжетной преемственности
Создайте ИИ-библию сеттинга, присвоив каждому установленному факту постоянный идентификатор, ответственного за решения человека, источник и четкие границы применимости. Отслеживайте, когда он истинен, где действует и какие персонажи о нем знают. Просите ИИ предлагать дополнения и отмечать противоречия; требуйте явного редакторского решения, прежде чем эти предложения станут каноном. Это руководство предназначено для авторов художественной литературы и игровых сценаристов, создающих рабочий справочник для своей следующей главы, сцены или квеста. Задача состоит в том, чтобы сформировать библию, к которой можно обращаться и которую можно дорабатывать без случайного изменения правил истории. Представленный ниже шаблон реестра преемственности связывает факты со сценами, которые от них зависят.
Что должна содержать ваша ИИ-библия сеттинга?
Начните с компактной справочной системы, отвечающей на практические вопросы, возникающие при написании текста. Может ли этот персонаж добраться до обсерватории до заката? Узнал ли он, как открывается ее дверь? Изменится ли этот ответ в другой сюжетной ветке?
Разделите библию на шесть взаимосвязанных разделов:
Используйте электронную таблицу, связанные документы или базу данных, с которой вам удобно работать. Присваивайте сущностям стабильные идентификаторы, такие как LOC-01 и CHAR-02; храните отображаемые имена и псевдонимы в отдельных полях. Переименование «Стеклянной обсерватории» не должно ломать каждую ссылку на запись о ее местоположении.
Относитесь к повествовательным описаниям как к удобным представлениям данных из реестра. Если краткое описание расходится с базовой записью, изучите первоисточник и устраните противоречие, прежде чем писать текст на основе любой из версий.
Кто владеет фактом и что делает его каноном?
Для данного рабочего процесса владение фактом состоит из двух частей: одна авторитетная запись содержит само утверждение, и один человек отвечает за утверждение изменений. Писатель-одиночка выполняет эту роль сам. Команда может поручить решения по локациям дизайнеру мира, а раскрытие тайн персонажей — нарративному лидеру, назначив одного ответственного за согласование пересекающихся решений.
Фиксируйте происхождение данных наряду с владением. В обзоре спецификации PROV от W3C (https://www.w3.org/TR/prov-overview/) происхождение (provenance) описывается как информация о сущностях, действиях и людях, участвовавших в создании чего-либо. В применении к библии истории это означает сохранение информации о том, откуда взялось утверждение, как оно менялось и кто его утвердил. Представленный здесь реестр адаптирует этот принцип; он не является формальной реализацией PROV.
Присвойте каждой записи явный статус:
При переносе существующей рукописи поручите ИИ извлечь потенциальные факты с точными ссылками на сцены и короткими подтверждающими цитатами. Проверяйте ссылки самостоятельно. Слова персонажа «обсерватория всегда заперта» подтверждают лишь то, что данное утверждение было произнесено; это не делает его автоматически объективным правилом мира.
Зафиксируйте правила иерархии источников вашего проекта. Например: принятое решение о ретконе отменяет предыдущую каноническую запись; принятые исходные сцены устанавливают факты; черновые наброски и результаты мозгового штурма остаются предварительными. Если две утвержденные сцены противоречат друг другу, отметьте конфликт как неразрешенный, пока не решите, какая из них будет изменена.
Как отслеживать хронологию и локации вместе?
Фиксируйте сюжетное время отдельно от времени внесения правок. Фраза «Мост закрывается на 6-й день» описывает событие. Фраза «Автор изменил дату закрытия моста в редакции 4» описывает редакторское решение. Их смешение создает двусмысленность: изменился ли сам мир или было исправлено его описание.
Для каждого события фиксируйте самое раннее и самое позднее возможное время, место, участников, предварительные условия и результирующее состояние. Используйте диапазоны, когда точность не требуется: формулировка «после утренней доставки, до заката» может быть полезнее выдуманного точного времени. Определите единицы календаря, если в вашем сеттинге используются нестандартные дни или времена года.
Для каждого маршрута записывайте пункт отправления, пункт назначения, способ перемещения, продолжительность или диапазон времени, а также условия доступности. Указывайте, действует ли маршрут в обоих направлениях. На карте два места могут находиться рядом, в то время как установленный вами маршрут требует долгого обхода.
Рассмотрим наглядный пример проверки преемственности: курьер выходит из сада в 09:00, путь до обсерватории занимает три часа, и еще 30 минут уходит на получение линзы. Самое раннее время прибытия — 12:30. Сцена, в которой курьер оказывается там в полдень, противоречит этим вводным данным, если только не действует утвержденное исключение.
Разрешите противоречие, изменив один из параметров: время отправления, маршрут, задержку или время встречи. Если дорога занимает от двух до четырех часов, время прибытия становится диапазоном. Сохраняйте эту неопределенность вместо того, чтобы фиксировать строгое противоречие.
Как отделить объективную правду мира от знаний персонажей?
Ведите записи о знаниях отдельно от объективных фактов. Для каждого значимого раскрытия фиксируйте персонажа, факт или убеждение, событие получения информации, время и условия сюжетной ветки. Различайте понятия «знает», «подозревает», «заблуждается» и «еще не узнал». Отсутствие записи означает лишь то, что знание не зафиксировано; это не доказывает неосведомленность.
У этого подхода есть прямой аналог в интерактивном повествовании. Официальное руководство Inkle по языку ink (https://www.inklestudios.com/ink/web-tutorial/) демонстрирует условный текст и выбор вариантов на основе ранее посещенных фрагментов сюжета. Там также описываются пользовательские переменные. Эти механизмы могут отражать доступ к информации, хотя авторам все равно необходимо решать, действительно ли посещение сцены дает персонажу знание конкретного факта.
Например, дверь обсерватории может открываться, когда медный диск совмещен с меткой. Это факт мира. То, что Мира узнает об этой процедуре во время демонстрации, — отдельное событие. Другой персонаж, прочитавший неполную записку, может лишь догадываться, как это работает.
В нелинейной игре привязывайте событие получения знания к соответствующему пути или условию состояния. Протестируйте как маршрут, где персонаж узнал процедуру, так и тот, где он ее пропустил. В романе следите за тем, чтобы объяснения и диалоги происходили после события получения знания по сюжетному времени, даже если главы расположены не в хронологическом порядке.
Универсальный реестр преемственности
Используйте следующие поля в качестве столбцов электронной таблицы или как шаблон записи в ваших заметках. Сохраняйте одно независимо изменяемое утверждение на запись. Примеры приведены исключительно для демонстрации рабочего процесса.
Ниже представлен компактный вид трех связанных записей. В полном реестре для каждой строки сохраняются поля доказательств и авторства, описанные выше.
Не допускайте, чтобы статус «не разрешено» молчаливо превращался в «нет». Вопрос Q-003 оставляет вариант с диском-заменителем открытым. Он ни разрешает, ни запрещает его. Сцена, требующая ответа, должна инициировать запрос на принятие решения.
Назначьте каждому открытому вопросу ответственного и точку принятия решения: «Разрешить до написания сцены S-15». Если ответ намеренно скрывается от читателей, отметьте, знает ли его сам автор. Известный автору секрет и пока не решенный дизайнерский вопрос требуют разного подхода.
Как ИИ должен использовать библию во время работы над текстом?
Подготовьте пакет контекста сцены, содержащий время, место, точку зрения, ветку, соответствующие канонические записи и неразрешенные зависимости целевой сцены. Включайте связанные предварительные условия, а не только записи, содержащие те же ключевые слова. Сцена у двери может зависеть от более ранней демонстрации в совершенно другой локации.
Используйте промпт, подобный этой универсальной инструкции:
Сопоставьте предоставленную сцену с прикрепленными записями преемственности и их указанной редакцией. Для каждого потенциального противоречия процитируйте фрагмент сцены и укажите соответствующий ID записи. Классифицируйте его как противоречие, недостающую информацию или предложенное дополнение. Проверьте хронологию, перемещения, доступ к локациям, знания персонажей и условия сюжетных веток. Сохраняйте неразрешенные вопросы. Варианты исправления предлагайте отдельно; не меняйте канон и не придумывайте ссылки на источники. Укажите, какие проверки не удалось завершить на основе предоставленных материалов.
Для генеративных задач запрашивайте альтернативы в рамках строгих ограничений: «Предложите три способа задержать Миру, не изменяя F-014 и не давая ей знаний до E-008». Описывайте желаемую атмосферу, темп и особенности окружения своими словами.
Проверяйте результат в два этапа. Сначала убедитесь, подтверждают ли указанные записи сделанные выводы. Затем решите, какие предложения идут на пользу истории. В реестр вносятся только утвержденные изменения. Если необходимый источник отсутствует, найдите его или оставьте замечание в статусе неразрешенного.
Как вносить ретконы, не стирая историю изменений?
Отличайте обычное событие от реткона. Если на 11-й день на двери появляется новый механизм, добавьте переходное событие и новое правило, ограниченное по времени. Если вы решили, что на ней всегда был другой механизм, исправьте более ранний канон и проверьте каждую зависимую сцену.
История версий позволяет восстанавливать прежние состояния. Введение в контроль версий в официальной книге по Git (https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control) объясняет, как системы контроля версий фиксируют изменения, помогают находить различия и позволяют возвращаться к предыдущим редакциям. Git — лишь один из вариантов; выберите систему работы с документами с удобной историей правок, если она лучше подходит для ваших задач. Отдельно фиксируйте причины изменения сюжетных решений.
Для каждого предлагаемого реткона:
Универсальная запись в журнале изменений должна содержать ID изменения, дату редакции, ответственного за решение, причину, старую запись, заменяющую запись, затронутые материалы и статус проверки. Например: «CH-006 предлагает требовать два совмещенных диска; затрагивает F-014, E-008, K-009 и S-12; решение ожидает утверждения». Одно лишь утверждение не означает, что зависимые сцены уже были исправлены.
Что следует проверить перед утверждением сцены?
После творческой доработки сцены прочитайте ее один раз исключительно для проверки преемственности. Убедитесь, что обязательные события уже произошли, условия перемещения и доступа соблюдены, персонажи владеют информацией, которую используют, а факты, специфичные для конкретной ветки, не выходят за ее пределы. Проверьте, чтобы новые детали были либо приняты в канон, либо явно оставались предварительными.
Зафиксируйте редакцию библии, использованную для этой проверки. Если последующее изменение затронет одну из зависимостей сцены, отправьте ее на повторное рассмотрение. Вы можете начать с одной локации, одного персонажа и ключевых фактов следующей сцены, расширяя реестр каждый раз, когда новая деталь начинает накладывать ограничения на дальнейшие события.