回合制页游
之战斗系统
“回合制是游戏的一种方式，全称为回合制策略游戏，所有的玩家轮流自己的回合，只有自己的回合，才能够进行操纵。回合制分类：
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！