联网战斗同步实现

联网战斗同步实现的心得

前言

最近在做联网战斗同步这块的东西，读了不少文章、书籍，于是整理了一下。

之前也有在 团队内部技术分享 中分享过这块内容，但是有些东西受限于时间，只是大概的略过，重点放在了实现与遇到的难题解决上。

后来，在做优化调整的时候，又有不少新的收获，改进了之前的分享稿。

欢迎各位小伙伴来一起讨论，通过分享讨论来不断进步。

---

简介

现状

网络游戏的同步方案，大概由以下三部分搭配组成

• 网络传输协议
• 网络同步模型
• 网络拓扑结构

网络传输协议（Network Transport Protocol）

• 分类

  • UDP协议
  • TCP协议

• 共同点

  • 在 TCP/IP 协议族中[物理层，数据链路层，网络层，传输层，应用层]，位于 传输层的协议，均依赖底层 网络层中的 IP协议。

• 区别

属性	UDP	TCP
传输可靠性	不可靠	可靠
传输速度	快	慢
带宽	包头小，省	包头大，费
连接速度	快	慢

• 此外，TCP还提供了 流量控制、拥塞控制等

• 其他

  • 关于 KCP协议
    • KCP协议是一个快速可靠协议，它以浪费10%-20%带宽的代价（相较于TCP协议），换取平均延迟降低 30%-40%，且最大延迟降低三倍的传输效果。纯算法实现，并不负责底层协议的收发。
    • 更详细信息可跳转最下方 参考资料2

网络同步模型（Network Model）

• 分类

  • 状态同步（State Synchronization ）
    • 本质：上传包含 游戏外部变化原因集合（玩家操作等）及 中间状态的子集（客户端计算的部分）；下发包含 游戏状态的集合。
  • 帧同步（Lockstep）
    • 本质：上传下发只包含游戏外部变化原因集合（玩家操作等）。
      • 对于A客户端： [输入A] -> [过程A + 运算A] -> 输出A
      • 对于B客户端： [输入B] -> [过程B + 运算B] -> 输出B
      • 确保 [输入] 相同，再保证 [过程] 与 [运算] 一致，那么 [输出] 一定是一致的
    • 逻辑帧，游戏在逻辑层面是离散的过程，即可认为是一个逻辑帧一个逻辑帧进行逻辑运算。
    • 渲染帧，游戏在渲染层面是离散的过程，即可认为是一个渲染帧一个渲染帧进行画面呈现。
    • 游戏逻辑帧 与 渲染帧 需要互相独立。

• 共同

  • 两种同步方案都分为 上传 和 下发 过程。
    • 上传 指客户端将信息传输给 服务器/客户端
    • 下发 指客户端从 服务器/客户端 中获取信息

• 对比

属性	帧同步	状态同步
流量	通常较低，取决于玩家数量	通常较高，取决于该客户端可观察到的网络实体数量
预表现	难，客户端本地计算，进行回滚等	较易，客户端进行预表现，服务器进行权威演算，客户端最终和服务器下发的状态进行调节或回滚
确定性	严格确定性	不严格确定性
弱网影响	大，较难做到预表现	小，较易做到预表现
断线重连	难，需要获取所有相关帧且快播追上进度	易，根据快照迅速恢复
实时回放	难，客户端需要消耗非常大性能去从头播放到对应序列，回放完后需要快播追赶	易，根据快照进行回放，回放完再根据快照恢复
逻辑性能优化	难，客户端需要运算所有逻辑，跟客户端性能强相关	易，大部分逻辑可在服务器进行，分担客户端运算压力
外挂影响	大，客户端拥有所有信息，透视类外挂影响严重	小，服务器可做视野剔除等处理
开发特征	平时开发高效，不需要前后端联调；但是开发时要保证各模块确定性，不同步BUG出现，难以排查	平时开发效率一般，需要前后端联调，无不同步BUG
第三方库影响	大，第三方库需要确保确定性	小，第三方库不需要确保确定性

网络拓扑结构（Network Topology）

• 分类

  • 对等结构
    • P2P结构（Peer to Peer）
  • 主从结构
    • CS结构（Client-Server）

• 共同

  • 网络时延的评估标准
    • Ping
      • 概念：网络连接的两个端之间的信号在网络传输所花费的时间。
      • 例：从A端发出信号开始计时，到B端响应并立刻返回响应信号，A端收到响应后停止计时，该时长为Ping。
    • RTT（Round Trip Time）
      • 概念：一般可认为等于Ping，但此处 RTT = Ping + 两个端的处理信号前等待时间 + 两个端处理信号的时间，即 实际体验到的游戏时延。
      • 例：A端逻辑发出信号开始计时，在A端等待一段时间、处理一段时间；发出到B端，在B端等待一段时间、处理一段时间；处理发出响应信号；再次在B端等待一段时间、处理一段时间；发出到A端，再次等待一段时间、处理一段时间；A端逻辑收到响应信号，停止计时；该时长为RTT。
    • 标准（单位 ms）
      • 极好：<= 20
      • 优秀：21 ~ 50
      • 正常：51 ~ 100
      • 差：101 ~ 200
      • 极差：>= 201
  • 丢包率
    • 原因： 直接原因是由于 无线网络 和 拥塞控制，根本原因比较复杂。
    • 标准：
      • 优秀：<= 2%
      • 一般：2% ~ 10%
      • 差：>= 10%

• 对比

属性	P2P结构	CS结构
样式	全连接的网状结构	星状结构
连接数	O(n^2)	O(n)
流量	各客户端相等，均为 O(n^2)	服务器为 O(n)，客户端为 O(1)
客户端间的时延	较小，为RTT/2	较大，为RTT

实现

广义

广义上来说，游戏采用的技术是：

• 网络传输协议： KCP & TCP
• 网络同步模型： 帧同步
• 网络拓扑结构： CS结构

图例

狭义

关联类

• 同步管理类
• 联网战斗数据缓存类
• 联网战斗场景类

同步管理类

功能

• 同步帧的操作的处理
  • 添加
  • 处理
  • 执行
  • 修正
• 对玩家操作的处理
  • 收集
  • 上传
  • 吞噬

联网战斗数据缓存类

功能

• 提供联网战斗通用数据模型
  • 解析玩家数据
• 客户端与战斗服交互的中枢
  • 发往战斗服消息，均由此统一发送
  • 收到战斗服的消息，处理后转发给其他业务类
• 断线重连相关处理
  • 追帧相关

联网战斗场景类

功能

• 处理联网战斗基础场景流程、方法
  • 房间状态切换流程
  • 创建角色数据及实体
  • 传送逻辑
• 实现本地战斗与联网战斗切换

为什么采用帧同步

1. 游戏的核心逻辑在客户端实现，服务器只负责转发验证等
2. 游戏类型及形式，动作类、房间为单位；更适合用帧同步
3. 开发速度快，周期短

重点处理

如同帧同步的简介中介绍，要保证 输出的一致性，先要确保输入、过程、运算的一致性。

浮点数与定点数 [运算一致性]

浮点数的运算在不同的操作系统，甚至不同的机器上算出来的结果都是有精度差异的。

一般解决该类问题方法：

• 使用定点数
• 使用分数

这里主要麻烦点在于lua支持定点数，lua中的小数是double，需要把lua源码中的基础小数全部替换为定点数。

然后，物理引擎的计算，第三方库的引用（比如随机数），都需要使用定点数。

确定的 随机数机制 [运算一致性]

确定的随机数机制就是保证各个客户端一旦用到随机数，随机出来的值必须是一样的。

得益于计算机的伪随机，通过设定同样的随机种子即可实现。

但是，在客户端内，需要明确区分随机数的类型

• 战斗类
  • 设计战斗的实体、BUFF、技能 等等
• 非战斗类
  • 主要是显示项的随机，比如 loading期间的 tip选择

这里，为了更明确区分，在客户端做了一层封装：

• AEUtil:GRandom，战斗类的随机数方法
• AEUtil:UIRandom，非战斗类的随机数方法

做好区分，也便于相关日志的打印。

使用战斗类随机数模块：

• AI
• 行为树
• 相机
• 技能、BUFF、特殊能力
• 实体相关
• 地图相关

使用 非战斗类 随机数模块：

• UI界面
• 外挂检测
• 数据收集
• 音乐音效

当然，也不是绝对的，比如实体相关的有些可以不用战斗类随机数，比如NPC弹出个对话，也是纯显示性的。这里是为了好区分，方便开发，一刀切了。

确定的 容器及算法 [过程一致性]

• 对于lua语言，不要用 pairs 方式遍历，要用 ipairs，也相应就要求容器必须是数组
• 所有用到的算法，必须是 稳定 的算法

隔离与封装 逻辑层 [过程一致性]

所有模块都可以分为 draw 与 update 两部分

• draw 进行绘制，走本地绘制帧更新
• update 进行逻辑计算，走逻辑帧更新，可被帧同步接管

实现帧同步尤其需要对 逻辑层的数据进行封装与隔离

以位移组件为例：

• 位移组件有两套坐标
  • 逻辑坐标
  • 渲染坐标
• 人物的行走都是通过逻辑坐标计算，渲染坐标是在渲染帧的时候，将当前渲染坐标与逻辑坐标进行比较，再用差值平滑过渡

同理的还有：

• 碰撞框的计算
• 各组件
• 各实体

做好分离，也便于之后做快照相关的优化。

支持本地战斗

创建联网战斗场景基类继承自单人战斗场景基类，用来统一控制联网相关的特殊操作，如 传送，协议交互 等。

然后，设置本地战斗变量，用来进行控制，若是本地战斗，交由基类处理。

同步模式 及 处理帧策略 [过程一致性]

同步模式

• 服务器： 固定推帧 30帧/秒
• 客户端：
  1. 30帧/秒，每次执行一次处理帧
  2. 60帧/秒，每次执行一次处理帧
  3. 30帧/秒，每次执行一次处理帧，绘制帧到来时，若有帧积压，再执行一次处理帧

处理帧策略

每次执行一次处理帧操作，具体释放帧数量

1. 释放1帧
2. 逐步释放帧
   • 累计帧数 < 2帧，释放1帧
   • 累计帧数 < 5帧，释放2帧
   • 累计帧数 < 10帧，释放3帧
   • 累计帧数 >= 10帧，释放所有帧
3. 可变释放帧
   • 释放帧数量由 PlayFrameScale 变量控制，可 加速/减速 播放（一般用于处理回放）
4. 释放全部帧

断线重连

断线重连，主要由 联网战斗数据缓存类负责。

1. 从服务器中获取重连过程中的战斗帧
2. 进入 追帧模式进行追帧，在追帧模式中，服务器发来的推送帧会被缓存起来
3. 追帧完毕后，退出追帧模式；并将追帧期间的 服务器推送帧压入 同步管理器中

同步校验

验证多个客户端是否同步，主要依赖于随机数及调用随机数的位置。

在联网战斗运行时，会将使用的随机数都打印出来，由于我们随机种子一致，所调用的随机数序列也应该是一致的，辅助以调用随机数的位置信息，战斗结束后对不同客户端的随机种子文件日志比对，可以校验同步。

我处理这块的方式是使用两个日志文件，

• 一个用来做同步校验：大部分内容是 使用随机数的模块 + 随机数范围 + 最终生成的随机数，还有一些必然一致的过程日志。
• 另一个用来做同步排查：包含更详细的日志信息

两场战斗结束后，用对比工具比较日志，一旦有差异，用更详细的日志信息，进行排查。

优化项

联网战斗同步向来不是一个做完就行的东西，而且也没有一套东西，在各个类型游戏通吃的情况。

所以，在实现完基础的同步架构后，还有很长的路要走。

目前只是搭建了一个基础的框架，要真正投入还有下面这些优化项可以做。

下面这些东西，有些已经做了，有些正在做，有些是一些设想，即将做的；欢迎各位伙伴一起来讨论。

快照的支持

在帧同步基础上，进行优化；就是 帧同步+快照 的模式。

其实已经不属于帧同步了，偏向状态同步。

快照作用就是将整个现场备份，缺点是数据量过大。

但是，我们以房间为单位的战斗，尤其适合 帧同步+快照；因为有明确的划分单位；并且房间初始，很多东西都是不需要存储的。

• 房间内的快照，所有实体的状态（怪物、NPC、传送门 等等），HP、EP、受损状态 等等
• 房间间的快照，实体都是初始创建，且实体的创建是不通过帧的，可以本地处理

这三者区别，

• 帧同步 => 没有进度条的播放器；想要看到第6分30秒的内容，必须从头开始看

• 状态同步 => 有进度条的播放器；知道时间，就可以直接切到相应时间开始播放

• 帧同步+快照 => 有进度条，但单位是5分钟；要看 6分30秒的内容，不需要从头看，但是也要从第5分钟开始播放，直到6分30秒

安全性

帧同步的安全性也是一个重大的问题，可以分为几大部分。

1. 客户端的安全模块，游戏的核心战斗逻辑演算都在客户端进行，所以对于数据的加密，防篡改等都是由安全模块统一处理。

2. 网络模块，对于网络层的外挂，由底层网络模块的加密等处理。

3. 联网战斗系统的防外挂模块

   基础的几个方案

   • 每隔一段时间，进行玩家信息收集并上传（如血量、技能使用、buff使用），出现结算不一致，由服务器裁决，可以解决部分外挂
   • 服务器新开一个“客户端”，在那个客户端上跑所有的帧，作为评判依据。
   • 等等

防外挂这个东西，就是魔高一尺，道高一丈，不断优化，不断调整的过程，有些东西也不好讲太细，只能说个大概。

不同步的处理

解决不同步问题，也是帧同步方案的一大痛点。

对于不同步的处理，可以分为三个部分：发现 -> 重现 -> 解决

作为开发，应该深有感触，如果方便重现，那解决问题就很简单了。

下面的处理方式都是针对传统的不同步处理各个步骤，进行优化设想。

一般出现不同步： 发现不同步 -> 打开日志开关 -> 使用同样的数据源 -> 复现问题 -> 解决问题

发现

发现不同步，最简单粗暴的方式，肯定是人力跑，没有技术成本，纯跑…

但是，缺点很多：

• 人力不足
• 时间不足
• 不够全面
• 不方便收集日志
• 不能体现技术实力
• 等等等等

所以，需要一种自动化的测试工具，来进行大量全面的测试。

目前打算是使用 python + jenkins 来部署自动化测试流水线，等测试完，再单独来说一说。

重现

重现不同步，也是很重要的一个步骤，能完美重现，那距离解决就不远了。

这里预期采用的方案是，固定数据源 + 回放机制。

• 固定数据源

  需要和服务器配合，服务器需要存储参战玩家信息及帧内容，便于回放。

  前期可以全部存储，但是这样服务器压力会比较大；后期可以将本地战斗产生的同步文件形成MD5，发给服务器；服务器判断各客户端MD5不同，采取缓存录像。

• 回放机制

  需要客户端实现一套根据帧内容回放机制，理论上来讲帧同步的回放还是比较好实现的。

  毕竟 确定的输入，确定的运算，确定的过程，都与时间无关联，可以得到确定的输出。

  但是，我们需要的是日志文件，所以绘制帧内容可以忽略掉，尽量做到逻辑帧的播放，这样在时间上也会更快。

解决

解决不同步问题，那就相对简单很多了。

实现了上面的发现 与 重现，可以无数次反复执行不同步数据源，验证是否解决也很便捷。

运行过程中的日志收集

这应该属于发现不同步的部分。

在实际项目中，日志的实现都是比较粗暴的，一般来说线上运行的模块，都不会开启日志文件。因为一般日志文件都会比较大，尤其是查同步问题的日志文件，涉及模块繁多，产生文件体积大。

所以，线上出不同步问题，往往也很难复现并解决，就是无法固定数据源。（不产生校验文件，就不能上传MD5，不能传MD5，服务器无法判断是否不同步，就不会缓存）

如果有一套性能损耗小一些的日志收集系统，会对同步问题的解决有很大的帮助，

正好最近看到了 《腾讯游戏开发精粹》- 第六部分 - 第14章 - 一种高效的帧同步全过程日志输出方案 。

上面的方案也对我有一些启发，之后可以去实验一下。

延迟处理

在实际测验中，会有玩家反馈卡顿情况。

延迟、卡顿的玩家体验，一般可以分为：

• 延迟高
• 波动大

而且，不同游戏类型对延迟的敏感度也不同，现在实现的这种偏格斗类型的游戏，对延迟敏感度还是比较高的。

再者，传统帧同步的处理，逻辑上就是比本地操作要慢一帧：

A帧操作 -> B帧上传 -> C帧执行

B ≥ A，C ≥ B+1

最终，还是要用数据来验证延迟的具体位置，可以按照下流程打时间戳，再收集各个数据，来分析并解决延迟与卡顿：

这里列出几个方向：

• 玩家的位置

• 玩家的机型

• 战斗的时间

• 玩家的运营商

数据收集的选项：

• 最小值
• 最大值
• 平均值
• 波动值

这里还要注意设置阈值，防止某个异常操作，导致数据不准确，拉高或拉低平均值。

甚至可以设置一些字段，来做筛选剔除异常数据。

感悟

不信推送，相信帧

推送缺点

• 每个客户端处理的时机不同
  • 收到的时机：服务器 推送A，再推送B；对于客户端肯定是先收到A，再收到B
  • 处理的时机：由于各客户端阻塞状态等，每个客户端处理推送时机是不一致的
• 推送可能丢失
• 推送内容，不支持在回放中处理

比如：

• 玩家复活
• 玩家掉线，删除角色

逻辑帧的更新流程是确定的

游戏进行过程中，所有的相关模块：

• 实体管理器

• 场景管理器

• 碰撞管理器

• 摄像机管理器

• 等等

这些模块的更新，都是固定顺序执行，所有参数都是确定的，所用随机都是指定随机方法

需要客户端同步的东西，必须通过帧来驱动。

同步的实质

同步，就像一个管理器，它的策略项设计项不难，难点主要在于管理的各个模块的内部实现。因为一场战斗涉及的模块很多，只要有一个模块实现有不同步的地方，整场战斗就不同步了。

在到后期查找不同步原因，也往往是去排查下属模块的实现，可能就是在于遍历方式，随机数的使用，逻辑帧绘制帧等。

主要还是要求：

• 实现同步下属模块的责任人，有联网战斗的意识，尽量的不使用本地数据，能区分出哪些代码可以使用绘制帧的更新，哪些坚决不允许使用绘制帧的更新。
• 做同步的责任人，对各个下属模块的涉猎广泛，不能只做完同步就可以了，还需要辅助下属模块进行不同步的排查。

解决这个问题的方向：

• 让所有实现模块的人都有联网战斗的意识，对整个逻辑帧绘制帧等更新都有概念。（难度很大）
• 实现自动化同步测试，在发现不同步问题，辅助去定位解决。

---

参考资料：

• DonaldW-网络游戏同步技术概述
• KCP - A Fast and Reliable ARQ Protocol、
• 《腾讯游戏开发精粹》