同步、战斗与实时交互

Category

server / sync 子树总览。覆盖：时间模型（01）、同步模型（02）、帧同步（03）、暂停追帧重连（04）、预测补偿（05）、确定性（06）、回放观战裁决（07）、技能系统（08）。

Definition

这一章讨论的是游戏里最容易把玩法问题逼成架构问题的那条主线：多端怎样共享同一局战斗，局内时间怎样推进，输入和状态怎样收敛，客户端何时可以先播，服务端何时必须裁决，断线、追帧、回放和技能系统又怎样建立在同一套时序规则上。

实时交互真正困难的地方，从来不是“服务器能不能算”，而是下面这些目标不可能同时最优：

• 手感要快。
• 公平性要站得住。
• 结果要可追责。
• 弱网要能容忍。
• 回放和观战要能重建。
• 工程复杂度又不能失控。

同步体系真正做的，不是选择一个时髦方案，而是在这些目标之间分配复杂度，并把代价变成可控的工程事实。

这一章的阅读顺序也有明确逻辑：

• 先把时间推进讲清楚，因为同步问题往往先是时间模型问题。
• 再讲同步模型，因为裁决权和一致性时机决定后续所有系统。
• 然后展开帧同步、暂停恢复、预测补偿和确定性这些最容易互相牵连的部分。
• 最后把回放、观战、技能系统放回同一条链路，说明它们为什么不是后补功能。

Related

关系链：时间（01）→ 模型（02）→ 帧同步（03）→ 暂停与重连（04）→ 预测补偿（05）→ 确定性（06）→ 回放裁决（07）→ 技能（08）。上游：runtime 子树（Tick 与执行模型）；下游：networking 树、system 树结算（对局结果的生效点）、树根 server 总览。

Reference

节点清单见下节。

本章文章

• Tick 与时间推进：先把逻辑时间、渲染时间和网络时间拆开，建立战斗时钟这层底座。
• 同步模型：把服务端权威、帧同步、锁步和混合方案放在同一组取舍里看。
• 帧同步详解：展开输入窗口、延迟帧、默认输入、哈希校验和快照恢复这些落地细节。
• 暂停、继续、追帧与断线重连：说明真正的房间级暂停、重连恢复和追帧分档该怎样组织。
• 预测、补偿与纠正：讨论客户端怎样抢时间，以及服务端怎样把预测重新收敛成权威结果。
• 确定性与数值一致性：讨论为什么很多“同步问题”其实死在浮点、随机和更新顺序上。
• 回放、观战与裁决：把输入日志、状态快照、仲裁证据和观战隔离统一进同步体系。
• 技能系统设计：从运行时骨架、效果管线、Buff 和同步边界出发讨论战斗内容如何长期扩展。