代码改变世界

回合制页游

2013-01-24 14:41  吴秦  阅读(10452)  评论(7编辑  收藏

回合制页游

之战斗系统

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

l  战棋类游戏

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

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

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

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

回合制页游:神仙道(大话神仙)、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

回合制游戏1

2:技能分类

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

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

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

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

3:五行关系(摘自百度百科

Buff/Debuff

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

HotDot:持续增益效果、持续减益效果,每回合都触发效果。例如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  BuffDebuffHotDot

l  等等

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

注意:

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

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

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

客户端逻辑:

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

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

[3].    播放战斗回合;

l  播放技能(一个技能可能有多个效果)

l  添加BuffDebuffHotDot图标

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

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

回合制游戏-前台解析

4:大致类图

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