帧同步可以轻松解决高互动的联网游戏（如格斗，RTS 等）的同步问题，但该方案对延迟很敏感，现在一般省内服务器延迟差不多 10-15ms （1帧），跨省一般 40ms （2-3 帧），在此情况下，使用 Run-Ahead 机制可以有效的掩盖延迟的体感，让用玩家立马看到自己的操作反馈。
该机制有很多其他名字比如：预测回滚（prediction and rollback），或者时间曲力（time warp），名字取的天花乱坠的，很多文章也只是云里雾里说一半天，结果还没说清楚，所以本文打算最简短的句子说清楚这个概念，并给出可以实际操作的实现步骤。
我觉得用 Run-Ahead 这个质朴的名字更容易说明这个算法背后的思想：提前运行，这个概念不光用在游戏同步里，也早已用在游戏模拟器中，为了便于理解，先说一下模拟器中的情况（更简单）。
RetroArch 使用 Run-Ahead 隐藏输入延迟，一般需要设置一下 Run-Ahead 的帧数，比如 0 是关闭，1 是提前运行一帧，2 是提前运行两帧，一般设置用 1 或者 2，不要超过 5，因为太高游戏表现会很奇怪：
运行时 RetroArch 为每帧保存快照，假定的是用户输入有持续性，那么运行时当前帧使用上一帧用户的输入作为本帧输入（假设 runahead 设置为 1），然后接着往下运行，如果用户新输入来了，一律把它算作当前帧-1 的输入，然后再去对比历史如果和上一帧所尝试假定的输入一致就继续，否则快照回退到上一帧，重新用新的输入去运行，然后再快进到当前帧。
通常手柄或键盘都有 5ms 左右的输入延迟（部分设备如 switch 的 pro 手柄延迟高达 15ms），再加上操作系统处理的延迟，投递到模拟器进程里，从按下到真正开始处理也许也差不多 1 帧的时间了，RetroArch 用这个功能，也只有用户真实输入和预测输入不一致时才会触发，由于间隔很短，所以即使纠正也难看出来，最终在模拟器上达到了物理设备一样的超低延迟体验。
理解了模拟器的 Run-Ahead 实现，其实在帧同步里的原理也就差不多了，无外乎是用远程的旧输入，搭配本地刚采集到的新输入，作为预测帧的输入值，产生新帧，不匹配了再回滚。
帧同步里引入类似 Run-Ahead 的机制，要求游戏最近所有状态都可以被快速保存、复制和恢复，实现有很多种，你可以用状态的反复前进、后退来实现，但是 BUG 率太高了，这里给出一个更简易的实现方式：
（点击 more 展开）
Read more…
关于游戏同步的话题说的太多了，我是不想再谈了，但是碰到一些含糊和容易引起混淆的地方，必须澄清一下，云风在 2018 年在《lockstep 网络游戏同步方案》中有一段：
首先，我认为把 lockstep 翻译成帧同步，还有与之对应的所谓“状态同步” （我在多次面试中听过这个名词），都是对同步算法的错误理解造成的。把自己所理解的算法牵强附会到已有的在欧美游戏先行者中经过实践的方案上。
最近网易雷火工作室的一篇文章《细谈网络同步在游戏历史中的发展变化》谈到了类似的观点，那么为了避免产生混乱，有必要对 “帧同步”这个说法做一次澄清。
帧同步不是单指某个具体算法，而是范指 “保证每帧（逻辑帧）输入一致” 的一系列算法，传统实现有帧锁定，乐观帧锁定，lockstep，bucket 同步等等，但凡满足“每帧输入一致”的方法皆可以归纳为帧同步类别，至于要不要回滚？服务端要不要跑一套完整逻辑？操作要不要是键盘鼠标？还是高阶命令？客户端要不要像视频播放器一样保证平滑缓存 1-2 帧？或者要不要保证平滑加一层显示对象的坐标插值？这些都是具体优化手段。
我在 2009 年公司应届生培训的《服务端开发培训》课程内，最早开始做同步技术培训：
这个 “帧间同步”喊着喊着就被喊成了“帧同步”，这应届生培训持续了好几年，应该数百人听过这个课程，后面的讲师又接着迭代这个 ppt 接着讲了好几年，听过的应届生们自己摸索后，又写了新的技术分享放到网上，兴许从那时候 “帧同步”和 “状态同步”的说法就流传开了吧。
（点击 Read more 展开）
Read more…
实时动作游戏在近年来得到迅猛的发展。而游戏同步问题，成为大家继续解决的核心问题之一。早在 2004年，国内游戏开发还处于慢节奏 RPG满天飞的情况下，我就开始实时动作游戏研究，分别在 2005-2006期间写了一系列相关文章，被好多网站转载：
帧间同步模式：《帧锁定同步算法》（2007）： https://www.skywind.me/blog/archives/131
玩法规避模式：《网络游戏同步法则》（2005）： https://www.skywind.me/blog/archives/112
预测插值模式：《影子跟随算法》（2007）： https://www.skywind.me/blog/archives/1145
如今十年过去，网上越来越多的人开始讨论游戏同步技术了，然而很多文章往往只针对某种特定的游戏情况，而观点又经常以偏概全。很多人并没有真正开发过实时动作游戏，更别说了解同步技术的前世今生了。转载别人的观点并加上自己理解的人很多，实际动过手的人很少。避免给更多人造成无谓的误导，我今天基于先前的实践和对欧美动作游戏，战网游戏，主机游戏（PSN，XBox Live等）网络技术的了解，来对这个问题做一个简单总结：
网速的变化
开发快速动作游戏，首先要对公网的网络质量数据有详细的了解。这里所说到的网速，是指 RTT，数据往返一周的毫秒时间，而非每秒传送多少 KB/s。我写这篇文章是基于我 2005-2006年开发的东西来说的，当时国内公网质量比国外差很多：
上图为 2005-2006年国内的网络环境，某三个省级 IDC的情况采样。当时公网 RTT平均值基本在100ms，120ms左右徘徊。所以我文中引用了很多 100ms。这个情况在2009 年以后已经好了很多（60ms的rtt）。到了2012年以后，公网平均 RTT已经降低到平均 40ms-50ms，省内平均10ms以内了：
上图为 2015年某省级 IDC的全国延迟情况，如若全国多布点以及区别电信联通的话，平均延迟能控制在20ms以内，延迟基本接近国外水平（当然带宽还差很多），比我当年文章中提到的网络情况好了不少。
Read more…
算法简述
动作类游戏如何在高延迟下实现同步？不同的客户端网络情况，如何实现延迟补偿？十年前开始关注该问题，转眼十年已过，看到大家还在问这类问题，旧文一篇，略作补充（关于游戏同步相关问题还可以见我写于2005年的另外两篇文章，帧锁定算法 和 网游同步法则）：
影子跟随算法由普通DR（dead reckoning）算法发展而来，我将其称为“影子跟随”意再表示算法同步策略的主要思想：
1． 屏幕上现实的实体（entity）只是不停的追逐它的“影子”（shadow）。
2． 服务器向各客户端发送各个影子的状态改变（坐标，方向，速度，时间）。
3． 各个客户端收到以后按照当前重新插值修正影子状态。
4． 影子状态是跳变的，但实体追赶影子是连续的，故整个过程是平滑的。
图1 算法演示
前面的1号终端控制红色飞船P1向左飞，并把自己的状态时时告诉服务器
后面的2号终端上接收到飞船P1的影子S1的状态（向左移动），并让P1的实体追赶S1
网络性能指标一：带宽，限制了实时游戏的人数容量
网络性能指标二：延时，决定了实时游戏的最低反应时间
使用该算法可以容易的开发出一款马里奥赛车，或者Counter Strike，详细说明见后：
Read more…
帧锁定算法解决游戏同步
早期 RTS，XBOX360 LIVE游戏常用同步策略是什么？格斗游戏多人联机如何保证流畅性和一致性？如何才能像单机游戏一样编写网游？敬请观看《帧锁定同步算法》
《帧锁定同步算法》转载请注明出处：https://www.skywind.me/blog/archives/131
Read more…
网路的硬件也有限，而人的创造也无限，在公网平均130ms的Latency下，是不存在“完全的”的同步情况。如何通过消除/隐藏延时，将用户带入快速的交互式实时游戏中，体验完美的互动娱乐呢？
以下六点，将助你分清楚哪些我们可以努力，哪些我们不值得努力，弄明白实时游戏中同步问题关键之所在，巧妙的化解与规避游戏，最终在适合普遍用户网络环境中(200ms)，实现实时快速互动游戏：
Read more…
Recent Comments