核心架构
-
Overwatch 采用 ECS 架构 管理复杂度
- Entity：ID + 一组组件（Component，仅存储状态，无行为）
- System：执行行为，关注特定组件组合（tuple / component-slice），在这些组件上处理逻辑
-
优点：
- 状态与行为分离，System 更纯洁、可组合
- 组件只存储数据，行为集中在 System
- 大多数 System 纯函数式（只读组件），少数修改状态
-
单例组件（Singleton Component）
- 存储全局共享数据，例如输入状态（键盘、手柄等）
- 减少 System 间耦合
-
Utility 函数
- 封装共享行为（被多个 System 调用的小逻辑）
- 依赖少组件、低副作用，避免 System 之间互相调用
ECS 设计规范与权衡
-
组件无行为，System 尽量无状态
-
如果 System 需要状态 → 放在 Singleton Component
-
副作用控制：
- Deferred Execution（推迟执行）：将副作用（如创建实体、特效）暂存到帧尾统一处理
- 防止 System 在帧中间互相依赖造成脏状态或竞态问题
-
实体创建与销毁
- 销毁推迟到帧末端安全
- 创建推迟可能导致同帧 System 无法获取新实体 → 需谨慎
网络同步 / Netcode
1. 预测与回滚（Prediction & Reconciliation）
- 客户端响应用户输入立即做预测，不等服务器确认
- 使用固定帧率 / 命令帧（command frames）同步模拟
- 客户端保存输入历史和移动状态历史
- 收到服务器确认后回滚到最后确认帧，然后重放客户端输入
2. 输入滑动窗口 + 丢包补偿
- 每个发送包包含自上次确认以来的所有输入帧
- 服务器缓冲区接收输入并补偿丢失帧
3. 延迟 / 缓冲 / 时间膨胀（Buffering / Time Dilation）
- 网络不稳定时，客户端加速或扩大缓冲区，减少预测错误带来的卡顿
- 网络恢复稳定后，缩小缓冲区
4. 命中判定（Hit Registration）
- 客户端可能预测子弹命中，但服务器是最终权威
- 远端实体使用插值，服务端回滚远端实体状态判断命中
- 高延迟情况下可能放弃客户端预测，直接等待服务器确认
设计原则总结
-
架构为 可维护性与可扩展性服务
- ECS + 严格准则（组件无行为，System 少状态）
-
网络同步：预测 + 回滚 + 丢包/延迟/预测错误补偿
-
Utility、Singleton、Deferred 操作用于缓解 System 间耦合与副作用
参考资料：
《守望先锋》架构设计和网络同步