实时游戏发展迅猛,同步技术也逐渐成为解决方案的核心之一。 本文简单讨论了帧同步和状态同步。


帧同步

什么是帧同步:帧同步常被RTS(即时战略)游戏常采用。在游戏中同步的是玩家的操作指令,操作指令包含当前的帧索引。一般的流程是客户端上传操作到服务器, 服务器收到后并不计算游戏行为, 而是转发到所有客户端。这里最重要的概念就是 相同的输入 + 相同的时机 = 相同的输出。

实现帧同步的流程一般是:

  1. 同步随机数种子。(一般游戏中都设计随机数的使用, 通过同步随机数种子,可以保持随机数一致性)
  2. 客户端上传操作指令。(指令包括游戏操作和当前帧索引)
  3. 服务器广播所有客户端的操作。(如果没有操作, 也要广播空指令来驱动游戏帧前进)。

因为帧同步的特性, 我们可以很方便的做出战斗回放:服务器记录所有操作, 客户端请求到操作文件再执行一次即可。

帧同步的特性导致客户端的逻辑实现和表现实现必须完全分离。Unity中的一些方法接口(如 Invoke, Update、动画系统等)是不可靠的,所有要自己实现一套物理引擎、数学库,做到逻辑和表现分离。 这样即使Unity的渲染是不同步的,但是逻辑跑出来是同步的。

我曾经参与过一个飞机类弹幕游戏的项目,它的同步方案就是帧同步, 可以完美的播放回放, 并实现服务器上加速验算。


状态同步

什么是状态同步:同步的是游戏中的各种状态。一般的流程是客户端上传操作到服务器,服务器收到后计算游戏行为的结果,然后以广播的方式下发游戏中各种状态,客户端收到状态后再根据状态显示内容。状态同步最广泛的应用应该是在回合制游戏中。

状态同步其实是一种不严谨的同步。它的思想中,不同玩家屏幕上的表现的一致性并不是重要指标, 只要每次操作的结果相同即可。所以状态同步对网络延迟的要求并不高。像玩RPG游戏,200-300ms的延迟也可以接受。 但是在RTS游戏中,50ms的延迟也会很受伤。 
举个移动的例子,在状态同步中, 客户端甲上操作要求从A点移动到B点,但在客户端乙上, 甲对象从A移动到C,然后从C点移动到了B。这是因为, 客户端乙收到A的移动状态时, 已经经过了一个延迟。这个过程中,需要客户端乙本地做一些平滑的处理,最终达到移动到B点的结果。

所以国产RPG游戏中,动画的特效一般做的比较绚丽(大), 攻击的时候给人感觉是击中了。放技能之前一般也有一个动画前摇,同时将攻击请求提交给服务器。等服务器结果返回时,动画也播放完毕了,之后就是统一的伤害效果和结算。


状态同步和帧同步的比较和选择:

比较:


状态同步

帧同步

流量

相对高

相对低

回放

记录文件大

记录文件小

安全性

服务器实现逻辑,安全性高

逻辑在客户端,反外挂压力大、无法避免开图挂

服务器压力



战斗校验

协议加密,内存混肴,误差校验,无法彻底解决。

服务器可以重启跑一遍战斗。

网络卡顿的表现

瞬移,回位,莫名掉血

战斗卡顿

实现

调优状态同步方式,客户端需要做插值处理。

客户端按照单机方式开发,保证逻辑层和表现层分离。逻辑层不要用到浮点数,不要用不确定顺序的逻辑结构。对于物理引擎和浮点数计算要不能使用Unity的。

选择:对于单位比较多的即时策略游戏,帧同步是很好的选择。反过来,如果玩家比较多,状态同步更合适,安全性更高。


如有错误,欢迎指出。