标签归档:万智牌

万智牌设计与平衡(6):物件生命周期

不少游戏有着庞大的物件数量,过段时间之后你希望在这类游戏中加入更多物件(收集式纸面游戏和MMORPG会比RTS更频繁)。这种时候管理物件生命周期就相当重要了。因为你添加了新物件,你想要让玩家觉得这是有趣的选择。这是一个我几乎不提及的大主题,但完全不提它我又觉得疏忽了什么。

你有3种方案来引入新物件:

a)它们和你当前的物件威力差不多
b)它们比当前的物件强得多
c)它们和之前的的物件差不多,但你把老东西废了(套牌轮换)

从短期来看,a方案和b方案是较为合理的选择。但是最终a方案会导致所有新物件在成千上万的现有物件面前毫无价值。大多数牌组(或部队、角色)都会选择使用老物件,老物件的池子更大更可能有好东西,即便新物件整体水平和老物件持平但它们看起来还是会比较搓。不过这方案对于物件池比较小的游戏(例如RTS的一两个扩展包)还算不错。

如果用b方案那新系列看起来很振奋人心,但随着这类物件越来越强力,游戏系统很可能会在这种负担下崩溃。若在你的游戏中更多强力物件意味着快速制胜,那你最终会迎来游戏会一回合收场的状态。如果强力防御在游戏里戏份很大,那也许有些策略会变得无人能挡,然后多数游戏局会陷入困境。理论上来说,游戏规模可以被无限放大(纯数字游戏的每个数都翻倍之后和之前本质上是一样的),但实际上高度复杂的游戏总会在某种规模时崩溃。你也许觉得你的游戏永远不会到那一天,所以b方案或许是个好选择。由于技术原因,电脑游戏的寿命都不太长,所以超长期的考虑有时也没什么用处。

顺便插一句,要记得就算没加入任何新物件,你也能在RPG的升级过程中发现一种新东西越来越强的现象:你用30级的道具换掉了20级的道具,以此来保证你对新道具的渴望。但我在这里主要说的是游戏持续运营过程中加入的新内容。

如果你做长线考虑的话c方案是必然的选择。如果想让游戏持续10年,并想在这期间持续引入新的玩法物件,就必须抛弃某些老物件才能避免新东西越来越强。不过玩家会因为你拿走了他们的老物品而对你很生气。你有几种方法来缓解这种愤怒,然而你不可能完全消除它。一种就是让玩家有一个专门的模式来玩他们的老物品,这个模式不太受新加物品的影响,新玩家不太可能参与其中,只有老玩家才能玩好这个模式。另一种方法是利用“潘洛斯阶梯”的力量,让每次要加入的系列看上去都比之前的更强(这样玩家就会觉得新东西比老东西好),但要做得好是一个微妙又艰巨的任务(理论上让两个系列按照剪刀石头布的关系排列就可以,一套里的物件可以克制另一套里的物件)。

无论你选择采用哪个方案,都要在测试新物件时记得将它们和老物件进行对比。人在测试时自然会趋向于使用新玩具。但这样很容易让所有新物件之间挺平衡,却没有和老物件平衡。

记住仍有一大堆问题是关于如何应对某些损害游戏体验的物件,你要决定是消除它、限制其使用还是修改它的功能。本文的重点是在游戏发布前调好平衡性。要当心,无论你之前多么仔细地平衡物件,有些问题物件还是会从你的眼皮底下逃过。当这些问题发生时处理起来相当痛苦(对你和你的用户来说都是),任何使它们尽量不出现的努力都是值得的。当然这些问题太多的话你的游戏就不可挽回了。

万智牌设计与平衡(5):如何构造物件费用

从某种意义上看,这个部分才是这篇文章的重点。我会列举构建物件的费用和平衡的各种技巧,大致按重要程度来说。

一些警告:这些最多是一些经验法则,不是绝对律法,有大量的例外情况。尽管我挑选的问题都尽量普适通用,但根据你开发的游戏类型,有些问题影响会更大。

1.调整费用而不是效果

如果有物件对它的费用来说太强力了,人们会注意到它的效果并想将其调低一些。抑制住这种冲动,最好先调整它的费用,这样你才能指望保留这个物件的特色和原始设计意图。即使一个物件看上去不好玩,也要扪心自问:使用它的人觉得它不好玩?也许它的费用该少一些,使用者就能找到乐子了。对面玩家觉得它不好玩?也许它的费用该多一些,这样对面的人能少受它的蹂躏。

除了保留设计意图外,首先调整费用还有其他好处。如果你反复调整费用,那么你在几轮迭代中做的事情会很好理解。反之一个大的效果变更往往意味着你的测试工作将重新来过,因为现在你相当于有了一个新物件。而且,如果你发现一个物件对它的费用来说太强力了,然后你调高了它的费用,那么你会收获一个昂贵的大单位。这样的物件会比那些便宜弱小的物件带来更多乐趣。

有时候确实需要调整物件的效果,不管它费用多少都显得很没趣(尽量避免那些会被人抛弃的效果)。有时候一个效果很难在不伤害整个系统的前提下构建费用(详见“不可量化效果的危险”一段)。但是改变费用应该是你的第一个想法,常常也是你接下来的想法。

2.单点理论

在有些游戏中,物件伴随着很多与之相关的数字。你通常只想要一种数字来代表费用,这样便于调整。否则,构建费用问题会变得过于复杂。这不意味着你不会去调整其他参数,而是说你会以一种数字来进行考量。举个例子,如果你的RTS单位消耗黄金和木头,想出一个合理的转换率(不必很完美,你可以在之后调整它)然后用黄金为单位写下所有东西的费用。这样你就能知道单位A是不是比单位B更贵了,而且当你增减费用时也能一眼看出。如果没有现成的数字可用,你可能要生造一个——就像魔兽世界中的物品等级。你在构建一个被经济学家称作价值标准的东西(一种或许有些武断的单位,用来度量你所有的费用),源自相同的理由。如果你稍微思考一下会发现规则1暗示了规则2。

3.色轮无处不在

在万智牌中,有5种颜色的卡牌,分别花费5种颜色的法术力。这看起来好像很特别,但其实我想说这其实很普通。

万智牌的色轮有什么用处?它是一种鼓励玩法多样化的方法。如果法术力没有颜色,我就只选最好的牌(在给定费用时)放进我的牌组。但在有色轮的情况下,如果我选了红色牌我就需要红色法术力,这会让我继续用红色牌变得更容易。现在(假设开发者已经搞定了平衡性)我也许构建了一套红色牌,或绿色牌,或蓝色牌……我有5倍的牌组类型。事实上我还有更多,因为还能构建双色牌。如果我搞了一套红绿牌组,有时我会挺难过的因为我的法术力是红色却想打一张绿色牌,但双色让我有更大的选择面(牌池),对我很有帮助。玩全部5种颜色可能太多了,我会时常面临牌色对不上的情况,但根据法术力生效的具体细节我大概可以用1到3种颜色。(如果我始终可以轻松地用5个颜色,那色轮对我就没意义了。又回到了在给定费用时选最好的牌的情况)

为什么这是一个普通的现象?因为基本原理就是在玩法物件中强化关联性可以增加变数。大多数时候关联性是100%的:如果你是神族,那你只能建神族单位。如果你个是牧师,你只能施放牧师的法术。但有时候也并非如此:如果在RTS中你升级箭术建筑,你会制造更多弓箭手,但你仍会有一些近战单位。如果你采了很多气,你可以造一些花费气的单位,但你仍然可以造那些花费水晶的单位。

确定你游戏中的“色轮”以及在宽泛(使用多种颜色较容易)和狭窄(必须专注某种颜色)之间做平衡是开发良好系统的重要内容。考虑两个因素:

a)使用多种“颜色”有多难?强制你建造气矿或花钱升级箭术把你分别推向耗气单位或弓箭手。你必须选择一个职业,做牧师和盗贼截然不同。

b)每种“颜色”有多少独特的东西?如果只有红色法术能直接伤害对手,那你会想要向牌组中加入红色牌(即便使用多种颜色会困难一些)。若每种颜色都可独立做任何事,那你只会选一种颜色用——不会为此多费一丝力气。

像万智牌这样的系统较好平衡了以上两个因素,所以你可以混合搭配颜色或者使用单一颜色,玩得好的话都很吸引人,当然要玩好不容易。平衡职业制RPG(强制使用一种“颜色”)已经够难了,平衡纯粹的加点制RPG(可以把任何牌加入牌组中)更是难上加难,而且可能永远无法成功。这些系统看似有着不错的多样性,但实际上容易退化为只有一种角色模型可用。

值得注意的是如果很容易使用多个颜色,或各种颜色完全没特色,那么你的游戏其实不存在“色轮”。还要注意的是玩家和你团队中多数初级设计师会倾向于更容易使用多种颜色,以及让每个颜色都有别的颜色的“独占能力”,别对这种倾向屈服。

4.剪刀石头布

剪刀石头布是一套异常强大的设计工具。假设你的游戏有3种玩法单位A、B、C,你想要把它们的胜率平衡在50%左右。你肯定会出错然后发现B对A的胜率是53%同时对C的胜率是57%。于是每个人都会只玩B了,你的游戏就会变得很无聊。但如果你让A克制B克制C克制A(克制意味着60%的胜率),那么除非极端情况,这三者都能保持可用(不是完全相等的比例,但已足够)。当然,让克制的胜率为100%更安全,但游戏可能就不太有趣了。

好游戏会把剪刀石头布体系用在各种地方。有时候很直白:骑兵打弓箭手时+2,弓箭手打步兵时+2,步兵打骑兵时+2(坦率地说我觉得没什么道理)。有时候很优雅:许多RTS游戏中地面近战克地面远程克空军克地面近战。

有些例子则是特殊能力单位输给拥有克制该能力的单位,该克制单位又输给普通单位。所以如果一个单位使用foo攻击(造成25%额外伤害),它就会输给具有foo防御的单位(只遭受一半foo攻击,但其余属性较低,比如血量少5%),这种foo防御单位就打不过正常单位。 从防御角度来看一个类似的例子是装甲单位、穿甲单位、普通单位。

一个微妙的剪刀石头布适用于许多游戏,包括大多数集换式卡牌和RTS游戏,在这种游戏中越后期创建的单位越强大。如果在游戏后期出现的单位不是单纯强大,而会同样更昂贵的话,你会得到这样的动态关系:

1<2<3<…<n-1<n<1

稍微出现得晚一些但是更强大的部队能让你赢得游戏。但打算非常晚才出一个很牛的部队不是件好事……可能在部队准备好之前你就输了。(上面的动态关系在RTS中代表研究套件,在集换式卡牌中代表法术力费用)

注意,你必须仔细处理剪刀石头布影响的轻重。如果蓝色套牌始终战胜绿色套牌、或盗贼始终战胜牧师,你的整个游戏环境还是具有多样性的(如果你把其他的剪刀石头布处理好了的话),但当个体玩家处于上述较量的被克制一方时他们会觉得没那么有趣了。

在游戏中使用剪刀石头布的技巧是尽量识别出该结构在哪,各个单位在其中扮演何种角色,然后确保每个单位都有所克制(它才有用)以及能被谁克制(才不会淘汰谁)。记住穿甲单位克制装甲单位很容易,但是记住普通单位克制穿甲单位要难一些。

5.别忽略白板曲线

大量的时间和注意力都会浪费在那些具有特殊功能的游戏物件上,为它们定费用是一件非常有挑战的事。但尤其在系统开发阶段,我们聚焦于白板曲线:那些只有基本属性的白板物件的费用。即便这看上去有些琐碎无聊,用费用正确地衡量该物件的能力,或属性A与属性B的价值换算,对于这个物件本身(多数游戏都有大量白板物件)和物件体系的地基是非常重要的。你会发现那些最善于“解构”特殊物件的开发者(从其中找到巧妙的组合)并不太擅长平衡白板物件。

当你调好了白板曲线后,你就能看看别的物件然后说:“好吧,这些属性值这么多,同时我们做了别的也有同样能力的物件,所以我们知道这种能力值多少了。”如果你知道如何在白板曲线(走运的话它会是线性的)里正确地添加能力的费用,就能为某个物件定费用了。如果你办不到这点,那每个物件都会需要进行玩测,你会早早耗尽测试资源。当创造出新物件时,你会想要尽量把测试精力放在新能力上而不是那些老能力的新组合上。一个坚实的白板曲线可以帮你实现这一点。

6.流程

我已在之前讨论了好几种组织设计和开发团队的方式,在这里不再赘述。

7.监视列表

让开发员多玩(开发中的)游戏是很有价值的,当东西做得越来越像样之后也要确保他们这样做。在开发的早期阶段,他们应该多关注游戏的乐趣性而少关注平衡性。之后当你聚焦于平衡问题时,在你团队中至少要有几名精英把时间花在解决那些破坏平衡性的东西上面。

所以说以良好的方式分割工作还是有意义的。我找到一个好办法是让所有的开发人员都到同一个房间里,列出所有被认为可能有问题的物件然后指派一些人去测试。当到了评估这个东西的时候,那个测试它的人很可能已变得喜欢它了,所以尤其要认真倾听作为对手人员的反馈意见。如果他们都认为这东西没问题,那很可能就真的没问题。如果测试者认为该物件挺平衡但别的人都讨厌它,这就是一个危险的信号。

8.辅助设计师的简单数据库

我们喜欢把所有卡牌的玩法数据放到一个简单的数据库里以便设计师和开发员使用。对于一个新游戏来说,至少部分设计师和开发员要能够直接修改这个数据库(例如添加新字段),这点很重要。数据库里除了数据之外还有很多评论。

对于一些复杂的游戏来说,单点(见第2部分)在哪并不太明显。在数据库里用一些公式将能力转化为单一的费用就比较方便。在理想状况下,每条不同的玩法属性都会转化为一个费用,任何特殊能力都会转化为费用(独特的能力需要估算并手工录入),一些合理的算法将它们联合表示为一个代表此道具效用的数字(尽可能准确)。于是这个道具在游戏中的成本就表示出来了。请注意这些数字不一定要都相等。一个有趣的游戏既需要好东西也需要烂东西。不过一个好的游戏开发员需要知道哪些是好那些是坏,且价值几何。

测试的价值远大于其成本。而评估公式或独能力的价值表面上不划算,但开发员还是大量用它们。

就这种部分自动化算费所需的工作量而言,不是所有游戏都值得这样去做。但那种持续运营的游戏(MMORPG或系列RTS游戏)能付得起这样的成本。拥有一个所有开发人员都可以写评论(而不是一个只有一个人会读的脚本文件)的数据库也总还是有价值的。

9.玩测vs理论分析

我在这儿写的大部分东西可能会给人一种我觉得理论分析比玩测更好的印象,或者精妙的公式会比实际玩游戏告诉你更多内容。实际上,我所认为的恰恰相反。理论分析经常犯错,目前为止玩测是最好的检验方式。但玩游戏的花费是很大的(尤其是测试概率性的东西),况且不可能有足够时间测试所有东西,甚至是其中相当小的部分都不可能(一旦你又掺入了交互)。所以即使很多理论分析在之后的玩测中都变为了空话,但还是值得去做。我发现2小时的高效讨论由100分钟毫无意义的理论分析和20分钟足以节约一周工作的干货构成。

然而要记得,如果人们在一个理论上反复争论了很久而毫无进展,那么最好搁置讨论直接试一下(不过在大家都有一些实际数据后有时候还是会值得回来继续争论)。

好的理论对确定那种需要特殊测试的危险区域尤其有价值。如果你知道法力值快速恢复或摸牌会出问题就能更仔细地测试它们。

10.为多种环境做开发

你的游戏常常会以多种方式来玩,但是每次都会使用一些相同的玩法元素。在万智牌中竞赛选手和休闲玩家可能会用同样的牌,或者同为竞赛选手也有玩轮抽和构筑赛的。在魔兽世界中也有很多休闲玩家和硬核玩家,大多数硬核玩家会在raid公会里或者忙于PvP。在一个环境中平衡的东西不一定在另一个环境中也平衡。因此即使在理论上也不存在一套柏拉图式完美平衡的道具。

如果你接受了并非所有物件都需要在所有环境都可用的观点,那么这么做理论上就没多大问题:让这个物件在它最适用的环境里做到平衡,并接受它在其他环境里不那么好这个事实。实际上,你不会有资源去测试所有环境中的所有物件。你最好的办法可能是挑选最具平衡压力的那个环境(往往是最具竞技性的环境)来做测试。如果一个物件看起来在其他环境出奇地好,你可创建一个特例来测试。

当心那些在你最重要或最流行的环境中的测试陷阱。如果你认为万智牌的限制赛或魔兽世界的PvE是最重要的内容,那不意味着你要将平衡测试专注于此(当然,你应该玩玩它们看是否有趣)。你应该把万智牌的构筑赛或魔兽世界的PvP作为最有物件平衡压力的环境并拿它们做测试。如果物件在高压环境做到了平衡,一般来说在低压环境里也会不错,少数例外也能被识别出来。

11.黑莲花效应

在你游戏中有一个不平衡的物件会怎样?也许不是强到逆天(无论使用者还是对手的游戏体验都被其支配)但是每个人都想有一个?如果你被开发者/平衡者的心态包围,你也许会觉得踩灭这些东西就是你的工作。一般来说这是正确的,不过我也要承认这并非完全正确。如果它不是碾压性的,万智牌里的黑莲花(或是魔兽世界中的正义之手)也能制造很好的效果。每个人都想要它,每个人都为它而激动。只要不是太难获得,每个人都有机会获得一件极品,他们能因拥有一件真正的好东西而感觉良好,而不是只能获得它们买得起的东西。

很多东西看上去都很类似。但也许有那么一些让你的游戏收获大于损失。记住游戏还是损失了一些东西:如果游戏里有一件最好的靴子,没有谁比它更好了,那么当一个角色穿上它的时候就等于删除了角色的靴子孔。游戏中其他的所有靴子都没有意义了。不过也许有时候这种成本是可以接受的。它肯定能成为玩家之间的谈资。

如果这道具会弄得对手很不爽,或者是否拥有它直接决定了游戏结果,那可能就太过了。

12.不可量化效果的危险

大多数物件都是可量化的:它们增加你的属性或者造成一定量的伤害或者是具体身材的生物。但有些物件不是:一个摧毁敌对生物的法术(无论范围多大),一个治疗友军所有伤害的法术(不论多贵),或取消对手施法的一踢。这些物件可能会比较危险。它们通常能被定价(如果只用2费太划算了,那你愿意花8费使用它吗?),但它们在度量上的缺陷会导致不好的效应。

在像万智牌或RTS这种由玩家支付费用的游戏中,这些道具会伤害到其他道具。如果你的摧毁任意敌对生物的法术要花4费,那你就很难使用超过4费太多的生物。也许5、6费你能接受但8费就不行了。一个杀死生物的法术很酷,但它值得让你不再使用所有昂贵的生物吗?你可以设计这样的物件,但它们会强烈影响其他物件,你要早做思考。虽然游戏系统开发一般聚焦于白板曲线,你仍然要尽早决定是否要设计这类非黑即白的法术并且在它们存在的同时平衡好白板曲线。从平衡角度来看,一个有“杀死生物”效果的游戏和没有它的游戏是有很大不同的;一个有“治疗你所有伤害”法术的游戏和没有它的游戏也是有很大区别的。

在MMORPG里这个问题常常以稍微不同的形式出现。角色升级后很多道具就该被淘汰了,但非量化道具很难被淘汰:治疗一个人的全部HP始终是很棒的,很难再有一个比它更好的治疗法术了。类似的还有获得一次额外攻击、阻止敌人的施法。一旦你给了玩家这样的好能力,如果它是非量化的,那你之后可能很难给他更好的了。

很难避免非量化道具,因为要摆脱它们常意味着把一些既简约又好玩的东西(获得一次额外攻击)变得不那么优雅(在40级以下获得一次额外的攻击)。但要小心这些道具会导致的潜在问题,决定它们是否值得。也许它们能被调整一下,也可能会成为你的“黑莲花”。

13.平衡出现较晚或稀少的强力效果

一个在卡牌游戏或RTS中出现得很晚的单位(往往由于其高费用或长科技树)是平衡上的棘手问题。人天生会对游戏里的这种东西进行评判。主要是它们出现得很晚或很少,甚至常常没机会出现。如果大多数牌是4费而巨龙是8费,那么许多盘游戏结束时它都会停留在你手牌里。它需要非常强大的能力作为弥补。如果你想让巨龙成为高端玩家在组牌时的可行选择,或者你想让大舰成为星际争霸中人族玩家的可行选择,那它或许应该比你第一眼时的感觉更强一些。如果你只要有办法放出一个超强的单位就能自动获得胜利那就太无趣了(而且就算它好玩,你也必然没法做出比它更贵的单位了)。因此大多数费用系统至少在可用单位中都有一个花费上限。

14.灵活性有时候没你想的那么有用

一般来说专注某一项的东西是最好的。单项很极品的物件好过多项表现平平的东西。所以一个四种属性+3的戒指应该比一个单一属性+12的戒指费用更低。一张允许你选择两种能力中的一种施放的牌并非是一张只能施放一种能力牌的两倍(实际上,我们的经验是先把这两种能力调得一样好,即它们的费用差小于1点法术力)。灵活性并非无用,但它往往没你想的那么有用。

15.错过目标的另一面

如果事实证明某个物件很难平衡,你通常想矫枉过正而不是一次次做小修改。如果盗贼太弱了就把他改强。如果毁灭之剑太强了就把它改弱。一旦两者你都错过了,那把它放到下次迭代中会容易一些。

这类平衡游戏物件的方法没法把一个无聊的游戏变得有趣。但它们可以使那些本来很有趣但有成千上万玩家在寻找系统漏洞的游戏免于崩溃。当下越来越多的玩家通过互联网分享他们的策略(要么通过攻略网站要么是直接在游戏里一起玩),对游戏保持平衡的压力已是相当之大。游戏设计师和开发员需要用上浑身解数来做到这一点。

万智牌设计与平衡(3):设计vs开发

接下来让我们直接进入专业问题。游戏的设计过程可以分为两部分:设计游戏方案,对这个方案进行调整。对电脑游戏而言,两者并没有明确界限,统称“游戏设计”是合理的;但在威世智,它们有着明确的划分:前一部分称为“设计”,后一部分则是“开发”。很显然,下文提到的“开发”并不具备电脑游戏世界里的一般含义,它专指调整的过程。在电子游戏世界里,“开发”与“编写游戏程序”是某种程度上的同义词,有时还指代“从提出构思到完成作品的整个过程”。同理,“开发员”也并非一般意义上的程序员,而是调测游戏方案的专门人员。如果把游戏看成一幢建筑,设计师就相当于建筑师,而开发员就是工程师。建筑师做得不够好,最多是房子不讨好;工程师做得不好,房子就会倒塌。

从以往的经验当中,我们知道不同的人可能只擅长研发工作的其中一部分,威世智较早意识到这2个角色间的区别。以万智牌新系列的开发为例,研发团队的其中一组设计师设计出一套全新卡牌,另一组开发员则接手调整费用、异能和其他事项。设计师的工作多数依靠天马行空的个人创造,开发员则遵循一套成熟的技术展开团队协作,将前者的创意成果调整到合理状态。设计师们会有限度地试玩自己的创作,目的是体验新作品的实战感觉;而同样的事情对开发员来说则是家常便饭,解构——修正——再解构是他们的主要工作。

比起开发人员,适合担任设计师的人才更为稀有,也很难为它们提供行之有效的职业培训。设计构思更像一种艺术而不是科学,开发则正好相反(当然,两者都有两面性)。包含大量物件的游戏所需的开发人员远多于设计师,前者较易通过职业训练来培养因而就成了值得庆幸的事。一个研发团队可能只需1-2名设计师,但却要4-5名开发员一起工作,才能达到最好的效果。

构思和研发相互独立的开发模式在扩展系列的设计中运作良好;新游戏——尤其是拥有众多游戏物件的游戏,开发过程就显得较为繁琐,一般可以分为如下四个部分:

基础玩法设计(“系统设计”)
基础玩法的调测和修改(“系统开发”)
游戏物件的创造(“系列设计”)
物件效果的调整和费用确定(“系列开发”)

上面只是概念上的划分,在实际工作中,四个部分之间显然是互相关联的。更大的项目甚至会动用4个团队,每个团队专门负责其中一部分工作;即便是只需一个团队的小项目,保证成员之间分工明确也是很有必要的。

接下来,请允许我向大家介绍各部分的具体内容、为什么要这样划分,以及它们彼此之间如何有效地进行沟通。

游戏系统的初始设计是最困难的部分。这里没有一成不变的规则,没有一步登天的捷径,我也不会试图向大家讲解(个人甚至不确定它能不能被讲解),但有几点可以明确:在这阶段,尽管设计师必须拿出足够数量的游戏物件来证实可玩性,设计过多的物件却很可能是个错误,进一步开展费用调整就更不用说了。

系统开发也许是最难讲解的部分,它包含游戏系统的基本调整和规则漏洞的填补两大单元;而最不显眼(却又同样重要)的环节则是费用系统的构造。没有合理的系统,游戏会面临严重的费用平衡问题。各位可以把费用系统想象成一套挂钩手柄(更形象的比喻是一系列带刻度盘的把手,这样你就可以调整它们),你将围绕它构建一套平衡过的游戏物件。每款游戏都有一定的物件(武器,咒语,人物职业,诸如此类),这些物件却不一定有合适的费用。所谓“合适”,意思是既简单又可靠:“简单”以致玩家可以轻松地理解和应用,“可靠”确保它有效地覆盖所有物件,从而在可用物件有限的情况下维持游戏环境的多样性。举个例子,如果国际象棋可以自选棋子,规定“每位玩家必须选择16枚棋子”就能视为一个费用(每选择一枚棋子,就占用了起始棋位的1/16);然而这系统并不可靠,因为在这样的规则下,人们可以用16枚皇后展开游戏。

系列设计阶段,研发团队将设计所有游戏物件。本阶段的重点是趣味性而不是物件间的平衡,所有物件费用都只是暂时性的。

进入系列开发阶段,物件将被赋予更准确的费用,其平衡性也会被反复的测试所验证。早期犯下的错误在本阶段会被发现和清除,但如果系统开发没有赋予足够的趣味性,本阶段对此将无计可施;如果系统开发没有创造出合理的费用系统,本阶段就无法对物件进行平衡。部分物件会被大幅修改甚至剔除,但总的来说,开发人员会尽可能保留每一个物件,而完善的费用系统对此很有帮助。

当然,这些阶段之间并不是、也不该是完全独立的。系统设计和系列开发显然应该分列首末,剩下两部分孰先孰后却有待商榷。不清楚物件细节的情况下设定规则细节显然毫无意义,没有既定系统的情况下凭空设计游戏物件同样并不可行——因此,这两者总希望自己被安排在对方之后开展。对此,安排两者同时进行,促进它们互相交流、互通有无,也许是最合理的解决办法。

对小型游戏的开发团队而言,小组之间有时会出现大量人员重叠,典型的工作安排甚至可以是这样的:一到两名设计师完成游戏系统的初始设计,交给系统开发员做测试,而其中一名设计师随即转入系列设计;系列设计完成后,负责系统开发的人员系列开发的工作。即使工作小组之间采取彼此独立的编制,人员重叠对保证设计工作的连贯性也非常重要,尤其在开发人员修改原始设计的时候,设计师的参与可以确保人们明确设计意图,从而找到两全其美的方法——至少也在知情的情况下改变设计意图,避免“意外”篡改的情况出现。允许小组成员扮演多个角色通常是件好事,团队领袖却不然,设计组的负责人应该始终坚持并代表团队的意念,受到质疑时必须站出来辩护而不是简单地解释和妥协。

综上,设计师的责任是游戏趣味性,开发员的责任是排查可能出现的问题——进入开发阶段的游戏却可能不怎么有趣,这可能因为游戏本身并不好玩,也可能是大量的修改扼杀了游戏乐趣。无论原因为何,解决问题的关键在于不让开发员们僭越到设计师的领域。经验老到的首席开发员可以敏锐地察觉到这种情形,也懂得提请上司将设计打回重做(是否由同一个设计团队重做则是后话)。

如果只看上面的描述,读者们会认为游戏设计无异于流水线式的自动生产,其出品也必定了无生气。实情并非如此。下面请允许我举例向大家说明,这样的拆分为什么有利于想象力自由发挥。

假设我们将为集换式卡牌游戏设计新的扩展系列。某人在研发初期提出一张新牌,这张牌看上去很有趣,但又有点非同寻常。年资较低的研发成员常认为“这张牌太破坏平衡,不能采用”;而所谓“破坏平衡”,意思是其效应以当前的费用来看太具破坏性(总体上超强)。如果把这张牌交给某位资深的开发员,他可能会这样评价:“哦,你看,这张牌现在是3费,所以有点过强……改成8费会不会好点?”得到的答案通常是“8费太高了,估计没人会用”,之后这张牌就被顺利收录了……一张新牌应该设计成3费、8费还是两者之间,这是开发阶段探讨的问题,但那并不等于“有了合适的费用,不管什么创意都会变得可行”,再怎么研究和修饰有时也不能让无趣的机制变得有趣。但如果设计团队愿意承担设计上的风险,专注于游戏的趣味性而把费用问题留给后续的研发工作,他们的意愿就更容易得到回报;哪怕两者由同一个团队完成,这条规律也同样适用。一旦知道费用问题可以留待将来解决,设计师们就不必过早为它担心了。

At this point we run smack into a terminology problem. The game design process can be split into two parts: designing the initial game, and tuning that design. Either of those things would be called “game design” in the computer world, and they wouldn’t necessarily be clearly distinguished. At Wizards, we distinguish them quite strongly, and we call the first one “design” and the second one “development”. So when I use the word “development” I mean this process of tuning an existing design. I won’t use the word “development” in the sense the computer world uses it: as a word meaning something like “coding” or “the general process of getting a game out, including everything from game design onwards”. And a “developer” is someone doing this job of tuning a game, not someone who is writing code. If you think of a game as a house, the designers are the architects and the developers are the engineers. If the architects are no good, no one will want to live in the house; if the engineers are no good, the house will fall down.

Relatively early on Wizards realized these two roles were different, largely because we found very different people were good at one or the other. If we produce a new Magic set, one group of people (the designers) will produce a set of cards. Another group (the developers) will then take that set of cards and adjust the costs, the details of how the cards work, and so on. The designers create new cards from scratch in various odd individualistic ways; the developers more often work in groups and apply fairly well-developed techniques to get the card file in decent shape.4 Designers playtest a fair amount to get a sense of how their design feels; developers playtest a lot, breaking the design, fixing it, and breaking it again.

Designers are rarer than developers, and it’s hard to give useful formal training in design. Design is probably more art than science, while development is more science than art (each has elements of both, though). A game with many complex gameplay objects will need more developers than designers, so it’s fortunate that developers are easier to train. We find 1 or 2 designers is often enough, whereas developers often work best in teams of 4 or 5.

This split between design and development applies pretty well to a new set of cards for an existing game. For a new game with lots of gameplay objects, it gets more complicated. There are four basic things going on:
1) design of the basic game (“game system design”)
2) tuning and modifying that design (“game system development”)
3) creation of the objects (“set design”)
4) tuning and costing of that collection of objects (“set development”)

Obviously all four of these things interact with each other, but we’ve found it very helpful conceptually to split them up. On large projects, we may even have four teams (with some overlapping personnel), one for each of these tasks. But even on a small project where it’s just one team for all four tasks, splitting them up mentally can help clarify what needs to get done.

Let me try to explain a little more what the pieces entail, and then why it makes sense to split them up and how to get the pieces to talk to each other effectively.

The initial game system design is the trickiest part. There are no hard and fast rules, and I won’t attempt to explain here how to do it (it’s not clear it can be explained). I will say that at this stage, enough sample gameplay objects are needed to try out the design and see if it’s fun, but designing a very large number of objects is probably a mistake, and tuning the costs in any concerted way certainly is.

Game system development is probably the hardest to explain. It includes basic tuning and filling in the holes in the rules. But probably the most subtle part of it is getting the costing system set up correctly. An otherwise solid design will often have serious problems in its costing system. Think of a costing system as a set of hooks and handles (or better yet, a collection of knobs and dials that you can adjust) around which you can build a large collection of balanced objects. The game design will want certain kinds of objects (weapons, or spells, or character classes). Do the right sorts of costs exist for those objects? By “right sorts” I mean something simple and elegant, so players can understand it, but still robust enough so that everything can be costed effectively — so that the variety of gameplay won’t collapse as players use just a small fraction of the choices available to them. “Everyone gets to bring 16 pieces to the table” is a costing system for choose-your-own-army chess (each piece you bring costs you 1 of your 16 slots) but it’s not robust, since players will choose nothing but queens.

Set design is where all the objects for the game are created. The focus should be on fun and not balance at this stage. Objects may have costs, but they are just guesses at this point.

In set development, the objects are given more accurate costs, and tested repeatedly for balance. Mistakes from earlier stages will become clearer here. If the game wasn’t fun before, set development won’t make it fun. If game system development didn’t create the right knobs, the set developers won’t be able to balance the set. Probably some objects will need to be tossed out or drastically altered, but the set developers should be making a good faith effort to include as many as possible, and a robust costing system will help.

Of course, these four phases can’t be completely separated, nor should they be. Step 1 pretty clearly comes first, and step 4 last, but steps 2 and 3 are problematic: each wants the other to come first. Designing the detailed rules for a digital object system without knowing what objects it needs to support is pointless, and designing objects without a system is impossible. Running them in parallel and having them talk to each other a lot is probably the best bet.

For smaller games, there may be a lot of overlap on the various teams. A typical setup might be a couple of people doing the system design, which they then hand off to a team of three or four developers. Those developers do system development while one of the designers designs the set, at which point the same developers develop the set.

Even if there are four separate teams, it’s important to have overlap among the team members for continuity. In particular, if developers need to change something in the design, it’s very important to have one of the designers right there who can say “well, this is the reason we designed it the way we did”. Then the developers can look for a change that preserves that original design intent, or at very least can override that intent knowingly rather than accidentally. In general, it’s best to have the overlapping team members not be the team leads. A team lead is more likely to be wedded to a particular choice and might well feel called upon to defend it rather than simply explain it.

In general, the designers are responsible for putting the fun in the game, and the developers for taking the problems out. But sometimes in development the game just doesn’t seem like fun: maybe the game simply wasn’t that fun to begin with, or maybe development had to make so many corrections to problems that the game suffocated under the weight of all the changes. At this point it’s key to resist the temptation of having a bunch of developers redesign a game. An experienced lead developer will spot this happening and go to his boss and ask that the game be kicked back to design (perhaps that same design team, perhaps a new one).

Looking back on what I’ve written, I realize this all may seem like an attempt to automate the production of games and thereby suck all the life out of it. I don’t think that’s true — let me give an example to try to explain why breaking things
into pieces like this can actually help free up people’s thinking.

Imagine a new set is being created for an existing trading card game. Relatively early on (in set design) someone proposes an interesting and rather unusual card. It often happens that a somewhat junior R&D member says “we can’t make that, that card’s broken!” Now often the card is “broken” (grossly overpowered) at whatever cost it currently has in the design file. A more senior developer may respond “well, it costs 3 now… would it be broken if it costs 8?” to which the answer will usually be “well, nobody would play it at 8, it would be terrible.” At this point hopefully it’s clear that in fact this card can go in the design file… it’s an issue for development as to whether it should cost 3, or 8, or something in between. That’s not to say any card is OK if you find the right cost; some game mechanics are just plain not fun. But if the design team worries about what’s fun and what isn’t, and leaves the costing for later, they are more likely to take the design risks that make for a fun card set. This applies even if the design team and the development team are one and the same. Knowing you will think carefully about costing later keeps you from worrying about it before you should.

万智牌设计与平衡(2):电脑游戏vs纸面游戏

如果要我把纸面游戏设计中的经验应用到电脑游戏领域,那这两者得在某些方面足够相似。我不会正面论证这个问题,取而代之的是会列举两者之间几点区别,一些显著但又不足以成为分水岭的区别,以此来证明它。

纸面游戏的设计过程花费低廉是两者最显著的区别。纸面游戏的第一个可玩原型能迅速做出来。更改规则时设计师只需向桌子对面的同事说声“不如试试这样!”,紧接着就能立马开工。如果想修改物件,他也只要拿起笔在卡牌或小抄上划去旧数据然后写下新的值就能完成。这样的运作方式非常高效,能够将更多时间和努力投入到设计工作中去而不是等待版本出来。换句话说,纸面游戏的原型制作和测试工作比电脑游戏更容易。

与原型制作并列的另一个问题是界面的设计。无论对纸质还是电脑游戏而言,界面设计都是个挑战,其中又以后者为甚。纸面游戏的界面糟糕(例如缺乏设计感的卡牌牌面)有时并不影响游戏性——设计师们也能在美工一团糟的情况下做出了不起的游戏系统;但对电脑游戏而言,界面的精美程度与游戏体验是密不可分的,将两者割裂开来是件非常困难的事。

纸面游戏与依赖编码的电脑世界的另一个差异体现在设计理念的还原度上。像万智牌这样的游戏,设计阶段的绝大部分构思至少在理论上是可行的(少数受规则系统的限制而行不通);但在电脑游戏世界里,有大量创意是无法实现的。万智牌可以在进入技术层面前完成大部分设计工作,同样的结论在电脑游戏里并不适用。

绝大多数纸面游戏的规则都是以日常语言(不完全是,读过万智牌完整规则的人都知道)而非电脑程序制定的。这是一把双刃剑,一方面,它让纸质游戏永远不至“崩溃”,比如玩家们会自发作出合理调整以弥补规则漏洞,但在另一方面,日常语言缺乏缜密性使规则表述难免出现歧义。对规则理解的分歧在一般游戏中最多使玩家之间出现争执,一旦出现在竞技层面,问题就变得严重得多;可过分追求严密性(别忘记,每一个游戏物件都需要相关的规则,这些规则之间又会产生互动)又无可避免地使规则条文化,这同样令玩家反感。电脑游戏能将上述的复杂过程内嵌在程序语言中,玩家永远不需要与之打交道。

总体上,纸面游戏的测试比电脑游戏容易——程序的纰漏可不像错别字这么好找;然而假如某个失误在发行后才被发现,纸面游戏将很难进行补救。如果你不小心印错一张牌,这个错误就会永远延续下去;但如果星际争霸里某个兵种应该多花20水晶,下一个补丁里把有关信息都改过来就行。宣称一张印着4费的牌应该是6费释放,无疑会给使用者带来不必要的负担(谁来做这个勘误?怎样确保玩家知道这个勘误?万一他们遇上不知道勘误的玩家呢?),甚至让勘误的举动得不偿失。

上述种种因素都影响着这么一个命题:如何在游戏设计的创意层面和技术层面之间(规则书排版和牌面美工设计之于纸质游戏,就如同程序编写之于电脑游戏)找到平衡。创意工作是桌游设计的重心,这很容易理解,毕竟“技术”层面在这里相对简单得多;可一旦了解到优秀的前期设计对后续制作过程的巨大帮助,人们还是会为两者的区别之大感到诧异。以电脑游戏工业的标准来看,WOTC算不上大公司;但我们拥有一支由40人组成的全职游戏设计团队,他们的唯一任务是游戏设计,至于图形设计、排版和印刷等琐事,这些人一概不管。即使是小型的集换式卡牌,也会有4-5名专职设计师负责,万智牌就更不用说了。相比之下,电脑游戏的制作预算一般更为充分,专注于游戏系统的设计人员却更少,部分人还要兼任其他职责。这种安排是不利于设计工作的,对涉及大量可收集物件的游戏而言更是如此。

编写电脑游戏程序需要大量资源,随时可能耗尽团队预算;但我认为,正是由于这部分工作耗费巨大,才更应该积极寻求廉价的替代品(廉价不代表容易实施!)——比如谨慎详尽的游戏规划。这并不是鼓吹用又长又臭的技术文件代替原型制作,相反,我认同可玩版本在游戏性评价方面无可取代的作用。我的立场是:与其反复尝试和修改,不如在游戏架构确立后马上调整物件费用、平衡物件强度,这样更有利于提高开发效率。

If I’m going to try to apply lessons learned in the paper world to the digital one, the two had better be close enough that the lessons are relevant. I won’t try to argue for that directly; instead, the individual points I make will, I hope, make that case. This section will briefly — in the interests of full disclosure — point out some of the ways that the two design problems are different. These differences are important enough to matter, but not enough to doom the enterprise.

The most obvious difference with the paper design process is how much cheaper it is. The first playable prototype can be made very early on with a paper game. And if the designer wants to change a rule, he says to the person opposite him “let’s try playing this way!” and they do that. If he wants to change a game object, he takes a pen and crosses out some bit of game data on a card or slip of paper and writes in the new value. This is enormously powerful, and allows a lot more time and effort to be put into the game design than into things like waiting around for a new build to show up. In other words, paper designs are much easier to prototype and test.

Tied in with this question of prototyping is that of interface. Interface is a challenge for both paper and digital games, but a much bigger one for the latter. One can imagine a good paper game with a bad interface (e.g. a poorly designed cardface) — also, as a designer, one can work quite productively on the game while its interface is in bad shape. For many computer games, the interface and the enjoyability of the game are so tightly tied together that it can be quite hard to separate them.

Another difference between the paper and digital worlds that’s tied in with the difficulty of coding is what percentage of design ideas are implementable at all. In a game like Magic, most new card ideas are at least possible to make (a few might not be due to technical problems with the rules system). With a computer game, a great many design ideas might not be practical to implement. So a large amount of Magic design work can be done before bringing in the technical experts. This would probably not be a good idea with a computer game.

Paper games have both the advantage and disadvantage that their rules are written largely (although not entirely, as anyone who has read the Magic rules knows) in English, rather than in computer code. On the plus side, the game can’t really “crash”… if something is poorly written, players will make some reasonable decision about what to do and move forward. English being less than precise, though, means that paper game rules will contain ambiguities: a mild annoyance in casual play, but a more serious problem in highly competitive play. Efforts to be extremely precise with rules (and remember, if there are many different gameplay objects, there are many rules, and many rules interactions) can lead to unpleasant legalese. Computer games can hide complexities in code that players never see.

Although paper games are on balance surely easier to “debug” than electronic ones — it’s easier to catch a typo than a subtle code bug — they are harder to patch. If a card has a misprint, it has it forever. If a unit in Starcraft needs to cost 20 more crystal, the next patch can make it so, in both gameplay and tooltip; declaring that a card with a printed cost of 4 should be played as if it costs 6 (by whom? how do they know? what if they meet someone else who doesn’t know?) is imposing such a burden on the user that it’s arguably never worth it.

All of these factors influence an important large-scale decision: how much effort to put into game design versus coding (think for the moment of things like laying out the rulebook or designing the graphics for the card face as the paper equivalent of coding) that game design. It’s not surprising that game design takes up a higher percentage of the effort in the paper world — the “coding” part is just plain easier — but given that a bit of time spent on game design can save a great deal of time coding, it’s perhaps surprising how big that difference is. Wizards of the Coast is not a large company by the standards of the computer industry, but we have around 40 people devoted full-time to game design. They don’t do graphic design, or layout, or printing… they just work on gameplay. Even a small trading card game will have 4 or 5 designers working on it, and Magic has many more. A typical computer game will have a much larger overall budget, but probably has fewer people devoted to gameplay, and many of them will have other duties. Designers of games that involve a large number of collectable objects, though, are discovering this may not always be the best mix.

So although the demands of coding might push one to spend almost all one’s resources on it, the fact that coding is so expensive should make one look for ways to substitute cheaper (but not easier!) things for it… like careful planning. I don’t mean this to be taken as an argument for long spec documents and no prototyping. On the contrary, I think there’s no substitute for having a playable version of the game to see if it’s fun or not. But once the basics of the gameplay are there, careful thought about balance and costing can save a great deal of time and effort over the more usual “keep trying stuff and adjust the broken bits”.

万智牌设计与平衡(1):引言

这个系列是万智牌首席设计师Robert Gutschera写的关于平衡卡牌的文章《Designing and Balancing Game Objects》。

从历史上看,游戏通常只有少数几种组成部件。如西洋跳棋只有一种棋子和棋盘,国际象棋有六种棋子,标准扑克牌有四种花色(在大多数游戏中意义都差不多)、每种花色有十三张按序编号的卡牌。更重要的是,玩家往往无法调整这些部件:人们永远无法用三枚皇后进行国际象棋比赛。

部分现代电脑游戏仍然遵循上述模式。一款典型的FPS(第一人称射击游戏)有一种角色和十几款武器供玩家从中选用(在道具刷新点)——这与国际象棋并无二致。但大多数电脑游戏要比这复杂得多。一款RTS(即时战略游戏)可以有数十种单位(算上升级和科技树在内的话更多),玩家可任选使用。在一个MMORPG(RPG网游)更是可以选择上百种角色技能、装备成千上万件道具,人物角色有着非常大的自定义空间。以上内容都属于我所说的“物件”,即可供玩家自由制定策略的游戏要素。

游戏设计师想要打造形式有趣、内容丰富的游戏环境。而玩家最大的愿望是赢。为了赢,他们总是试图“解构”一款游戏,即只采用占支配地位的游戏策略,其他的一律淘汰,将纷繁复杂的决策树简化为单一的制胜之道。要应对这种情况,设计师们必须平衡各种可能出现的策略,使其中的大多数是有意义的(有几个“坏”的策略有时并不是坏事,不必求全),确保作品拥有足够的策略丰富性。

绝大部分电脑游戏都要与上述问题相抗争(可以说每个游戏都要不同程度地处理它)。游戏物件越丰富,矛盾就越严重。但也有一类非电子游戏:物件收集式游戏,同样饱受策略平衡问题的困扰。物件收集式游戏既包括万智牌这种集换式卡牌游戏,也包括战锤(Warhammer 40K)、MageKnight这样的收集式战棋作品。尽管后者的棋子多为金属或塑料制造,但出于习惯,我还是将这类作品统称为纸面游戏(papergames);相应地,在家用机和手持设备等电子平台上推出的游戏则统称电脑游戏(尽管那些游戏物件众多、玩家选择丰富的电子游戏,大部分都是名副其实的“电脑”游戏)。

本文将讨论物件收集式(非电子)游戏设计师常用的几个观点和设计技巧,间中插入一些电脑游戏设计师感兴趣的话题。在即将开始的第二部分,我将对比两者设计上的异同,第三部分是游戏设计过程的分解介绍,随后会讨论构建“物件费用”的几个基本逻辑,最后是构建、平衡物件费用的几个小技巧。

本文的很多例子来自万智牌、星际争霸和魔兽世界。这些游戏都具有相当的知名度,容易引共鸣。但它们所反映的问题广泛适用于具有大量物件供玩家选择的游戏如:RTS、MMORPG及其他物件竞争类游戏如Kart Rider(跑跑卡丁车)、基于收集模式的网络游戏如Pax Nora或ChronX。