|
GameRes游资网授权发布 文/Ron Ngai
场景背景
毫无疑问,策划都喜欢多人同屏战斗。什么万人大地图,这肯定是策划的最爱了。可是对于游戏来说,这并不是什么非常好的设计。即使解决了服务端计算的性能压力,客户端显示的性能压力。万万没想到的是我们游戏在客户端网络带宽上面遇到了压力。
假设1000人同屏,那么要同时同步1000个人的位置,移动方向,速度,释放技能,伤害,血量,buff等信息。这n^2的网络带宽复杂度,对于服务端来说,其实只要申请大些的带宽,买贵点其实就可以解决了。但是对于时常处于不稳定和低网速网络环境(电梯、地铁、偏远山区等环境)下的手机,特别是还处于2g,3g的网络环境下的手机,那么小的带宽承载能力其实根本无法应付这么大的网络消息同步的。造成后果,游戏会有明显的收包卡顿,有些会出现好几秒,出现非常不好的游戏体验。
另外,即使手机可以承受,在当下手机网络流量并没有那么廉价的情况下,如此耗费网络流量,很难的得到玩家的承受。
以上,对于实时同步信息的模式,在大规模多人对战手游中,并不是一种非常合适的方案。
解决预想
问题在于客户端的网络带宽,如果减少客户端接收的网络带宽才是重点。不去同步那么多的信息,那么就需要客户端和服务端尽量约定规则。使用客户端先行,服务端演练计算的方式来实现。貌似业界已经有这种方案了,传闻lol、dota2就是这么实现的(这方便并没进行查阅,只是有个印象)。
到战斗开始的时候,先同步必要的信息,譬如场景内的怪物、位置、AI、血量、技能等信息和一个随机数。AI的行为通过随机触发。那么需要同步的信息就只剩下那些无法确定的因素。譬如玩家,什么时候释放什么技能、如何移动,我们是无法确定的,但只要在外面服务端的演练中同步上,那么同样可以演练出客户端的整个战斗过程出来。
对比可以发现,使用这种方法,我们只需要同步玩家的技能、移动就可以了。省去了很多其它可以直接演练出来的信息。为了避免演练的偏差,可以定期同步一些内容。这样既可以保证战斗的一致性,也大幅度减少了带宽流量。
当然使用这种方式,对客户端和服务端的约定要求非常高,相比也复杂了许多,对于研发人员的要求同样要高许多。
不过业界已经有成型的方案,自然可以解决。对比玩家体验,这方面的优化还是很有必要的。
|
|