对部落战争的分析与研究.docxVIP

对部落战争（COC）的分析与研究COC特点COC，也就是部落战争，是一款实时策略游戏，非常优秀，特点突出。实时性强，表现流畅游戏中可以觉得到的一个非常重要的特性就是流畅，几乎感觉不到服务器通信带来的延迟。在战斗与建设场景中也能看到，每个角色的不同活动，普通军民的采集活动，工人的建设，士兵会按自己的喜好攻击目标，如果有障碍也会自动寻找最近的路线。回放功能当玩家攻击敌人和收到攻击都会收到通知消息，在通知消息查看中，可以点击回放，重现战斗的过程。战斗时操作简单可以看到在战斗阶段，玩家可以作出的操作仅仅是布置士兵出现的位置。接下来都是由电脑自动呈现效果，比如攻击，寻路，目标选择等等。初始化时间比较长这段时间应该是对资源的后台加载，也说明在游戏中应该很少加载资源，这也是游戏流畅的一个原因吧。命令队列实现COC给人感觉就像一款《星际争霸》一样的即时战略游戏，但是更简单得多。从而我们可以仿照星际争霸的方式来实现。客户端负责将玩家在什么时候对指定目标的操作记录下来，整个战斗过程都将是一个自动根据时间推演的过程。这样的设计首先的好处就是，提交的请求数据包将是非常小的，一个单位操作的数据也就是4*4（单位类型，时间，坐标x，y），16个字节。如果是有50人参与战斗，不用1K字节就完成了，当然在具体实现可能会使用json,xml的方式传递，数据包也可能会进行封装。如果要实现回放的话，那么只需要保存下目标村落的部署及基本信息，就可以了。加载后，按时间推演即可。只要所有的计算方式都是固定的，结果也不会出现不确定性。现在比较不确定的地方就是服务端如何校验的问题，是否会对所有的命令进行回放，还是只是对结果进行评估。因为COC中防御布局对战局影响很大，一样的建筑也能有不同的效果，胜负可能只在一点细微的差距，要实现一个准确评估公式难度将很大。所以我更倾向命令回放的验证方式。主循环实现考虑到加速与验证的需要，我们在实际实现中也不能完全按真实时间来播放或验证一场战斗，可将时间从连续变为均匀离散，按200毫秒为1单位的进行循环计算（人在感觉上对200毫秒的差异还是能接受的）。循环中按各个防御建筑与攻击单位逐一更新。下面是一个普通模式下客户端处理流程实现：加载战斗信息WHILE（计时未到战斗结束 OR 是否达到战斗结束条件）-建筑全毁或攻击者全牺牲{ 根据玩家的输入，转化为操作命令，并放入命令队列（该处理可能是异步的）命令队列处理WHILE（遍历各单元）｛状态判断（例如：死亡的话，就可以不需要进行继续处理）选择动作目标（索敌，或帮助队友，需要遵循业务策略）动作表现（例如：移动、攻击、魔法、技能）伤害产生与处理，或掠夺奖励产生根据单位的状态更新动画与声音效果｝计时增加200（如果循环在渲染中，就需要进行帧率优化处理）} 战斗结束，计算结果或进行验证回放验证流程会稍微有点区别：加载战斗信息与命令队列WHILE（计时未到战斗结束）{ 命令队列处理WHILE（遍历各单元）｛状态判断（例如：死亡的话，就可以不需要进行继续处理）选择动作目标（索敌，或帮助队友，需要遵循业务策略）动作表现（例如：移动、攻击、魔法、技能）伤害产生与处理，或掠夺奖励产生根据单位的状态更新动画与声音效果｝计时增加200（如需渲染，就进行帧率优化）} 战斗结束，计算结果或进行验证其中可以使用状态模式来处理单元对象的状态判断，刚开始状态可能比较简单，如果加入更多的单位类型或者技能魔法可能会出现更多的状态，各种状态之间的变化与处理可能会更多。验证后发生的事首先为了保证客户端的流程性，提交了战斗结果后，将会等待服务端的验证结果，会继续像单机游戏一样继续玩下去。但是指令不会提交到服务端。当服务端验证成功那么自然数据将发生更新，客户端将累积的其他指令提交服务端，而服务端则验证指令后更新对应的数据。但如果服务端发现提交的战斗结果未能通过验证，那么将会让客户端退出游戏，当客户端再次上线，数据将恢复到错误的提交以前。使用分布式设计来降低服务器负荷基于回放的验证方式，肯定会带来较大的计算量，索敌，寻路，还有业务逻辑策略都会占用较多CPU。那么必定需要采用分布式多服务来分担计算压力。COC独特的游戏设计将战斗模块设计得相当具有独立性，那么战斗验证独立出来将变得很容易。我们可以将担负战斗验证的部分，独立出来，成为战斗服务器。在其启动后，就在主服务器上进行注册，如果有战斗发生，主服务器只需要将防守方的布阵，攻击方的队伍以及攻击方的布置指令、客户端计算结果，发给战斗服务器，当战斗服务器完成验证返回，再发送结果到客户端。基于战斗计算的独立性，可以很容易增加战斗服务器的数量，来减少负荷，甚至实现热添加也不太难。非对称验证法龙之谷、DNF这类动作类，本地实时性要求很强，不得已才在客户端计算，并且由于对外挂的惩罚力度不够，还造成了外挂泛滥的