标签归档:doom3

DOOM3网络同步体系

概述

由于doom3是开源的,另外网页上有大量研究doom3的文章,所以分析起来难度比较小,值得注意的是Valve公司旗下的source引擎的基础也是类似这套体系,所以也可以从中得到不少东西,包括他在source sdk上的一些介绍文章,目前的文章还在草稿期,比较乱,后期我再进行整理。

简单的一句话介绍doom3的网络体系就是基于客户端预测及快照的网络同步方式c/s网络拓扑结构udp作为底层网络协议

基本代码分析

相关文件
AsyncClient.*
AsyncServer.*
AsyncNetwork.*
每帧逻辑位于Common::RunFrame
如果是多人游戏,则代码走
idAsyncNetwork::RunFrame();
if (idAsyncNetwork::isActive()) {
     session->GuiFrameEvents();
     session->UpdateScreen(false);
}
单机游戏的话 ,代码走
session->Frame(); // 最终也是调用Game::RunFrame
session->UpdateScreen(false)
idAsyncNetwork::RunFrame()代码中,如果是服务端,则走AsyncServer::RunFrame逻辑,如果是客户端则走AsyncClient::RunFrame()逻辑
AsyncServer::RunFrame最终调用的逻辑是执行Game::RunFrame,另外在代码最后发送了当前的系统快照。系统快照的发送时间限制了最大比特率为 16000 bytes / s 即大概16k每秒,如果上次发送时间与本次发送时间超过了1秒或者小于每秒的比特率,则发送快照及本帧的指令信息(注意这里的指令信息会额外多发送之前的一些指令,因为udp不可靠,另外如果进行重发及验证,还不如每次都额外多发一些)。
AsyncClient::RunFrame的逻辑最重要的是客户端预测的逻辑,客户端预测的在本玩家PVS下的所有实体(玩家,怪物,投射物灯),不仅仅是本地玩家,另外预测是有一个最大预测时长的,默认的预测时间为c->s的延迟时间,预测的本地玩家直接使用的就是当前的操作指令,而其他玩家,使用的是之前的指令,这样的话本地玩家是完全没有延迟反应的。
关于客户端预测的细节,客户端预测的初始值是往返的响应时间,假设为100ms,首次执行的时候,ClientPredictTIme为100ms,gameTimeResidual为16.67ms,假设客户端机器性能非常好,没有任何掉帧,则本次RunFrame会一次性执行 (100 + 16.67) / 16.67 次模拟,及玩家位置会在这帧内多次执行到7帧后的位置(即客户端预测服务端收到包并返回给自己时 ,自己应该处于的位置) ,
下一帧,如果还是没有收到服务器返回,则本次只执行一次,而非多次,因为由于上一帧的预测影响,导致gameTimeResidual已经是负数了。所以本次只累加了16.67ms。
由于出现延迟的下一帧就会移动预测到延迟时间后的游戏时间,之后每帧实际上都也是步进一次,所以实际上并不会出现预测自己的情况出现,只有在第一次会出现一次跳跃。
注意,客户端预测不仅仅是基于之前指令进行计算,同时也发送了本机之后的指令给服务端,否则服务端会一直接受不到最新的指令,毕竟两者之间是有延迟存在的。

攻击相关的本机预测

查看Weapon::Event_LaunchProjectiles可知,目前联机的时候,甚至连投射物都没有做预测播放,投射物的产生以服务端的快照为准,由于doom3是fps游戏,所以攻击流程为player::Weapon_Combat -> weapon::BeginAttack(); ->weapon脚本调用Event_LaunchProjectiles状态,注意整个过程中,人物,武器的动画状态都是预测的,即立即显示出开火的相关状态,但是伤害的投射物及最终伤害都未预测
投射物由服务端快照创建,当投射物遇到障碍物时,预测爆破及特效。
最终的伤害及效果都有player::readFromSnapshot处理,比如当前血量比原来血量少,则播放受击动画,反馈等,如果死亡,则播放死亡。

关于指令及快照的发送及接收

玩家指令,还有快照信息都是通过不可靠的消息传递的
指令包是不管是否有无收到的,默认doom会复制之前的5条指令,因为就算你保证发送成功了,服务端时间也未必恰好用你发的指令进行计算。当有延迟的情况出现时,延迟的客户端会体验发送预测延迟时间内的指令,为了后期恰好给服务端使用。
服务端的指令包及snapshot也不是保证一定收到的,反正如果没收到,收到最新的时候都会从lastsnapshot从头开始计算
所以在doom中不会出现等待的情况,只会回拉

关于平滑拉扯

由于客户端预测的存在,另外客户端并不会等待服务端指令,服务端也不会等待客户端指令,所以整个客户端及服务端都是异步的,这样肯定会出现不一致的情况,这种情况的处理需要做一些平滑,否则感受会比较差,doom3是这么做平滑的。
其他玩家的渲染位置与当前真实渲染位置是会做平滑的,即当前逻辑位置虽然是直接拉到了理想的服务器位置,但是渲染位置用了smooth做了慢慢平滑
代码在 idPlayer::GetPhysicsToVisualTransform
及 idPlayer::ClientPredictionThink均有涉及,这里的平滑只涉及到了其他玩家。
注意渲染位置并不会立即改变,只会每帧改变一次(smoothedOriginUpdated),免得出现位置跳跃。
因为玩家本身的指令应该与服务端的指令几乎是完全一致的,不应该出现偏差,仅当服务端没有收到指令包(因为这里是UDP)超过两次时,才会进行一次平滑到真实位置(因为udp并不可靠)。
另外还有一个平滑是关于玩家的视角,即玩家的那个晃动视角
其他玩家的攻击指令没有做预测

真实主客机的测试

主机无延迟
客机有200ms单向延迟,400ms往返延迟
现象为
在客机屏幕,由于有400ms延迟及客户端预测的存在,所以主机的玩家一旦移动就会出现尽量同步到400ms后的位置,所以一旦开始移动就有个快速拉扯,停止的时候也会回拉。
在主机屏幕,由于延迟为0,所以客户端移动虽然有延迟,但是不会出现加速及回拉的情况。
比较出乎我意料的是,在客机屏幕的客户端预测,居然不会影响到本地玩家,我一直以为本地玩家也会有快速拉扯,实际上完全没有。不管在主机还是客机屏幕,本地玩家的行为都完全正常。
与之前的代码分析完全一致。

使用该做法的游戏

http://dev.dota2.com/showthread.php?t=527&page=7&p=4253&viewfull=1#post4253

dota2这篇论坛上的资料透露, Counterstrike, Left 4 Dead, Team Fortress 2等游戏都采用了该技术,而dota2在此技术的基础上,去掉了客户端预测,减少了拉扯现象,不过玩家的控制信息得不到立即反馈,该文章也是为了解答玩家关于控制延迟的疑问。