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

发表评论

电子邮件地址不会被公开。 必填项已用*标注