游戏开发——战斗系统之技能设计 - 推酷
游戏开发——战斗系统之技能设计
& & & &现在在做的项目大致分为两块：战斗系统和除战斗系统之外的(简称外围系统)，而我一直在做的是外围系统的开发，至少在6月份返校毕业答辩之前没有动过战斗系统。答辩回来之后很长一段时间内也是在做外围系统的bug修复，可是由于种种原因项目赶不上所谓的进度了，上周五主管问我和另外一个也主要负责外围系统开发的同事谁更忙，我一句我没啥事干，结果主管说战斗系统的主动技能让我来做。这周一开会负责人一纸任务安排扔下来，上面写着XX同事这周完成主动技能的开发及相关系统的bug修复，还说没完成任务就XXX，此处省略XX字。
& & & & 再稍微说下目前本人的情况：不是计算机相关专业毕业的，去年学了两个月C++，一个月Cocos2dx，然后十月份入职现在的这个公司，因此相关技能水平就。。。现在在做的项目加上被砍掉的项目，共经历过两个项目开发。本着一腔热情加上强大的互联网资源，到目前为止项目组安排的任务都按时完成了。所以可以说是个稍微合格的游戏开发从业者吧。
& & & & 扯了这么远回到正题吧。技能的设计，首先我来理解一番游戏中的技能。在回合制游戏中，主动技能的流程大致为：释放技能，得到技能影响值(项目组天天喊的buff)并
确定技能对象
，技能检测+影响值添加到技能对象。而这次的主动技能设计我也是照着这个思路来的，因此本文可以据此大致分为三块来讲：技能释放部分，buff生成部分(不添加至对象)，技能检测部分。(本项目的技能相对来说较简单，技能释放不考虑魔法值，buff生成不考虑别的影响因素，技能检测不涉及命中率)
& & & &战斗：
& & & &己方队伍+敌方队伍，说白了就相当于一个卡牌游戏。
一、释放技能
& & & &本项目的释放流程大致为：战斗场景(BattleScene)中，当前操控的己方队员达到技能CD时间，玩家主动执行某个操作释放当前战斗队员的技能。释放的技能可能是一个组合技能也可能是单个技能。
在这里要控制的是：技能信息(影响值、技能释放者、技能作用者、技能影响回合)，技能管理(触发检测、产生技能影响、清除影响)。因此我首先想到的时候要在该场景里生成一个技能管理器，负责处理这里要做的技能控制。
写了一个技能管理类：skill_command(称为技能控制器吧)，大致成员如下：
class skill_command
*这个成员函数返回值用来做对是否是即时生效型技能的判读
bool init();
skill_info
//技能的信息
//技能使用者
//技能作用者
技能是在BattleScene释放，且需要在该场景下做一系列的检测，所以我的想法是将技能管理作为该场景内的成员，在该场景内执行技能管理类的检测函数。而考虑到技能可能是组合技能，所以在场景类中，我以一个vector存储技能管理对象。
class BattleScene
vector&skill_command*& vecSkillC
& & & &采取了这样的设计之后，每一次操作队员释放某个技能，先分解技能组合，产生一个技能信息则new一个指针存储在vecSkillCmd中：
vec = analyze(skill)
for(//做个循环)
auto skill_cmd = new skill_command();
skill_cmd-&init();//在这里还需要设置技能信息及作用对象等
vecSkillCmd.push_back(skill_cmd)
& & & &做这样的设计考虑的是：释放一个技能，将其组合技能分解出来单独控制，化繁为简。也因为我已经得到了一个技能产生作用需要的信息(记录了技能信息、技能作用者和使用者)，所以我在技能作用、检测阶段就不需要额外再向用户需要诸如技能对象等信息，只需要在场景中提供检测条件即可，条件达成了就可以直接在skill_command内部实现技能影响。想当初上一个项目我也参与到了战斗系统后期的维护工作，做的一块就是优化技能的效果表现，当初碰到最大的麻烦就是很难确定技能对象，所以那时候好苦逼的在找技能对象。所以这一次我的想法是，不管技能如何我首先要做的就是拆解开来，单独的确定其使用者和作用者，这样每次一次做技能检测和产生技能效果我都能找到对象。
& & & &设计案中也提到，技能可以分为即时作用和延时作用。指的是某些技能是一使用就会产生效果(如发射子弹、发射激光等)，而有些是需要达到某个条件(如碰撞到了敌方队员)才会产生效果。所以基于化繁为简的考虑，在分解技能信息，产生技能控制器的阶段我就将这两类技能分开处理。具体做法是在BattleScene场景内再添加一个成员专门用来存储即时作用的技能：
class BattleScene
vector&skill_command*& vecSkillC
vectpr&skill_command*& vecInstanceSkillC
& & & &这样处理之后，在生成技能控制器阶段依据一技能生效类型分开存储至不同的管理容器内。在检测阶段就只需要在不同的条件阶段，循环检测不同的容器内容，就可以达到我们的设计目的。如对于即时生效的技能，我只需要在释放完技能后对vecInstanceSkillCmd的成员做检测即可。当然会说直接将vecSkillCmd放在这里检测不就可以了么？这就是我如何将一个技能管理器skill_command存储的考虑了。
& & & & 上文提到了，依据技能的作用类型分别会将技能控制器存储至vecSkillCmd和vecInstanceSkillCmd。这里考虑了其作用时间，同时我也考虑了其作用条件。因为有的技能是即时无条件作用，而有的是即时有条件作用。针对即使无条件作用的，因为此种技能即时无条件作用了，所以我不需要在释放完之后再做管理，因此我没有存储至vec中。而即时有条件作用的才会存储至vec中以备之后做检测，这里我们用了一个成语函数releaseSkill表示技能释放动作：
void BattleScene::releaseSkill()
vec = analyze(skill);
for(//做个循环)
auto skill_cmd = new skill_command();//生成一个技能控制器
skill_cmd-&init();//在这里还需要设置技能信息及作用对象等
if(//如果不是立即生效)
vecSkillCmd.push_back(skill_cmd);
else//即时生效
if(//无条件触发) //执行触发效果
skill_cmd-&triggerSkill();
CC_SAFE_DELETE(_cmd);//删除该指针
vecInstanceSkillCmd.push_back(skill_cmd);
& & & & 进行到这一步，关于技能的释放部分就差不多了。而在项目中我做的技能释放也就是这样一个操作。
二、buff生成
其实上周五安排我做技能的时候，我一开始想的是如何做buff的生成。同事也提到要写个通用的接口，可以做道具的处理(加血、加速等道具),这样就可以省时省力。所以首先做的工作便是做buff，当然也没办法，因为那个时候没策划跟进我该如何做技能，直到这周三勉勉强强才把方案拿过来，此处又要省略XX字了。
因为我们已经有了一个role角色类，我想到buff不就是加到角色上的么，因此我的设计方案是如之前写技能控制器一样，在role角色类内添加成员作为buff控制器。也是基于化繁为简的考虑，一个buff就生成一个控制器，buff控制器内部也是包含buff信息，作用者和使用者等信息：
class buff_command
//buff的信息
//buff的使用者
//buff的作用者
& & & &每一次产生了一个buff，就生成一个控制器，与技能控制器的设计思路类似：在role角色类内部以容器管理这些控制器，每次使用技能或者使用道具而得到了一个buff，就生成一个buff存储至容器内，以便做后面的技能检测和buff效果生成：
class role
void addBuff();
vector&buff_command*& vecBuffC
& & & & role角色类一个buff管理成员和一个buff的生成函数。buff的生成函数在技能控制器的初始化函数内部调用，其大致内容如下：
void role::addBuff()
//检测重复buff
auto buff_cmd = new buff_command();
buff_cmd-&init();
vecBuffCmd.push_back(buff_cmd);
& & 跟技能控制器的生成类似，这里有一步的内容是做buff重复性检测：已经触发的buff删除其buff效果，而没有触发的则直接从容器中删除。
& & & &结合第一部分的内容大致做个流程介绍：
& & & &1、首先在SceneBattle场景触发技能使用：
battle_role-&releaseSkill();
& & & & & &&
2、触发技能使用之后解析技能组合生成技能控制器，初始化技能控制器信息：
auto skill_cmd = new skill_commant();
skill_cmd-&init();
& & & & & &&
3、生成技能buff：
bool skill_command::init()
initSkillInfo();
//技能作用对象生成buff信息
skill_obj-&addBuff();
经过以上三步，简单的一个buff便已生成。
三、技能检测
& & & &这一部分我感觉有点复杂，也是我拿不准的地方。周六刚测试了一遍整个释放-添加-检测逻辑，在现有的几套技能中是没有问题的，就是不知道之后的会怎么样。
& & & &项目的技能检测设计为：首先要检测触发条件，再检测生效条件。既首先一个技能要因某个条件而被触发，如己方队员碰了一下对方，或者己方队员碰到了某个场景元素，那么该技能便达到了触发条件；满足了触发条件之后，接着去做技能的生效条件，如该技能是要释放者碰到了对方才会释放，或者碰撞到了己方队友才会释放等等。所以在技能控制器skill_command内部写了两个成员函数：
class skill_command
//用来做触发条件的检测
void checkTriggerCondition();
//达到触发条件了，则触发技能
void triggerSkill();
& & & &技能的检测主要就是靠这这两个成员函数来实现，当然实际上这两个函数是带参数的。调用函数的地方是在BattleScene场景中：
BattleScene:://某个动作
auto skill_cmd = vecSkillCmd[i];
//每次先做条件检测，达到条件了之后控制器内部的bool型成员为true
skill_cmd-&checkTriggerCondition();
//内部bool型成员为true的时候执行该成员函数的内部动作
skill_cmd-&triggerSkill();
& & & &因为之前的设计中在技能控制器内部有技能作用者这一成员_obj，所以实际上技能的触发是调用_obj的成员函数来实现：
bool buff_command::triggerSkill()
_obj-&triggerBuff();
& & & & & &
而我设计的触发buff这个成员函数，里面的实际动作是对role这个类里面的buff容器进行管理：
void role::triggerBuff(//带能找到该buff的一个参数)
if(//是该buff)
auto buff_cmd = vecBuffCmd[i];
buff_cmd-&trigger();
& & & &这一步便实现了一个buff的触发。回到我们之前提到的buff_command这个控制器：
class buff_command
void trigger();
//buff的信息
//buff的使用者
//buff的作用者
& & & &成员函数trigger实际上是对buff的作用者_obj执行buff结算。依据buff类型(血、速)等，对角色的相应数值进行调整。而在实际的设计过程中，考虑到buff信息的独立性，以一个独立的结构体：buff_info作为role的成员变量，每次做buff结算的时候实际上调整的是该成员的值，然后再将这些值添加到角色role的相应信息上去。这样相对独立的设计，一方面适合直观的展现每次技能使用带来的技能影响(当然是对我们开发人员来说)；一方面因为是改别人的代码，这样独立的设计一个buff信息不会影响到已有代码所实现的功能(改代码好苦逼，主要是容易偏离原有设计者的思路)。
& & & & 这样buff的检测+产生效果功能便已实现，最后的就是buff的清理工作了。
& & & & 回合制游戏的一大特点就是一回合一回合的走下去，buff的影响效果也是有回合影响的；而技能的释放也只是会在当前回合有效：即释放了一个技能，只会在当前回合做有效性的检测——vecSkillCmd/vecInstanceCmd执行成员的内部检测函数，而当前回合结束后要删除所有成员(因为释放动作已经结束了，当然还要内存释放)。
& & & & 技能控制器的控制很简单，只需要在每次回合结束的时候清理vecSkillCmd的成员及内存释放，而vecInstanceCmd由于是管理的即时生效型技能，所以这个应该在释放完技能(即技能特效播放完)就需要清理及释放。
& & & & 而对于buff控制器则稍微复杂点，因为涉及到buff有没有被触发：
& & & & 1、对于触发了的buff，要做回合检测：达到了回合限制则开始清理buff——调整角色类role的成员buff_info的值(即清理buff的影响值，假如造成了10点扣血，则清理的时候要加回10点血)。这里可能需要解释一番buff的生效机制：假如触发了10点扣血的buff，那么role的成员buff_info里面的_hp数值就要调整为-10，表示扣血。每次对角色的数值信息进行结算的时候加上了这个buff值-10，就相当于实现了扣血功能，所以在清理buff的时候要加回10，buff_info里面的_hp数值就成为了0.
& & & & 2、对于没有触发的buff，则直接清理删除掉，这个跟技能控制器的清除管理思路类似。
& & & & 这个清理工作是在每回合结束时进行，清理函数设计为角色类role的成员函数，对于场景中的每个角色都执行内部设计的清理检查函数。
& & & & 至此这一周所做的工作便是这些了，写这篇博客相当于是对一周工作的总结，也不知道设计上哪些地方不合理了。不合理也木有办法，我所会的就是这些了。。。其实本来还想结合设计模式相关的知识来梳理一番这周的工作，可是还没有看相关的书籍所以不好怎么去梳理。总之设计模式相关方面的书肯定是要看的，最近在看《STL源码剖析》和《Programming in Lua 3》这两本书，看完其中一本之后便需要看关于设计模式相关的资料了。
& & & &在写完之后其实自己也想了一些改进：针对buff的最终影响类型——血、速、攻、魔等，写不同的类，然后统一让buff_command进行管理，这样是否便达到了可扩展的要求呢？今后如果还需要有额外的buff影响，那么只需要再添加额外的类让buff_command类进行管理即可？
& & & &不管这次的设计思路如何，总归是对自己的一种锻炼吧，之前毕竟没做过这些而今后总是会要做这些工作的~所谓的一些术语如：代码耦合度、代码复用、可扩展性等都是需要进一步的理解，在工作中需要再多注意的。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致分析让战斗系统富有趣味性的设计要素
发布时间： 09:41:23
作者：Mike Birkhead
我已经谈论过许多有关战斗的不同话题，比如如何设计敌人，如何设计遭遇战，如何确定差距以及深度和广度的重要性。上述话题涵盖了战斗的方方面面，接下来我们要讨论的是战斗的趣味性问题。战斗缘何显得有趣？对于这个满载着丰富内涵的问题，我们能否给出答案？我认为我们可以做到。
当你向玩家提供多种符合逻辑的意向和动作序列，随后通过目标、环境和对手等情境背景对其进行限制，这样战斗可以达到最佳状态。
意向和动作序列
动作的形成分为3个步骤：首先，产生目标；其次，选择意向，也就是实现目标的具体做法；最后，生成实现意向所需的动作序列。
1、目标：我想要杀死对手
2、意向：我想使用剑来杀死对手
3、动作序列：我要先拔出剑，走向对手，然后不断按攻击键
目标较为简单。它们清楚地显示出你希望完成的事项，但是缺乏具体内容。目标不会告诉你要如何实现，于是便有了意向。对于每个目标，其解决方案都不止一种。假设我想要打开一盏灯。可行的解决方案之一是走过去打开开关，但是如果我刚好看到好友经过开关，也可以让他帮我打开。目标保持不变，但意向已经发生了改变。
这对战斗设计有何启示呢？多种复合逻辑的意向，这个短语是指玩家应当有不止1种方法来解决问题，比如可以用多种方法为猫剥皮。但是，玩家机制和意向间并非总是一对一的关系，这让事情变得更为复杂。接下来，让我们通过例子来理解上述内容。
向玩家提供意向，这个方面的理解较为困难。奎托斯（游戏邦注：游戏《战神》的角色）带有的机制如下：轻击；重击；魔法攻击；特殊攻击；抛掷；躲闪；跳跃。
我承认，这些描述显得过于简单。是否需要将跳跃和双重跳跃区分开来？这值得考虑。但现在，我们先尽量保持内容的简单，随后你就会知道我这样做的原因。这是是构建到奎托斯身上的机制，你或许已经猜到了，这些机制可以用来决定其战斗意向。
奎托斯的目标很简单：杀死对手。但是，意向并没有如此简单。从表面上看，他有3到4个意向：普通攻击、特殊攻击、魔法攻击和抛掷。这是真实的情况吗？这些算是意向吗？这些问题并没有明确的答案。
funcombat_intentions(from gamasutra)
抛掷显然是种有意进行的战略举措，可以算是意图。但是，轻击之类的视为动作似乎更加合适。轻击是战略的一部分，抛掷属于战略。以下是较为完善的意图列表，但并不全面：
1、冲刺：不断做出动作且只使用轻击。
2、群体控制：做出大范围的动作，进行群体控制。
3、碾压：做出大型、缓慢和冲击力大的动作。
4、迂回：翻滚或跳跃避开伤害巨大的攻击，绕到怪物的背后。
5、发射：将东西撞向空中，然后让其停留在空中。
6、抛掷：抛掷不仅可以造成伤害，还可以让你不受到伤害。
7、毁灭：使用魔法造成全屏伤害，同时不对角色产生不利影响。
这些意向是你的战斗“动词”。那么，动作与意向间的区别在哪里呢？简单地说，卓越的意向能够生成各种不同的动作序列，当然不排除有某些意外情况。单步骤意向很无聊。如果我的意向是“轻击”，那么动作序列就是“让角色站立并猛按轻击键”。相反，如果意向是“冲刺”，那么动作序列就需要融合多项机制：翻滚，轻击两次，继续翻滚。
即便面对那些理解最为透彻的战斗系统，清晰界定意向也是件很困难的事情。我曾经花整整一天时间来界定奎托斯的意向和对应动作序列，发现很难将其具体化呈现。我对这款游戏较为熟悉，如果我面对的是这种情况的话，那么很难想象那些刚刚接触系统的玩家会有何表现。我声明这点并不是为了让你退却，事实上你应当带有些许害怕的心理，因为微小的恐惧感并不会对你构成伤害。我提及这些内容的目的在于，让你理解失败是完全可以接受的。不了解系统或操作错误同样能够将游戏玩下去。只需遵从规则来完成任务，你就不会出错。
现在，我们知道了创造多种符合逻辑意向的含义，接下来我们要分析战斗中最棒的部分。
提供选项是不够的，因为对玩家来说选项只是摆摆空姿态而已。此外，外来选项会对游戏和整体玩家体验造成损害。你每次增加玩家选择模型的大小和复杂性，就会加重他们思维上的工作量。研究者甚至创建方程式来讨论这个问题。这就是所谓的Hick’s Law，简单地说，这条定律表明人们做出决定所需耗费的时间与他所面对的可选项数量有关。
当你听到这条定律时，你会觉得这是显而易见的，但在设计战斗时却很容易被遗忘。战斗的发生是迅速的。一旦怪物做出动作，玩家要在几秒的时间内对其做出正确的反应。那么，我们要如何为玩家提供帮助呢？这时候就要考虑到限制性了。你必须用战略限制来挑战玩家，这些限制分为3种类型：目标、环境和对手。听起来似乎很棒，实际效果如何呢？
我在《魔兽世界》中玩的首个职业是术士，这是个提供大量选项随后睿智地以情境背景对他们进行限制的绝佳范例。作为术士，我可以做出的动作数量很多，还有3种不同的宠物供我使用，但是最终我总结出了两种主要意向。我可以专注于利用持续伤害法术，也可以专注于使用直接伤害法术。接下来，让我们考虑两种不同的对手，就可以看到我的选择受到怎样的限制。
面对战士：我应该怎么做呢？我会给他加上许多随时间持续造成伤害的法术然后与他保持距离，因为他没有应对这些伤害的措施。他没有驱散法术的技能，而只要我位于他的攻击范围之外，他就无法对我造成伤害。我的技能选择受到了对手类型的限制，因为我不希望让他追上我。他的某些技能导致我的部分法术失效，但这并没有关系，因为我还有更多能够对其生效的法术。
funcombat_spells_instant(from gamasutra)
面对法师：当面对法师时，能否采用同样的战术呢？当然不行！当面对法师时，我的意向与上述情况完全不同。我的计划是使用宠物之一令其晕眩，然后尽量与他拉开距离，持续施放最强大的直接伤害法术，直至其失望。我的持续伤害法术对战士极为有效，但是对法师则不然，因为他有驱散法术的技能。此外，我根本无法保持自己能够同法师拉开距离。他的移动比我快，而且他的法术射程与我的几乎相同。也就是说，对手的技能再次限制了我的意向。
funcombat_spells_cast(from gamasutra)
假如我正处在对手无法触及的悬崖上，情况又会如何呢？现在，我们开始考虑环境背景的问题。如果我面对的是战士，那么接下来就很简单了。他根本打不到我，我只要随意按动数字键就可以获胜。但是，这种优势在面对法师时便不复存在，这种特别的环境限制对他并不适用。那么，这是否表示法师完全无需担心环境限制呢？答案是否定的！
看看，这便是战斗变得愈发有趣的地方，法师必须考虑所谓的“视线”问题。他只能在看到我的情况下施放法术，所以法术的引导时间越长，在有藏身之处的环境中他便越难以用法术击中我。但是，术士有许多瞬发法术，这意味着我向他施放这些法术要更加容易。你可以看到，在这种环境背景下，我应对法师的意向发生了改变，侧重于使用另一套法术。这才是有趣的战斗。
但是，真正有趣的事情在于，目标的改变对意向和动作序列的影响。在上述两个场景中，我的目标都是为了杀死对手。假如我的目标发生改变，那么又会怎么样呢？假设我的目标不是杀死他们，而是尽量保证自己的存活，等待援军到来。如果是这样的话，我又需要完全改变自己所使用的技能。对于我来说，这样的系统才能称得上优秀系统。
到现在为止，上述内容的理论性似乎过于浓重。诸如意向、限制性还有我还未谈及的合适性似乎显得有点陈腐呆板。“只是电子游戏而已，别太认真。”显然，我并不同意这样的看法，我有充足的理由。真正有意义的讨论在于，如何解决所面临的重要问题。
题材转换是作为设计师可能遇到的难题之一。我们在设计某种题材游戏中所获得的知识和技能并不总是能够直接运用到另一种题材中，这个问题在关卡设计中尤为突出，特别是从动作冒险游戏转换成第一人称射击，反之亦然。
射击类游戏中的遭遇战设计与动作冒险游戏中的遭遇战设计完全不同，而这种差异可能给设计师带来巨大的问题。但是，赋予战斗趣味性的方式仍然保持不变：你要向玩家提供选项，然后通过情境背景来限制选项。两种题材的不同之处在于其选择的限制方式。
在多数情况下，动作游戏选择通过对手来限制你的行为，而射击游戏更侧重于通过环境来进行限制。这才是两种题材之间的关键性区别，接下来我们将对其进行更深入的探讨。
funcombat_constraints(from gamasutra)
我们已经分析过奎托斯的例子，这里不再重复。那么，射击游戏的情况又是怎样的呢？我的意向是什么呢？我们以《光晕》为例，因为这款游戏清晰地呈现出理解机制和理解意向两者间的差异。乍看之下，散弹枪、狙击枪和冲锋枪等武器的选择似乎是在向你提供意向，但这种想法并不准确。
应当记住的是，意向是你实现目标的具体方法，意向可以用来创造出一系列动作步骤。你或许会有“我想用散弹枪杀死这个家伙”的想法，但你更可能想的是“我有把散弹枪，所以我准备迂回袭击他。”你认识到这两个想法间的区别了吗？你的意向并非散弹枪，而是迂回袭击对手，而你之所以做出迂回这种限制性的选择，是由武器选择和环境设计共同决定的。
在《光晕》之类的射击游戏中，你还可以选择战斗的场地。目标依然是杀死对手，但是你的可行意向形成融合了对所拥有武器、战斗场地的可行路线以及对手所处位置的综合考虑结果。
当然，让《光晕》显得特别出众之处在于，游戏的AI迫使你改变或调整意向，因为对手会在战斗空间内不断移动。此刻迂回包抄或许是最优选择，但当对手移动到竞技场左侧后，策略便需要进行调整。现在，较好的选择应当是切换成冲锋枪来射杀对手。同时，或许在不经意间，对手阵营中有人利用了那条现在已被你忽视的迂回路径。
但是，射击类游戏同《战神》等混战类游戏相比仍显简单。在后者的环境中，制定意向时需要考虑到更多的内容。尽管如此，需要记住的是，他们的战斗准则是相同的。设计选项，设计限制性，最后将这些内容传达给玩家。
经过上文的讨论，现在我们到达了战斗系统设计的最高点：清晰性。意向和限制性都需要以清晰性为基础。玩家必须知道他们的选项，虽然玩家可能对目标不甚了解，但是必须让他们总是了解其实质。
目标清晰性和实质清晰性感觉似乎是相同的，但事实情况并非如此。二者间有明显的差异，但是如同选择数量过多或过少的微妙平衡一样，这种差异很难界定。实质指事物展现其独特之处的特征，但是它并没有阐明目标。它确实有其存在的目标，但是它不告诉你，至少没有马上告诉你。玩家需要自行找出目标。它会同玩家交流，有时还会与玩家玩类似《Hot and Cold》的游戏：呈现你的做法是好的，或呈现你的做法仍有不足之处。但是，目标不应当直接阐明。
这场选项、限制性和清晰性三者间的战斗感觉起来很复杂。我们向玩家提供仅可能多的工具，但不至于多到让他们觉得不知所措；我们用各种情境来限制玩家，但不至于多到排除所有的选择和个性化；最后，我们将内容清晰地传达给玩家，但不至于清晰到消除所有的猜疑和发现。我们就像禅师一般，不断地寻找探索折中之路，而智慧就藏在这个过程中。
当你向玩家提供多种符合逻辑的意向和动作序列，随后通过目标、环境和对手等情境背景对其进行限制，这样战斗可以达到最佳状态。当你看到这句话时会觉得它很简单，但我们现在都知道这完全是误解。
但你应当知道，这些并非战斗设计的规则。它们只是工具和指导意见，类似所有工具，它们需要在特定的时间和地点下才能发挥作用。
观察你正在设计的战斗系统，回答以下问题：意向有哪些？限制性有哪些？如果改变目标会发生什么情况？是否清晰地展示所有的内容？但是，最重要的是，看看是否能够从战斗中感受到乐趣，这个方面不可出现偏差。
游戏邦注：本文发稿于日，所涉时间、事件和数据均以此为准。（本文为游戏邦/编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）
Opinion: What Makes Combat Fun
Mike Birkhead
I have covered a lot of different topics about combat: How to design your enemies, how to design your combat encounters, how to define the gap, and the importance of depth and breadth. This covers a lot of ground, which is great, but it is high time we grasp for the slippery opponent that is fun. What makes Combat fun? Can we even answer a question so laden with meaning? Yes, I believe we can.
Combat is at its best when you provide the player with multiple valid Intentions and Action Sequences, and then constrain them through the situational context of their Goals, their Environment, and their Opponents.
Intentions And Action Sequences
There are three steps to an action: first, second, you choose an intention, which is the specifics of how you are going
last, you generate the sequence of actions needed to realize your intention.
Goal – I want to kill my opponent
Intention – I am going to use my sword to kill my opponent.
Action Sequence – I am going to pull out my sword, walk up to my opponent, and press my attack button over and over.
Goals are simple. They are clear declarations of what you hope to accomplish, but they lack specificity. A goal never says how you are going to do it, and this is where intentions come in. Now, for any single goal there may be more than one path to its resolution. Let’s say I wanted to turn on a light. One possible solution is to reach over and flip the switch, but I could, if I saw a friend pass by, ask him to flip the switch for me. The goal has remained the same, but the intention has shifted.
What does this mean for combat? To put it in plain terms, options. Multiple valid intentions, therefore, is a phrase that means the player must have more than one way to approach a problem — more than one way to skin a cat, in other words. Where things get complicated, though, is that it is not always a one-to-one correlation between player-mechanics and intentions. Here, let’s study a quick example.
Understanding what it means to provide Intentions to your player can be a bit confusing, but bare with me. Let’s start by listening some of the mechanics we provide Kratos.
Light Attacks
Heavy Attacks
Magic Attacks
Special Attacks
This is, I admit, a slight oversimplification. Do you list jumping and double jumping separately? Debatable. For now, though, let’s try and keep things simple, because you are going to see where I am going with this shortly. These are the mechanics that are built into Kratos, which, as you might guess, can be used to determine his combat intentions.
Kratos’s goal is simple: kill his opponents. It is his intentions, however, where things are not so intuitive. Seemingly, he has three or four intentions: normal attacks, special attacks, magic, and throws. Is that it? Are these the intentions? Here’s where it gets dicey, because the answer is both Yes and No.
Throwing, which is a clear declaration of an intended strategy, works
however, something like light attacks is more appropriately labeled as an action. Light attacks are a PART of a strategy, while throwing IS the strategy. Here is a better, but not perfect, list of intentions:
Poke – keeping on the move and using only light hits.
Crowd Control – committing to big moves, like special square, and controlling the crowd.
Crush – committing to big, slow, heavy moves
Flank – rolling and jumping around damaging attacks to get at the backside of a monster.
Launch – knocking things into the air and keeping them up there.
Throw – throwing is not only damaging, but also leaves you free from attack while throwing.
Nuke – magic is generally a get out of jail free card. All damage and no penalty.
These Intentions are the “verbs” of your combat. What’s the key difference here? Simply put, and with some fair exceptions, great intentions generate action sequences with variety. A single step intention is boring. If my intention was “light attacks”, then you are saying your action sequence is “stand and mash the light attack button”; conversely, if your intention is “pokes”, then you are saying your action sequence is a mixture of many mechanics: roll in, use two light attacks, roll away.
Clear demarcation of your intentions can be a tricky proposition for even the most well understood combat systems. I spent many a day crafting playgrounds for Kratos, yet I still find it hard to put them to specifics. If it is that hard for me, someone who is familiar, then you can imagine how hard it can be when starting down the barrel of a new system. I state this not to warn you off, or to scare you — no, actually, you should be frightened, as a little fear never hurt anybody. Instead, I bring this up to make you understand that failure is ok. It’s ok not to know, and it’s ok to get it wrong. Just approach the task with the deference it is due and you can’t go wrong.
This is only half of the equation, though. We now understand what it means to create multiple valid intentions, hopefully, but we have yet to review the second part of the equation. The best part of the combat is yet to come.
Constraints
Providing options is not enough, because options for options’ sake is an empty g moreover, extraneous options are damaging to the game and the player experience as a whole. Every time you increase the size and complexity of the player’s choice matrix, you are increasing the mental workload they must perform. They have even creating equations to talk about this problem. It is called Hick’s Law, and it states, in short, that the time it takes for someone to make a decision is a result of the number of possible choices he or she has.
It seems intuitively obvious when you hear it stated like that, but it can be easily forgotten when designing combat. Combat happens quickly. A monster acts, which forces the player to react within a split second, and to react in the correct way. So, how do we help the player? Well, that’s where constraints come in. You must challenge the player with strategic constraints, and these constraints come in three types: goal, environment, and opponent. That’s nice, but what does this look like in practice?
The first class I played in World of Warcraft was a warlock, and it is a fantastic example of providing massive amounts of options and then intelligently constraining them based on the context of the situation. As a warlock, I had a vast multitude of actions I could perform, and I had three different pets I could use, but ultimately I had two major intentions. I could focus on my damage over time spells, or I could focus on my direct damage spells. Let’s look at two different opponents, and we’ll look at how my choices become constrained.
Facing a Warrior — what am I going to do here? Well, I’m going to throw a bunch of damage over time spells on him and run away, because what can he do about that? Nothing, that’s what. He has no ability to remove them, and as long as I stay out of his range, he cannot hurt me. I am constrained by my opponent, because I never ever want to let him catch up to me. His abilities have made a section of mine valueless, but that is ok since I have many more that have great value.
Facing a Mage — what about a mage, do the same tactics work? Nope! With a mage my intention, is completely different. My best plan is to use one of my pets to temporarily stun him, get as far away as possible, unleash the heaviest damaging spells in my arsenal, and not stop until he is dead. My damage-over-time spells, which work fantastically against the warrior, do not work nearly as well, because the mage has the ability to remove them. Additionally, staying away from the mage serves zero purpose. He can travel faster than I can, and his spells have just as much if not greater range. Again, I am constrained by my opponents abilities (and he, mine).
What happens when I am up on a ledge? Now we are dealing with environmental context. In the case of the warrior, all bets are off. He can’t even get to me, so I can just roll my face along the number keys and la meanwhile, the mage doesn’t give one lick that I am on a ledge, as this particular bit of environmental constraint does not apply to him. Is the mage completely immune to environmental constraints? Nope!
See, and this is where things get interesting, he has to worry about what is called “Line of Sight”. He cannot cast a spell at me unless he can see me, so the longer his casting time, the harder it can be to hit me in an environment with opportunities to hide. As a warlock, however, I have many “instant cast” spells, which means that I have a much easier time casting those particular spells. So you see, in this environmental context, my intention against a mage shifts to use one set of abilities to another. That’s interesting combat.
Where things get really interesting, though, is when you change the goal and see how that affects the intentions and action sequences. In both those scenarios above, my goal was to kill my opponent. What if my goal was different? Let’s say my goal was NOT to kill them, but to simply stay alive as long as possible until help could arrive. Suddenly I am going to make use of a completely different set of abilities. That, to me, is the sign of a great system.
Right now, this all seems a little heady, a little academic. Words like intentions, constraints, and even, though I haven’t brought it up, affordances can all seem a little bit stuffy. “It’s just video games, man.” I disagree, obviously, and I have good reason. Meaningful discussions are how you overcome important problems, and great discourse is only possible when you all share the same lexicon.
One of the great difficulties of being a designer is switching genres. Our knowledge and skills acquired in one genre are not always directly applica this is especially true when deali even more true when going from action adventure to first person shooters and vice versa.
How you design combat encounters in a shooter is completely different from how you design them for an action adventure game, and this difference can pose great problems to designers trying to and yet, what makes combat fun is still defined the same way: you provide the player with options, and then constrain those options through a situational context. It is in their choice of constraints that they differ.
Action games, in the most general sense, choose to constrain you through your opponent, while a shooter places greater emphasis on constraining you through the environment. This is a critically important distinction to make, and through this lexicon we can discuss the difference in a meaningful way.
We’ve already looked at Kratos, so we shall forgo the double comparison, but what about shooters? What are my intentions? Let’s look at Halo, because it brilliantly showcases the difference between understanding your mechanics and understanding your intentions. It might appear, at first glance, that the weapon selection — shotgun, sniper rifle, and battle rifle — provides you with a set of intentions, and while this is a great guess, it would be off.
Remember that intentions are the specific way you are going to achieve a goal, and they are used to create a list of action steps. You wouldn’t say “I’m going to shotgun this guy” – I mean, you could, but it is more likely you would be saying, “I have a shotgun, so I’m going to flank him”. Do you see the difference? Your intention is not the shotgun, but instead flanking, and your constrained choice of a flanking maneuver is a combination of your weapon choice and the design of the environment.
In a game like Halo, or any shooter I like, the options provided to you include options on the field of battle. The goal is to kill your opponents, but your possible intentions are formed through a combination of what weapons you have, the possible ways to navigate a combat space, and the positioning of your opponents.
What sets Halo apart, of course, is that their AI forces you to alter or adjust your intentions as they dynamically move through the space. The flanking maneuver might be the optimum choice, until they move to the left side of the arena. Now, instead, the better choice is to switch to your battle rifle and catch them as they advance through gaps. Meanwhile, unbeknownst to you, a brute has used the very flanking path you ignored. Shit!
This is in pretty stark contrast to a melee focused game, like God of War, where the environment is, for the most part, meant to get the hell out of the way – flat, always flat! What is important to understand, though, is that the principles of their combat is the same. Design options, design constraints, and then finally communicate them to the player.
Communication
This brings us to the culminant point: clarity. All of this, both intentions and constraints, is contingent upon there being absolute clarity. The player must know what their options are, and though they may not know their purpose, they must always know their essence.
Clarity of purpose and clarity of essence feel putatively similar, but do not be fooled. There is a meaningful difference here, which, like the subtle balance of too much or too little choice, is difficult to thread. The essence — how it looks, feels, sounds, acts, and reacts — of something will outline its unique plac it is not, however, going to spell out its purpose. It has a purpose, yes, but it isn’t going to tell you — at least not right away. It leaves that up to the player to learn. It speaks to the player, and it can, at times, play a game of Hot and Cold: showing what you did was good, or showing what you did was bad. But it shouldn’t, unless core, be spelled out.
This battle of options, constraints, and clarity can feel Herculean. We provide our player with as many tools as possible, but never so many that he is overwhelmed
we constrain the player in various situations, but never so much that we remove all ch lastly, we communicate with clarity, but never in a way that removes all doubt and discovery. Like zen teachers, we are constantly in search of the middle road, and there is as one of my favorite quotes says, “Add things until it starts sucking, take things away until it stops getting better.”
Combat is at its best when you provide the player with multiple valid Intentions and Action Sequences, and then constrain them through the situational context of their Goals, their Environment, and their Opponents. It sounds simple, when you read it, but we both know that it is not.
Admittedly, I tend to write with great force — all “musts” and “requires” — but know that this is not a rule. It is simply a tool, a guide, and like all tools it has its time and place. Take comfort in it, as in all likelihood it will guide you to the right questions, but do not become married to it.
Look at the combat you are designing and ask the good questions: ask yourself for a li ask what constr ask what happens if
ask if you are showing it all with clarity. Most of all, though, ask if you are having fun. You can’t go wrong with that. ()
CopyRight Since 2010 GamerBoom All rights reserved &&闽ICP备&号-1