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

发表回复

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