之战斗系统

“回合制是游戏的一种方式，全称为回合制策略游戏，所有的玩家轮流自己的回合，只有自己的回合，才能够进行操纵。回合制分类：

l  战棋类游戏

n  SLG：角色扮演因素较少，战斗以整体策略为主

n  SRPG：角色扮演因素为主，战斗为回合制，通常己方人员较少，特别依靠培养系统铸造的强人

l  半即时制：使用行动点数系统，行动点数基于角色行动需要而设定的耗时系统或者行动速度的差异。”——维基百科，http://goo.gl/Efbly

回合制端游：大话/梦幻西游、问道、QQ仙灵、水浒Q传2、神雕侠侣等等。

回合制页游：神仙道（大话神仙）、QQ水浒、TNT、楚河汉界、新梦幻之城、火影忍者OL等。

回合制游戏中战斗系统是玩法的核心，相对而言也是较复杂的一块，下面围绕页游战斗系统战斗介绍：

1.         战斗系统

a)        技能分类

b)        Buff/Debuff

c)         技能效果

2.         服务器设计

3.         客户端设计

战斗系统

回合制战斗系统偏休闲，无需复杂、敏捷的操作（对apm无要求），特点：

l  按照某个属性比较，确定先攻方。

n  神仙道（大话神仙）使用速度属性，比较速度确定先攻方；

n  QQ水浒使用敏捷属性，比较敏捷确定先攻方；

l  轮流出招，直到一方全部死亡。

l  队伍阵型概念（九宫格），不同阵型直接影响到总的战斗力。

l  战斗过程由服务器计算，客户端只是简单的动画播放。

下图是回合制战斗过程的简单抽象：

图1：回合制战斗过程简单抽象

通过图示简单的抽象，基本体现战斗的流程。其实战斗过程可以分为，全自动模式、半自动模式。全自动模式，进入战斗之后玩家只有2中状态：出招、被打，直至一方死亡，过程中玩家不介入，例如神仙道（大话神仙）、QQ水浒、楚河汉界、还有我们即将上线的游戏；半自动模式，玩家在每回合战斗之前，需要选择技能、攻击对象、嗑药等，组队竞技的话，玩家不在自己的回合，还回有等待状态，不能做任何操作，例如TNT弹道轨迹。

客户端游戏采用的都是半自动模式，玩家在自己的每回合之前都可以进行一些操作，以提供更多乐趣。目前页游这两种形式都有，如果偏休闲的采用全自动模式。

影响战斗的因素有：技能、阵形、装备、其它各种功能性药水之类的。阵形、功能性药水相对而言较简单，主要是数值方面的设计，这个由产品来把控。技能比较复杂，下面详细介绍。

技能分类

【技能分类1】按技能效果分类，1：普通技能、2：攻击技能、3：增益技能；

【技能分类2】按技能触发分类，1：主动（选择时触发）、2：被动 （被攻击时触发）、3：伴随 （攻击时触发）、4：常驻（不用触发，影响属性）；

【技能分类3】按技能属性分类，如金、木、水、火、土五行之类的。例如，我们的游戏存在以下分类：1：普通，2：火系，3：水系，4：地系，5：自然系，6：超能系，7：格斗系，8：幽灵系。

【技能分类n】…

图2：技能分类

技能系统之复杂由上面的分类可以看出。

从效果分类上，普通技能触发失败，才会使用普通技能。而增益技能又可分为Buff/Debuff、Hot/Dot，其中Buff/Debuff是作用一次，持续xxx回合数；Hot/Dot是持续增益效果、持续减益效果，每回合（满足条件的回合）都触发效果。

从触发时机看，不同的技能在战斗回合中，处理顺利不一样。顺序稍有差池，可能会得出完全不同的结果。

从属性分类看，往往伴随相生相克，在战斗回合中直接影响到属性伤害效果。相克关系打击伤害效果加成，反之伤害减免。

图3：五行关系（摘自百度百科）

Buff/Debuff

Buff、Debuff：效果作用一次，持续一定回合数，每回合结束后回合数减1，回合数为0删除并清除效果。例如Buff“战争颂赞”——以战斗的旋律颂唱，增加己方所有队员x点攻击力，持续2回。Debuff“危险热浪”——降低所有敌方对火系魔法的抗性10%，持续2回合。

Hot、Dot：持续增益效果、持续减益效果，每回合都触发效果。例如Hot“炽热之魂”——注入炽热的灵魂，使宝宝的天生技能攻击附带x点火属性伤害。

Buff/Debuff看上去简单，但是跟触发时机、相生相克、伴随技能结合在一起就特复杂。例如“勇敢的心”——格斗者的意志无坚不摧，HP降为0时能够继续战斗1回合，并且下一攻击伤害提升1倍，这个技能只有在HP降为0时才能触发；“危险热浪”——降低所有敌方对火系魔法的抗性10%，只对火系魔法有效；“烧伤”——在受到火系法术的攻击敌人有一定概率被烧伤，每回合扣取本次技能伤害的10%，持续3回合，这个技能是伴随火系技能概率触发，并持续3回合。

技能系统代码方面一定得设计灵活可扩展，支持新增技能或技能类型。

灵活的配置文件（很重要），要使得产品对所有技能要灵活可配，否则代码就得做特殊处理！理想的配置方式是，产品配置excel，然后配置工具转换为xml等代码方便处理的格式。

技能效果

这里说个我们项目的经历，前期我们预期是一个技能对应一个效果（攻击者的施法动作效果，打在战斗单元身上的效果），还有一点我们遗漏了，Buff类技能都有小图标展示（或者效果）持续展示的。制定协议和技能效果时，按照一对一的格式。到了后期发现这样满足不了产品需求。往往一个技能会伴随多个效果，例如施放一个技能，可能伴随：

n  技能打击效果

n  暴击效果

n  眩晕

n  中毒

n  ….

正确的设计是技能是由多个效果组成的，这些在制作资源、协议的时候都要考虑到。并且把技能拆分成多个效果，技能更灵活可配，产品可以自由组合效果为新的技能。

服务器设计

对于玩家在每回合中能不能操作，服务器端逻辑会有些不同，服务器端逻辑如下：

[1].    从数据库读取战斗单元相关数据，进行初始化。包括战斗单元本身的属性、技能、装备、功能性药水等等动态属性；

[2].    读取静态配置数据，包括技能配置、装备配置等等；

[3].    开始回合战斗；

[4].    决定攻击者；

[5].    如果不是全自动模式，需要等待玩家选择攻击技能、攻击对象；否则，服务器按照一定规则决定攻击技能—>决定攻击对象；

[6].    技能释放逻辑（较复杂）；

l  触发时机

l  触发条件

l  攻击对象，属性相生相克

l  伴随技能

l  技能触发概率

l  Buff、Debuff、Hot、Dot

l  等等

[7].    回合结算（如果不是全自动模式，推送结果给客户端；否则，战斗结束一起推送），开始下一回合，调到步骤【3】

注意：

²  设计上要考虑可重入测试、每回合详尽的日志以方便查找bug！

²  热更新配置，使服务器不停机reload使新配置生效。

客户端设计

客户端解析战斗数据，顺序播放战斗效果，不对战斗过程做任何控制。当然这里的不做任何控制，有的逻辑可以客户端，如Buff、Debuff这种持续一定回合数的技能buff图标显示可以由客户端计数并显示。

客户端逻辑：

[1].    如果不是全自动模式，每个回合对应玩家都需要操作，选择播放技能、嗑药等操作发给后台；

[2].    解析后台返回战斗数据；

[3].    播放战斗回合；

l  播放技能（一个技能可能有多个效果）

l  添加Buff、Debuff、Hot、Dot图标

[4].    回合结算，清除战死单位、过期Buff/Debuff

[5].    开始下一回合，调到【1】或【3】

图4：大致类图

注意：客户端保证按序解析，播放战斗过程，要考虑可重新播放入口以重现问题，方便查找bug！