Metlivi 博客

当游戏多次误解玩家输入时,何时应该提供选项?

在游戏多次未能理解玩家的自由文本操作后,应当停止要求玩家换一种说法,转而提供一组少量的、可选的相关操作选项。保留玩家尝试输入的操作(使其可见或以其他方式留存),解释各选项的作用,并提供返回自由文本输入的明确途径。这是针对重复失败的一种恢复步骤,与在单次操作含糊不清时提出一个澄清性问题并不相同。

2026年9月30日7 分钟阅读休闲、旅行与城市体验作者:Metlivi Editorial Team
第 1 节

将多次未命中视为恢复点

当游戏已理解操作的大部分内容,但无法确定玩家具体指的是哪个指代对象时,一次性的澄清是很有用的,例如:“你是想用黄铜钥匙还是银钥匙?”然而,文本屡次无法被识别则是另一回事。此时系统可能不知道玩家想要做什么,或者其词表并未包含玩家选用的词语。如果不断重复“换一种说法试试”,只会让玩家盲目猜测解析器隐藏的规则。

关于游戏对话界面的研究指出了这种矛盾:自由形式的语言可以容纳更广泛的回复,但可能无法识别玩家的意图;固定选项菜单更容易被系统解析,却限制了表达的丰富性。这些证据表明,应将选项菜单作为后备方案,而非作为自由文本的默认替代品。参考《玩转文字:从直觉到游戏对话界面的评估》(Playing with words: from intuition to evaluation of game dialogue interfaces)。

一个实用的触发条件是在同一场景或操作中连续出现两次未被识别的尝试。这是一项设计建议,而非引文研究确立的绝对阈值。其核心特性在于:该触发机制应当是可预测的、与当前任务紧密关联的,并且能够在游戏让玩家陷入漫长的死循环之前生效。如果某个游戏的输入方式噪点特别多,或者该场景本身就将尝试探索作为游戏玩法的一部分,游戏可能需要设定不同的阈值;这一阈值应当经过深思熟虑并在实际交互中进行测试。

第 2 节

保留玩家已经尝试过的内容

当后备方案出现时,应在输入框、日志或其他可见位置保留玩家最后尝试输入的文本。如果游戏将其清空,玩家可能不得不重新组织他们已经输入过的操作。展示这些语句也有助于说明:游戏确实收到了输入,只是未能将其映射到所支持的操作上。

后备方案可以确认玩家的尝试,而无需归咎于玩家:“我无法将‘用钩子撬开铁栅栏’与此处的任何操作对应起来。”如果游戏识别出了操作中合理的一部分,应当说明识别出了什么:“我找到了铁栅栏,但我不确定你想对它做什么。”不要假装系统理解了它实际上未能理解的内容。这种措辞清晰地区分了“未知命令”与“目标已知但操作未确定”。

W3C 对“错误建议”(Error Suggestion)的解释指出:当输入被拒绝且存在已知的有效修正时,系统应提供该修正。其示例包括展示可接受的值或可能的更正方案。该指南是针对网页内容编写的,而非游戏对话,因此将其应用于游戏是一种明智的设计借鉴。其相通的原则十分有用:在系统有能力提供具体下一步建议时,务必提供。参考 W3C《理解成功准则 3.3.3:错误建议》(Understanding Success Criterion 3.3.3: Error Suggestion)。

第 3 节

提供一个契合当下的精简操作菜单

后备菜单中应包含少数由当前场景支持的原生操作。例如,如果玩家正在与一扇锁着的门互动,选项可以是“检查门锁”、“尝试使用钥匙”和“走开”。这些只是示意性选项,并非针对具体某款游戏的结论。选项应描述明确的操作,使用清晰的动词,并避免引导玩家进入游戏当前无法处理的分支。

让选项紧密贴合场景与当前状态。如果眼前的障碍是一个具体的物体,像“探索”、“交谈”和“使用道具”这样宽泛的菜单可能帮助不大。反之,高度具体的选项只有在其前提条件满足时才应出现。如果玩家的背包里没有钥匙,就不要提供“尝试使用钥匙”。一个提供无法执行的操作的菜单,不过是用一种混乱取代了另一种混乱。

游戏对话研究还表明,菜单的样式会影响体验:完整的句子有助于表达角色将要说什么,而抽象的标签则会让交互更偏向策略控制。合适的详细程度取决于具体的操作及其后果。对于简单直接的操作,使用简短标签;当某个选择可能会改变场景或促使玩家做出重要回应时,应提供更多解释。参考《玩转文字:从直觉到游戏对话界面的评估》。

第 4 节

使菜单保持可选并明确指示如何退出

该菜单应该提供一条前进路径,而不是悄然关闭自由文本输入功能。提供一个醒目的选项,如“继续输入”或“返回自由文本”,并明确告知玩家可以使用它。如果游戏在显示选项的同时允许自由文本输入,请清晰传达这一机制;如果选择某个选项会关闭菜单,也请同样说明。

在按钮和选项上使用操作性标签。W3C 设计系统建议,按钮文字应指明用户的具体动作,而非使用“提交”等通用标签。在游戏中,“检查门锁”或“继续输入”比“继续”提供的信息要明确得多。尽管这一具体的界面指南源自网页表单,但明确指示动作所带来的清晰度完全适用于游戏控制。参考 W3C 设计系统《表单》(Forms)。

保持退出方式的一致性。如果某个恢复菜单中显示“继续输入”,而在另一个菜单中显示“取消”,玩家可能无法确定两者是否都能保留当前状态。如果离开菜单会丢弃已输入的文本,应在丢弃前发出警告。如果玩家可以通过键盘、手柄、触控或其他支持的交互方式选择选项,请确保这些恢复选项可以通过游戏的常规控制方案进行选择和激活。

第 5 节

避免陷入反复要求换一种说法的死循环

显示菜单后,当玩家再次输入不支持的内容时,切勿立即重新跳出相同的提示——“我无法理解,请再试一次”。这只会重新触发失败模式。相反,应该保留新的尝试并保持所提供的选项可用,或者在解析器掌握了足够信息时提供更有针对性的提示。允许玩家选择预设操作、修改文本,或者在场景允许的情况下退出当前交互。

微软关于对话式后备方案的指南建议:设计一系列循序渐进的后备响应,避免重复使用一模一样的致歉语,并在系统重定向时保留用户离开时的进度。该指南专为对话类产品编写,因此其具体的移交建议无需生搬硬套到游戏中。但其可借鉴之处在于:使每个恢复步骤都切实有用,避免让用户从头重新开始已做过的工作。参考 Microsoft Learn《设计优雅的后备方案与移交》(Design graceful fallbacks and handoffs)。

一个简单的恢复序列可以如下所示:

第一次不支持的输入:说明该操作未被识别;保留文本,并在已知的情况下提供简短且与场景相关的提示。

第二次不支持的输入:在保留文本的同时,展示一个包含有效预设操作的精简菜单。

在该菜单中:允许玩家选择操作、编辑并重新提交文本,或在游戏允许的情况下退出交互。

如果下一次输入仍然不支持:保持恢复选项可用,并阐明可执行的操作范围,而不是重新触发相同的换说法提示。

第 6 节

测试后备方案是否真正有效

使用与设计者预设措辞不同的合理输入来测试该序列:例如同义词、简短命令、物体名称和更长的描述。检查游戏是否在每次失败后都保留了输入,展示的选项是否对当前场景有效,并允许玩家在不丢失当前进度的前提下返回输入状态。还要测试当某个选项在被选中前因场景状态发生改变而失效时会发生什么。

针对每次测试提出具体问题:在一次未命中后,玩家能否清楚游戏没有理解什么?他们能否看到有用的下一步操作?他们能否在不被迫选择菜单选项的情况下继续尝试自己原本的想法?如果对其中任何一个问题的回答是否定的,请修改提示信息、选项集合或返回路径。这是一套基于上述交互原则拟定的评估检查清单,而非某项用户研究得出的报告结果。

设计的目标是实现有条理的恢复:确认不支持的输入,予以保留,在反复无法识别后提供相关选项,并将自由文本作为明确的前进方式。该菜单应该减少猜测,同时将使用该菜单的控制权完全交由玩家决定。

相关阅读

继续探索这个主题