Что на самом деле может знать ИИ-помощник пропавшего персонажа в детективной игре?

Разделяйте сюжетные записи и доступ помощника

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

Инструменты для создания интерактивной литературы, такие как Twine, организуют истории в виде фрагментов (passages) и могут использовать переменные и условную логику для изменения того, что видит игрок. Это даёт полезную аналогию для проектирования: рассматривайте каждую авторскую запись как дискретную единицу и делайте доступ к ней зависимым от соответствующего фрагмента, события или выбора. Twine’s basic concepts

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

Указывайте для каждого факта источник и время его появления

Полезная запись факта отвечает как минимум на четыре вопроса: что именно утверждается, кто или что предоставило информацию, когда она стала доступна помощнику и является ли она прямой или выведенной логически. Модель происхождения данных W3C (provenance model) описывает истоки информации в терминах сущностей, действий и агентов; она также позволяет фиксировать, как один элемент был получен из другого. Это практичная концепция для вымышленных записей, даже если в игре вместо формальной модели используются простые метки. W3C PROV Model Primer

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

Утверждение: Мара планировала покрасить садовые указатели; Источник: Общая заметка о планировании; Известно помощнику с: Понедельник, 10:00; Тип: Прямое утверждение

Утверждение: Указатели были перенесены в помещение; Источник: Обновление на общей доске; Известно помощнику с: Вторник, 16:30; Тип: Прямое обновление

Утверждение: Мара могла перенести их, потому что прогнозировался дождь; Источник: Заметка о погоде плюс обновление; Известно помощнику с: Вторник, 16:30; Тип: Логический вывод; не подтверждено

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

Чётко разграничивайте наблюдения, сообщения и выводы

Наличие источника не делает его содержимое автоматически достоверным. Персонаж может описывать то, что он видел; записка может быть неполной; в расписании может быть зафиксирован план, а не реально совершенное действие. Маркировка типа записи помогает помощнику точно формулировать ответ: фраза «На доске сказано, что указатели перенесли» отличается от «Мара перенесла указатели», и обе они отличаются от «Она, вероятно, перенесла их из-за погоды».

Используйте единый и лаконичный набор терминов: прямое наблюдение, свидетельство персонажа, авторская запись и логический вывод. Логический вывод должен ссылаться на подтверждающие его записи и оставаться помеченным как вывод. W3C PROV явным образом моделирует ответственность агентов за действия и происхождение одной сущности от другой; применение этого разграничения к диалогам помогает игре показать, откуда взялся вывод, вместо того чтобы преподносить его как новый непреложный факт. W3C PROV-O

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

Определяйте доступ во времени сюжета, а не только по персонажам

Для каждой записи указывайте событие, открывающее доступ помощнику. Отправленное сообщение может стать доступным сразу после отправки; объявление, прикреплённое к доске, — когда помощник проверит доску; разговор — только после того, как игрок решит спросить о нём. Избегайте расплывчатых формулировок вроде «помощник знает всё, что есть в архиве», если в сюжете не установлено, что содержит этот архив и когда он обновляется.

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

В Twine переменные истории могут быть доступны во всех фрагментах, тогда как временные переменные ограничены текущим фрагментом в Harlowe и SugarCube. Эта разница наглядно показывает, почему авторам следует осознанно решать, сохраняется ли факт на протяжении всей истории или относится только к конкретной сцене. Конкретная реализация зависит от формата истории, поэтому воспринимайте это правило как модель проектирования, а не как инструкцию по коду. Twine Cookbook: Variables

Сделайте неопределённость полезной для игрока

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

Такой подход поддерживает интригу без произвольного всеведения. Исследования в области интерактивного нарратива рассматривали, как ограниченность знаний может влиять на поведение игрока, включая работу на базе интерактивной книги *Anchorhead* для изучения моделей игроков. Для авторского помощника вывод с точки зрения дизайна вполне умеренный: то, что узнали игрок и помощник, может повлиять на их дальнейший выбор, поэтому отслеживайте эти состояния знаний явно. Rivera-Villicana et al., “Informing a BDI Player Model for an Interactive Narrative”

Быстрый чек-лист перед написанием реплик помощника

Перед составлением ответа проверьте следующие пункты для каждого значимого утверждения:

Присутствует ли утверждение в авторской записи или оно помечено как вывод?

Указан ли в записи источник и разделяет ли она план, свидетельство, наблюдение или более позднее подтверждение?

В какой момент сюжета помощник получил к ней доступ?

Позволяет ли вымышленная роль помощника иметь доступ к этому источнику?

Если запись неполна или противоречива, сохраняет ли диалог эту неопределённость?

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

Продолжить изучение темы