pvp/pve的一些思考

前些日子开发了两个PVP/PVE玩法，那种5V5/15V15规模。由于结合大量玩家或机器人在一起战斗放技能什么的，设计到大量计算量和网络资源，故这块可以有优化可以做。

不考虑匹配规则这块。

之前我做群体PK的时候，做过一部分优化，可以翻下以前的博客。当时在野外场景，五十多号玩家在PK，不停的放技能，还有两百来只怪，优化后CPU降为6%左右，网络发包量这个降低了些，但不太好估计。当然里面还可以再优化，至于为什么还是占这么高，里面一些原始设计方案存在一些问题，因为设计底层模块和AI设计，目前不大好改，然后判断关系比较复杂，涉及到的字段处理较多。后期重构了这部分，因为新游戏的PK玩法变化较大。

发包量这块，原始设计是不管能不能发，先序列化要广播的包，然后在发送，其实大部分情况下发不出去。具体原因就不细说了，我这部分优化是先判断能不能发，发个哪些人等，后来测试了下，计算量减少了些。包括原来移动逻辑，也做了些调整。

即将做的还有两个PVP大规模玩法，一个是帮派战，规模约八十号人进副本，还有个四百号人进副本的争夺战，这两个是在最快情况下需要考虑的情况，当然一般情况下，不大可能同时参与。

那么问题就来了，原来的架构设计是否能承载这么多人同时战斗？是否需要场景分线？计算/内存/网络资源这些绕不开的怎么优化？写日志这块？如果有定时任务那么在触发定时逻辑时，如果处理过慢会影响其他定时任务怎么办？考虑到底层框架的设计，上层业务怎么调整等等都需要考虑，不然一场战斗会影响其他服务和正常逻辑。然后广播包的处理，一条要广播的消息序列化后，就发送即可，不需要再次序列化，在服务间零拷贝传递，由于是多线程处理，云风作者实现了个广播服务，用了引用计数，这样最后一个会释放，具体代码我也没看。

如果把整个系统功能划分一下，其中有点耗时的有视野模块，战斗模块，技能模块这些，其中战斗模块涉及关系的判断，比如两个人能不能打，一般在副本中是敌对关系的话我们会用阵营去判断，当释放一个AOE技能时，友方需要过滤，那么可能会走到其他关系判断。由于用的是一套判断关系，那么这里会有些冗余的计算量。AOE释放范围大小也会筛选，反正就是尽快把事情做完。

如果就以目前的基础代码去实现这四百人规模团战，我估计cpu要爆，不考虑写日志，玩家在地图格子的分界点跨越，还有AOE技能，纯粹定时若干秒加经验，估计也比较费时，就来拆分基础代码，这样就简化为加经验，只序列化一次消息内容，然后广播给副本场景中的玩家。本来是准备把定时处理这么多玩家分摊到每秒的，因为策划那边说不行，后来就用上面方法的。

总之这种规模的玩法，尽量少些遍历，先处理简单条件，不成立立即跳出，有些不变的可以在循环外面先计算好等，后面想到再补充。

这段时间会开发四百号人夺城战，会着重优化代码，尤其是原有的底层基础代码设计，包括战斗筛选逻辑，事件分发等。