【阅读笔记】如何确定网络同步方案？多人游戏同步模型分享

https://mp.weixin.qq.com/s/6YF0-_tRr3VQUh1vlh6j6g

1 游戏同步中的主次

开发多人游戏为了保证让每个人都有好的游戏体验，防止作弊总是需要去考虑的。

除此之外，在开发多人游戏时我们还需要考虑如何“欺骗”玩家的眼睛，让他们认为他们在同一个世界中。

为了达到这种看上去近似的效果，我们需要确认哪些状态是需要同步的，只要同步了这些状态，这个游戏世界就看上去一样了。而哪些状态是无需同步的，并没有特别大的影响。

在我们的游戏中，玩家的各种属性、在世界中的坐标、游戏世界中的敌人各种属性、道具获取以及各种触发器的触发等等都有可能会对游戏的表现产生影响，因此需要考虑同步；但是像例如海底的水泡粒子效果、道具获取后的碎裂效果，甚至是背景音乐则不会对游戏的表现产生特别的影响，因此并没有必要去同步这些内容。

2 同步输入or同步状态

最基本的游戏网络同步模型大概可以分为以下4种：

client-server：专用服务器

client-server：玩家之一作为服务器

peer-to-peer

peer-to-peer：帧同步

前两种模型的相同点都在于有一台机器负责整个游戏世界的模拟，最大的区别在于这台负责整个游戏世界模拟的机器是谁。

通常，开发商或发行商管理的计算机作为服务器，这也往往需要更多的计算机和运维人员。基于这种同步模型，客户端的玩家按下一个按键，客户端并不会真正的执行影响游戏状态的操作。操作只会被发往服务器，并在服务器执行它，之后服务器将执行完这个操作之后的结果（通常是游戏世界的状态变化）返回给客户端。

搭建服务器虽然能提高游戏体验，但是确实代价高昂。

最理想的还是通过玩家自己建立host。突然想到，这个结构很像区块链。查了下确实有在运用区块链在手游界的。

由于网络延迟，因此服务器和客户端并非时刻保持一致的，为了使游戏玩家的状态变化自然（主要是指玩家的位置、角度等状态），常用一种基于插值的同步算法（影子跟随算法）

1. 服务器间隔固定的时间向客户端同步状态数据

2. 客户端收到数据之后进行同步，一般的属性数据例如血量等等直接根据服务器的值来同步。而诸如位置等信息在客户端则保存为ServerPosition或者称为影子，而客户端的位置则不断向ServerPosition靠拢。

3. 位置同步的过程为了更加平滑，要使用插值，步进距为玩家的移动速度。因此，虽然ServerPosition是跳变的，但是在客户端的表现上却是连续平滑的。

当然，将所有的逻辑放到服务器并经过服务器的模拟之后再将结果返回给客户端的过程会带来一些滞后感，当玩家对操作的敏感度要求较高时，这显然不是一个很好的解决方案。因此，客户端的输入预测和服务端的延迟补偿开始得到应用。通过在客户端侧的输入预测，可以让玩家的输入得到立刻的反馈。而延时补偿则保证了结果的正确性。这个过程可以基本概括为以下几个阶段：

1. 当玩家按下按钮时，客户端立刻执行相应的操作例如开始播放某个动作或是开始移动。与此同时，客户端还会向服务器发送一条包含了时间戳的消息。

2. 服务器经过一段延迟后收到了客户端发来的按钮被按下的消息，于是服务器会回滚到按钮被按下的时刻，在这个时刻执行按钮对应操作，之后再重新模拟到当前时刻。

3. 之后服务器将当前的状态同步给客户端。

4. 客户端收到服务器同步过来的数据，此时由于网络延迟的缘故，客户端收到服务器的消息时也已经过去一段时间。所以客户端同样需要回滚到服务器发出消息的时刻，并根据服务器发送的状态来修正自己的状态。

虽然这样做能够更好的保证玩家的手感，但是我们发现无论是客户端还是服务器，一旦收到消息包之后都需要回滚。而这种回滚机制相对来说较为复杂，并且也不容易在已有的游戏中加入这种机制。

（后两种）Peer to Peer点对点同步模型是一种很经典的网络游戏网络同步模型。带有帧同步模型的Peer to Peer在很多RTS游戏中得到了大量应用

它将对游戏世界的模拟分配给了所有玩家，因而每个玩家的客户端都在模拟着自己的游戏世界。这样做的一大好处在于玩家的输入总是立刻响应的，我按下一个按钮，按钮造成的结果便发生了，同时我需要做的是将我的操作发送给和我相连的客户端，让他们也去根据我发送的操作模拟游戏世界。但是这样做的一大弊端在于不能保证客户端看到的游戏画面是一样的。

因此，游戏行业大多会采用帧同步模型来保证同步的可靠性。很多早期的RTS游戏都采用了帧同步来作为网络同步的方案。

RTS游戏中常常伴随着数十上百甚至上千个逻辑实体单位，如果采用状态同步的话数据量相对要大很多。但是如果只同步玩家的操作呢？如果每个客户端在相同的情况下开始游戏，并且运行完全相同的步骤，那么客户端就可以不通过接收状态同步信息就能保证游戏的同步了。

这也是这种模型的一大优势，我们除了发送玩家的操作之外几乎不需要再发送任何数据。这种同步输入的方式可以说非常适合RTS游戏，因为它们有那么多的单位，同步所有单位的状态是不容易的。

因此，采用这种模型就可以把游戏的过程分为一个一个的回合。游戏的每一步都需要通过网络来收集所有玩家的操作输入，然后再往下执行。当然，一提到“回合”这个词，大家想到往往是所谓的回合制游戏，但事实上只要回合的频率足够快，仍然是可以做出即时游戏的感觉。

大菠萝就是把等待时间减为0了。

当然，由于没有同步游戏的状态，而是同步玩家在游戏内的输入操作，因此实现完全同步还是有一些事情需要注意的。因为一旦一个小小的不同步发生，就会产生蝴蝶效应，从而引起很明显的不同步。一个典型的例子便是我以前在开发一个战斗回放系统时，发现由于一个士兵在寻路的时候稍微走到有点不一样的地方，就导致了一场战斗的结果大不相同。

虽然我们目前的项目并没有采用帧同步的方案，但是还是想和大家分享一点教训。

例如不要使用浮点型数据，这是由于舍入会造成误差，所以建议各位使用整形数据。

同样，另一个又被重视又被忽略的是随机数的问题。

大家都知道帧同步要保证随机数也完全一致。因此，大家都会去同步随机数生成器的种子和它们的使用方式。但是一个潜在的可能性是某一方的非游戏逻辑对象使用了随机数生成器，从而造成不同步。例如某一方的移动设备性能更好，也因此屏幕上有一些额外粒子特效，这些粒子特效是有可能会使用随机数发生器的，如果这些游戏逻辑之外的对象使用了随机数发生器就会造成不同步的发生。