Когда игра должна предлагать варианты выбора после неоднократного непонимания ввода игрока?
Если игра не смогла распознать текстовое действие игрока более одного раза, ей следует прекратить требовать перефразирования и предложить небольшой необязательный набор релевантных действий. Сохраняйте введенный текст видимым или доступным иным способом, объясняйте, к чему приведут предложенные варианты, и обеспечьте понятный способ вернуться к свободному вводу текста. Это шаг восстановления при повторных сбоях, а не просто уточняющий вопрос, когда неоднозначно лишь одно действие.
Относитесь к повторяющимся ошибкам как к точке восстановления
Однократное уточнение полезно, когда игра поняла большую часть действия, но не может определить, какой именно объект имеет в виду игрок: «Вы имеете в виду латунный ключ или серебряный ключ?» Неоднократно нераспознанный текст — это другая проблема. Система может не понимать, что именно пытается сделать игрок, или в ее словаре может не быть слов, выбранных игроком. Повторение фразы «Попробуйте иначе» заставляет игрока гадать о скрытых правилах парсера.
Исследования диалоговых интерфейсов в играх описывают это противоречие: свободный ввод на естественном языке допускает более широкий спектр ответов, но также может не распознать намерения игроков; фиксированные меню ответов проще интерпретировать, но они ограничивают свободу выражения. Эти данные подтверждают использование меню выбора в качестве резервного пути (fallback), а не стандартной замены свободного текста. «Playing with words: from intuition to evaluation of game dialogue interfaces»
Практическим триггером могут служить две подряд нераспознанные попытки в одной и той же сцене или для одного действия. Это рекомендация по проектированию, а не универсальный порог, установленный упомянутыми исследованиями. Важными свойствами являются предсказуемость триггера, его привязка к текущей задаче и срабатывание до того, как игра загонит игрока в затяжной цикл. Игре может потребоваться другой порог, если ее метод ввода особенно зашумлен или если эксперименты являются частью игрового процесса сцены; такое решение должно приниматься осознанно и проверяться на практике.
Сохраняйте то, что игрок уже попытался ввести
Когда появляется резервное меню, сохраняйте последний введенный текст в поле ввода, логе или другом видимом месте. Если игра стирает его, игроку, возможно, придется заново формулировать уже составленное действие. Отображение фразы также помогает прояснить, что игра получила ввод, но не смогла сопоставить его с поддерживаемым действием.
Резервный сценарий может подтвердить попытку, не обвиняя игрока: «Не удалось сопоставить „поднять решетку крюком“ ни с одним действием здесь». Если игра смогла определить правдоподобную часть действия, укажите, что именно удалось распознать: «Я вижу решетку, но не понимаю, что именно вы хотите с ней сделать». Не заявляйте о большем уровне понимания, чем есть у системы на самом деле. Такая формулировка четко разграничивает неизвестную команду и известный целевой объект с неопределенным действием.
В пояснении W3C к разделу Error Suggestion (Предложение по исправлению ошибок) говорится, что при отклонении ввода и наличии известного полезного исправления система должна его предоставить. Примеры включают показ допустимых значений или вероятных исправлений. Это руководство написано для веб-контента, а не для игровых диалогов, поэтому его применение к играм является осознанной адаптацией дизайна. Общий принцип здесь крайне полезен: предложите конкретный следующий шаг, когда система в состоянии это сделать. W3C, «Understanding Success Criterion 3.3.3: Error Suggestion»
Предложите короткое меню действий, подходящих для текущего момента
Резервное меню должно содержать несколько предусмотренных разработчиками действий, поддерживаемых текущей сценой. Например, если игрок взаимодействует с запертыми воротами, вариантами могут быть: «Осмотреть замок», «Попробовать ключ» и «Отойти». Это иллюстративные варианты, а не утверждения о какой-либо конкретной игре. Варианты должны описывать понятные действия, использовать четкие глаголы и не уводить игрока в ветки, которые игра в данный момент не может обработать.
Сохраняйте варианты привязанными к сцене и ее состоянию. Общее меню вроде «Исследовать», «Поговорить» и «Использовать предмет» может быть менее полезным, если непосредственным препятствием является конкретный объект. И наоборот, узкоспециализированный вариант должен появляться только тогда, когда выполнены его условия. Если ключа нет в инвентаре игрока, не предлагайте вариант «Попробовать ключ». Меню, предлагающее невозможные действия, лишь заменяет одну путаницу другой.
Исследования игровых диалогов также показывают, что стиль меню влияет на восприятие: полные предложения помогают передать то, что скажет персонаж, тогда как абстрактные метки придают взаимодействию характер стратегического управления. Правильный уровень детализации зависит от действия и его последствий. Используйте короткую подпись для простого действия; давайте более подробные пояснения, когда выбор может изменить сцену или повлечь за собой заметные последствия для игрока. «Playing with words: from intuition to evaluation of game dialogue interfaces»
Сделайте меню необязательным и покажите, как из него выйти
Меню должно предлагать путь вперед, а не просто молча отключать свободный ввод текста. Добавьте видимый вариант вроде «Продолжить ввод» или «Вернуться к свободному тексту» и дайте понять, что игрок может им воспользоваться. Если игра принимает свободный текст во время отображения вариантов, сделайте это поведение очевидным; если выбор варианта закрывает меню, сообщите и об этом.
Используйте подписи действий для кнопок и вариантов выбора. Дизайн-система W3C рекомендует использовать на кнопках текст, называющий действие пользователя, вместо шаблонных названий вроде «Отправить». В игре формулировки «Осмотреть замок» или «Продолжить ввод» гораздо информативнее, чем просто «Продолжить». Конкретные рекомендации по интерфейсу взяты из веб-форм, однако четкость именования действий легко переносится и на управление в играх. W3C Design System, «Forms»
Сохраняйте единообразие пути выхода. Если в одном меню восстановления используется «Продолжить ввод», а в другом — «Отмена», игроки могут не понять, сохраняют ли оба варианта одно и то же состояние. Если выход из меню приводит к сбросу текста, предупредите об этом заранее. Если игрок может выбирать варианты с помощью клавиатуры, контроллера, сенсорного экрана или другого поддерживаемого метода, убедитесь, что к вариантам восстановления можно получить доступ и активировать их в рамках стандартной схемы управления игры.
Избегайте циклов с бесконечными просьбами перефразировать
После показа меню не возвращайтесь сразу к шаблонной подсказке «Я не понял; попробуйте еще раз», если игрок снова вводит неподдерживаемую команду. Это лишь перезапустит цикл ошибок. Вместо этого сохраните новую попытку и оставьте предложенные варианты доступными или дайте более конкретную подсказку, если у парсера достаточно данных для этого. Позвольте игроку выбрать предусмотренное разработчиками действие, отредактировать текст или покинуть взаимодействие, если это уместно в контексте сцены.
Руководство Microsoft по проектированию резервных сценариев диалога рекомендует выстраивать последовательность резервных ответов, избегать одинаковых повторяющихся извинений и сохранять точку, на которой остановился пользователь при перенаправлении. Оно разработано для диалоговых продуктов, поэтому точные советы по переключению (handoff) могут не подходить для игр буквально. Главная мысль, которую стоит перенять: делайте каждый шаг восстановления полезным и не заставляйте человека заново выполнять уже проделанную работу. Microsoft Learn, «Design graceful fallbacks and handoffs»
Простая последовательность восстановления может выглядеть следующим образом:
Первый неподдерживаемый ввод: сообщить, что действие не распознано; сохранить текст и дать краткую, релевантную для сцены подсказку, если она есть.
Второй неподдерживаемый ввод: отобразить небольшое меню допустимых действий, предусмотренных автором, рядом с сохраненным текстом.
В этом меню: позволить игроку выбрать действие, отредактировать и повторно отправить текст или выйти из взаимодействия, если правила игры это допускают.
Если следующий ввод все еще не поддерживается: оставить доступными варианты восстановления и пояснить доступное пространство действий вместо повторного показа одной и той же подсказки с просьбой перефразировать.
Проверяйте, действительно ли резервный сценарий помогает
Протестируйте последовательность на правдоподобных вариантах ввода, отличающихся от предпочтительных формулировок дизайнера: синонимах, коротких командах, названиях предметов и более длинных описаниях. Убедитесь, что игра сохраняет введенный текст после каждого сбоя, показывает подходящие для текущей сцены варианты и позволяет игроку вернуться к вводу текста без потери контекста. Также проверьте, что происходит, когда вариант выбора становится недействительным из-за изменения состояния сцены до его выбора.
Для каждого теста задавайте конкретный вопрос: понимает ли игрок после ошибки, что именно не удалось распознать игре? Видит ли он полезное следующее действие? Может ли он продолжать развивать свою первоначальную мысль, не будучи вынужденным выбирать вариант из меню? Если ответ на любой из этих вопросов отрицательный, доработайте сообщение, набор вариантов или путь возврата. Это предлагаемый контрольный список оценки, основанный на приведенных выше принципах взаимодействия, а не зафиксированный результат пользовательского исследования.
Цель состоит в предсказуемом восстановлении: подтвердить неподдерживаемый ввод, сохранить его, предложить релевантные варианты после повторяющихся ошибок и сделать свободный ввод явным путем вперед. Меню должно уменьшить необходимость гадать, оставляя при этом за игроком право решать, пользоваться им или нет.