Состояния неудачи в текстовых играх: как отличить сюжетную неудачу от проблемы ввода или доставки

Сначала спросите себя, что именно пошло не так

Практичный первый вопрос: поняла ли игра предполагаемое действие и разрешила ли его в рамках сюжета? Если да, результат может быть сюжетной неудачей. Если нет, определите, в чём дело: во вводе, в неосведомлённости персонажа или в доставке системой. Это разделение на четыре части — инструмент проектирования, основанный на том, как системы интерактивной литературы разграничивают синтаксический анализ (парсинг), правила мира, развитие сюжета и отмену действий; это не универсальный технический стандарт. Например, в документации к Inform парсер и симулированная модель мира описываются как отдельные компоненты игры, а парсер может сообщать о нескольких различных причинах, почему команда не была сопоставлена. (Inform 6 Designer’s Manual: Introduction, Inform 6 Designer’s Manual §33: Helping the parser out of trouble)

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

1. Обоснованная сюжетная неудача

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

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

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

2. Неподдерживаемый ввод: игра не смогла распознать формулировку

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

Парсеры интерактивной литературы наглядно показывают, почему полезная обратная связь должна быть конкретной: Inform выдаёт разные ошибки для нераспознанного глагола, неясной ссылки, слишком короткого ввода и объекта, которого не видно. В руководстве также показано, как игра может заменить типовую ошибку парсера более информативным сообщением. (Inform 7 §18.35: Printing a parser error) В чат-игре лаконичный ответ мог бы выглядеть так: «Я не могу распознать фразу “спросить про абрикосы” здесь. Вы можете спросить о доставке или выбрать тему на прилавке».

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

3. Недоступные знания персонажа: корректный вопрос, на который пока нет ответа

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

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

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

4. Технический сбой доставки: возможно, действие так и не дошло до сюжета

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

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

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

Разграничивайте значения повтора, отмены и возобновления

Эти слова описывают разное влияние на состояние, поэтому не используйте их как синонимы. «Повторить» (retry) отправляет действие заново в текущем состоянии; оно не должно незаметно стирать уже свершившееся последствие. «Отменить» (undo) восстанавливает более раннее состояние. «Возобновить» (resume) продолжает игру с последнего подтверждённого состояния после прерывания. «Начать заново» (restart) запускает историю с самого начала.

Руководство по формату Harlowe для Twine описывает «undo» как возврат к предыдущему фрагменту с отменой изменений переменных, сделанных в текущем фрагменте; «restart» описывается как перезагрузка страницы для начала истории с нуля. Также отмечается, что история отмен может быть ограничена. Эти механики показывают, почему элемент управления должен сообщать масштаб своего действия, а не полагаться на размытую надпись «попробовать снова». (Harlowe 3.3.8 Manual: undo and restart)

Компактная последовательность решений помогает поддерживать единообразие интерфейса:

Поняла ли игра действие и разрешила ли его? Если да, сообщите о сюжетном исходе и оставшемся состоянии.

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

Было ли действие понято, но персонажу не хватает информации? Объясните границы знаний и любые внутриигровые способы узнать больше.

Есть ли неопределённость в обработке или доставке? Сообщите, что именно подтверждено, затем предложите безопасный способ проверить или продолжить.

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

Краткая проверка согласованности для каждого сообщения об ошибке

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

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

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