01手游帧同步的要点总结

与状态同步比较

状态同步：状态变化时同步

帧同步：每帧都同步，同步的是帧号和玩家输入；各前端对于同样的输入序列肯定演化成同样的结果

优点

对于前端来说开发效率较高，如同单机游戏，能实现更好的表现效果

流量消耗是稳定的，方便实现录像回放

缺点

网络要求较高

反外挂能力弱

断线重连所需时间长

实现过程

客户端和服务端有完全一样的演算逻辑（排除一切随机因素）

服务端以固定帧频，每帧演算（这里也可以不演算），并将帧号和用户输入同步到客户端

客户端接到服务器数据后，以同样逻辑步进一帧

战斗结束后，以服务端的演算结果为准（也可以不立即验证，而是找服务器空闲时候秋后算账）

实现要点

解决卡顿

使用buffer（可根据延时调整大小）

本地插值平滑

表现与逻辑分离

解决延迟：使用UDP，需要解决丢包问题

一次携带多帧数据，降低丢包率

丢包后客户端重新请求

注意浮点数和随机函数带来的不确定性问题

要有合理的监控机制

对外挂和作弊的监控

对不同步case的监控，有助于发现和修复bug

02Unity3D RTS游戏中帧同步实现

帧同步技术是早期RTS游戏常用的一种同步技术。与状态同步不同的是，帧同步只同步操作，其大部分游戏逻辑都在客户端上实现，服务器主要负责广播和验证操作，有着逻辑直观易实现、数据量少、可重播等优点。

部分PC游戏如帝国时代、魔兽争霸3、星际争霸等，Host(服务器或某客户端)只当接收到所有客户端在某帧输入数据后，才会继续执行，等待直至超时认为该客户端掉线。很明显，当部分客户端因网络或设备问题无法及时上传操作数据，会影响其它客户端的表现，造成不好的游戏体验。考虑到游戏公平竞争性，这种需要等待的机制是必需的，但并不符合手游网络环境的需求。为此，需要使用“乐观”模式，即是Host采集客户端上传操作并按固定频率广播已接收到的操作数据，不在乎部分客户端的操作数据是否上传成功，且不会影响到其它客户端的游戏表现。

03复盘王者荣耀手游开发,Unity引擎使用帧同步放弃状态同步

现在来看，选择帧同步方案之后，我们再把它的缺点进行优化或是规避，之后它带来的好处是非常明显的。《王者荣耀》重除了英雄的设计以及技能的感觉，还有很重要的一点，就是它确实在做一些非常有特色的英雄，它的技能、反馈、体验上面都做得不错，这些都是基于帧同步技术方案带来的优势。

我们选择了方案之后，当时觉得很high，觉得这样一个技术方案开发起来得心应手，效率如此之高，做出来的效果也很好。

但事实上，它也有好的一面，也有坏的一面，技术测试版本上线后质量不好，其中技术层面遇到的问题就是下面这三座大山。

第一是同步性，同步性这块容易解决，其实也解决了;

第二也是最大一块网络问题，帧同步它的网络问题导致我们对它技术方案的原理没有吃透，碰到了一些问题，那时候游戏的延迟很重，画面卡顿，能明显感觉走路抖动的现象;

第三是性能问题，这个问题始终存在，我们也一直在优化。

04Recast & Detour 寻路引擎的基本流程

Recast & Detour是一个开源的寻路引擎，其遵循zlib协议，基本上你可以免费且无限制的将它用作个人和商业产品中。

从名字中我们可以看到，这个引擎分成两部分：

第一部分是Recast，主要功能是将场景网格模型生成用于寻路的网格模型（Navigation Mesh）。所生成的寻路网格模型当然要比原模型简单很多，这也提高了实时寻路算法的效率。

第二部分是Detour，主要功能是利用上一步所生成的Navigation Mesh进行寻路，其包含了多种寻路算法，根据不同的路径光滑程度与寻路时间效率的要求可做不同的选择。

05IOS 内支付那点事

iOS是由苹果公司开发的移动操作系统。苹果公司最早于2007年1月9日的Macworld大会上公布这个系统，最初是设计给iPhone使用的，后来陆续套用到iPod touch、iPad以及Apple TV等产品上