整体图景

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

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

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

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

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