| 小熊毛毛 |
2008-08-11 00:40 |
|
这个神奇新技术被叫做“0网延技术”，它对于整个网络联机游戏有非同小可的意义（街机杀手）。本来网延是联网格斗的杀手，要想解决只有通过改善全国网络大环境的方法。（但这在短期内根本不可能实现），他的出现无异于黑暗中的一盏明灯，照亮了我们前进的方向。
但由于相关作者没有公布源代码以及实现方法，我们不知道这个技术是实现方法。所以我昨天使用了NFBA后在想它是如何实现的。下面谈谈我的想法：
以前的kaillera客户端是这样的：你在这一帧（“局域网”的话每秒60帧，“非常好”的话每秒30帧）按了一个键，然后马上发出去，等待对方接受，对方接受后再返回一个数据，之后你的模拟器才执行你刚才按的键。每帧都发，也每帧都收，如果收发中途慢了，那么模拟器就会用停止工作的方法来等待对方的回应。如果网络延迟有200PING的话，那么你按了一个键几乎要等半秒才有效果。
问题是如果这个角色有一招出招是很快，那等你看见了再防御是根本防不了的。只有靠预测对手会出什么招，自己是该上防还是下防还是跳起。这样连招派会非常吃的开，因为只需要背一个出招很快的多项选择套路就够了，压死对手，让他猜选择题，而这些选择题，猜对的几率是很小的。
我想要想解决网延带来的防御问题，只有把客户端判定“本地化”不再用暂停等待对方的回应。再外加2个技术，一个是“游戏变化加速”，另一个是“变化多帧发送”才可以解决。也就是说，用加速和用多帧发送来抵消原来的暂停等待时间。
客户端判定“本地化"：原来是按了键，0.5秒才有用。现在是立即执行，不再等待对方的同步。
游戏变化加速：原来每秒固定60帧或30帧(不够的就等待对方)，现在每秒的帧是变化的，比如每秒68帧，而帧是根据网延技术出来的，用来抵消等待时间，做到游戏不停顿。
变化多帧发送：原来每秒固定60帧或30帧，就每秒发60次或30次的操作指令，每次只发一帧的操作指令。现在每次发送的多少帧的操作指令，是变化的，有可能，这次发1帧，下次发2帧，下次发5帧。也就是说，如果有网络延时那就有积压，本来该送到的没送到，退回来了，那就下次一起再给他发过去。
综合起来就是，与原来的同步等待方式不同，新的方式不讲求同步，而是各顾各的，大家管的只是收发数据。每个玩家电脑里跳帧的地方跟对方不同，如果自己跟不上节拍那就一次多收对方几帧操作指令，然后游戏加速运算，把“掉队”的时间追回来。通过双方不停变化加速和多帧发送来让两方的游戏最终保持一样的运算结果。
说了半天只是我个人的推测，没有经过详细证明。但有3点是存在的！
1：NFBA的联网会跳帧，那些消失的帧到哪里去了呢？（可能是一定时间内收不到对方操作帧的话，就放弃、跳过了吧）
2：NFNA的FPS会有68这种数字，为什么超过60呢？是计算精确度问题还是……
3：NFBA的录像文件格式非常小，就想ZIP压缩过一样，回放的时候是完全正常的，没有跳帧。但如果你打开“视频》双线过滤方式》DIRECT3D 7”，回放录像会不同步。为什么不同步?，难道改个渲染模式就不同步了？
这个神奇新技术被叫做“0网延技术”，它对于整个网络联机游戏有非同小可的意义（街机杀手）。本来网延是联网格斗的杀手，要想解决只有通过改善全国网络大环境的方法。（但这在短期内根本不可能实现），他的出现无异于黑暗中的一盏明灯，照亮了我们前进的方向。
但由于相关作者没有公布源代码以及实现方法，我们不知道这个技术是实现方法。所以我昨天使用了NFBA后在想它是如何实现的。下面谈谈我的想法：
以前的kaillera客户端是这样的：你在这一帧（“局域网”的话每秒60帧，“非常好”的话每秒30帧）按了一个键，然后马上发出去，等待对方接受，对方接受后再返回一个数据，之后你的模拟器才执行你刚才按的键。每帧都发，也每帧都收，如果收发中途慢了，那么模拟器就会用停止工作的方法来等待对方的回应。如果网络延迟有200PING的话，那么你按了一个键几乎要等半秒才有效果。
问题是如果这个角色有一招出招是很快，那等你看见了再防御是根本防不了的。只有靠预测对手会出什么招，自己是该上防还是下防还是跳起。这样连招派会非常吃的开，因为只需要背一个出招很快的多项选择套路就够了，压死对手，让他猜选择题，而这些选择题，猜对的几率是很小的。
我想要想解决网延带来的防御问题，只有把客户端判定“本地化”不再用暂停等待对方的回应。再外加2个技术，一个是“游戏变化加速”，另一个是“变化多帧发送”才可以解决。也就是说，用加速和用多帧发送来抵消原来的暂停等待时间。
客户端判定“本地化"：原来是按了键，0.5秒才有用。现在是立即执行，不再等待对方的同步。
游戏变化加速：原来每秒固定60帧或30帧(不够的就等待对方)，现在每秒的帧是变化的，比如每秒68帧，而帧是根据网延技术出来的，用来抵消等待时间，做到游戏不停顿。
变化多帧发送：原来每秒固定60帧或30帧，就每秒发60次或30次的操作指令，每次只发一帧的操作指令。现在每次发送的多少帧的操作指令，是变化的，有可能，这次发1帧，下次发2帧，下次发5帧。也就是说，如果有网络延时那就有积压，本来该送到的没送到，退回来了，那就下次一起再给他发过去。
综合起来就是，与原来的同步等待方式不同，新的方式不讲求同步，而是各顾各的，大家管的只是收发数据。每个玩家电脑里跳帧的地方跟对方不同，如果自己跟不上节拍那就一次多收对方几帧操作指令，然后游戏加速运算，把“掉队”的时间追回来。通过双方不停变化加速和多帧发送来让两方的游戏最终保持一样的运算结果。
说了半天只是我个人的推测，没有经过详细证明。但有3点是存在的！
1：NFBA的联网会跳帧，那些消失的帧到哪里去了呢？（可能是一定时间内收不到对方操作帧的话，就放弃、跳过了吧）
2：NFNA的FPS会有68这种数字，为什么超过60呢？是计算精确度问题还是……
3：NFBA的录像文件格式非常小，就想ZIP压缩过一样，回放的时候是完全正常的，没有跳帧。但如果你打开“视频》双线过滤方式》DIRECT3D 7”，回放录像会不同步。为什么不同步?，难道改个渲染模式就不同步了？
关于NFBA延迟补偿技术的实现原理，昨天晚上想的一下，结合推荐配置要求中提到的10倍于原FBA的CPU（占用率）与内存要求和作者介绍视频中提到的预测，基本上能确定延迟补偿技术和零延时的实现原理了！
类似之前猜想的双层进度（开台能看见的及时的一个、后台类似老模式的真实进度一个），实际上NFBA应该较原画面（前台可见进度）使用了10个以上的模拟进度去演算在前后几帧可能出现的按键组合，前台是以玩家当前操作和对方玩家的最优预测作显示标准的，当后台进度接收到对方真实按键且当前台预测按键错误时，一个调度机制会告诉前台从10个推算进度中恢复哪个进度作为前台画面的标准，以准保画面同步的正确性和玩家要求的按键立即反应到屏幕！
这在极个别本来“中招了”突然变成“没中招”的情况中，可以看出来（该调度系统的运作）
随着电脑配置的加强，越来越多的预测协调机制会使以前认为不可能的事情变为可行。或许不久的将来，我们就能玩到以这样高分支推演的技术开发网游，甚至让使要求眼（反应）到手（行动）随时保持0.2秒以内、1/60秒“帧技”的真格斗网游能在网络上绽放异彩……
|
|