16年年底的时候我从当时的公司离职，来到了目前任职的一家更专注于游戏开发的公司。接手的是一个platform游戏项目，基本情况是之前的团队完成了第一个版本，即单人模式的基础玩法，但是之后对该项目的定位又变成了一个本地局域网的联机手游(2-4个玩家)。因此，重写项目底层外加确定网络同步方案就成了第一件需要去认真考虑的事情了。那么本文就来聊聊网络同步这件事吧。
游戏同步中的主次
开发网络多人游戏是一件十分有趣的事情，但是和单机游戏相比无疑增加了更多的挑战。
例如，我们之前开发的单机版本并不需要多么担心作弊的问题。这是因为购买我们游戏的玩家(假如我们的单机游戏不免费发布的话)即便作弊，影响的也仅仅是他自己的游戏体验，不会影响到别人。
但是开发多人游戏就不是这样了，为了保证让每个人都有好的游戏体验，防止作弊总是需要去考虑的。
除此之外，在开发多人游戏时我们还需要考虑如何“欺骗”玩家的眼睛，让他们认为他们在同一个世界中。
当2个或4个玩家一起在手机上玩游戏时，看上去他们确实像是在共享同一个虚拟世界，在同一个世界中游玩。但事实却是，玩家自己的手机只是对“同一个”虚拟世界的近似模拟。换言之，他们的游戏世界每一个都是独一无二的，只不过从外观上看起来像。
因此，为了达到这种看上去近似的效果，我们需要确认哪些状态是需要同步的，只要同步了这些状态，这个游戏世界就看上去一样了。而哪些状态是无需同步的，即这些对象的状态是否同步对整个游戏是否看上去一样并没有特别大的影响。
在我们的游戏中，玩家的各种属性、在世界中的坐标、游戏世界中的敌人各种属性、道具获取以及各种触发器的触发等等都有可能会对游戏的表现产生影响，因此需要考虑同步;但是像例如海底的水泡粒子效果、道具获取后的碎裂效果，甚至是背景音乐则不会对游戏的表现产生特别的影响，因此并没有必要去同步这些内容。
同步输入or同步状态
既然明确了不存在两个完全一样的游戏世界，每个游戏世界无非都是近似的模拟。那么接下来我们就要来选择一个适合的网络同步方案以满足这种需求了。
两种client-server模型的相同点都在于有一台机器负责整个游戏世界的模拟，而这台负责整个游戏世界模拟的机器是谁则是这两者最大的区别。在我们的项目中，我们借助其中一个玩家的手机作为服务器，我们叫它Master主机，而一般的玩家设备则被称为Client。当然，更常见的一种情景是游戏开发商或发行商管理的计算机作为服务器，这也往往需要更多的计算机和运维人员。
通常，基于这种同步模型的游戏中客户端不能做出真正的决定。一个情景就是当客户端的玩家按下一个按键，客户端并不会真正的执行影响游戏状态的操作，相反操作会被发往服务器，并在服务器执行它，之后服务器将执行完这个操作之后的结果(通常是游戏世界的状态变化)返回给客户端。
由于大家都知道的网络延迟，因此服务器和客户端并非时刻保持一致的，为了使游戏玩家的状态变化自然(主要是指玩家的位置、角度等状态)，我们使用的是一种基于插值的同步算法(当然，这种方式也常常被称为影子跟随算法)：
服务器间隔固定的时间向客户端同步状态数据
客户端收到数据之后进行同步，一般的属性数据例如血量等等直接根据服务器的值来同步。而诸如位置等信息在客户端则保存为ServerPosition或者称为影子，而客户端的位置则不断向ServerPosition靠拢。
位置同步的过程为了更加平滑，要使用插值，步进距为玩家的移动速度。因此，虽然ServerPosition是跳变的，但是在客户端的表现上却是连续平滑的。如下图所示，左侧的画面为Server的状态，右侧的画面为客户端的状态，玩家和场景内的怪物位置通过Server告诉客户端，客户端于是开始追赶Server发来的状态。
当然，将所有的逻辑放到服务器并经过服务器的模拟之后再将结果返回给客户端的过程会带来一些滞后感，当玩家对操作的敏感度要求较高时，这显然不是一个很好的解决方案。因此，客户端的输入预测和服务端的延迟补偿开始得到应用。通过在客户端侧的输入预测，可以让玩家的输入得到立刻的反馈。而延时补偿则保证了结果的正确性。这个过程可以基本概括为以下几个阶段：
当玩家按下按钮时，客户端立刻执行相应的操作例如开始播放某个动作或是开始移动。与此同时，客户端还会向服务器发送一条包含了时间戳的消息。
服务器经过一段延迟后收到了客户端发来的按钮被按下的消息，于是服务器会回滚到按钮被按下的时刻，在这个时刻执行按钮对应操作，之后再重新模拟到当前时刻。
之后服务器将当前的状态同步给客户端。
客户端收到服务器同步过来的数据，此时由于网络延迟的缘故，客户端收到服务器的消息时也已经过去一段时间。所以客户端同样需要回滚到服务器发出消息的时刻，并根据服务器发送的状态来修正自己的状态。
虽然这样做能够更好的保证玩家的手感，但是我们发现无论是客户端还是服务器，一旦收到消息包之后都需要回滚。而这种回滚机制相对来说较为复杂，并且也不容易在已有的游戏中加入这种机制。
综上，我们可以看到在这两种同步模型中，服务器获取客户端的操作指令并在服务器内模拟整个游戏世界，之后服务器是将服务器所维护的游戏世界内的状态同步给各个客户端，因此这里主要是做状态同步。
Peer to Peer点对点同步模型是一种很经典的网络游戏网络同步模型。带有帧同步模型的Peer to Peer在很多RTS游戏中得到了大量应用，不过在讨论帧同步模型之前，我们先来聊聊一般的Peer to Peer。
相对于C/S模型拥有一个计算机负责整个游戏世界的模拟，Peer to Peer模式并没有单一的计算机来负责模拟游戏世界。相反它将对游戏世界的模拟分配给了所有玩家，因而每个玩家的客户端都在模拟着自己的游戏世界。这样做的一大好处在于玩家的输入总是立刻响应的，我按下一个按钮，按钮造成的结果便发生了，同时我需要做的是将我的操作发送给和我相连的客户端，让他们也去根据我发送的操作模拟游戏世界。但是这样做的一大弊端在于不能保证客户端看到的游戏画面是一样的。
例如上图上方的怪物射出的子弹可以通过画线来阻挡，但是由于client1和client2都是在模拟自己的游戏世界，因此延迟或是不同移动设备本身的性能问题就有可能会造成client1的画线操作同步到client2上时产生不同的结果。所以我们发现只是简单的让每个客户端模拟自己游戏世界(就像单机那样)，同时简单的将操作同步给别的客户端，至少在同步这个问题上是不靠谱的。
因此，游戏行业大多会采用帧同步模型来保证同步的可靠性。很多早期的RTS游戏都采用了帧同步来作为网络同步的方案。至于为什么很多人在介绍帧同步的时候，都喜欢把早期的RTS游戏搬出来作为一个例子呢?我想各位看一眼RTS游戏的游戏截图就能猜到个大概了。
RTS游戏中常常伴随着数十上百甚至上千个逻辑实体单位，如果采用状态同步的话数据量相对要大很多。但是如果只同步玩家的操作呢?如果每个客户端在相同的情况下开始游戏，并且运行完全相同的步骤，那么客户端就可以不通过接收状态同步信息就能保证游戏的同步了。
这也是这种模型的一大优势，我们除了发送玩家的操作之外几乎不需要再发送任何数据。这种同步输入的方式可以说非常适合RTS游戏，因为它们有那么多的单位，同步所有单位的状态是不容易的。
因此，采用这种模型就可以把游戏的过程分为一个一个的回合。游戏的每一步都需要通过网络来收集所有玩家的操作输入，然后再往下执行。当然，一提到“回合”这个词，大家想到往往是所谓的回合制游戏，但事实上只要回合的频率足够快，仍然是可以做出即时游戏的感觉。
当然，由于没有同步游戏的状态，而是同步玩家在游戏内的输入操作，因此实现完全同步还是有一些事情需要注意的。因为一旦一个小小的不同步发生，就会产生蝴蝶效应，从而引起很明显的不同步。一个典型的例子便是我以前在开发一个战斗回放系统时，发现由于一个士兵在寻路的时候稍微走到有点不一样的地方，就导致了一场战斗的结果大不相同。
虽然我们目前的项目并没有采用帧同步的方案，但是还是想和大家分享一点教训。例如不要使用浮点型数据，这是由于舍入会造成误差，所以建议各位使用整形数据。同样，另一个又被重视又被忽略的是随机数的问题。大家都知道帧同步要保证随机数也完全一致。因此，大家都会去同步随机数生成器的种子和它们的使用方式。但是一个潜在的可能性是某一方的非游戏逻辑对象使用了随机数生成器，从而造成不同步。例如某一方的移动设备性能更好，也因此屏幕上有一些额外粒子特效，这些粒子特效是有可能会使用随机数发生器的，如果这些游戏逻辑之外的对象使用了随机数发生器就会造成不同步的发生。
哦，对了，最后需要说明的一点是帧同步还可以和C/S模型组合使用，我们可以通过服务器来转发客户端的操作数据，而不必让各个客户端直接通讯。公司内有项目组采用的就是这种方案。