我在一个基于帖子的RPG中创作，一个LLM作为游戏主管运行。设计中最难的问题不是叙述——而是信任：同一个模型既写故事又报告骰子，所以“巨魔击中你”是不可证实的。玩家感觉到这个快， “相信我”什么也没用。

我们的解决方案是故意让人觉得无聊——commit-reveal（Blum, 1981），应用到生成叙述的模型：

- 服务器在读取玩家动作之前，预先滚动本轮可能需要的所有骰子，并将SHA-256的清单打上戳。玩家d20作为盐值的个人承诺，甚至当一轮的滚动被隐藏以制造戏剧效果时，也会发布清单。

- 模型从不滚动任何东西。它被递交了骰子，并围绕它们写了场景。一个确定性的规则引擎重新计算了密封的骰子的所有结果——模型的叙述不能夸大伤害、翻转失误或发明命中，因为任何与重新计算不一致的内容都将被锁定或拒绝。

- 每个滚动的种子也混入了一个drand beacon round（我们控制不了的公共随机数），记录在清单中——所以我们也不能购买一个幸运的预滚动。

- 当轮次解决时，密封的清单打开，并在客户端进行验证：玩家的手机重新计算了暴露的清单与预轮戳的匹配。

这个解决方案修复了：后向滚动、幽灵命中、夸大伤害——所有“叙述家调整现实后看到发生了什么”的类别。

这个解决方案修复不了，无法修复的：叙述家仍然选择目标、赌注和哪些战斗发生。故事偏见是真实的，并且不可证明。我们发布了执行日志和检查边距直方图（装载骰子将统计上暴露），但我并不认为这是一样的。

有一个工作例子，使用shasum的单行命令可以在终端中运行：tabled.gg/fair — 完整的参考设计位于[https://tabled.gg/fair/spec](https://tabled.gg/fair/spec）。

很高兴在约束机器上深入到任何人的要求——有趣的Bug都在“模型叙述自由”和“服务器严格执行”的 seam之间。