一、联机第一晚：两个英雄互相"瞬移"
"云间对决"第一次双机联机测试，小陈和老周各拿一台手机。结果——
小陈："我看到你的英雄在'瞬移'，一下出现在这里，一下出现在那里！"
老周："因为你手机 30 帧，我手机 60 帧，我们看到的'世界'根本不一样！"
"这就是网络同步（Network Synchronization）要解决的核心问题：让所有玩家看到的游戏世界是一致的。 MOBA 里 5v5 十个人，每个人手机上的英雄、小兵、野怪都必须'同步'——你在上海放了个技能，在成都的队友要'同时'看到。"
二、先搞懂问题：延迟与不一致
"为什么联机会不同步？根源是两个字：延迟（Latency）。"老周画：
网络延迟的现实：
你在上海，服务器在北京：
你的操作 → 网络传输（约 30ms）→ 服务器处理 → 传输（30ms）
→ 对方看到你的操作，最少 60ms 之后
普通网络延迟：20-100ms（毫秒）
高延迟（跨省/跨国/弱网）：200ms+
延迟带来的三个问题：
① 位置不同步：你看到的敌人位置，是 60ms 前的位置
② 事件不同步：你放的技能，对方"晚看到"
③ 结果不同步：如果两边各自算伤害，结果可能不一样！
（你这边敌人死了，他那边的敌人还活着——"我明明打死他了！"）
"MOBA 最不能忍的就是'两个客户端各自为政'——所以必须有统一的'权威'来决定'世界是什么样'。这就是同步方案的核心。"
三、两种同步方案：状态同步 vs 帧同步
"游戏联机有两大流派，MOBA 类用的是其中之一。"老周说：
① 状态同步（State Sync）—— 服务器权威，客户端"汇报"
服务器是"唯一真相"（权威服务器 Authoritative）
客户端：
操作 → 上报服务器
服务器：
计算所有逻辑（移动/伤害/血量）→ 把"最终状态"广播给所有客户端
客户端：
接收状态 → 渲染（插值让画面平滑）
优点：服务器权威，防作弊容易
缺点：每帧都要传大量状态（带宽大）
代表：MOBA 手游多数、吃鸡类
② 帧同步（Lockstep/Frame Sync）—— 只传"操作"
所有客户端本地跑同一套游戏逻辑
只互相广播"我按了什么键"
每个客户端按相同输入、相同逻辑 → 推出相同结果
优点：带宽极小（只传输入）
缺点：逻辑必须"确定性"（同样的输入必须同样的输出）
任何一个客户端逻辑不一致 → 世界分叉
代表：RTS（星际争霸）、格斗游戏、部分 MOBA
帧同步的"确定性"难题（MOBA 用帧同步的代表：早期王者荣耀）：
同样输入 → 必须同样输出，意味着：
- 不能用随机数（或随机种子要同步）
- 不能用浮点运算差异（不同手机精度可能不同）
- 所有逻辑必须在"固定帧率"下跑（第二章的 FixedUpdate！）
一旦有人逻辑分叉 → 整个世界崩坏
状态同步的代价：
服务器要算所有逻辑 → 服务器压力大
每帧传状态 → 带宽大（需要压缩/插值优化）
"一句话：状态同步 = 服务器说了算（重传状态，防作弊好）；帧同步 = 大家自己算（只传按键，省带宽但要求逻辑确定）。 王者荣耀早期用帧同步（省带宽），后来部分场景改状态同步（好维护）。咱们的简化版，用状态同步更现实。"
四、状态同步实战：英雄移动的"三步舞"
"选状态同步，那英雄移动怎么实现？"老周写：
状态同步下英雄移动流程：
客户端A（你） 服务器 客户端B（队友）
│ 按移动键 │ │
│ 本地先动（预测） │ │
│ ──移动指令──▶ │ │
│ │ 服务器算出新位置 │
│ │ ──位置状态广播──▶ │
│ │ │ 收到位置 → 渲染
│ ◀──服务器确认位置─────── │ │
│ 修正本地位置 │ │
三个关键优化：
① 客户端预测（Client Prediction）：
不等服务器，先本地移动（不卡顿）
服务器返回后，校正误差
② 插值（Interpolation）：
收到的位置是"过去"的，在两帧之间平滑过渡
→ 让画面不"跳变"
③ 延迟补偿（Lag Compensation）：
服务器判定"你打中了吗"时，回看"你看到敌人时的位置"
→ 避免"我以为打中了，服务器说没打中"
这是网络游戏的"老三样"：预测、插值、延迟补偿
"网络游戏的体验，全靠这三招——玩家感觉'流畅'，其实是客户端预测在骗过大脑；'公平'，是延迟补偿在兜底。MOBA 的'手感'，一半是网络层给的。"
五、同步什么：全量同步 vs 增量同步
"不是所有东西都要每帧同步——同步的内容要有取舍。"老周说：
同步内容分级：
每帧同步（高频）：位置、移动方向（角色、弹道）
事件同步（触发时）：技能释放、伤害、死亡、Buff
低频同步（隔几秒）：血量、蓝量、金币、等级
结算同步（对局结束）：胜负、数据统计
带宽优化：
位置同步：只传"增量"（位移向量，不传完整坐标）
或者：定时快照 + 差值
事件：用紧凑协议（二进制替代 JSON）
压缩：数值用短整型/位打包
示例（英雄位置增量）：
每帧：{id: 3, dx: 0.12, dy: -0.03}
（id + 位移量，比传完整坐标省很多）
服务器逻辑帧率：
30 tick/s（每秒同步 30 次）→ 网络包 33ms 一个
移动端常用 20-30 tick，兼顾带宽和手感
"同步策略的本质：'少传、勤算、巧渲染'——能本地算的本地算（预测），能少传的少传（增量），能缓存的缓存（插值）。带宽是稀缺资源，游戏优化一半在'省带宽'。"
六、断线重连与防作弊
"联机游戏还有两个绕不开的问题：断线和外挂。"老周说：
断线重连（Reconnect）：
玩家网络波动 → 掉线 → 不能直接判负！
方案：
服务器保留对局状态（快照）
玩家重连 → 下发完整状态 → 恢复画面
断线期间：英雄由 AI 托管（自动回城/跟随队友）
超时判定：多久不重连判挂机/判负
防作弊（Anti-cheat）：
状态同步的天然优势：服务器权威
客户端只能"上报操作"，不能"直接改血量"
→ 外挂很难"一刀 999"（服务器不认）
常见作弊与防御：
透视/全图 → 战争迷雾由服务器下发，客户端看不到就看不到
加速 → 服务器校验移动速度是否异常
自瞄 → 操作合法但精度超常，用行为分析检测
帧同步的劣势：客户端本地算逻辑 → 容易被改内存作弊
所以 MOBA 用状态同步的另一大理由是：防作弊
数据校验：
服务器验证每个操作的合法性（冷却好了吗？蓝够吗？）
客户端上报的数值不可信，服务器自己算
"记住：'服务器权威'是网络游戏安全的地基——客户端只是'提款机上的键盘'，钱在服务器手里。这也是为什么王者荣耀用服务器同步大部分逻辑（防外挂）。"
七、选型：云间对决用什么方案
云间对决的网络方案（简化版决策）：
✅ 状态同步（服务器权威）
- 10 人对局，带宽可接受（位置增量 + 事件同步）
- 防作弊简单（服务器算伤害）
- 逻辑好维护（客户端不用保证确定性）
技术栈：
- 传输：TCP（可靠）或 UDP+重传（快，游戏专用）
- 服务器：独立对战服务器（每局一台）
- 匹配：大厅服务器 + 对战服务器分离
- 框架：Nakama/Photon（第三方）或自研（高级）
简化版建议：
先用 Photon 等成熟框架（省时）
或本地联机（同一 WiFi 局域网测试）先跑通
理解原理后，再决定是否自研
"做联机游戏的现实建议：先用成熟方案（Photon/Nakama）把游戏做出来，再考虑自研。 网络同步的坑太深，团队前期别在网络上耗死——'能跑通'比'最优'重要。"
八、章末：老周的第七层总结
第七层：网络同步
├── 核心问题：延迟 → 世界不一致
├── 状态同步：服务器权威（传状态，防作弊好）
├── 帧同步：只传操作（省带宽，要求逻辑确定）
├── 老三样：预测 / 插值 / 延迟补偿（手感来源）
├── 同步分级：高频位置 / 事件 / 低频数值 / 结算
├── 带宽优化：增量同步、二进制协议、20-30 tick
├── 断线重连：状态快照 + AI 托管
├── 防作弊：服务器权威（客户端只是键盘）
└── 选型：状态同步 + 成熟框架起步
下一章预告：
联网能跑了！但游戏包越来越大（几百 MB 资源），
手机一进对战就卡（资源加载慢）……
—— 客户端架构与资源管理：场景管理、资源加载、热更新。
"小陈，两台手机终于'看到同一个世界'了——你放技能，老周那边同步掉血，不瞬移了！"老周看着测试结果，"但王姐又抱怨了：'你们这个游戏包怎么 800MB？手机下载要半天，进对局还要加载半天！'——这就是下一章：客户端架构与资源管理。让游戏'又小又快又能热更新'。"