回合制MMORPG



 

  虽然许多人觉得即时制MMOPRG玩起来更流畅爽快刺激，但回合制MMORPG在
国内网游市场上仍拥有不少忠实玩家。个人觉得抛开某几款大红大紫的回合
制MMORPG带来的跟风效应来说，回合制战斗系统有其本身的优点：低操作门槛
且较休闲的战斗模式下提供了可以深层挖掘的配合策略。
  好的回合制战斗系统需要：
  * 平衡的数值分配
  * 可控的属性增长
  * 合理的技能设计
  * 与技能互补的BUFF
  * 有惊有喜的怪物AI
  * 可控的装备系统
  * 低门槛的基本操作
  * 可深层挖掘的战术搭配
  * 引导玩家沟通的战场内容
  * ...
  要全部做到位真不容易。
 
  或许说远了，本文要说的是回合制MMOPRG的战斗系统程序设计。
  而且，是非常传统的那种。
  所以，下文会假设我心中的"非常传统的那种回合制战斗系统"是众所周知的*_#
 
---------------------------------------------------------------------
 
  回合制战斗特殊性是：它将参战双方阵营都纳入一个看似副本的"战场"中进行
一整场属性互动；完毕后才可与真正的游戏场景中的其他复杂系统交互。
  这个战场上的互动对象通常包括以下几类对象：
  * 玩家角色
  * 宠物（召唤物）
  * 怪物
  * 战场道具（通常只指战斗背包中的药，功能性物品等）
  而作为网络游戏，驱动这些对象进行互动的系统只有两个：
  * 网络协议系统（处理战斗协议的上/下行）
  * 定时器系统（触发定时的时间片来驱动战斗状态机）
 
  据上所述，设计战斗系统的程序基础框架时可以有一定的原则：
  * 基础模块关系清晰
      似乎有点教条式，但越复杂的系统越需要越清晰的模块关系。
    自己造一座城，然后把自己困在里面，那不就悲剧了吗。
    战斗系统可能是一个回合制MMORPG中最复杂的系统之一，因为最长时间的
    玩家间连续有状态交互就发生在这个系统中。什么bug都可能出。
 
  * 基础对象间复杂度差异尽量小
      其实基础对象无非几种：
      Fight(战斗对象)
      Camp(阵营对象)
      Host/Watcher(战士对象/观察者对象)
      Pet(宠物或怪物对象)
      AIChip(AI对象)
      Buff(Buff对象)
      Skill(技能对象)
      Item(道具对象)
      ...
     
      虽然不可能每个模块代码行数量一致。但是将复杂度差异控制到尽量小，
      能使你后续对功能点的定位速度提高一个数量级；你肯定不愿意两年
      内对为了对某个功能的修改而一次一次地对拥有10000行的fight.xx文件
      vi + search上一万次。
     
      一个有效的方法是引入更细粒度的新对象来分摊原有对象的功能点，
      比如Camp中可引入 Map(站位网格信息对象) 来独立处理阵法站位映射。
 
  * 绝大部分新需求只需要简单派生处理
      基础模块中应该完成策划案中对战斗系统的通用需求。
    而预留少量几个接口：比如 (1)初始化配置接口 (2)奖励接口 (2)惩罚接口
    供派生重写。而预留之前应该与策划人员商定绝大部分的新玩法需求可以用
    你预留的接口派生重写的方式简单满足。只有这样战斗基础模块才有价值。
 
  * 对较特殊需求留有改动可能性的空间
      做游戏不同于做一次性出最终版的传统软件。做游戏，做的就是反复。
    所谓反复，可能是为了某个需求你得将整个构架反过来再复过去。
      有人很热衷于重构么？如果有，那也是出于不得已。
      将Fight包含的基础对象链中的class作为可配置的，是相对灵活的方式。
    在类似Python, Lua等将class作为first class value的语言中，很方便。
   
  * 将驱动方式抽离单独模块
      回合制战斗的主要的驱动方式是 网络协议 的接收。
      只所以要将驱动方式单独抽离，可方便地提供不同形式的驱动源输入。
      或许你只希望一个单机版的录像文件驱动战斗？
      或许你希望一个文本行格式的测试用例驱动战斗？
      或许你彻底不需要任何形式的驱动？
 
  * 必须给策划留下[极大的]配置空间
      如果有可能，最好编写大量的代码生成器，并提供一个策划可接受的
    编辑方式（比如 xls / csv 等基于单元格的格式）。
      类似Skill，Buff，AI，Trigger，Equip等都交给策划来100%控制吧。
    想什么时候改xls就什么时候改，改完运行一下代码生成器生成代码文件，
    立即可以看到改动效果，节省不少策划<->程序的交流成本。
      当然，这样做需要预先对Skill，Buff，AI，Trigger，Equip等的可配
    置内容有策划<->程序间的讨论和约定；但很明显这是一劳永逸的事情。
    
  * 可以在线热更新绝大部分战斗配置
      配置，就难免出错。特别是由策划来配置。所以必须提供一个热更新
    的机制使得服务器不停机便可以令新配置生效。所幸的对是现在绝大部分
    脚本语言而言，做到这一点已经不是多难的问题。
 
  * 核心代码不traceback
      是程序都会有错误，没错。但是经过严格的编写和测试，我们应该保证
    核心代码极少出现致命的错误。如果出现了，也别乱try/catch + log 让
    它过去就算，让战斗系统挂掉吧，早挂早好。
 
  * 配置代码即使traceback，也使影响尽量小
      配置代码是代码生成器根据策划填写的xls生成的。可以列为"不受信任"
    的函数块。战斗系统调用这些函数块时，应该做好它们会traceback的
    准备。但是，即使它们出现traceback，也应该做一些事情使得对游戏世界
    的影响尽量小，比如：(1)错误结束的战斗不给予奖励 (2)错误结束的战斗
    至少能保证所有战斗中玩家能够退出战场返回正常游戏场景继续游戏。
    (3)认真记好错误现场的日志。
 
  * 严格时序的详尽战场日志记录
      在上下文战场信息缺失的战斗日志中追查错误，事倍功半。
      严格时序，所有战场事件有效信息的日志是必要的。至少前期是必要的。
    最好每场战斗有单独不重复的战斗ID，每行日志有ID+回合数信息再加事件
    信息。为错误的追踪查证提供有力的支持。
 
  * 可重入的战斗测试用例机制
      可重入是指同一份输入数据驱动两次独立的战斗，战斗系统会得到两次
    完全一致的输出结果。如果战场日志足够详细，我们可以认为能得到两份
    完全相同的战场日志（包括所有的掉血，命中率，暴击率计算结果值）。
      实现可重入的战斗测试用例机制在回合制战斗系统中是可以做到的，
    使用自定制的随机数函数，并在输入中将外部因素全部重置（其实外部因素
    不多），然后驱动（这里就看出【将驱动方式抽离单独模块】的必要）直至
    完成一场战斗即可。
 
  * 可重入的性能分析用例
      引入合适的profiler机制来对可重入的测试用例进行性能分析。毕竟战斗
    在回合制MMORPG中是重头戏。能看出瓶颈的点应该尽早优化，持续优化。

即时制与回合制的战斗

 

以下内容，可以帮助你理解主流MMO的设计原则和不会导致致命错误的设计方向。

一、理论前提

1. 所有的游戏，都是行为、结果交替出现的过程；

2. 玩家的行为可以产生结果，结果影响玩家进行行为；

在此基础上，我认为

回合制，是断点式的表现行为和结果，切行为和结果同时出现在玩家面前。具体请看下图；

行为选定之后，结果必然产生，而玩家只有通过下次的行为来改变这个结果。但玩家是通过目前的结果来分析，并试图改变；最终是否可以改变这个结果，却不能肯定，因为必然要受到其他行为的干扰。

即时制，是连续性的行为与结果互相干扰的过程，可以想象成2个脉冲你上我下的前进过程。看下图；

 

行为可以造成某个结果，但是是否最终造成一个结果，还要受到其他行为的干扰，而新的结果，又将对下一次的行为造成影响。

战斗过程中，以1次的行为、结果产生作为一个节拍来进行，周而复始，那么基本的战斗设计就是如何表现和扩大化行为与结果之间的关系。

回合制中，行为表现出来之时，结果也随之立刻表现出现出来。期间，玩家无法对即将出现的结果造成任何影响。而这恰恰是即时制的精髓所在——如何有效的通过行为影响结果。回合制所强调的，便是之前的谋划过程。

二、实例

这里举几个例子，来帮助大家理解。已经理解了第一部分，可以直接跳过。

 三、战斗的设计

该部分内容将集中根据以上文中的2幅图讲述。有任何不理解之处，请盯住图5分钟……

PART A.从回合制的图（后简称“回合图”）中可以看出，

1、回合制的战斗基本形式，在于大量的行为同时交织在一起，对结果造成影响。而魅力所在，就是人的行为、对结果的判断

是否和结果相符，是体现战斗中能力的主要手段。

2、（接上）所以，回合制的基本形式以下几种

a. 结果完全不可预知；

b. 部分可预知；主要体现形式。

c. 完全可预知；没有任何行为可以阻止想要的结果发生，是一种绝对的“行为-结果”过程。

在以上3种回合制的基本形式中，是否具备行为方式，使得玩家具有足够的能力来预知、控制结果的产生，是评判玩家能力的

主要根据。

因此，在游戏中，玩家的主要成长过程，就是将完全不可预知转向完全可预知的过程。

PART B.从即时制的图（后简称“即时图”）中可以看出，

1、即时制的战斗基本形式，在于行为能不能有效的干扰其他行为，使之结果变为自己想要的结果。而干扰的时机、干扰性成

为评判战斗实力的重要标准。

2、（接上）即时制的基本形式以下几种

a. 先发式，强迫使对方无法对自己的行为产生干扰

b. 条件反制式，针对性的干扰对方的行为

c. 后发被动式，缺乏干扰动作能力，但本身抗干扰能力也强。

在游戏中，玩家的主要成长过程，与回合制也大有不同，即时制的成长，都以强化自身的特点为路线；譬如某玩家属于先发

式类型，在其游戏过程中，更多的要注重可先发行为的强化、扩展，并以此为中心形成玩法。

PART C.PVE的设计

PVE的设计，这里仅指练级中的普通打怪。

在我们的思维定性中，该过程是枯燥的，而这个结论是必备的。

1、从回合制的角度来看，玩家的行为即使本身不具备强大的可预知性，也可以在这种战斗中得到明确的即定结果。玩家使用

一个300伤害的群法技能，就一定会对一群怪物造成300伤害，不会有任何的其他情况发生。

回合制中的可预知能力，是回合制的最基本因素，是每个玩家必须要体验到的内容。即使不通过PVE战斗，也必须通过其他方

式体现。任何不具备该过程的回合制，都是不可取的。

2、从即时制的角度来看，PVE的战斗是锻炼玩家使用干扰行为、寻找干扰时机的过程。

即时制中干扰行为能力的有与无、玩家对这些行为能力的熟练与否，是非常重要的因素。

PART D.PVP的设计

回合制的PVP，是一个比较可预知结果的行为能力的过程；

即时制的PVP，是一个互相干扰的过程；

战斗系统对于绝大多数角色扮演游戏来说都是十分重要的一部分，如何使得战斗系统设计的健壮、条理清晰且扩展性良好在整个游戏的开发中都是一个十分重要的话题。

　　首先需要理清回合制战斗的总体流程，如图1 所示：

图1 回合制战斗流程图

　　接下来，要根据战斗中所需要的数据抽象出相应的数据结构：

　　1.战斗进程数据结构

　　　对于每一场战斗来说，都需要在进程中保存战斗的pid，回合计数，战斗类型（PVE or PVP），

　　　战斗性质（该字段实际保存的是战斗类型的一个细化，其中包括PVE中的野外普通怪、副本怪、精英怪和世界boss（杀死后定时刷新）， PVP中的战斗、切磋、竞技等，根据游戏内容的扩展会有所增加），

　　　进程状态（主要对应图1中的几个主要过程，包括进程初始化、等待新一回合、等待玩家选择该回合战斗策略、处理战斗结果、等待客户端播放战斗动画、战斗结束处理），

　　    战斗场景（包括战斗场景id以及坐标，用于记录玩家战斗记录、以及向世界频道发送广播等），

　　　 当前回合战斗播放数据（服务器端计算出本回合战斗结果后，构建客户端动画播放数据，保存在该字段中），

　　　玩家发起战斗时候点击怪物的id、pid、类型、场景等（用于确定战斗性质、世界广播以及战斗结束对金钱物品掉落、精英怪和世界boss等的特殊处理，这些数据不能够保存在战斗对象里面去，因为玩家点击一个怪物进行战斗（例如世界boss），而实际进入战斗的怪可能有多个（世界boss带着几个小喽啰）。这样，我们就无法确定应该以哪个战斗对象为准，战斗性质就无法确定，战斗结束的后续处理也无法进行），

　　　 战斗开始时间（用于通关霸主，如果该次战斗所用时间破纪录，该玩家将上榜——扩展功能），

　　　 观战玩家（用于保存观战玩家，服务器端向参战玩家推送本回合战斗结果数据时，给观战玩家也推送一份——扩展功能）。

　　2. 战斗对象数据机构

　　　对于每个战斗对象（不论玩家、怪物或雇佣兵都抽象为战斗对象），应包含以下数据：

　　　对象编号（用于同客户端确定动作的实施者和接受者），对象类型（目前包括玩家、怪物、雇佣兵三种），对象id（如果对象类型是玩家，那么就是玩家的唯一id，如果是怪物，那么就是怪物的类型id而非唯一id），对象名称，

　　　对象出手顺序，对象攻击速度（根据这个字段确定出手顺序），所在放标识（a方/b方的枚举），当前气血/魔法值，气血/魔法上限值，逃跑失败次数计数（逃跑失败一次，下一次逃跑成功率将增加），对象是否已逃跑

　　　对象当前回合战斗策略，对象状态（目前共有正常、睡眠、眩晕、死亡四种），是否处于防御状态，是否处于魔免状态，是否被强制普通攻击（中了对方的嘲讽），是否不能暴击，

　　　当前角色一直存在的反弹列表和比例，如黑足的“荆棘护体”技能，该字段为一个列表，格式[{引起抵消的技能id, 剩余点数} | ...]，

　　　当前角色剩余的伤害抵挡抵挡点数列表，格式[{引起反弹的技能id, 反弹数值-整形是固定值,浮点型是比例} | ...]，