分类目录归档:Uncategorized

万智牌设计与平衡(4):为什么要构造费用

构建费用的基本目的是让游戏可以有许多玩法物件的乐趣。如果这些物件确实做到了各不相同,那有些必然会特别强力,也就意味着这些物件会更容易让你获得胜利。如果星际的虫族农民、机枪兵和航母战斗力一模一样那这游戏会相当无趣。但如果我们想要玩家也会用那些非强力物件,我们就需要为强力物件分配高一点的费用,为弱小物件分配低一些的费用。

精准的费用和良好的游戏平衡并非只是为了那些最老练的玩家。也是为了那些菜鸟玩家(这点也许更为重要),以此保障他们的游戏体验。如果航母的费用太高,那就永远不应该建造它们。如果盗贼比别的职业弱,那选择这个职业的玩家(由于无知或由于个人口味)就“犯了个错”。别的玩家会让他们知道(自己做错了),而这些玩家可能会对这个游戏失望。所以你得保证有一些基本的玩法选择是合理的,并非说它们要始终正确而是在于它们不能始终错误。

一个游戏有多少合理的选择很大程度上取决于游戏类型。在一款RTS中,你可能想要每个单位都是一个合理的选择,至少在某些情况下。想必你想要MMORPG中的每个职业都是可用的。但是当物件数量非常多之后——一整套万智牌的卡牌或MMORPG的道具——你可能不想它们全都是可用的,甚至即便你想你也没办法让它们都能用。

不想让这些物件都可用是因为比较它们的好坏正是游戏乐趣的一部分。升级你的牌组、军队或角色是人们玩游戏的一大原因。如果有些选择对新手来说简单直白(这么做才是对的),就像“扔掉你那白色新手剑换上这把+2力量的闪亮新剑”,那么这些选择对老玩家来说更是显而易见。这没问题,只要保证游戏中有大量更难的选择让老玩家去克服就行了。

如果你可以做出一款游戏拥有成千上万的玩法物件并且它们能力相等,这也不一定是件好事。假设一个玩家策略是由20个物件(牌组中的卡牌、或角色拥有的道具)构成的子集,成千上万的物件都需要被考虑一遍,具有相同可行性的玩家策略有如此众多,没有哪个玩家(或设计者)能够搞明白。一个游戏有3到4种完全不同的方式去玩一个盗贼很酷很有趣。但一个有3到4千种方式的游戏则让人感到困惑和讨厌。

即使你有让全部选择都可用的想法也无法实现,这是因为你无法准确地平衡所有物件。如果你的游戏中有大量功能不同的物件,你怎样在效用上把它们做到完全一致呢?魔兽世界满级角色身上只有这么多个孔位,万智牌的牌组里只有这么多张牌,只有前100的物件有能力竞争这些位置。如果你降低费用让一个较弱的物件变得强大了,你也许是让它取代了前100里某个东西的位置。但是很可能最终你也没有改变可用物件的数量。所以使每个物件都可用的想法除了让你被误导外不会有什么卵用。

在任何情况下,让所有物件完美平衡的危险都不值得忧虑(没哪个游戏有这个问题)。重点是要弄清楚你想要可用的物件占总体的比例是多少。把它们调整平衡并接受其他物件要差一些这件事。从现在开始我会假设你已经确定了一组要平衡的物件并着手开展工作。

要平衡几组物件,你需要将费用分摊。要记住,费用可能会被玩家认作费用,也可能不会。在星际争霸中一个单位的费用主要是建造消耗的水晶和气,但你为了能够建造它所打通的科技树和建造时间也是费用。在万智牌中一张牌的费用主要是其所需的法术力,但这样想往往更有帮助:除此之外它还消耗了一张牌(即你用掉了一张手牌也是要算进去的,只有在那种每回合结束时自动补充手牌的游戏中才不存在这种费用)。这就是为什么0费的牌并不是真正免费的。魔兽世界中道具的黄金价值和它的费用几乎没什么关系。它的费用在某种意义上是为了得到它所花费的时间和克服的困难(怪物多久掉落一次),但那太难量化了,因此用更容易处理的物品等级来代替。(下文有更多说明)

故事的原理

选自《故事》的前言,我觉得同样适用于游戏导演和游戏策划。这可以启发我们,学习和积累哪些东西是有利于设计的,而哪些东西是可以被打破和挑战的,又有哪些东西是需要及时改正的。

《故事》论述的是原理,而不是规则。

规则说:“你必须以这种方式做。”原理说:“这种方式有效……而且经过了时间的验证。”二者有着本质的区别。你的作品没有必要以一部“写得好”的剧本作为摹本去写;而是必须依循我们这门艺术赖以成形的原理去写好。急于求成、缺少经验的作家往往遵从规则;离经叛道、非科班的作家破除规则;艺术家则精通形式。

《故事》论述的是永恒、普遍的形式,而不是公式。

任何兜售商业成功范本和故事速成模式的说法,都纯属无稽之谈。尽管有各种潮流,有旧片重拍和好片续集等,但当我们将好莱坞电影作为一个整体来审视时,我们发现其故事设计之丰富多样确实令人叹为观止,而其中却没有一个范例。《顽固分子》所代表的好莱坞典型性绝不多于《门第》、《来自边缘的明信片》、《狮子王》、《重金属乐队纪实》、《命运的逆转》、《危险的关系》、《圣烛节》、《离开拉斯维加斯》以及属于从闹剧到悲剧的数十种类型和次类型的成千上万部优秀影片。

《故事》激励人创造能够令六大洲的观众兴奋不已而且历久不衰的作品。没有人需要另一本重炒好莱坞残羹剩炙的菜谱。我们需要重新发现我们这门艺术的潜在原则,那些解放才智的指导原理=无论电影在哪儿拍摄——好莱坞、巴黎抑或香港,只要它具有原型的特质,其愉悦性便会在全球引发永久性的连锁反应,从一家影院传到另一家影院,从一代观众传向下一代观众。

《故事》论述的是原型,而不是陈规俗套。

原型故事挖掘出一种普遍性的人生体验,然后以一种独一无二的、具有文化特性的表现手法对它进行装饰。平庸的俗套故事则将这一模式颠倒过来:其内容和形式都贫乏得可怜。它将内容囿于一种偏狭的、具有具体文化特性的体验之中,然后饰之以陈腐而无特色的庸常形式。

例如,根据过去的西班牙习俗,女儿出嫁必须以年龄长幼为序:在西班牙文化中,一部关于严父、弱母、嫁不出去的大姑娘和苦待闺中的小女儿的19世纪家庭的影片,也许能打动那些依稀记得这一习俗的观众;而在西班牙文化之外,观众却未必能够领会。作者唯恐故事感召力有限,便求助于过去的观众喜爱且熟悉的场景、人物和动作。结果呢·世人对这些陈词滥调更加兴味索然。

反之,如果艺术家切实下功夫去寻找一个原型,这种压抑的习俗则可能成为轰动世界的素材。原型故事能创造出世所罕见的场景和人物,令我们目不暇给地去观赏每一个细节;而其讲述手法又能揭示属于人性真谛的冲突,使之得以从一个文化到另一个文化不胫而走。

在劳拉·埃斯奎弗的《情迷巧克力》中,母女之间就依赖独立、永恒和变化、自我和他人之间对立的要求短兵相接——这些冲突都是每一个家庭感同身受的。然而,埃斯奎弗对家庭和社会、亲情和行为的观察和表现是那样地富于人所未见的细节,以致我们不可抵御地被其人物所吸引,沉湎于一个我们从来不曾知闻亦不可想象的领域。

陈规俗套的故事不会流传开来,而原型故事却会不胫而走。从查利·卓别林到英格玛·伯格曼,从萨蒂亚吉特‘雷伊到伍迪·艾伦,诸多电影故事高手为我们提供了我们渴求的双锋际遇。

首先,使我们发现了一个我们不知道的世界。无论是言情还是史诗,无论是当代还是历史,无论是现实具体还是方外幻想,一个出色艺术家的世界总是能使我们感受到一种异域之情、离奇之叹。就像一名劈路而行的林中探险者,我们瞠目结舌地步入一个未曾触及的社会,一个破除了陈规俗套的领域,在其间腐朽化为神奇,平常变成非凡。

其次,一旦进入了这个奇异的世界,我们又发现了我们自己。在这些人物及其冲突的深处,我们找到了我们自己的人性。我们去看电影,从而进人一个令人痴迷的新世界,去设身处地地体验初看起来似乎并不同于我们但其内心却和我们息息相通的另外一个人的生活,去生活在一个虚构的现实,从而照亮我们的日常现实。我们并不希望逃避生活,而是去发现生活,以一种焕然一新的试验性的方式去使用我们的头脑思想,去激荡我们的情感,去欣赏,去学习,去增加我们生活的深度:《故事》的写作宗旨即在于培育出具有原型魅力的电影,从而为世界带来这种双重愉悦。

《故事》论述的是全面彻底、始终如一,而不是捷径。

从灵感闪现到最后定稿,写一个剧本也许需要花费和写一部小说同样的时间。电影剧本和小说作者都是要创造同样的内容丰富、感情强烈的世界、人物和故事,但由于电影剧本的篇幅中有许多空白,我们常常误认为写电影剧本要比写小说更快更容易。但是,尽管粗制滥造者能够以其最快的打字速度迅速填满稿纸,电影剧作家却总是惜字如金,不断删改,力图以最少的文字表达最多的信息。帕斯卡尔曾经给朋友写过一封长而无当的书信,然后在信尾的又及中深表歉意,说他没有时间写一封短信。就像帕斯卡尔一样,剧作家明白简是关键:简明扼要需要花费时间,卓越超群来自于孜孜以求。

《故事》论述的是写作的现实,而不是写作的秘诀。

艺术的真谛并不是需要策划什么阴谋来保守的秘密。自从亚里士多德撰写《诗学》后,两千三百年来,故事的“秘密”就像街上的图书馆一样一直是公开的。讲故事这个行当里根本就没有什么难解的奥秘。事实上,乍看起来,在银幕上讲故事似乎是轻而易举之事。但是,当你一步一步地接近其中心,一个场景接着一个场景地努力着要把故事讲好时,这个任务就变得越来越艰难,因为我们意识到在银幕上绝对没有藏拙之地。

如果银幕剧作家未能以其纯粹戏剧化的场景打动我们,他不能像小说家那样利用作者的声音或者像戏剧作家那样利用独白来将其掩藏在自己的言语背后。他不能利用解释性或情感性的语言来抹平逻辑的裂缝、粉饰动机的模糊或情感的枯燥,不能仅仅是告诉我们该想什么或该如何感觉。

摄影镜头是可怕的x光机器,任何虚假的东西都逃不过它的透视。它将生活放大数倍,使每一个软弱无力或不近情理的故事转折暴露无遗,逼得我们困惑、失望到直想脱身而逃。不过,假以决心和研究,难题便会迎刃而解。银幕剧作充满了神奇,但并没有不可解读的奥秘。

《故事》论述的是如何精通这门艺术,而不是如何揣摩市场行情。

没有人能够教别人什么畅销,什么不畅销,什么能打响,什么将失败,因为没有人知道。好莱坞的哑炮在其制造过程中注入的商业心机与轰动作品是一样多的,而那些被钱场的智者打入另册的暗淡的剧情片——《普通人》、《偶然的旅游者》、《猜火车》——却默默地征服了国内外的票房。我们这个行当一切都没有保证。所以,多少人绞尽脑汁、搜索枯肠却始终不得其门而入。

当你满怀上述担忧,战战兢兢地涉足其中时,你就必须按照大都市的规矩,老老实实地去找一个经纪人,兜售你的作品。如果你的作品质量果然出类拔萃,那你便能看到它在银幕上得到忠实的体现,否则的话……如果你匆匆忙忙地炮制出了去年暑期档热门影片的翻版,那么你便加入了每年以成千上万的陈词滥调故事充斥好莱坞的那些三流作家的行列。与其痛思时运不济,不如起而磨砺自己,以臻卓越。如果你在经纪人面前拿得出饱蕴才思、富有独创的剧本,他们将会争先恐后地争当你的代理人。你所雇佣的经纪人将会在正闹故事饥荒的制片人中挑起一场夺标战,中标者将会付给你一大笔钱,数目之巨足以令他囊中羞涩。
而且,一旦投拍,你的完成剧本面临的干预会少得令人惊奇。没有人能保证不幸的人员组合不会毁掉一部好作品,但好莱坞最优秀的演艺和导演天才肯定深切地明白,他们的事业全靠优秀的剧本来支撑。然而,由于好莱坞对故事的需求太贪婪,剧本常常在尚未成熟之前就已选定,然后在拍摄现场被迫修改。沉稳的作家并不出卖初稿。他们会耐心地数易其稿,直到本子尽可能地符合导演和演员的工作要求。未完成的作品较容易遭到窜改,而多加润饰的成熟作品却可以保持其完整性。

《故事》论述的是对观众的尊重,而不是对观众的鄙薄。

天才作家写不出好作品不外乎两个原因:他们要么是被一个他们觉得非证明不可的观念所蒙蔽,要么是被一种他们必须表达的情感所驱策。天才作家写出好作品一般是因为这个原因:他们被一种要打动观众的欲望所感动。

在多年的演员和导演生涯中,夜复一夜,我总是怀着敬畏的心情面对观众,对其反应能力敬畏不已。他们就像中了魔术一样,面具全部脱落,赤诚的面孔全不设防,对一切感受兼收并蓄。电影观众不会防卫自己的情感,他们以一种连自己的爱人也不知晓的方式向故事人敞开心扉,迎接欢笑、眼泪、恐怖、暴怒、同情、激情、爱恋和仇恨——这场仪式常常令他们精疲力竭。

观众不仅令人惊叹地敏感,而且一旦他们在黑暗的影院坐定,其集体智商则能飞跃二十五点。当你去看电影时,你难道不是经常觉得自己比你所看到的内容更加聪明吗·人物还没开始行动,你就知道他们要做什么;影片离结尾还老远的时候,你就看出了结局。观众不仅聪明,而且是比大多数电影更聪明;当你置身于银幕的另一面时,这一事实也不会改变。作家所能做的一切就是,尽其所能,以求超越聚精会神的观众所表现出的敏锐的集体感知力。

一部电影如若不了解观众的反应和期待,必将行之不远。你必须以一种既能表达自己的想象,又能满足观众的欲望的方式来构建自己的故事形态。观众和其他诸多要素一样,是设计故事的决定力量,因为没有观众,这种创作行为便失去了意义。

《故事》论述的是独创,而不是复制。

独创性是内容和形式的融合——独具慧眼的主题选择加上独运匠心的故事形态。内容(场景、人物、思想)和形式(事件的选择和编排)相辅相成、相得益彰而且相互影响。一手把握内容,一手精于形式,作家便可以雕琢故事。当你反复推敲故事材质时,故事形态便会自行重塑。当你玩味故事形态时,心智和情感的精灵便会渐渐浮出。

一个故事不仅是你该讲什么,而且还包括怎么去讲。如果内容是陈词滥调,那么讲述手法也必定是陈规老套:但是,如果你的想象深远而新颖,你的故事设计必将独出心裁。反之,如果故事手法纯属老调重弹、司空见惯,也就需要用陈规俗套角色来演绎陈陈相因的行为。然而,如若故事设计新颖别致,那么背景、人物和思想也必定要同样令人耳目一新才能使其臻于完满:故事形态的构建是为了适应故事材质;故事材质的推敲是为了支持故事设计。

不过,切忌将猎奇误以为独创。为不同而不同就跟屈从于商业规矩一样,难免流于空洞。一个严肃的作家在经过经年累月的搜集整理、广征博采和冥思苦想,终于建立起了一个故事素材的宝库之后,决不会将自己的想象①[想象(vision):指导演对其未来影片画面的想像力。——译者]囿于某一公式的藩篱或使之沦为标新立异的下品。“范本”公式可能会窒息故事的声音;而“艺术片”的含糊其辞则又会导致表达的口吃。就像小孩摔碎东西取乐或无理取闹以博大人关注一样,太多的电影制作者不惜采用婴幼儿的伎俩在银幕上大叫:“瞧瞧我的本事!”成熟的艺术家决不会故意引人注意,明智的艺术家决不会纯粹为了打破常规而行事。

霍顿·富特、罗伯特·奥尔特曼、约翰·卡萨维茨、普雷斯顿·斯图尔奇斯、弗朗索瓦·特吕弗和英格玛·伯格曼等大师的影片具有的个人特质有如DNA,使人只需读三页故事梗概便可以准确无误地判定作者是谁。伟大的银幕剧作家总是以其个人化的故事风格而独树一帜;这种风格不仅与其想象不可分割,而且从深层意义而言,这种风格即是想象象。他们的形式选择(主人公人数、故事进展的节奏、冲突的层面、时段的安排等)与实质内容的选择(背景、人物、思想)既相辅相成又相反相成,直至一切因素融合成一个独一无二的剧本。

更进一步,如果我们暂且将其影片的内容搁置一旁,只去研究其片中事件的纯粹形式,那么我们将会发现,即如一段没有歌词的旋律,就像一幅没有原物的剪影,其故事设计本身便重重地承担着含义。故事大师对事件的选择和安排即是其对社会现实中各个层面(个人的、政治的、环境的、精神的)之间的互相关联所作的精譬妙喻。剥开其人物塑造和场景设置的表层,故事结构便展示出作者个人的宇宙观,他对世间万物之所以如是的最深层的模式和动因的深刻见解——这是他为生活的隐藏秩序所描画的地图。

无论你的英雄是谁——伍迪·艾伦、大卫·马梅特、昆廷·塔伦蒂诺、鲁思·普罗尔·贾布瓦拉、奥利弗·斯通、威廉·戈德曼、张艺谋、诺拉-埃夫龙、斯派克·李、斯坦利·库布里克——你崇敬他们皆因他们是独一无二的。他们之所以出类拔萃是因为他们选择了别人没有选择的内容,设计了别人没有设计的形式,并将二者融合为一种不会被误认的、只能属于他自己的风格。我要求你们也要这样。

不过,我对你们的希望不止于能力和技巧。我渴望看到伟大的影片。过去二十年来,我确实看到过好电影,而且还有一些很好的电影,可是却很少很少有一部具有震慑人心的力和美的影片。也许原因在我;也许我看电影看腻了。可是,我并不这么认为。现在还不。我仍然相信,艺术能改造生活。不过,我知道,如果你不会弹奏故事交响乐中的所有乐器,那么无论你的想象中有多么美妙的音乐,你注定只能哼出那千篇一律的老调=《故事》的宗旨即是加强你对这门手艺的掌握,将你从束缚中解放出来,使你得以表达你对生活的新颖独特的看法,提高你的才能,使你超越陈规俗套,创造出具有独特材质、结构和风格的电影。

一次关于测试用例的讨论

目前项目上的测试用例是由相应功能的策划来撰写的,由此引发了一些讨论。下面记录的是我和同事的聊天记录。


天涯一隅 15:56:54
我想起刚才提及的一个很有意思的问题,就是关于写测试用例的。我在写过很多测试用例之后也会发现这样的问题:整个方案是自己写的,自己在思考边界时已经有了固有模式,所以写用例时能覆盖到的未知区域也不多。但是如果让别的人来写测试用例,小团队又没有专门的测试人员。不知道你有什么看法?

Allen Young 16:01:05
我的想法是测试用例可以交叉来写~~这样也会有一个互相检查和思考的作用,可能写测试用例的人会想到写文档的人没想到的东西,但这样策划的工作量会增加不少

Allen Young 16:02:05
测试用例完备,可以从规则上去要求程序必须所有的点是pass掉,可能 会减少后期一些反复的事情

Allen Young 16:02:23
但游戏有时会有很多感性的东西,这个又似乎要看具体的执行程序

天涯一隅 16:05:42
是思考得全面的功能bug少,还是测试得多的功能bug少?

Allen Young 16:08:45
最后那句应该说得太感性,我意思是比如两位程序员做同一个功能的差别

Allen Young 16:14:40
程序这边做,目标必须是思考 得全面,所以BUG少

Allen Young 16:15:13
测试得多而BUG少的话,这样是不合格的程序

天涯一隅 16:17:50
你说的这种在功能设定上也是相同的,自然是思考得全面让其少出问题是最好的。但我关注的可以举这样的例子来考量:一共有10个小时,分别用于开发和测试。那我们应该以2/8、5/5还是8/2来分配时间呢?

Allen Young 16:18:18
因为程序不象策划,一个功能的方案确认后,程序不需要有太多想法,程序框架,开发方式都是已经确认好,有开发模式的(当然较另类和复杂的另说),他只需要在这个相对较小和确定的方向去做一定的设计

Allen Young 16:19:14
策划在设计一个功能时,可能就需要考虑到很多点了,游戏的核心原则,一些既定的规则,操作,体验等等

Allen Young 16:20:07
你是说程序开发和测试的分配?

Allen Young 16:20:26
其它条件已经准备就绪?

天涯一隅 16:20:37
我是说整个功能。从策划这边设定到编码到测试完。

Allen Young 16:22:13
策划和编码这块不好说,要看具体东西吧

天涯一隅 16:23:22
可能无法具体到是策划还是程序的工作上。比如在这个语境下,测试不仅是测功能的bug,还测策划没有考虑到的地方或者是做出来之后发现的和其他功能有冲突的地方。我想的是一个功能的制作这个整个周期中,让其最终变得“正确”的话,倒地是“快写快做快速测试”更好还是“深思熟虑精炼测试”更好。

Allen Young 16:23:53
以前的一般策划功能设计这块似乎都不太长,我觉得前期沟通确认一些实现还是有必要,策划设计这边应该给更多一些的时间片去做可能会好些

Allen Young 16:26:11
这个我想,可以快为主,但快不能失去必要深度的思考

天涯一隅 16:29:20
那么我觉得可以让策划在做完功能的设定后,和负责开发这个功能的程序一起来写测试用例。背靠背的

天涯一隅 16:29:34
2个人能覆盖的盲区会比1个人大得多

Allen Young 16:30:46
嗯~~~似乎不错~~程序也不会很草率的去看文档

天涯一隅 16:31:25
测试用例写好了,程序再开始写,我记得敏捷开发里面这个叫test-driven develop

Allen Young 16:31:58
可以尝试

Allen Young 16:32:21
因为很多程序有个毛病

Allen Young 16:32:28
文档看得不细

Allen Young 16:32:55
这个会变相拖长时间,有时可能会是比较严重的

天涯一隅 16:43:41
负责开发的人看文档不细也是多年感触了。但是我发现我在看别的文档的时候,吸收得也不好。我在看的当时是很仔细的,逻辑比较绕的地方还会反复看。但在实际用起来的时候发现,文档是别人的思想写出来的,我看的时候能晓得,但是文档关了之后再过段时间我就记不清楚了。于是还是吼起问写文档的人xxx东西是怎么样的。其实文档是作为思想记录的很方便的一个东西,但是传递思想的效率还是不高。也许自己理一次并写下来,能较好地解决这个。

Allen Young 16:49:35
如果配合思维导图呢?

天涯一隅 16:49:38
您好,我现在有事不在,一会再和您联系。

天涯一隅 16:55:24
我用过很多文档的形式,不限于word excel 导图 图画 动画。不过就我个人的经验看来,各种文档的形式可以解决一些沟通上的便利问题,却无法解决思想的传达。思想的传达我目前觉得是没有捷径的,要把一个人脑子里想的东西比较好的带到另一个人脑子里去,各种形式的文档只能提供辅助。而关键是在于交流思想的人要有积极的心态,还有努力将这些文档里的东西变为自己的行为。这让我想起读书的时候,老师讲一种思想(知识)传递给我们,那个过程也不是什么很轻松的事情。我们要看文档(书),记笔记,对不懂的地方反复提问,下课后反复琢磨。最终这些思想才会变成我脑袋里的东西,而不是仅仅是写在书上的文字。

Allen Young 16:56:24
这个是不是就只能去营造这种氛围了?

天涯一隅 16:59:00
从整体层面来说,是的。从具体层面来说,就是交流的人要有这种意识。不能觉得沟通想法就是一份完善的文档就行了。我在这上面还是走过不少弯路的,以前我也是觉得多半是文档不够有趣不够简洁或者不够突出重点。后来觉得问题不全在文档上面,只在文档上做改进来改善沟通效率是不够的。

Allen Young 16:59:55
嗯,沟通和沟通的意愿确实很重要~~

使用沮丧系数评估闯关游戏关卡

Wooga’s Florian Steinhoff opened his talk at GDC 2014 in San Francisco on the performance of Jelly Splashwith five simple words: “Hate is a powerful emotion.”

While many of us think to avoid engendering hatred with our games, Steinhoff recommends that hate should actively be embraced.

“If someone hates your game, they feel passionately about it, and so they maybe love it a little bit too,” he detailed.

With this counterintuitive philosophy laid out, Steinhoff went on to give a list of best practices on how you can turn frustration into a driving force of player engagement and retention.

Wooga成员Florian Steinhoff在最近于旧金山召开的GDC 2014大会上以“仇恨是一种强大的情感”这句话开始了关于《Jelly Splash》的演讲。有意思的是同年中国GCD上乐元素游戏高级副总裁徐辉做的“从《开心消消乐》看休闲游戏制作”的演讲中也提到了沮丧系数。

虽然我们多数人认为要避免玩家对游戏产生仇恨情绪,但Steinhoff却认为我们应该积极利用仇恨这种情绪。

他解释称,“如果有人恨你的游戏,就说明他们对它反应强烈,所以他们还是有可能对它存在一点好感。”

Steinhoff继续列出了一系列如何将受挫感转化为玩家粘性和留存动力的举措。

Get spiky  激怒玩家

When Steinhoff laid out the difficulty curve of Jelly Splash, he showed a collection of difficulty models Wooga tried but ultimately found unworkable.

This collection boasted the standard 45 degree incline, an exponential “hockey stick”, and a curvy variant on both. In the end, Wooga opted for a spiky line with multiple sharp peaks and valleys.

The spikes represent Blocking Levels or – as Steinhoff described them – “crazy difficult levels” which are used to slow players down. Unfortunately, these levels engender a lose rate of “up to 95 percent”.

To compensate for these, Wooga sprinkled in Relief Levels – the valleys – which allow players to recover from Blocking Levels and amps up their confidence to try again.

The third level type essential to Jelly Splash’s success is the Build Up level, which are increasingly difficult stages on the slopes leading up to the spikes.

当Steinhoff列出《Jelly Splash》的难度曲线时,他展示了Wooga尝试过但最终放弃的一些困难模型集。

这个集合包含标准的45度角斜面,指数化的“曲棍”,以及两者的弯曲变量。最终,Wooga选择了一个拥有多个犀利高峰和低谷的曲线。

这个峰值代表“阻塞关卡”,或者说是Steinhoff所描述的用于降低玩家速度的“疯狂难度关卡”。不幸的是,这些关卡所产生的流失率“高达95%”。

为了弥补这一点,Wooga引进了“放松关卡”——低谷,允许玩家从“阻塞关卡”中解脱出来,并提升再次尝试的信心。

第三个关卡类型实际上就是令《Jelly Splash》获得成功的“增强关卡”,它斜坡走向峰值时不断增长的难度阶段。

wooga-jelly-splash-2-r471x

Jelly Splash

Steinhoff stressed, however, that developers shouldn’t save spikes – Blocking Levels – until late in the game. In fact, he advocated confronting a player with one in the first play session to reinforce them with a loss.

“Players need to lose, and lose early on – otherwise they’ll think it’s a game for kids and will put it down and never play again.”

Steinhoff强调,开发者在游戏接近尾声之前不应该节省峰值(“阻塞关卡”)。事实上,他还主张在玩家首次游戏体验中引进一个峰值,迫使他们面对挑战。

“玩家必须失败,而且要早点失败——否则他们就会认为这是儿童玩的游戏,并退出游戏不玩了。”

FUUU Factor  沮丧系数

The key to building frustration with Blocking Levels is to aim the right FUUU factor, named after the now-infamous Rage Guy meme.

FUUU factor, as Steinhoff explained it, is best described in a simple athematic equation:

# of tries until won / # of times you almost won a level.

Put another way: the more frustratingly close calls, the lower the FUUU factor – and a lower FUUU factor leads to a more motivated, enraged, and engaged player.

For example, if a player needs 100 tries before they clear a level and they only have five near-wins, the level has a FUUU factor of 20. If a player attacks the same level and has 25 near-wins, it has a FUUU factor of 4.

That level will be viewed as more frustrating, sure, but that frustration is sticky.

“Don’t be afraid to frustrate the players, listen to the data, and ignore the whining,” Steinhoff concluded, before pointing out that you should toss out all levels with a FUUU Factor greater than 10.

创造“阻塞关卡”中的受挫感关键就在于瞄准正确的FUUU系数。

所谓的FUUU因互,正如Steinhoff所言,是一个简单的外加公式的最佳描述:

获胜之前的尝试次数/你在一个关卡中几乎快胜利的次数

换句话说:你越是侥幸脱险,FUUU系数就越低——-较低的FUUU因素可以产生更有动力、被激怒和投入性的玩家。

例如,某一玩家在清除一个关卡之前必须尝试100次,并且仅有5次将近获胜,该关卡的FUUU系数就是20。如果一名玩家在同个关卡中有25次几乎获胜,其FUUU系数就是4。

该关卡看似更令人抓狂,但这种受挫感却具有粘性。

Steinhoff总结表示,“不要害怕让玩家受挫,听从数据的指示,并忽略玩家抱怨”,并指出开发者应该丢掉所有FUUU系数大于10的关卡。

Lucky me, lucky you   运气因素

Another key point Steinhoff addressed was the role of luck in games.

Luck allows players to blame a game for a loss, and increases the chances that they’ll continue plugging away at a difficult level. Conversely, players will like the dopamine rush of “feeling lucky” when they clear a tough level.

But designers should love luck, too, since it can simultaneously speed up poor players – allowing them to clear levels well beyond their skill level – and slow down power players by forcing undesirable boards on them.

Overall, Steinhoff notes that “luck broadens the user funnel and keeps more players in your game,”

But the catch with luck in puzzle games is that players want to believe it’s their skill, and not luck, that helped them clear a challenge.

As such, they’re prepared to a game that’s “about 50 percent luck” – but Steinhoff noted that you, as a developer, want a game with “about 70 percent luck” for the balancing of exceptionally adept or struggling players.

The key to reconciling this 20 percentage point gap lies in “deceit skill” – moments where players feel they have more skill in a game than they ultimately do.

Steinhoff所述的另一个关键就是游戏中的运气因素。

运气允许玩家将失败归咎于游戏,并增加了他们继续挑战困难关卡的机率。玩家扫清一个困难关卡时总会享受那种“感觉走运”的快感。

但设计师也应该推崇运气因素,因为它可以同时加快菜鸟级玩家的速度,允许他们在超越技能水平的情况下扫清关卡——另外还可以通过施加这种不受欢迎的障碍而放慢高手玩家的速度。

Steinhoff指出“运气扩展了用户漏斗,并留下了更多的游戏玩家。”

但解谜游戏中的运气因素的魅力就在于,它让玩家相信是自己的技能而非运气,帮助自己克服了挑战。

因此,他们适合那种“运气约占50%”的游戏,但Steinhoff指出,作为开发者应该拥护那种“含70%运气因素”的游戏,以便平衡极为熟练的玩家和新手玩家。

调解这20%差距的关键就在于“欺骗性技能”——即玩家觉得自己在游戏中拥有比实际上更高技能的时刻。

F* yeah   险胜时刻

The final recommendation Steinhoff gave in the process of crafting a frustration-driven puzzle game is to sprinkle in “Fuck Yeah moments” – or, F* Yeah moments
These moments of pure, unadulterated bliss happen when everything falls in a player’s favour and they skate through a challenging level when all looks lost.

Using an extreme example in Bejeweled where a concatenation of combos lead to a victory in a lost cause level, Steinhoff said the feeling a player walks away with at the end can only be described with the following meme.

Steinhoff noted that these F* Yeah moments provide a ray of hope for players in difficult times, and hope is an extremely powerful motivator for player engagement and retention – perhaps equal to frustration.

In order to make sure players respond properly to F* Yeah moments, however, Steinhoff recommended tossing them at the player early.

This allows them to become aware of the existence of F* Yeah moments as they’re getting invested in a game and thus creates a hope for their reappearance in later, more frustrating levels.

As an added bonus, Steinhoff pointed out that these F* Yeah moments are eminently sharable – players will want to tell others about their amazing ccomplishments, which aides in game discovery.

Steinhoff针对创造受挫型解谜游戏的最后一个建议就是,引进“险胜”时刻。

这是指当一切都顺从玩家意愿,并让他们在看似失手的情况下险胜富有挑战性的关卡,这种纯粹的欣喜若狂的时刻。

例如,在《宝石迷阵》中某个注定失败的关卡中连结了一个消除组合并获得胜利,Steinhoff认为这种感觉会让玩家离开时产生极大的满足感。

Steinhoff指出这种出乎意料的险胜时刻为身陷困境的玩家提供了一线希望,这种希望是玩家粘性和留存的强大激励因素——-其威力与受挫感相当。

为了确保玩家正确响应这种时刻,Steinhoff建议开发者尽早向玩家引进这种设置。

这可以让他们在投入游戏的过程中了解险胜时刻的存在,并因此在之后更困难的关卡中产生一线希望。

Steinhoff指出这种险胜时刻具有分享性——玩家会告知他人自己的惊人战绩,而这一点又有助于提升游戏的曝光度。

Three principles of Frustration    有关挫败的三个原则

While forging a game with frustration as the main motivator is a tricky prospect, the end results are inarguable if it’s implemented properly.

In order to make sure a game’s injected with the proper levels of frustration, Steinhoff recommended that developers follow three simple rules to help players hate – and thus love – a game.
“Make it difficult, keep it casual, and use more luck”.

虽然制作以受挫感为主要激励因素的游戏是一个棘手的挑战,但如果执行得当就可产生极佳效果。

为了确保游戏注入了合适的受挫关卡,Steinhoff建议开发者遵从三个简单的原则来促使玩家痛恨,并因此而爱上游戏——“增加难度,保持休闲性,使用更多运气因素。”

万智牌设计与平衡(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。