在线联机原型全集：第 14 章　房间逃脱（Room Escape — Synchronous Puzzle）

房间逃脱（Room Escape — Synchronous Puzzle）

• 类别：同步合作解谜 + 状态机驱动 + 事务一致性
• 目标：验证Puzzle FSM 的可组合性、跨客户端同步一致性、多操作并发冲突的仲裁与回滚机制；同时验证房间生命周期与重进/旁观、现场日志（Event Log）与复盘（Replay）的最小实现。
• 原型代号：proto-014-room-escape-sync
• 依赖模块：proto-002-rps（回合/提交时序基元）、proto-007-snake-battle（房间/网关骨架）、proto-009-coop-minesweeper（协作与同步基线）、proto-010-city-slg-mini（一致性结算思路参考）
• 推荐语言栈：Go / Java / Rust / TypeScript（服务端以 Go/Java 为主，客户端以 TS/Unity 任一）
• 协议栈：HTTP（配对/开房/复盘拉取） + WebSocket（帧内事件与状态推送） + Cron/DelayQueue（超时与回退）

1. 核心玩法概述

• 目标：2–5 名玩家被困在同一“房间/场景”，需要并行协作在有限时间内解开若干互相制约的谜题链（开关、密码轮盘、线路接通、权重秤、激光反射镜阵、音阶/节拍器、线索拼图等），最终开启出口。

• 关键设计：

  1. Puzzle FSM（谜题有限状态机）：每个谜题是一个独立 FSM，多个 FSM 通过事件/条件互相约束，组成场景级超图。
  2. 同步解谜：动作常常需要多人同步（如双开关 2/3 人同时按下、节拍器多声部齐奏）。
  3. 并发冲突：玩家操作存在竞争与顺序依赖（重复按、抢占旋钮、互斥操作），需有仲裁、锁、乐观校验、回滚与可重放事件流。
  4. 时序与延迟补偿：动作窗口（例如 500ms 同步判定窗）、软同步（客户端预测 + 伪装延迟）与硬落点（服务端权威判定）。

2. 场景/房间生命周期

• 状态机：Idle → Matching → Preparing → Active(Playing) → Success/Fail → Review/Replay → Closed

• 关键事件：

  • E_CREATE_ROOM：创建房间，载入场景配置与 Puzzle FSM 图。
  • E_JOIN / E_LEAVE：玩家加入/离开；支持断线重连（持有 seat）。
  • E_START：人数与准备条件满足，生成初始世界快照（Snapshot_0）。
  • E_TICK：固定帧（如 20/30fps 逻辑帧），驱动计时器与 FSM 事件轮询。
  • E_PUZZLE_EVENT：来自玩家操作的输入事件（含客户端时间戳与序号）。
  • E_TIMEOUT：关卡/子谜题超时，触发恢复或失败分支。
  • E_CLOSE：回收资源，持久化日志与成绩。

3. Puzzle FSM 设计

3.1 基本概念

• Node：状态（如 LOCKED, PARTIAL, READY, SOLVED）。

• Edge/Transition：触发条件（按钮被按下、旋钮落位、多个传感器满足 AND/OR、时间窗、外部 FSM 事件）。

• Guard：保护条件（玩家数、持有工具、多谜题前置完成度）。

• Effect：执行副作用（播放动画、打开门、修改另一个 FSM 的 Guard、生成线索）。

• Scopes：

  • Local FSM（单谜题内闭环）
  • Cross-FSM（跨谜题联动，如“电源接通”解锁“密码终端”）
  • Scene FSM（关卡级控制：计时、胜负判定、全局重置）

3.2 典型状态机（示例：双开关同步门）

stateDiagram-v2
    [*] --> LOCKED
    LOCKED --> ARMED: SwitchA=ON && SwitchB=ON within 500ms
    ARMED --> OPEN: ConfirmByServer
    ARMED --> LOCKED: Timeout(>500ms) or AnySwitchOff
    OPEN --> SOLVED: DoorFullyOpened
    SOLVED --> [*]

3.3 场景级依赖图（示例）

graph TD
  Power[电源总闸 FSM] --> Panel[配电面板 FSM]
  Panel --> Laser[激光镜阵 FSM]
  Laser --> DoorA[门A-双开关 FSM]
  Panel --> Scale[砝码平衡 FSM]
  Scale --> DoorB[门B-密码盘 FSM]
  DoorA --> Exit[出口门 FSM]
  DoorB --> Exit

3.4 配置格式（YAML 片段）

puzzles:
  - id: "doorA"
    type: "dual_switch"
    params:
      sync_window_ms: 500
    states: [LOCKED, ARMED, OPEN, SOLVED]
    transitions:
      - from: LOCKED
        to: ARMED
        guard: "switchA.on && switchB.on && within(sync_window_ms)"
      - from: ARMED
        to: OPEN
        guard: "server.confirm"
        effect: "doorA.open()"
      - from: ARMED
        to: LOCKED
        guard: "!within(sync_window_ms) || anySwitch.off"
  - id: "panel"
    type: "wiring"
    deps: ["power"]
    effect_on_solved:
      - "laser.enable()"

4. 并发冲突模型与仲裁

4.1 冲突来源

• 同一资源的互斥操作（同一旋钮的转动、同一键盘的输入焦点占用）。
• 顺序依赖的乱序到达（网络延迟导致 A 后到 B 先达）。
• 同步窗口判断（多玩家需 500ms 内共同完成动作）。
• 跨 FSM 副作用时序（A 解锁导致 B 的 Guard 改变，期间 B 已提交的操作需如何处理）。

4.2 一致性策略（组合拳）

1. 服务端权威（Authoritative Server）：所有状态转移以服务端时间与顺序为准。

2. 乐观并发 + 版本校验（CAS）：客户端提交包含 puzzle_version，服务端校验；不匹配则拒绝并下发最新快照。

3. 细粒度锁：

   • 资源锁（Resource Lock）：如旋钮/键盘为 mutex，占用窗口（如 2s）或直到提交/取消。
   • 同步锁（Sync Barrier）：服务端为某一组动作设 Barrier（时间窗 + 成员列表），在窗内收集齐才转移，否则自动回退。

4. 判定窗口与延迟折中：

   • 服务器使用接收时间戳 + 客户端发送时刻（经 NTP/同步偏差校正）进行“窗口合并判定”。

5. 补偿与回滚：

   • 失败转移触发逆操作（如旋钮回弹、键盘取消输入、砝码复位）。
   • 通过事件溯源（Event Sourcing）重放获得一致快照。

6. 抢占策略：

   • **先到先服务（FIFO）**对互斥资源生效；
   • 队列可见（客户端可见“我排第2位”）降低体感冲突；
   • 支持队长/主持强制解除占用（带冷却与告警事件）。

4.3 仲裁流程（伪代码）

OnClientAction(puzzle_id, actor_id, action, client_ts, puzzle_ver):
  if puzzle_ver != P[puzzle_id].version:
      reject(ERR_VERSION_CONFLICT, snapshot=P[puzzle_id].snapshot)
      return

  if action.targetsMutexResource() and ResourceBusy(action.target):
      enqueue(queue[action.target], actor_id, action)
      notify(actor_id, QUEUED, pos)
      return

  lockIfNeeded(action.target)
  appendEventLog(...)
  ok = tryTransitionFSM(puzzle_id, action, server_now)
  if !ok:
      rollbackSideEffects(...)
      releaseLock(action.target)
      notifyFailure(...)
  else:
      P[puzzle_id].version++
      broadcastStateDelta(...)
      releaseLock(action.target)
      drainQueueIfApplicable(...)

5. 网络与时序

• 逻辑帧：推荐 20Hz（50ms）或 30Hz（33.3ms）作为状态广播频率上限；事件即时流式分发。

• 同步窗口：500–800ms 作为合奏/双开关的默认窗口（可按难度曲线调整）。

• 延迟补偿：

  • 客户端对本地输入即时回显（预测），若被服务端否决，进行平滑回退（动画过渡 150–250ms）。
  • 对“多人同步”场景，客户端可显示同步计数器/脉冲指引，帮助在窗口内完成动作。

6. 数据模型（简化）

6.1 表/集合

• rooms：room_id, scene_id, state, created_at, seed, snapshot_ver
• room_members：room_id, user_id, seat, join_ts, leave_ts, role
• puzzles：room_id, puzzle_id, fsm_state, version, last_update
• event_log：room_id, seq, actor_id, puzzle_id, action, client_ts, server_ts, applied(bool)
• replays：room_id, blob_uri|segments（用于复盘/分享）

6.2 事件（WS）

// 客户端 → 服务器
{ "t":"act", "rid":"r1", "pid":"doorA", "a":"switchOn", "ts":1731055200123, "ver":7 }

// 服务器 → 客户端（状态差量）
{ "t":"delta", "rid":"r1", "pid":"doorA", "from":"LOCKED", "to":"ARMED", "ver":8 }

// 服务器 → 客户端（拒绝+快照）
{ "t":"reject", "rid":"r1", "pid":"doorA", "err":"VERSION_CONFLICT", "snapshot":{...}, "ver":8 }

7. 关卡与谜题类型库（可复用）

1. 双/三开关同步门：同步窗口 + Barrier。
2. 密码盘/拨码盘：焦点互斥 + 版本校验。
3. 激光镜阵：连续旋钮互斥、解的唯一性校验。
4. 配电/线路接通：图连通性检查 + 随机种子生成变体。
5. 砝码平衡：重量约束 + 临界值抖动容差。
6. 音阶/节拍合奏：节拍器同步 + 容差窗判定（±60–120ms）。
7. 线索拼图：拖拽互斥 + 磁吸吸附（容差像素）。

8. 难度与流程控制

• 渐进教学（Onboarding）：先单人可解，再引入必须协作的门槛（同时按、多点连线）。
• 失败与宽恕：失败不立即 Game Over，可回退一层、给出有限提示、延长时间。
• 观测与旁观：允许断线者旁观模式回到房间，减少队友等待。

9. 作弊与容错

• 防脚本/宏：随机化交互节奏（小幅抖动窗口）、对超人类反应打分并触发二次确认。
• 时间戳作恶：以服务端时间为准，客户端时间仅作参考；强制时间偏差上限（如 >±1.5s 触发校正）。
• 重放对账：关键谜题的状态转移必须能事件重放得到同一结果（确定性）。

10. 运维与指标

• 核心指标：

  • 关卡通关率 / 平均耗时 / 放弃率
  • 每类 Puzzle 的冲突拒绝率 / 回滚率 / 队列平均等待时长
  • 同步窗口命中率（多人动作在窗口内达成的比例）

• 日志采集：事件流水、判定路径、Guard 评估耗时、锁等待。

• A/B：窗口大小、容差、队列提示 UI 样式对成功率与爽感的影响。

11. 测试计划（要点）

• 单元测试：

  • FSM 转移闭包性（无悬空状态/死路）、副作用幂等性。
  • 版本冲突用例（ver+1/过期提交/乱序提交）。

• 仿真对抗：

  • 注入随机延迟 & 抖动（0–300ms），验证同步窗口判定稳定性。
  • 资源锁竞争 10–100 并发虚拟客户端，观测队列与吞吐。

• 回放一致性：

  • 随机种子 + 事件流重放必须得到相同 SOLVED 轨迹。

12. 客户端交互与 UX 准则

• 显式占用提示：控件被占用时显示队列位置与预计等待；允许请求协助（Ping 队友）。
• 同步引导：节拍光环、同步倒计时条、脉冲振动/音效。
• 冲突反馈：被拒绝时柔性回退，给出为什么（版本过期/占用/时窗 miss）。
• 旁观视角：摄像机锁定队友关键操作点，降低掉线/新手的迷茫。

13. 性能与扩展

• 房间粒度：单房间 2–5 人，状态极小；房间为天然分片，可在网关层按 room_id 一致性哈希。
• 快照策略：关键转移时刻生成微快照（Diff），支持断线重连秒回。
• 可插拔 Puzzle：FSM 以配置驱动（YAML/JSON），服务端加载注册表 + 工厂模式生成。

14. 示例时序（多开关同步）

sequenceDiagram
  participant C1 as Client A
  participant C2 as Client B
  participant S as Server
  C1->>S: act(switchA.on, ts=1001, ver=7)
  C2->>S: act(switchB.on, ts=1020, ver=7)
  S->>S: create SyncBarrier(window=500ms, actors={A,B})
  S->>S: both within window? yes -> FSM LOCKED→ARMED→OPEN
  S-->>C1: delta(p=doorA, to=OPEN, ver=8)
  S-->>C2: delta(p=doorA, to=OPEN, ver=8)

15. 最小可用清单（MVP）

• 房间创建/加入/准备/开始/结束的基本流
• 事件总线 + Event Log（可重放）
• Puzzle FSM 引擎（状态/转移/Guard/Effect）
• 资源锁（互斥占用） + 同步 Barrier（时间窗）
• 乐观版本（ver）+ 冲突拒绝 + 快照下发
• 至少 4 种 Puzzle 模块化接入（双开关、密码盘、配电板、激光阵）
• 复盘/回看（按事件流播放 UI）

16. 迭代路线（建议）

• v0.1：单房间、双开关 + 密码盘，完成 FSM/锁/Barrier/回放骨架。
• v0.2：接入配电板/激光阵，完善跨 FSM 依赖；加“同步节拍”。
• v0.3：旁观/掉线重连、A/B 同步窗口、性能压测与指标仪表盘。
• v1.0：创作管线（Puzzle 编辑器 → YAML 导出 → 服务端加载），社区关卡。