文字游戏失败状态：如何区分剧情挫折、输入问题与传输问题
在对话式文字游戏中，一个不成功的回合并不总是意味着玩家做出了糟糕的选择。可能是场景中发生了一个合乎情理的剧情挫折，游戏可能不支持该措辞，角色可能缺乏行动所需的知识，或者消息可能根本未能送达。这些情况需要不同的反馈以及不同的重试效果。首先对原因进行分类，然后告知玩家发生了什么变化以及接下来可以做什么。
首先询问是什么失败了
一个实用的首要问题是：游戏是否理解了预期的行动并在虚构剧情中进行了解算？如果是，结果可能是一个挫折。如果不是，请确定问题是出在输入、角色的信息认知，还是系统的传输上。这种由四个部分构成的区分是一种设计辅助思路，借鉴自互动小说系统如何划分语法解析、世界规则、故事流程和撤销行为；它并非通用的技术标准。例如，Inform 的文档将解析器和模拟世界模型描述为游戏中独立的部分，其解析器可以报告命令未能匹配的几种不同原因。（Inform 6 设计师手册：引言，Inform 6 设计师手册 §33：帮助解析器摆脱困境）
将消息视为游戏响应契约的一部分。它应该回答三件事：发生了什么、虚构状态是否改变，以及玩家现在可以做什么。像“纸船在到达对岸之前翻了。折好的纸条还在你手中。你可以尝试较宽的水道或选择其他方式过河”这样简短的一句话，就能将挫折、保留的物品以及下一步操作表达得清清楚楚。
1. 合乎情理的剧情挫折
当游戏理解了该行动，对照当前场景进行了核对，并有意生成了游戏世界内的结果时，挫折是恰当的。也许是玩家试图一次搬运太多图书馆的书，导致其中一本滑落到附近的椅子上。也许是一只纸船在到达浅溪对岸之前进水了。结果可以带来不便或令人惊讶，但无需将这次交互变成对玩家本人的评判。
其决定性特征是状态改变。如果场景表明船沉了，这个结果在故事中就应当成真。如果玩家能够挽回它，请说明方法；如果船已经没了，不要暗示重试相同的文本就能撤销该事件。重试可能意味着制作另一艘船、选择另一条路线，或者在发生变化的场景中继续前行。确切的选项取决于游戏的规则。
一个有用的挫折提示会指出尝试的行动、造成的后果以及可用的后续操作。它不应该仅仅因为结果不理想，就将一个本受支持的行动掩饰为输入错误。反之，如果游戏实际上没有改变故事状态，也不要暗示发生了某种后果。这种区分可以让玩家明白他们是在新情况下继续推进，还是在纠正一个未被处理的命令。
2. 不支持的输入：游戏无法理解该措辞
不支持的输入意味着系统无法将玩家的消息映射到其支持的行动上。玩家可能会在游戏仅接受少数按钮选项的场景中输入“向面包师询问杏子的事”，或者使用了解析器无法识别的名称。这说明了界面的覆盖范围有限，并不代表玩家的想法质量不高。
互动小说的解析器说明了为什么有用的反馈应当具体：Inform 针对未识别的动词、不明确的指代、输入过少以及看不见的对象分别列出了不同的错误。其手册还展示了游戏如何用信息更丰富的消息替换通用的解析器错误。（Inform 7 §18.35：打印解析器错误）在对话游戏中，简明的回应可能是：“我在这里无法理解‘询问杏子的事’。你可以询问递送情况，或者从柜台上选择一个话题。”
提供一条补救途径。根据界面的不同，这可能意味着显示已识别的选项、提出一个具有针对性的澄清问题，或邀请玩家重新组织措辞。不要将不支持的命令描述为剧情上的失败：如果没有执行任何操作，请明确说明这一点。保持先前的场景完好无损，并说明发送更正后的输入将重试同一时刻，而不是倒退故事事件。
3. 角色知识不可用：一个有效的问题，但尚无答案
有时输入是可以理解的，但角色掌握的信息不足以采取行动。玩家可能会在店员助手看到收据之前，询问对方包裹送到了哪里。游戏可以识别该问题，同时合理地暂不提供明确的答案。
这与不支持的输入不同：话题或行动是有效的，而限制属于故事中角色的知识范畴。请清晰地划定这层界限。例如：“米娜还没看到送货单，所以她说不出街道名称。包裹标签还在柜台上。”如果玩家可以检查标签、询问他人或稍后再来，请指出这条途径。如果不行，请说明实际已知的内容，而不是生造提示或将该问题视为格式错误。
决定这种回应是否推进时间或改变状态。如果提问是游戏世界内的常规行动，游戏可能会记录该对话或改变角色随后的回应方式。如果游戏打算让询问知识不消耗行动机会，请保留当前场景，并允许提出下一个问题。玩家不应该去猜测一次获取信息的请求是否悄悄消耗了一次机会。
4. 技术传输失败：该行动可能从未抵达故事中
传输失败发生在剧情之外：响应超时、重复出现，或在句子中途中断。除非游戏知道行动已被处理，否则它无法稳妥地声称角色已采取行动或故事已推进。这与游戏世界内的消息（例如“信使找不到该地址”）不同，后者属于剧情结果。
使用平实的系统状态措辞并报告已知状态。如果游戏可以确认该回合未被处理，请直接说明并让玩家重新发送。如果无法确定该回合是否已被处理，请避免盲目引导重复发送，以免可能执行两次该操作。简要解释不确定性，并提供一种检查当前场景或从最后确认的点恢复的方式。这些设计建议是从区分输入匹配失败与故事结果的需求中推导出来的；所引用的虚构系统并未定义对话传输失败的通用协议。
当传输恢复时，恢复最后确认的消息，或者显示场景和已知已完成的最新行动的简要回顾。将回顾标记为回顾，而不是新的故事回合。如果玩家选择重新发送，请说明这是否会被视为一次新的尝试。这一点小小的透明度可以防止重复操作被误认为是故意重试。
让“重试”、“撤销”和“继续”代表不同的含义
这些词语描述了不同的状态效果，因此请避免混用它们。“重试”是在当前状态下再次提交行动；它不应该悄悄抹去已确立的后果。“撤销”恢复较早的状态。“继续”在中断后从最后确认的状态恢复。“重新开始”则是从头开始故事。
Twine 的 Harlowe 手册将撤销记录为返回上一个段落并遗忘在当前段落中进行的变量更改；它将重新开始描述为重新加载页面以重新开始故事。它还指出撤销历史记录可能会受到限制。这些机制说明了为什么控件应该明确传达其作用范围，而不是依赖于模糊的“再试一次”标签。（Harlowe 3.3.8 手册：undo and restart）
一个简洁的决策流程有助于保持界面的一致性：
游戏是否理解并解算了该行动？如果是，报告剧情结果和留存的状态。
系统是否未能将措辞映射到受支持的操作？解释无法解算的内容并给出补救途径；保留当前场景。
行动是否已被理解，但角色缺乏信息？解释知识边界以及任何在游戏世界中了解更多信息的方式。
处理或传输是否不确定？说明已确认的内容，然后提供安全的检查或继续方式。
如果玩家想要回退，将控件标记为“撤销”，并说明它恢复了哪一刻或哪些更改。将“重新开始”保留给从头再来。
针对每种失败消息的简短一致性检查
在发布响应之前，对照故事状态进行检查。如果它描述的是挫折，世界是否真的改变了？如果它描述的是不支持的输入，游戏是否避免了假装行动已发生？如果角色缺乏知识，回应是否将其与缺失命令区分开来？如果传输失败，玩家是否知道该回合是否已处理？最后，重试或继续控件是否履行了其标签所承诺的功能？
当文字游戏的反馈能帮助玩家区分角色所经历的内容与界面无法完成的操作时，游戏就会显得公正合理。清晰的后果保留了故事的连贯性；具体的输入指引使再次尝试成为可能；坦诚的知识限制维持了剧情的合逻辑性；而明确的恢复路径则为玩家提供了可靠的前进方向。