[游戏开发]关于手游客户端网络带宽压力的一点思考

## 关于手游客户端网络压力的一些思考

### 场景背景

毫无疑问，策划都喜欢多人同屏战斗。什么万人大地图，这确定是策划的最爱了。但是对于游戏来讲，这并非什么很是好的设计。即便解决了服务端计算的性能压力，客户端显示的性能压力。万万没想到的是咱们游戏在客户端网络带宽上面遇到了压力。

假设1000人同屏，那么要同时同步1000我的的位置，移动方向，速度，释放技能，伤害，血量，buff等信息。这n^2的网络带宽复杂度，对于服务端来讲，其实只要申请大些的带宽，买贵点其实就能够解决了。可是对于时常处于不稳定和低网速网络环境(电梯、地铁、偏远山区等环境)下的手机，特别是还处于2g，3g的网络环境下的手机，那么小的带宽承载能力其实根本没法应付这么大的网络消息同步的。形成后果，游戏会有明显的收包卡顿，有些会出现好几秒，出现很是很差的游戏体验。
另外，即便手机能够承受，在当下手机网络流量并无那么廉价的状况下，如此耗费网络流量，很难的获得玩家的承受。

以上，对于实时同步信息的模式，在大规模多人对战手游中，并非一种很是合适的方案。

### 解决预想(帧同步)

问题在于客户端的网络带宽，若是减小客户端接收的网络带宽才是重点。不去同步那么多的信息，那么就须要客户端和服务端尽可能约定规则。使用客户端先行，服务端演练计算的方式来实现。貌似业界已经有这种方案了，传闻lol、dota2就是这么实现的(这方便并没进行查阅，只是有个印象)。
到战斗开始的时候，先同步必要的信息，譬如场景内的怪物、位置、AI、血量、技能等信息和一个随机数。AI的行为经过随机触发。那么须要同步的信息就只剩下那些没法肯定的因素。譬如玩家，何时释放什么技能、如何移动，咱们是没法肯定的，但只要在外面服务端的演练中同步上，那么一样能够演练出客户端的整个战斗过程出来。
对比能够发现，使用这种方法，咱们只须要同步玩家的技能、移动就能够了。省去了不少其它能够直接演练出来的信息。为了不演练的误差，能够按期同步一些内容。这样既能够保证战斗的一致性，也大幅度减小了带宽流量。

固然使用这种方式，对客户端和服务端的约定要求很是高，相比也复杂了许多，对于研发人员的要求一样要高许多。

不过业界已经有成型的方案，天然能够解决。对比玩家体验，这方面的优化仍是颇有必要的。