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