39手游网

帧同步:浮点精度测试

来源:39手游网 浏览次数:234

最早接触帧同步的概念是在2005年开发PS游戏高智能方程式赛车3的时候,当时负责赛车游戏的逻辑,物理,AI和录像回放等功能,录像回放就是使用点帧同步实现的。一场比赛只要保存玩家在不同时刻的操作即可,回放的时候就再跑一遍游戏在相同的时间执行相同的操作,得到相同的结果。对于主机游戏来说帧同步实现要简单很多,因为设备唯一,不存在浮点精度的问题,甚至都不需要逻辑层和表现层分离,只要简单的限帧即可。




2015年开发一款3D战斗卡牌游戏的时候又使用了帧同步技术,因为当时服务器只有一个人战斗逻辑在客户端,一开始使用主机模式问题很多,迫不得已临时改成帧同步。因为是中途改的所以实现比较简单,使用FixedUpdate对逻辑限帧,使用TCP,可以说问题还是很多的。但因为1V1的横版游戏,玩家操作频率非常低,战斗也相对简单,有些不同步和延迟也还能接受。当时因为时间紧迫,开发的时候就遇到一个不同步问题解决一个,例如脚本更新顺序,逻辑帧更新等,其实也发现有浮点精度的问题,但因为时间有限只是对一些地方做了截断保护,后续项目又改成状态同步了也没有深究。


后来也了解过同类型游戏刀塔传奇的帧同步,刀塔传奇逻辑使用lua脚本,双精度浮点数double的精度问题比float好很多,另外2D游戏的运算相对3D简单,当时只遇到过一个数学运算有问题做了特殊处理就解决了。



最近在做一款射击类MOBA项目的时候,又采用了帧同步技术(帧同步和状态同步的对比和选择后续做更详细的介绍)。这是一款3D物理的俯视角射击MOBA项目,游戏中大量运用了真3D物理运算,双摇杆射击,最多支持16人战斗。游戏节奏非常快,操作频率非常高,一直会有大量玩家同屏团战,每个角色射速极高每帧有多发子弹,每个子弹都有弹道和物理计算,是一款对性能和延迟要求非常高的游戏。这时候同步就不能有一点问题了,任何一个Error或者运算的不同步就会导致结果的巨大差异,并且非常显而易见,使游戏无法进行,因此浮点精度问题也必须得到彻底解决了。



浮点精度的问题在PC上就有跨平台的问题,因为语言编译器不同使用的寄存器和运算过程中的舍入方式不同。就会导致在不同平台下相同的float运算会出现不同的结果,这方面有很多文章阐述就不多做阐述。而在手机上IOS还好比较单纯,Android设备系统硬件千差万别就更容易出现精度问题了。



首先我做了一些单元测试。



*如上图,通过简单的单元测试函数对各种常规的数学运算做了测试。



测试方法是:


  • 首先在Windows64位电脑上生成浮点型测试数据,然后通过测试函数执行n次运算。
  • 将测试结果的二进制保存到配置文件中。这里需要说明的是因为float是小数点后7位,在编辑中最多可以显示到9位例如1.876777650比较起来不直观。另外也存在多个十进制数据对应一个二进制浮点数的情况,例如在编辑器中看到5.0,保存之后再读取显示可能就是4.9999999,他们两个对应相同的二进制是一样的。为了便于对比,我写了一个简单的函数将各种类型统一转成二进制,保存的时候按二进制写入和读取,输出的时候也对应输出浮点数的二进制表达方式。



*如上图,将各种类型转换成二进制字符串的函数。


  • 在其他各种设备运行测试程序,读取浮点测试数据,执行相同的运算,显示测试数据和运算结果的十进制和二进制结果。
  • 读取Windows64位电脑上的二进制测试结果,和当前运算结果进行比较,如果不同显示Error,并显示双方的二进制结果。


结果如下:




可以发现连简单的x*x+y*y+z*z计算就出现了结果不一致,并且x*x,y*y,z*z和x*x+y*y都是一致的,就是y*y+z*z出现了不一致,猜测可能是不同设备的寄存器使用和舍入方式不同导致的误差,任何一个数学运算都有可能出现。



进一步测试:


  • 进过更细致的测试,我发现Windows,IOS,Android三个平台之间会出现float运算结果不一致的情况,其中Windows设备之间、IOS设备之间是一致的(也可能设备较少),Android平台下即使同一个平台不同机型之间也会有大量运算不一致。并且各种运算都有可能出现,没有规律可言(例如某个只有数学运算不一致)。
  • 此外我又针对Unity的Physx物理引擎做了精度测试,创建一个3D世界,随机分布各种几何体胶囊,球,茶壶,立方体等等,然后从原点位置随机发射1000根射线,再用相同的方式记录和对比结果,最终发现物理运算也出现了不一致的现象!
  • 最后我还让做AI的同事对Unity的寻路系统Navmesh做了测试,生成一张带Navmesh的场景生成10000个测试路径然后保存和对比,这次结果就比较有趣了,让我吃了一惊,结果居然是一致的!



测试结果:


  • 通过测试可以发现在如果逻辑代码中使用float连最基本的数学运算都保证不了,可见逻辑部分是不可能使用float了。
  • 同样物理运算也会有不一致的问题,不能直接使用,但测试结果主要在浮点数位数的误差上。
  • 使用Navmesh没有发现不一致的问题,可能有隐患但应该还是可以使用的。


解决方案:


  • 代码中使用float的问题,我们通过在逻辑层使用定点数取代float来解决。我在刚入行的时候使用过定点数,当时主要是为了解决在手机上浮点数运算非常慢的问题。早期Doom,Quick等都使用过定点数的优化方式,在3D游戏编程大师的书中还提供过一套定点数学库。我的一个同事在此基础上实现了一套基于定点数的数学库,提供和Unity相似的接口,并对一些函数做了查表优化。另一个同事修改了导表工具,使得策划的填表数据也支持定点数,完美解决。后来我们还逆向了另外一款爆款帧同步游戏看了一下,他们也做了特殊处理,使用乘1000的方式来解决,类似我们的顶点数学库但更难使用。





  • 因为大量使用了真实的3D物理,所以物理对我们来说是一道跨不过去的槛。我们尝试过多种解决方案,先是让公司引擎组的同事帮忙修改Unity和PhysX源码发现工作量巨大,然后又尝试修改bullet为定点数替换PhysX,但是修改后的Unity版本性能差了几百倍无法使用。最终迫于时间压力,我们还是采用了有些隐患的做法:只使用Unity最基本的射线和BoxCollider,在此基础上实现了一套简单的定点数物理引擎。但是即使这样还是会出现不一致的问题,我们又加入了尾数截断,按碰撞方向截断等方式保障一致性。最终在几十万把上线测试中还没有发现物理导致的不一致问题。(需要说明的是,如果要使用动态碰撞器,需要修改一下Unity源码,让物理引擎的Update可以再逻辑帧驱动,非常感谢引擎组同事的帮忙。Unity的新版好像提供了这个功能。)
  • Navmesh没有发现问题,我们实际使用也没出现问题,我们只使用了Navmesh的路点。


总结:


Float的一致性问题是帧同步方案的最基本的问题,也是相对比较好解决的问题,在后续开发过程中我们还遇到了无数帧同步的坑和难点,特别是同步和延迟的问题。帧同步是一个上手简单快速的技术,但是对操作频繁对延迟要求极高的大型游戏来说就变的非常难了。



针对同步问题我们还开发了一整套工具,当出现不同步的时第一时间就会上报,同时上传录像和日志到文件服务器,可以较快速的定位问题,统计不同步率。配合敏捷开发每日自动构建,代码Review,每次提交自动编译等,及时发现问题。最近一次上线测试玩家进行了39727次战斗未出现不同步,同步率至少达到王者荣耀的水平。



帧同步的不同步的测试还是比较困难和痛苦的,因为只要有一点没测到导致不同步上线之后可能就有非常大的风险,后续也会开发更强大的自动化测试工具,实现一种愉悦的开发方式!



补充:


  • 针对double类型我也做了测试,不一致性较float大幅下降,但还是会产生不一致问题。
  • PhysX有一个一致性开关,即使打开了,也还是会产生不一致问题。
  • 在延迟上也做了大量优化,逻辑层和表现层完全分离,不使用FixedUpdate的方式降低输出延迟;同时使用了TCP,自己实现的可靠UDP和冗余包的非可靠UDP三种方式通信;极致压缩优化协议包降低在MTU范围以内;逻辑帧负载均衡;分地域部署和匹配;多线程收发等等。延迟数据接近王者荣耀的水平(双摇杆操作更多,服务器部署上延迟略高)。
android好评游戏 IOS好评游戏

更新时间:2019-08-12 22:29
广告合作