把实体桌游搬进浏览器：随机房间、联机快照与规则回归

把实体桌游搬到浏览器，首先遇到的问题是：桌边玩家可以协商理解的规则，程序必须给出确定的执行顺序。房间朝向、骰子消耗、死亡处理和回合交接，都需要在界面与状态中留下明确的位置。

escape-from-HDU 是这样一个电子桌游项目，页面标题为《极速逃脱1：亡命房间电子版》。它使用原生 HTML、CSS 与 JavaScript，提供本机同屏和最多六人的局域网房间，联机服务使用 Node.js 内建模块。

这篇记录整理于 2026 年 10 月 25 日，依据的是仓库在 8 月 30 日的公开提交 68ecc114。以下讨论对应这份实现；源码里的后续改造建议会单独说明。

先把一桌规则拆成数据

棋盘是 5×5 的随机房间。正厅固定在中心，内圈放置八个随机房间，外圈则把十五个房间和一个出口一起洗混。房间还有各自的门型、朝向、搜查标记与效果，因此“向相邻格移动”需要同时考虑位置和房门关系。

回合围绕三颗行动骰展开，可能出现移动、窥视、搜查、转向、推人、交换和空白。三颗骰子的六面配置各不相同，重投和行动限制又会受到房间、模式影响。把骰面、房间和模式定义集中在 game-data.js，可以让规则数据与执行过程保持清楚的边界。

项目提供竞速、经典、团队和内鬼四种模式，人数限制也随模式变化：竞速和经典为 2–6 人，团队为 4 或 6 人，内鬼为 3–6 人。经典模式还会合并两组道具形成十四张牌，并加入死亡后在正厅重生的处理。共享棋盘并不意味着共享全部胜负与道具规则。规则数据

界面需要解释一次行动为什么成立

对这种游戏，房间牌面既是视觉元素，也是规则入口。界面提供房间效果详情、实际朝向与房门预览、规则书、道具区和事件日志，让玩家能够从当前画面追溯行动依据。

这里尤其需要区分“看得见什么”和“现在允许做什么”。即使一个按钮可以显示，强制房间效果尚未结束时也不能任意插入下一步；选择了用于某个效果的骰子，就应该精确消耗那颗骰子。否则界面看起来完成了一次操作，规则状态却可能已经偏离。

样式中也为桌面和窄屏设置了不同布局，并提供减少动画的样式。代码具备这些适配，只能说明布局有对应分支，实际设备上的可读性与操作体验仍需单独检查。

从本机同屏到局域网：同步整份状态

本机同屏可以直接打开 index.html。局域网模式由房主启动 Node.js 服务，其他设备通过同一网络访问，再用五位房间码加入。房间保存在服务进程内存中，服务关闭后房间也会结束。

当前联机实现采用客户端执行规则、上传状态的方式。客户端提交整份游戏状态和 baseRevision，服务端检查当前操作者、版本号、状态结构、牌组以及部分状态转移，再返回确认后的快照。

客户端执行操作
  -> 提交 state + baseRevision
  -> 服务端校验并更新版本
  -> 客户端取得房间快照

普通轮询间隔是 850 毫秒，页面隐藏后调整为 2200 毫秒。对于少量玩家的局域网原型，整份快照让同步路径比较直观，也方便发生分歧时恢复到同一份状态。代价是每轮都会传输完整状态，规则执行仍有相当一部分留在客户端。联机实现

版本号在这里承担的是冲突检测。如果两次操作都基于旧版本，后到的写入会收到冲突响应；客户端随后丢弃待上传状态，采用服务端快照。网络错误时也优先恢复到已确认状态。把“本地刚算出的结果”与“服务器已经接受的结果”分开，能避免失败操作一直留在玩家眼前。

内鬼模式还提出了信息边界问题

内鬼身份与手中道具涉及私密信息。当前界面会限制其他玩家看到的内容，但服务端快照仍包含完整的游戏状态。因此，界面隐藏还不能提供网络层面的保密。快照代码

这也给后续改造划出了清楚的方向：由服务端执行完整规则，为每个玩家生成各自可见的状态，再选择适合的推送或轮询机制。仓库的技术评审讨论过服务端权威规则、私密视图和 SSE；这些属于后续设计，不能直接作为当前已实现的能力。

让容易反复出错的规则留下回归用例

8 月 30 日的提交进一步补充了玩法与联机边界的处理。仓库使用 Node.js 内建的 node:test，分别保存数据定义、经典模式、服务端和玩法回归测试。

其中值得持续保留的场景包括：

• 旧存档中的走廊迁移后，仍然遵守禁止搜查的规则；
• 书房效果精确消耗选定骰子，酒窖效果按队列处理并清理失效项；
• 强制效果期间阻止其他操作，回合结束只推进一次；
• 开局与加入同时发生、当前玩家离房时，房间仍维持合法状态。

这些用例把“某次点击似乎正常”变成了可以重复检查的状态约束。尤其是回合类游戏，错误经常发生在两个阶段交接的位置，单看某个动作的结果还不够。玩法回归测试、服务端测试

接下来怎样判断它更可靠了

这个项目已经把随机地图、行动骰、四种模式与局域网大厅串在一起。后续可靠性可以围绕三个问题衡量：断线和重进能否恢复每一个阶段，私密信息是否只发送给对应玩家，以及完整规则能否由服务端统一判定。

电子化让规则变得可执行，也让规则之间的空隙更容易被看见。把这些空隙写成状态约束、测试用例和明确的后续任务，是这份桌游原型值得继续记录的部分。