我制作了《采访》这个小型Unity调查游戏，玩家可以自己编写问题。 语言模型提供了角色的话语；C#负责案件文件、姿态、问题预算和最终审批。 有一个值得单独设计的决策问题：当回复永远不会到达时会发生什么。 免费游戏使用了我的付费Unity工具，离线AINPC。 这里要强调的是恢复行为，它也适用于自定义实现。 三种不同的结果： 一致的答案、矛盾的答案和后端失败不应该被视为同一事件。 矛盾的答案仍然是生成的行。 在当前游戏中，没有自动捕获语义事实检查器。 保持案件和裁决机制在代码中不证明每个句子都同意档案。 描述的恢复路径更窄：对话轮次失败，产生了没有发言答案的结果。 这与决定模型是否理解了问题或其答案是否真实无关。 玩家得到的结果： 游戏允许玩家提问十八次。 当选择了失败路径时，提交的问题从重复问题历史中被移除，使用问题计数器减少一。 如果问题耗尽了预算，那么结束条件会被清除，玩家可以尝试再次提问。 然而，已经应用的压力仍然存在。 这是一个部分恢复，而不是完全回滚。 按压或指控角色已经改变了场景的姿态状态。 恢复问题并不能恢复提问的每个后果。 这个区别很重要，以便展示给玩家的解释。 将问题称为“退款”而不明确资源的名称会使其听起来像是姿态、推理令牌或整个轮次状态被重置。 实际承诺要小得多：缺失的答案也不会使用有限问题中的一个。 仍然有意义的词语 在失败路径中，有一个作者的行关于连接暂时断开并再次询问。 这给了界面一个可见的反应，而不是留下一个空白答案。 它仍然会打断虚构，特别是如果玩家将沉默视为关于角色的证据。 在角色内要求重复问题可能会更不打扰，但也会冒着将技术故障隐藏在对话中。 重复的 canned 答案会变得显眼。 这些是设计权衡；我没有运行一个比较研究来证明哪一个更好。 恢复和真实性是独立的检查 A 对缺失回复的fallback 不会保护谜团免于可信的发明细节。 需要自己的规则来检查矛盾、可接受的不确定性和替换对话。 这是一个值得评估的想法，而不是我声称的当前演示的能力。 同样，问题限制改变了每个轮次的成本，但我没有测量它是否使模型错误更为明显。 它是一个约束游戏，而不是关于每个玩家的经验的证据。 上述行为通过阅读会话和场景恢复代码进行检查；它不是一个新的运行时基准。 我的下一个设计问题是关于代码创造的体验：在后端失败之后，是否应该保留玩家的压力选择、恢复整个轮次，还是让玩家重试成为一个明确的单独动作？ 上下文：免费的Windows游戏可以在https://merrymaker14.itch.io/the-interview找到。 附图是一个真实的游戏截图，用于上下文，而不是捕获此失败路径。 写作和翻译使用了AI辅助；描述的行为与游戏代码进行了检查。