整体图景

为了便于描述，我把虚拟世界的设计过程切分成了几块——不过，这个设计过程实际上是整体的。你不能把设计的各个侧面孤立起来看：这些侧面彼此影响的方式，可能不会立刻显露出来。

举例来说：工匠们抱怨自己的城镇死气沉沉。你查明，这是因为制造（与战斗不同）是一种单人活动。你引入了一些需要好几个角色一起协作的制造流程。玩家们把房子盖得彼此紧挨着，好让自己能迅速往返于各个制造中心。城镇因此变得更有生气。可是，如今人们在城镇里待的时间比在荒野里长，冒险者便抱怨荒野死气沉沉了。

如果你提前看出这些问题，就可以把它们作为一个整体来处理。一次只处理一个，可能只是把它们推来推去。这就像想把一个燃烧的圆环扑灭，却一段一段地浇水——你刚把这一段浇灭、移到下一段，前一段就又烧起来了。你必须一口气把它整个扑灭：你没法靠切分来解决问题。遗憾的是，只要设计团队不止一个人，你就总免不了某种切分；在这种情况下，平衡各项事务就更难了。

由子系统相互作用引起的问题，主要属于一致性、兼容性与深度这几类；幸运的是，这些是可以处理的。不过，当一份设计要求两个彼此直接对立的元素同时存在时，就必须做出艰难的决定：你可以要永久死亡，也可以要某种形式的复活，但不能两者都要。间接的矛盾解决起来几乎一样困难，只是更不容易发现。玩家希望能以固定价格卖掉自己制造的商品，以保证一份收入；可这样一来，就会有很多人去制造那些商品，制造的人一多，原材料的价格就会被抬高，而原材料一贵，玩家从自己商品上得到的收入又会减少。

解决办法并不容易找到。切分带来的困难，可以通过稳妥的开发实践来处理——沟通、定期的设计会议、内部网站、首席设计者签字确认，等等。至于设计本身的问题，团队必须力求稳健：他们可以处理事先注意到的任何问题，但虚拟世界一旦上线，他们就得依靠自己内置的制衡机制，来确保不会出什么可怕的岔子 ¹。尤其是任何针对经济的新设计，几乎肯定不会一上来就管用，所以必须准备好损失控制代码，以应对不可避免的磨难。

设计不足与设计过度

设计不足是从零开始写起的虚拟世界常犯的问题。开发者花了太长时间创造和搭建这个世界，以至于忘了往里面加玩法。玩家可做的事不多，而没法拿来做事的东西却很多。另一种情形是，可做的事很多，但只能对同样的东西一遍又一遍地做。无论哪种情形，内容就是不够。这个虚拟世界也许辽阔、美丽、精雕细琢，却只是一个空壳。玩家想要的东西，他们根本没法得到：这就像去购物，却发现所有商店都关了门 ¹。

设计过度同样是问题。在这种情形里，设计者抠得太细，细到把一切活动都淹没了。玩家想做成一件事，得先做一大堆别的事；他们真正想做的事，就淹没在这堆别的事情发出的噪声里。虚拟世界里容得下一点点烦人的细节，而有些细节，在有的玩家眼里就是比在别的玩家眼里更烦人；不过，一旦玩家觉得这些细节无关紧要，他们就会反抗。我不想在买箭的时候还得指明倒钩样式、箭杆长度和箭羽的组成／配置，我只想要能搭在弓上射出去的东西！

设计过度与设计不足都是同一件事的结果：焦点用错了地方。设计者盯住某个东西，盯得太细：就设计不足而言，那是虚拟世界的基础设施；就设计过度而言，那是建在这个地基之上的结构。

设计不足与设计过度都说明了选择性深度的另一个侧面：一个地方的细节过多，会让人以为别处的设计浅薄——即便客观地看，别处的细节恰到好处。

参与式设计

一群乐手凑到一起开始即兴合奏时，他们做的就是某种形式的参与式设计。每个人都有想法，都拿出来请大家认可。有些想法行得通，有些行不通，而别人还会提出更好的想法。一起捣鼓代码的计算机程序员干活的方式也一样：一个人敲键盘，别的人提建议，改动照着这些建议做，新的建议又跟着冒出来。这是一个编辑过程，理想情况下由 spiritual community（精神共同体）的成员来完成 ¹。

参与式设计之所以好，是因为每个人都参与进来，每个人都能做出贡献，每个人的贡献都得到承认。它有助于培养共同体意识，也让所有参与者对最终成品有一份投入。那么说来，它对虚拟世界就是理想的做法了？

在设计团队这一层，是的。最终批准必须由一位（首席）设计者正式做出，但这实质上只是给共识意见盖个橡皮图章 ²。头脑风暴是管用的。

可是，把参与式设计扩展到设计团队之外，就完全是另一回事了。虚拟世界一旦进入 beta 测试，设计者一向乐于接受玩家的想法，但在那之前呢？管理起来可能非常困难，尤其是邀请虚拟世界的潜在玩家参与设计，会把贡献者的人数增加好几个数量级。设计团队本身既可以作为一个整体协同行动，也可以按个人各走各的。通常会是前者，因为不这样的话，玩家就会设法挑动设计者互相对立。不过，这并不是玩家可能这么做的唯一原因。我下面会解释……

设计者为什么会想让玩家参与设计？这么做有几个值得称道的理由：

• 让玩家感到自己对虚拟世界有一份投入。

• 一万个头脑胜过十个头脑。

• 设计者可以充当文化种子。

• 玩家觉得自己有影响力——他们真能带来改变。

• 如果玩家更了解设计过程，就不会对表面上让他们不快的东西做出条件反射式的反对。

• 它把玩家吸引进一个共同体。

此外还有一些不那么值得称道的理由：

• 玩家可能被操纵，去接受一些他们本来会觉得难以下咽的建议。

• 设计者可以接受一些他们早就想到的“新”建议，让玩家误以为自己参与了，其实并没有。

• 设计者可以摘走玩家无偿付出所结出的最好的果子。

愤世嫉俗的看法（而玩家可以非常愤世嫉俗）是：这一切主要是一场公关活动。真正重要的东西从来不会被讨论，除非是为了让玩家提出一个设计者中意的方案，好让它在实施之后不受欢迎时，批评能被引开。毕竟，虽然有些玩家的想法会很出色，但大多数没法用（陈腐、前后不一、离谱、乏味、实现不了、版权属于别人，等等）；发一个问题出去，然后等“正确”的回答出现，再把它抓过来当作一个了不起的原创想法，这是再简单不过的事。参与设计的玩家，往好里说是一块供设计者试探反响的板子，往坏里说是背叛了尚未登场的玩家的叛徒。在这种情况下，设计者如果作为一个整体行动，就比不这样更容易摆布参与式设计。

幸运的是，这种对参与式设计的轻蔑看法还没有在玩家群体里占据强势地位。参与式设计确实管用，能带来实实在在的好处。它将被《星球大战：银河》（Star Wars Galaxies）大量采用，很可能在那里效果不错。在面对一项重大考验时——让玩家逐渐明白，新手不能一上来就扮演绝地武士（Jedi）角色——参与式设计的优势尤其明显 ³。

不过，它长远的未来更不明朗。与玩家创造内容的情形一样，设计的某些方面也存在涉及“权利”的法律问题。假如一位编剧向一位导演推销了一个电影构想，而这个构想五年后出现在一部电影里，连署名都没有（更别提报酬），这位编剧就会请律师出面 ⁴。虚拟世界的玩家提出了一个设计构想，为什么这个构想被采用时，他却得不到（职业上或金钱上的）任何认可？

“意见是自愿给出的”这种答复，也只能在有限程度上管用。举例来说，它可能是另一个虚拟世界里已经存在的素材，而那个世界的设计者持有版权。再说，尽管“你的想法被纳入设计就已经是足够的回报”这一假定眼下还有市场，但未必永远如此。假如有一个新的、高知名度的虚拟世界为它采用的任何由玩家提出的想法付钱，情况就很可能改变。在那种情况下，完全的参与式设计可能很难有效推行。

测试设计

大型虚拟世界是先设计、后实现的 ¹。实现之后，可以用试玩把已经悄悄混进来的许多设计 bug（以及程序 bug）找出来。不过，在这个阶段修掉它们代价很高，因为要改动代码（可能是相当大的改动）。设计里的毛病，能在实现之前修掉的越多越好。

可是，当没有一个世界可供测试时，你怎么测试一份设计？

有些方面可以通过写一些又快又糙的程序或宏来测试。经济系统变成一张电子表格；战斗变成几屏 C 代码。这有助于把数值算对，但对玩法什么也说明不了。结果可能是一个平衡性很好、玩起来却纯粹是苦差事的虚拟世界。

用桌面推演的方式来模拟虚拟世界，能取得出人意料的效果。你画出一片区域的粗略地图，在上面放几枚棋子代表玩家角色（PC）和怪物，然后移动它们，按你预想中成品该有的样子去做事。不过，这需要一种超出大多数设计者能力的纪律性；你确实应该在推演结束后做记录、讨论发生过的事，但大多数设计者一有机会就忍不住当场争论起来；结果是，这类纸笔模拟通常达不到本来可能有的效果。

我通常向新虚拟世界的设计团队推荐两样东西，来对付这些问题：dummy logs（虚构日志）和 mock diaries（虚构日记）。两者都基于同一个前提：设想将来某个时候，虚拟世界已经实现，人们真的在玩它。那些玩家会在做什么？

dummy logs 对文字世界比对图形世界更管用。做法是写出一份假想的游戏过程记录，就像某个典型玩家会记下来的那样。它迫使设计者直面自己的决定带来的具体后果：界面、房间描述、移动、交流、整体气氛，以及（至关紧要的）玩家会做什么。这个练习通常会把一份设计最大的长处和短处都暴露出来：设计者随后就可以把长处做足、把短处铲掉。

对图形世界来说，dummy logs 更像是 dummy storyboards（虚构分镜）而不是日志，效果也没那么好 ²。话虽如此，问问新虚拟世界里那些热情十足、一心想当设计者的人，他们觉得大门一开自己的玩家实际上会做些什么，仍然大有收获。

mock diaries ³ 和 dummy logs 类似，但针对的是更长期的问题。做法是为一个玩家写出一连串假想的日记条目，覆盖若干次想象出来的游戏过程，讲这个玩家的一个或几个角色过得怎样、做了些什么。如果这些条目常常缺少兴奋点或乐趣，或者开始看起来千篇一律，那你可能已经发现了一个潜在的问题。

dummy logs 和 mock diaries 可以针对各种不同的玩家群体、以及他们在游戏历程中的不同阶段来写。你的第一次游戏过程，会和你玩了一周之后的不同（本来也应该不同！），而玩了一周之后的，又会不同于一个月、六个月、两年以及更久之后的。为这些时段写出 dummy logs 或 mock diaries，你就能让自己确信：会有足够的玩法支撑长期游玩，而且这对你针对的所有主要玩家群体都成立。

dummy logs 和 mock diaries 各有变体。例如，杰西卡·穆里根建议用 mock letters（虚构信件）而不是日记；这类信件能帮设计者去考虑好玩在哪里，而不是仅仅假定它们好玩。

不管怎么说，设计都必须测试。正如程序员每写完一段新代码就要测试它一样，设计者也应当考虑，往虚拟世界里每加一样新东西，会产生什么影响。我得赶紧补一句：你不必每次都写出 20 条新的 mock diary 条目，但至少应当考虑它放到设计其余部分里是否行得通。虽然偶尔你真得说一句“哎，先放进去看看效果吧”，但大多数时候不必如此。想想好玩家和坏玩家分别会怎么理解它，你就有答案了。如果一个想法太原创，以至于你没法这么做，那好吧，你可以把它写进设计文档然后祈祷——但务必确保：万一它真的失败了，没有什么重要的东西是靠着它能行得通才成立的。