游戏开发入门（九）游戏同步技术

Admin

视频链接：游戏开发入门（九）游戏同步技术（3节课 时常：约1小时07分钟）
第三个视频后9分钟没有声音，不过核心内容都已涉及到

---

笔记与总结（请先学习视频内容）：

1.网络同步的概念与意义

• 概念：任何一款网络游戏，为了尽可能的让不同玩家在同一时刻体验相同的内容，就必须要让不同的客户端看起来“同步”。
• 意义：早期的单机游戏，所有的游戏内容都是在玩家自己的机器上运行，不需要给其他的玩家看，也就不存在同步的概念。 但是在网络游戏中，你必须要保证A玩家走到B玩家面前的时候，B玩家在自己客户端上也能看到A玩家走来，A玩家攻击的时候，B玩家能即使看到并躲闪。但是我们知道，网络延迟是不能消除的，我们只能尽可能的减小延迟。对于局域网游戏由于玩家在物理环境下很近，网络延迟可以控制在很小的范围。但是对于广域网，我们无法更改玩家的网络环境，就只能通过各种手段消除/隐藏延迟，让玩家觉得“不卡”。在网络游戏中，同步的核心就是这个。
• 拓展：同步的底层机制一般都是一样的，通过Tcp/Udp来实现消息的发送与接收。但是具体到游戏里面，不同的游戏采用的同步机制与手段是不同的。比如一个卡牌类的游戏，玩家对几百毫秒的延迟是没什么感觉的，但是在动作游戏里面这是绝对难以接受的，另外有的游戏同步的数据量很少，有的游戏需要每帧都同步大量数据，所以“同步”问题一直都是业内比较头疼同时也在不断探索的一个重点。
  

2.外网的平均网络延迟
120ms以内，基本上玩家都可以接受

3.同步技术的基本常识：

• a.同步给谁？
  某个用户：如私聊的聊天信息
  同屏内的所有玩家：发给同一个区域内的所有玩家
  同一个服务器的所有玩家：遍历整个服务器所有玩家，然后逐个通知，如全服喇叭
• b.同步的数据是？
  命令数据：发送一个消息，通知另一端去执行某个操作，一般通过RPC实现
  状态数据：针对某一个数值，按照一定频率不断的发送给另一端，来让不同端的该数值保持一致
• c.同步的周期? 在特定逻辑触发时执行 一定频率不间断的发送
  

4.网络游戏面临的问题与解决思路
网络延迟：由于网络延迟无法避免，所有优化的核心就是如何根据当前环境减少延迟以及如何优化
客户端的视觉感受。一般对同步数据的暴力校正效果是非常差的，需要用各种手段去平滑的处理。
网络带宽：手游玩家可能会对流量的消耗比较在意，所以要尽可能的减小同步的数据量。减少方式有

• a.在对象第一次同步的时候将完整的对象信息同步过去，后续只同步那些发生改变的数据
• b.对协议内容进行优化，比如不需要可靠的同步消息可以使用UDP，减少一些校验等
• c.某些复杂的数据内容可以只传递简单的数据信息，然后不同的客户端以及服务器通过算法在本地计算出结果
  

反外挂：

• a.关键的游戏逻辑要放在服务器上面
• b.协议需要加密，密钥需要频繁的改变
• c.服务器对客户端发送的消息要验证，不合理的及时校正
  

5.常见的外挂类型

• 修改客户端内存数据
• 截取并修改客户端发送到服务器的消息
• 调整网络延迟，让其他客户端不能正确获到玩家位置
  

外挂的核心思路：不断去检测本地数据的变化并尝试去修改，很有可能就找到游戏逻辑的漏洞。理论上，完全避免外挂也是不可能的，不过可以尽量避免同时增加外挂实现的难度

6.关于P2P同步与服务器同步
有过计算机基础的朋友应该了解P2P，即点对点，就是说两个游戏端直接相连，消息不需要发给其他人。服务器同步的架构里面，所有的客户端都需要链接到一个服务器上面，然后所有的消息都需要服务器先验证，然后在发送给其他客户端。我们常见的网络游戏都是基于服务器同步的。

7.P2P同步常见的同步策略——时间轴同步：

• a.常规同步 A产生命令发给B的同时，立刻执行。B收到消息后再去执行。这个过程有延迟
• b.约定同步
  为了克服上面的执行不同步，A在产生命令的同时将消息与当前时间戳都发送给B。B收到命令后，根据
  网络情况在预测时间与A“同时”执行。或者A在产生命令的同时告诉B，应该在哪个时间戳开始执行，B收到 消息后在与A商量好的时间去执行。
  

注：该方法肯定也可能会有延迟的，不过一定范围内可以接收，效果也比常规同步的好一些

8.P2P同步常见的同步策略——帧同步：
帧同步的核心是保证各个端的逻辑帧保持一致。如果A在执行第N+1帧的时候需要B的第N帧数据，那么必须等到B
的第N帧数据同步过来后才能执行。

• 优点：保证逻辑上的完全同步
• 缺点：如果一个客户端的网络环境差，会导致另一个客户端也卡顿。
  

注：视频中提到对视觉要求不是很高的游戏采用帧同步，这句话有待商榷，他这里可能只是针对P2P。我们所熟知的“王者荣耀”采用的就是帧同步的方法，只不过他是在服务器同步架构下，采用的是乐观帧以及各个细节的逐步优化来完成的，后面简单讲解

9.服务器常见的同步策略——服务器时间轴同步：
前面提到过，服务器同步架构下，所有的消息都要通过服务器验证与转发。这与P2P基于时间轴同步策略是相同的，不过因为中间多了一道程序，延迟还可能有所增加。视频中所指的这种同步，在业界常说的状态同步差不多，也就是客户端的某些同步属性要与服务器保持一致。状态同步与时间轴同步的概念侧重点与分类有点不同，大家理解就好。

• 优点：可以对客户端消息进行验证，防止外挂。
• 缺点：延迟比较高，所以为了表现流畅，一般都是客户端在执行命令的时候立即执行操作，然后发给服务器去验证，如果验证不通过，服务器还会对客户端进行校正。
  

10.服务器常见的同步策略——服务器帧同步：
帧同步在服务器架构下仍然可以使用，不过在处理上可能有些差异。一般来说，客户端玩家在触发了某个按键操作的时候，会将操作的命令（注意：这个命令包含的只是玩家按键的信息，没有其他逻辑信息）与当前帧发送给服务器。服务器收集到所有客户端当前帧的操作信息后，就会广播执行给所有客户端。如果有的客户端没有发送当前帧的指令，服务器就不会广播消息，这时候所有客户端就会锁帧。
帧同步优化：为了避免客户端网络出现延迟的问题，产生了“乐观锁”的处理手段。就是服务器不去等待客户端是否发送了帧操作数据，每隔固定时间就广播给所有客户端。（视频第二节后面的内容就是这种机制）

11.同步中常见术语

• 主像：本地玩家角色，当前设备控制的角色
• 影像：本地客户端看到的其他玩家角色
• 客户端：包含本地玩家的终端设备
• FPS：帧数
  

12.位置同步
区域位置同步：给玩家配置一个范围，玩家移动超出这个范围后立刻触发同步更新中心坐标。同时为了防止玩家总在一个很小的范围移动，可以设置每隔一段固定时间就进行一次同步。

13.操作同步
客户端触发某个操作立刻执行，然后发送给服务器，服务器广播给其他客户端执行

14.命中同步
这个不同的游戏有不同的方式，可以选择让客户端进行判定，把结果传给服务器。也可以把玩家操作
发给服务器，让服务器去计算判断。

15.网络同步调试手段

• a.Log/断点 如果可以在开发时就定位到问题，那最直接的办法就是断点。如果不好定位，可以采用输出日志的方式，即log
• b.录像/录屏（Fraps）
  录像与我们常说的视频录像不太一样，而是我们记录玩家在各个时间点的操作，从游戏开始到结束完全的模拟一遍。这其实也是游戏回放的基本思路，很明显这样很容易重现我们之前出现的问题，这个录像一般需要游戏项目提供相关的功能才可以。
  如果游戏本身不支持录像功能，那可以借助工具来调试，如Fraps可以按特定帧数截屏
• c.网络模拟软件（Network-Emulator-Toolkit）
  开发者的游戏环境与玩家一般是不同的，为了测试在外网环境下玩家的游戏情况，我们可以借助一些网络模拟软件来调整当前开发环境下的网络延迟