帧同步

1：帧同步如何解决不同步的问题？ 可靠稳定的帧同步基础算法 消除浮点数带来的精度误差 控制好随机数 参考： Unity帧同步游戏极简框架及实例(附客户端服务器源码) 2：帧同步怎么做到流畅的战斗？ 首先，定义一下流畅的战斗，流畅的战斗并不是代表着游戏的帧数一定要多高多高，而是说游戏的帧数在某一个帧数范围内小规模的变动，例如稳定在30帧这样。 对于单机游戏来说，如果要保证稳定在30帧，每一帧的逻辑、渲染等耗时不能高于33MS，所以需要小心的规划每一个函数的使用，采用分帧执行、算法优化等手段优化卡顿点。 而对于帧同步来说，不仅仅需要完成单机游戏的优化、还要针对网络波动进行针对的优化。 我们知道，网络传输无法保证每一次传输的延迟都是一定的，有时候10MS就能完成一次传输，有时候1000MS才能完成一次传输，那么客户端如何保证网络传输不稳定的情况下，逻辑帧的运行还是相对稳定的呢？下面是给到的两种解决方案。 收到逻辑帧消息之后，不立即去播放，而是存着，播放使用固定的延迟进行播放 ，表现上就是玩家每次进行操作的时候，并不是马上生效的，而是有一小段固定延迟，这样网络在我们设置的延迟内波动的话，玩家是感受不出来卡顿的。但是缺点也很明显，每一个玩家都会有一段延迟。 另外一个处理方式就是， 逻辑和表现进行分离 ， 表现帧由玩家和逻辑帧进行驱动，逻辑帧卡顿并不影响表现帧，表现帧由玩家进行控制播放

帧同步含义 游戏客户端接受来自网络的多个客户端的操作，如果这些操作在各个客户端是一样的，那么多个客户端的显示也就一样了，这就带来了“同步”的效果。所以在这种情况下，各个客户端的运算要绝对一致，不能依赖诸如本地时间、本地随机数等等“输入”，而要一切以网络来的操作数据为主。 一般来说，大多数的游戏客户端引擎，都会定时调用一个接口函数，这个函数由用户填写内容，用来修改和控制游戏中各种需要显示的内容。比如在在Unity里面叫Update()，这类函数通常会在每帧画面渲染前调用，当用户修改了游戏中的各个角色的位置、大小后，就在下一帧画面中显示出来。而在帧同步的游戏中，这个Update()函数依然是存在，只不过里面大部分的内容，需要挪到另外一个类似的函数中，我们可以称之为UpdateNet()函数——由网络层不断的接收服务器发来的“网络帧”数据包，每收到一个这样的数据包，就调用一次这个UpdateNet()函数，这样游戏就从通过本地CPU的Update()函数的驱动，改为根据网络来的UpdateNet()函数驱动了。显然，网络发过来的同步帧速度会明显比本地CPU要慢的多，这里就对我们的游戏逻辑开发提出了更高的要求——如何同步的同时，还能保证流畅？ 实现UpdateNet函数内容，其实就是定义一个堆栈用于存放网络发过来的消息，通过帧监测将其数据拿出来使用

上节讲到了匹配系统，匹配完成之后，我们就需要开始进行帧同步了。但是，需要注意，只有房主才可以调用开始帧同步的方法。因此，需要加一层判断。 然后，房间内的其他玩家需要监听开始帧同步的广播，接收到开始帧同步的消息之后，进入游戏场景。 game_scene：游戏主场景。（终于到最关键的逻辑部分了） 首先，进入游戏主场景之后，进行一些玩家的初始化（比如位置，血量，攻击，防御等信息），还有摇杆的初始化。 需要注意的是，玩家的出生位置这一部分逻辑稍微复杂一些。因为，没有服务器逻辑支持，所以只能在客户端想办法。于是，我预先定义了两组，共六个玩家的位置。然后，把服务器传过来的房间内玩家也进行分组，最后将两个分组内的玩家分别和位置信息映射好就可以了。这部分逻辑在GameScene.ts的 initPlayerPoss方法里。 摇杆分为左摇杆和右摇杆。左摇杆是控制坦克的位置和方向的，右摇杆控制坦克的炮头方向和射击。（坦克的方向和坦克的炮头方向互不影响，需要注意一下） 所有初始化动作完成之后，就需要处理逻辑帧消息和发送帧消息了。以下是接收帧消息和发送帧消息的主要代码 每次处理完帧消息之后，就把逻辑帧的信息同步到表现层，然后把当前帧的消息发送到服务器。 之前，给服务器发送帧消息，我是每次摇杆监听到有变动就发送。这样会导致帧消息发送太频繁，没有必要这样做。另外，还会导致一个致命的问题，帧消息的顺序错乱

​最近在用腾讯的小游戏联机对战引擎（以下简称MGOBE）改写我之前写的坦克大战。因为时间有限，每天都是下班业余时间去搞，也是第一次写帧同步，因此遇到了很多问题，也因此学到了很多东西。（不了解这个框架的可以看我之前的简单介绍以及我为什么要用这个框架： 惊！！！个人游戏开发者的福音来了！ ） 目前主要实现的功能，就是匹配系统和帧同步的平滑移动，自我感觉效果还可以，不过还是有很多需要优化的地方。 因无法上传视频，想看视频效果的可以关注公众号「如若清风」，查找近期文章帧同步一即可看到。 匹配系统：包括小游戏的授权，获取openid等。匹配设置15秒超时，会提示是否重新匹配，或者取消匹配。 帧同步移动：移动的平滑处理，试了很多种方法。试了航位推算预测和平滑处理，不知道是算法不对，还是其他原因，总之不理想，最终用的插值算法。 今天这篇文章，主要先讲解一下，MGOBE框架的前期准备工作，把环境配置好。 打开产品介绍页 https://cloud.tencent.com/product/mgobe，点击立即使用，进入控制台 。 点击左侧【游戏概览】菜单，然后找到添加游戏，填写游戏基本信息。 点击下一步 ，进入服务开通页面，点击确定，即创建完成。 创建好之后，显示基本信息。其中游戏id，游戏key和域名是我们以后需要的 好了。今天就了解一下MGOBE框架的基本概况，下一篇，就开始详细讲解匹配系统了。

帧同步这部分比较复杂，细枝末节有很多优化点，也有一些不同的优化方向，根据不同项目类型、对操作手感的要求、联机玩家的个数等，会有不同的难点和痛点。不同的优化方向，优化手法的差异，可能导致一些争论。并且，帧同步，本身也有很多变种，以应对不同的需求。所以，本文一切都是基于作者的项目类型（ACT）来做的方案和优化，并不一定适合其它也需要帧同步的游戏，故在此提前说一下，以免引起一些不必要的误解。 帧同步的几个难点 帧同步的基础原理，以及和状态同步的区别，已经有很多文章介绍，我就不再赘述，大家可以自行google。以下只说几个难点。 保证客户端独自计算的正确，即一致性 帧同步的基础，是不同的客户端，基于相同的操作指令顺序，各自执行逻辑，能得到相同的效果。就如大家所知道的，在Unity引擎中，不同的调用顺序，时序，浮点数计算的偏差，容器的排序不确定性，Coroutine内写逻辑带来的不确定性，物理浮点数，随机数值带来的不确定性等等。 有些比较好解决，比如随机数值，只需要做随机种子即可。 有些需要注意代码规范，比如在帧同步的战斗中，逻辑部分不使用Coroutine，不依赖类似Dictionary等不确定顺序的容器的循环等。 还有最基础的，要通过一个统一的逻辑Tick入口，来更新整个战斗逻辑，而不是每个逻辑自己去Update。保证每次Tick都从上到下，每次执行的顺序一致。 物理方面

一、同步 所谓同步，就是要多个客户端表现效果是一致的，例如我们玩王者荣耀的时候，需要十个玩家的屏幕显示的英雄位置完全相同、技能释放角度、释放时间完全相同，这个就是同步。就好像很多个人一起跳街舞齐舞，每个人的动作都要保持一致。而对于大多数游戏，不仅客户端的表现要一致，而且需要客户端和服务端的数据是一致的。所以，同步是一个网络游戏概念，只有网络游戏才需要同步，而单机游戏是不需要同步的。 二、状态同步和帧同步的区别 最大的区别就是战斗核心逻辑写在哪，状态同步的战斗逻辑在服务端，帧同步的战斗逻辑在客户端。战斗逻辑是包括技能逻辑、普攻、属性、伤害、移动、AI、检测、碰撞等等的一系列内容，这常常也被视为游戏开发过程中最难的部分。由于核心逻辑必须知道一个场景中的所有实体情况，所以MMO游戏（例如魔兽世界）就必须把战斗逻辑写在服务端，所以MMO游戏必须是状态同步的，因为MMO游戏的客户端承载有限，并不能把整张地图的实体全部展现出来（例如100米以外的NPC和玩家就不显示了），所以客户端没有足够的信息计算全图的人的所有行为。 具体到客户端和服务端通信上，在状态同步下，客户端更像是一个服务端数据的表现层，举个例子，一个英雄的几乎所有属性（例如血量、攻击、防御、攻速、魔法值等等）都是服务端传给客户端的，而且在属性发生改变的时候，服务端需要实时告诉客户端哪些属性改变了，客户端并不能改变这些属性