美高梅娱乐mgm2399 6

美高梅娱乐mgm2399:帧同步游戏的设计,实时动作游戏同步方式和传输协议选择

  也有使用
UDP的端游,客户端每秒钟上传50次键盘信息到服务端,丢了就丢了,后面持续发送过来的键盘数据会覆盖前面的数据,所以丢了没关系,更快捷。当然,UDP也不是必须的,近两年网速提高很快,省内都能做到10ms的
RTT 了,跨省也就 50ms的rtt,不少页游上用该方法上裸的 TCP
照样跑的很顺畅。

后话

美高梅娱乐mgm2399:帧同步游戏的设计,实时动作游戏同步方式和传输协议选择。对于开发人员来说,优化协议和同步算法是在已有网络环境下提升用户体验的可用方法,也是较平民化的方法,在网络抖动有限、丢包并不频繁、网络环境不至于太差的情况下,的确能有效提高游戏体验;然而这种方法也存在局限性,在网络环境超出可控范围,如在地铁上、商场里等人潮拥挤、存在网络热点,延迟或丢包率极高的环境中,还是无法解决问题,所谓“巧妇难为无米之炊”,再牛X的协议和算法,也无法点石成金,要从根本上解决问题,最终还是要回到网络质量上。和平民化方法相比,改变网络质量需要在资源和底层调度策略上的积累,如何优化遍布全国各地乃至全球各地的玩家网络接入点到服务器端的网络链路?如何优化玩家客户端最后一公里即客户端到无线基站的接入QoS
(Quality of
Service)?这种方法可以称之为高富帅方法,而有这种大规模需求,又能采用这种方法的,放眼望去,恐怕只能看到一家公司了:腾讯。好消息是,腾讯已经将这种能力在腾讯云开放了,称之为:智营网优。现在申请,免费试用!

想了解更多有关游戏加速方案和案例,立即报名1月19日腾讯云GAME-TECH沙龙杭州站,我们一起探讨:

直播链接:

TCP还是UDP,这是一个问题

保证了逻辑运算的一致性以及逻辑帧的平滑加速,基本上可以动手把一个单机游戏改成多人联机游戏了,在局域网运行勉强还能接受,可惜,我们做的是互联网上的游戏。接下来了解一下移动网络的延迟情况。首先是TCP,保证了包序,丢包自动重传,看起来就是我们想要的拼图,并且已经有人帮我们实现了,而且还帮老板省了一大笔钱。诚然,可靠的传输协议非常诱人,并且也有不少成功的例子,且再权衡下缺点再做决定。TCP是基于重传来保证可靠性,如果IP包丢包,TCP协议需要等待至少2个往返时延才会重新发送这个数据包,丢包严重甚至会断线,一旦断线,则触发断线重连流程。看看下面一组数据。

美高梅娱乐mgm2399 1

Paste_Image.png

这是腾讯一款以忍者格斗为题材的ACT手游给出来的数据,可以看到在各种网络情形下,UDP的表现(延迟分布)基本上都优于TCP。

那么到UDP,非面向连接的传输协议,没有自动重传,没有拥塞控制,不能保证包序,甚至不能保证可到达,只保证了数据报完整的基础特性。优点是延迟小、数据传输效率高、资源开销小,如果用来作为网络游戏的传输方案,需要在应用层定制更多适用于网游的特性。在UDP基础上定制一个应用层的协议,难度比较大。基于UDP也有一个通用的解决方案UDT,保证了可靠性和包序,但是跟TCP类似的,UDT也是基于超时重传的方式保证可靠。下面我想把一些专用定制的方案拿出来讨论。

首先,帧同步需要每帧广播数据,广播的频率非常高,这要求每次广播的数据要足够小,最好每个网络帧在一个MTU以下,这样可以避免在IP层分片,降低延迟,互联网的MTU标准为576字节,有效载荷长度控制在(576-8-20)548字节以内。为了尽量避免重传,游戏里面可以用冗余的方式——每个帧数据包实际包含了过去2帧的数据,也就是每次发3帧的数据来对抗丢包。三个包里面只要有一个包没丢,就不影响游戏。另外,定制的方案还需要有一个请求“下载”丢失帧的特性,以防止连续3个包全丢的情况。对于“下载”特性,则可以考虑使用TCP。这是全冗余的做法,缺点是会导致流量增加2倍。还有一种动态冗余算法,根据客户端的丢包状况动态调整冗余倍数,上面介绍的那款ACT游戏就是用了这种方法,本质上还是用流量换速度。

接发包速率对一款PVP竞技型的商业游戏来说至关重要,目前还只是学习到皮毛,以后深入了解后再补充。除此之外,后续还需要服务器介入,解决断线重连和反作弊等问题,先写到这里。

  这类算法由于位置判定更为精确,所以计算量大,很多没法服务端判断,而是客户端直接判断,比如
FPS射击是否打到别人,客户端先判断,除了狙击这种一枪毙命的射击外基本都是客户端判断的。由于计算更为复杂,每秒同步发包差不多到
30个以上,这样的模式下,每局游戏的人数也不可能很多,一般16人左右。而且很多才用
P2P的方式运行,具体 FPS游戏的实现,及 DR算法的代码编写,见
“影子跟随算法”这篇文章。

MOBA类和“吃鸡”游戏为什么对网络延迟要求高?

我们知道,不同类型的游戏因为玩法、竞技程度不一样,采用的同步算法不一样,对网络延迟的要求也不一样。例如,MOBA类游戏多使用帧同步为主要同步算法,竞技性也较高,无论从流畅性,还是从公平性要求来说,对响应延迟的要求都最高,根据业内经验,当客户端与服务器的网络延迟超过150ms时,会开始出现卡顿,当延迟超过250ms时,会对玩家操作造成较大影响,游戏无法公平进行。类似地,“吃鸡”游戏(如《绝地求生》)玩法对玩家坐标、动作的同步要求极高,延迟稍大导致的数据不一致对体验都会造成较大影响,其实时性要求接近MOBA类游戏。而对于传统mmorpg来说,多采用状态同步算法,以属性养成和装备获取为关注点,也有一定竞技性,出于对游戏流畅性的要求,对延迟也有一定要求,同步算法的优化程度不一样,这一要求也不一样,一般情况下为保证游戏正常进行,需要响应延迟保持在300ms以下。相比之下,对于炉石传说、斗地主、梦幻西游等回合制游戏来说,同时只有一个玩家在操作双方数据,无数据竞争,且时间粒度较粗,甚至可通过特效掩盖延迟,因此对网络延迟的要求不高,即便延迟达到500ms~1000ms,游戏也能正常进行。这里,我们不对同步算法做进一步说明,重点说一下协议的问题。

美高梅娱乐mgm2399:帧同步游戏的设计,实时动作游戏同步方式和传输协议选择。从单机游戏到网络游戏

单机游戏,这里指即时的动作类游戏,玩家输入操作,通过终端运算而进行的游戏。加入了多人网络以后,玩家的输入不仅仅只是在本地的终端上运算,还会通过网络同步,使多人可以在同一个虚拟环境中同时游戏。由此,网络多人快节奏的动作游戏带来了新的问题:一致性响应性美高梅娱乐mgm2399:帧同步游戏的设计,实时动作游戏同步方式和传输协议选择。,带宽延迟。网络游戏的实时PVP就是为了平衡这四点的要素。

  预测插值模式:《影子跟随算法》(2007):

美高梅娱乐mgm2399:帧同步游戏的设计,实时动作游戏同步方式和传输协议选择。加速方案

基于udp定制传输层协议,引入顺序性和适当程度或者可调节程度的可靠性,修改流控算法。适当放弃重传,如:设置最大重传次数,即使重传失败,也不需要重新建立连接。比较知名的tcp加速开源方案有:quic、enet、kcp、udt。其中,quic是源自google的tcp替代方案,其主要目的是为了整合TCP协议的可靠性和udp协议的速度和效率,其主要特性包括:避免前序包阻塞、减少数据包、向前纠错、会话重启和并行下载等,然而QUIC对标的是TCP+TLS+SPDY,相比其他方案更重,目前国内用于网络游戏较少。kcp的作者是国内优秀开发者,社区也发展良好,kcp的作者和社区开发者对enet、kcp、udt做了性能测试,详情可参见:,
从测试情况可以看到,kcp表现不错,其次是enet,表现最差的是udt。不过,这里也提出一个问题,原始enet保留了tcp重传的指数避让特性,每次重传间隔还是乘以2,默认rto也较高,这可能是测试中enet表现不如kcp的主要原因,如果对enet代码稍作调整,结果又当如何?这里,我们先排除传输性能,从其他方面对enet和kcp做一对比(满分5分):

 

美高梅娱乐mgm2399 2

我们对libenet略微做一些调整——默认rtt从500ms调整成50ms,
去除超时重传的指数避让策略。Linux下用TC命令模拟网络延迟和丢包率,控制延迟分别为30ms,
50ms, 70ms,控制丢包率分别为1%, 3%, 5%, 7%,
10%,在模拟出的不同网络环境下,对tcp,
原始enet和改进后的enet进行了对比测试。

测试中考察两个性能指标:

1)平均响应时间;

2)响应时间超过300ms的包的比例。

libenet的代码调整:

美高梅娱乐mgm2399 3

图 1 调整默认RTT为50ms

美高梅娱乐mgm2399 4

图 2 取消指数避让

tc命令如下:

模拟延迟100ms(rtt为200ms): tc qdisc add dev eth0 root netem delay 100ms

模拟1%丢包率:tc qdisc add dev eth0 root netem loss 1%

对比结果数据如下:

 

美高梅娱乐mgm2399 5

图 3 不同丢包率和网络延迟下TCP协议、ENET、优化后ENET的平均响应时间对比

 

美高梅娱乐mgm2399 6

图 4 不同丢包率和网络延迟下TCP协议、ENET、优化后ENET的超时响应比例对比

从图中可见,在平均响应方面,TCP协议的劣势不明显,在延迟为30ms,丢包率为1%时,改进后的ENET平均RTT为69ms,
原始ENET平均RTT为67ms,
TCP平均RTT为67ms;但是从响应时间超过300ms的比例看,在延迟为30ms,丢包率为1%时,改进后的ENET
RTT超过300ms的包为0,而TCP
RTT超过300ms的比例则超过了2%,如果是在游戏中,这个表现已经能明显影响游戏体验了。结果表明,TCP在网络稍不稳定的情况下就已经有比较大的问题了,改进后的ENET有明显优势。

帧同步的原理

了解帧同步技术,不妨可以参考下DOOM/QUAKE I/II/III
网络模型的演化,约翰·卡马克为FPS的网络同步写下了原型,后面的版本又在这基础上做出了众多改良版本。

帧同步技术最重要的基础概念:
相同的输入+相同的时机=相同的显示
意思是每个客户端接受的输入是相同的,执行的逻辑帧也是一样的,那么结果也是同步一致的。为了跟每个机器执行的快慢无关,每个逻辑帧为固定帧数固定时长,游戏当中的实体都是按照这种设定运算,因此移动、碰撞等都能算出相同的结果。而渲染帧(一般为30到60帧),则是根据逻辑帧(10到20帧)去插值,得到一个“平滑”的展示。逻辑帧实际是是由一个个定时下发的“网络帧”来驱动,而渲染帧则由本地CPU的update驱动,渲染帧只是逻辑帧无限逼近(插值),如果逻辑帧突然中断,则游戏就会卡在那一帧状态,这就是lockstep的由来。

为了保证游戏同步执行的一致性,代码必须按照lockstep的方式组织运算,不依赖本地客户端的帧率,时间或者随机数。理想状态下,每个“网络帧”被及时接收,客户端渲染帧都能满帧运算,游戏就像播放电影一样。但在网络游戏中,各个客户端的硬件和网络情况都不一样,可能会导致客户端收到“过去时间”里的一堆网络帧,因此,必须要有处理这些堆积起来的网络数据的能力。最简单的做法是加速播放(快进),根据堆积的量计算出加速比率,以此快速地执行逻辑帧,尽快地追上最新的实时帧。同时,在加速的过程中,可以考虑丢弃用户的操作,因为玩家看到的是“过去”的状态,此时进行控制打击是没有意义的。另外一种处理方式是,直接运算直至追上最新的网络帧,这样会直接闪现到“最新”的状态,玩家可以马上操作。比较建议采用快进的手段,这种方式可以让玩家感受到相对自然的游戏画面。这一基础特性也用于支持后面的断线重连。

  开发快速动作游戏,首先要对公网的网络质量数据有详细的了解。这里所说到的网速,是指
RTT,数据往返一周的毫秒时间,而非每秒传送多少 KB/s。我写这篇文章是基于我
2005-2006年开发的东西来说的,当时国内公网质量比国外差很多:

相关阅读

「腾讯云游戏开发者技术沙龙」1月19日杭州站报名开启啦~畅谈游戏加速

经典游戏服务器端架构概述
(1)

阻击外挂:《龙之谷手游》安全测试的那点事


此文已由作者授权云加社区发布,转载请注明原文出处

帧同步的引入

帧同步应该是引入多人网络以后,能想到最直接
的同步方式,在理想状态下,是合适的解决方案。而现实是,帧同步需要发送大量的帧数据来驱动游戏逻辑,需要客户端能在一段时间保持网络稳定(低延迟,少量的网络抖动)。此外,还有状态同步技术,帧同步是把玩家的动作直接同步到其他玩家的终端上,通过确定性的运算达到同步效果,而状态同步是所有客户端的动作发送到服务器,由服务器计算并把最终状态广播下发。网上有大量的资料对这两种技术进行对比,下面只对帧同步的技术做讲述。

  结果同步往往比较简单,位置即使全部错乱或者延迟很久都没有关系,因为游戏过程完全不在乎位置,只在乎最后的结果,比如《梦幻西游》这样的“回合制
RPG”
游戏,屏幕上的人走到哪里确实无所谓,所有操作都是要点击或者选择菜单来下命令,象这样的游戏背后其实是文字游戏,只是加了一个图形的壳。

总结

测试结果符合预期,在实时性方面,TCP协议的网络抗性欠佳,对MOBA类或其他实时性要求较高的游戏,我们不建议使用TCP作为协议载体。事实上,王者荣耀,乱斗西游的通信协议也确实是基于UDP封装的,别问我是怎么知道的。

帧同步的响应性

对于实时PVP的游戏来说,手感流畅的角色控制体验很重要。玩家的输入往往在几十分之一秒内,就开始显示变化,而在帧同步中,玩家的输入发送到网络,下一个网络帧操作回来时尽快处理并显示
,当网络不稳定时,常常会时快时慢,非常难以预测输入动作后,角色会在什么时候起反应。要解决这个问题,可以参考下传输语音业务的做法,在接收网络数据时,不立刻处理,而是给所有的操作增加一个固定的延迟,在延迟的时间内尽可能收集更多的网络包,然后按固定的时间去播放(运算)。这种做法相当于建立了一个网络缓冲区,平滑了因为网络抖动而时快时慢的数据包。这里添加的固定延迟可以按照玩家所在的网络延迟来设置,可以动态地取一个连续平稳(避免抖动)的值,可以使用累计或抽样的加权平均来获取延迟。玩家发出的操作只要在固定延迟内接收,游戏就可以流畅运行,网络的抖动已经被间隔相等的逻辑帧抹平了。

  网速的变化

传输层协议和延迟

不同传输层协议在可靠性、流量控制等方面都有差别,而这些技术细节会对延迟造成影响。tcp追求的是完全可靠性和顺序性,丢包后会持续重传直至该包被确认,否则后续包也不会被上层接收,且重传采用指数避让策略,决定重传时间间隔的RTO(retransmission
timeout)不可控制,linux内核实现中最低值为200ms,这样的机制会导致丢包率短暂升高的情况下应用层消息响应延迟急剧提高,并不适合实时性高、网络环境复杂的游戏。

  其实状态同步是一种乐观的同步方法,认为大家屏幕上的东西不同没关系,只要每次操作的结果相同即可,不需要象“帧间同步”那样保证每帧都一样,因此,对网速的要求也没有
“帧间同步”系列算法那么苛刻,一般100ms-200ms都是能够接受的(DiabloIII里面300ms的延迟照样打),偶尔网络抖一下,出现1秒的延迟,也能掩盖过去。然而比起
“帧间同步”,状态同步方式对玩法有不少要求,诸如
“一次性”,“决定性”的事件要少很多,而且代码编写会复杂一些,不果由于能容忍更坏的网络情况,以及容纳更多同时游戏的人数,在一些玩法确定的游戏中(RPG,FPS,赛车),被广泛使用。

作者:腾讯云游戏行业资深架构师 余国良

  当然,等到你的游戏发布出去了,开始挣钱了,你想改进你的游戏效果,特别是高峰期的卡顿比例(需要收集客户端统计),那么你可以使用
UDP来改进,《街霸4》和《英雄联盟》都是使用 UDP的,比如你可以使用
libenet(英雄联盟用的)。不过 libenet所采用的传输技术,是上世纪的标准
ARQ做法了,《街霸4》所采用的传输技术远远高过
libenet,如果你想采用更为现代的传输技术,赢得更低延迟的话,可以使用我的“快速传输协议-KCP”(),被再若干上线项目和开源项目使用的协议,效果远远
PK libenet。

欢迎大家前往云加社区,获取更多腾讯海量技术实践干货哦~

  2012年,Sony推出
Playstation Now技术,可以在 PSV和
PS3/PS4上玩云游戏,玩家不需要购买游戏就可以免费体验一定时间。使得
PSV/PS3等低端硬件也可以流畅的跑 PS4游戏。

  关于帧间同步的“帧锁定算法”系列的方法有很多类似实现(包括后面提到的帧间无等待改进,包括
LockStep等),但是他们的核心都是一个:保证所有客户端每帧的输入都一样。这样的方式被格斗游戏,RTS和足球(FIFA类)、篮球(NBA)等体育和动作游戏大量使用,比如我们熟悉的各大战网平台游戏(Xbox
Live等),还有很多基于模拟器的街机对战平台。以及不少大型多人横版动作游戏。以开发便利,同步逻辑直观而受到大家欢迎。

  帧锁定算法多用在
C/S模型中(或者一人做主多人做从的P2P里),它和
LockStep(多用于P2P)共同存在的问题就是
“网速慢的玩家会卡到网速快的玩家”,老式游戏经常一个角色断网,所有人就在那里等待。为此出现了帧锁定的改良版本
“乐观帧锁定”(具体描述见帧锁定文章的下半部分)经过了不少游戏的实践检验。先前还有几款上线的横版格斗页游(如熟知的街机三国)用
Flash 的 TCP without NODELAY
来每秒20个关键帧的模式(特意找该游戏开发者确认了一下)跑该算法(由于近两年国内网速提高,Flash的
Tcp without NODELAY也能做很多事情了),效果还不错。

美高梅娱乐mgm2399 7

  中国的网络情况比较特殊,会存在有些网络
UDP连接不上的情况,因此都是先连接 TCP,然后试图
UDP,UDP不通的情况下,退回 TCP也能正常游戏,一旦 TCP断开,则认为
UDP也断开了。

  根据游戏类型,选择恰当的同步方式和传输协议是最基础的问题,很多讲述网络同步的文章一般就是只会强调上述那么多种算法的其中一种方式,好像使用该方式就可以
hold住所有游戏一样的,其实并非如此。技术需要多和策划沟通,别策划一个需求下来,技术就来一句:无法实现,这样的游戏永远没有竞争力。就像国内当时都是慢节奏
RPG,偶尔有点
ARPG的时候,大家觉得《DNF》这样的游戏无法实现,于是韩国实现了,在市场上取得了先机,国内才慢慢跟进,再一看,哇塞,好多坑呢。

  通常
RPG攻击分为“有锁定攻击”和“无锁定攻击”,有锁定攻击意思是,我朝你发射火球,不管你怎么跑,火球都会追踪并射击到你,比如你在我面前横着跑过,我向你发射火球,可以发现火球并不是直线飞行,而是曲线追踪着你就过去了,这叫有锁定攻击。无锁定攻击一般是范围攻击,先播放个动画(比如挥刀),然后将攻击请求提交服务器,服务器结果回来时,动画刚好播放完毕,然后大家一起减血。

  实时动作游戏在近年来得到迅猛的发展。而游戏同步问题,成为大家继续解决的核心问题之一。早在
2004年,国内游戏开发还处于慢节奏
RPG满天飞的情况下,我就开始实时动作游戏研究。分别在
2005-2006期间写了一系列相关文章,被好多网站转载:

相关文章