多人战斗是非常动态的环境，所以我们设计了一套测试机制，协同服务器、客户端和QA Team一起选择稳定的服务器和客户端版本，部署在几乎接近于真实的外网测试环境，测试服务器长期地在同一位置进行大量角色的耗费性能模拟。有了这样的测试环境，我们就可以采用之前提到的各种数据上的Profile工具进行调优。

首先，我们从全局角度上来考虑这个优化问题，策划同学根据收集到的性能数据和玩法设计，估算出我们游戏里面的重点密集区域，主要是主城里面的摆摊区和外贸行。它的开销主要是主城本身的复杂物件开销和多人开销。

我们把拍卖行和摆摊区的区域分别进行设计，拍卖行设计为室内，摆摊区设计为室外，这样的话通过遮挡剔除，我们会剔除掉部分进入室内的角色。

而对于野外的盟会战开销，盟会战我们优先是选择在野外地图中，而且是性能比较好的区域 进行投放，包括复活点、传送点，我们都采用类似的方法来设计。甚至在主城门口的接收区也设计了城门、城墙这样大型遮挡，来剔除进入城内的角色的渲染开销。

从程序的角度来看，关键策略是根据重要度，在全局的角度来分配计算的配额。例如针对动画更新，我们设计了一个算法，优先更新离你最近的以及最靠近视野中心的一个角色，其它的角色可以不更新或者是隔一定的帧数来更新。

另外，我们对特效的开销也做了分级，每个特效类型都被分配了一定的权重，当整个特效类型的预算耗费达到了一定的指标之后，新的特效将不再产生。我们也特别开发了一套系统，来判断主角和主角关系链上面的角色，例如同小队、游戏目标、攻击主角的人，优先把配额分配给这些角色。

其次，我们也测试了角色LOD，在多人且相当近的范围内，角色可以采用更加低的LOD级别，像这样的两个角色的多边形数目，左边的是 100%，右边的只有左边的15%，但是从远处看起来基本上没有任何区别。

所有的策略都建立在相机的位置和玩家的当前性能之上，而且各个模块可以根据当前的性能指标进行动态的Scale（扩展）。在多人团战中，使用了动态预算系统，经过调校的多人战斗有了非常流畅的表现。

由于多人场景是一个非常动态的情况，所以会存在非常频繁地加载和释放的调用，为了防止卡顿，我们针对加载创建做了非常多的平滑处理。

例如，我们给定运行时候的角色加载数目上限，我们给Streaming（流式加载）和Loading（底层加载）层控制任何Geometry（物件）和材质的创建数目，甚至包括根据移动来加载的植被，也有平滑加载的机制来防止系统在过度震荡的情况下引起卡顿和多余的计算开销。

其实，平滑开销的方法也会用在其它的系统里面，例如，我们在处理最远一级的阴影系统，计算物件之间的遮挡关系时，也是平滑到多个帧里面来完成，避免单帧计算出现的卡顿。