# 整体图景 LLMS 索引： [llms.txt](/dvw/llms.txt) --- 为了便于描述，我把虚拟世界的设计过程切分成了几块——不过，这个设计过程实际上是整体的。你不能把设计的各个侧面孤立起来看：这些侧面彼此影响的方式，可能不会立刻显露出来。 举例来说：工匠们抱怨自己的城镇死气沉沉。你查明，这是因为制造（与战斗不同）是一种单人活动。你引入了一些需要好几个角色一起协作的制造流程。玩家们把房子盖得彼此紧挨着，好让自己能迅速往返于各个制造中心。城镇因此变得更有生气。可是，如今人们在城镇里待的时间比在荒野里长，冒险者便抱怨荒野死气沉沉了。 如果你提前看出这些问题，就可以把它们作为一个整体来处理。一次只处理一个，可能只是把它们推来推去。这就像想把一个燃烧的圆环扑灭，却一段一段地浇水——你刚把这一段浇灭、移到下一段，前一段就又烧起来了。你必须一口气把它整个扑灭：你没法靠切分来解决问题。遗憾的是，只要设计团队不止一个人，你就总免不了某种切分；在这种情况下，平衡各项事务就更难了。 由子系统相互作用引起的问题，主要属于一致性、兼容性与深度这几类；幸运的是，这些是可以处理的。不过，当一份设计要求两个彼此直接对立的元素同时存在时，就必须做出艰难的决定：你可以要永久死亡，也可以要某种形式的复活，但不能两者都要。间接的矛盾解决起来几乎一样困难，只是更不容易发现。玩家希望能以固定价格卖掉自己制造的商品，以保证一份收入；可这样一来，就会有很多人去制造那些商品，制造的人一多，原材料的价格就会被抬高，而原材料一贵，玩家从自己商品上得到的收入又会减少。 解决办法并不容易找到。切分带来的困难，可以通过稳妥的开发实践来处理——沟通、定期的设计会议、内部网站、首席设计者签字确认，等等。至于设计本身的问题，团队必须力求稳健：他们可以处理事先注意到的任何问题，但虚拟世界一旦上线，他们就得依靠自己内置的制衡机制，来确保不会出什么可怕的岔子 [^128]。尤其是任何针对经济的新设计，几乎肯定不会一上来就管用，所以必须准备好损失控制代码，以应对不可避免的磨难。 [^128]: 既然制衡机制本身就是玩家 exploit（可被利用的漏洞）最丰富的来源之一，在设计它们时也必须小心。就我个人而言，减少 exploit 与设计 bug 的最好办法是唱反调：假如这条或那条规则已经生效，我会怎么把系统搞垮？许多成功的虚拟世界设计者都是前黑客（按这个词的传统含义），这或许并不只是历史的偶然吧？ --- 本节页面： - [设计不足与设计过度](/dvw/book/05-life-in-the-virtual-world/05-64-the-whole-picture/05-65-under-and-over-design/) - [参与式设计](/dvw/book/05-life-in-the-virtual-world/05-64-the-whole-picture/05-66-participatory-design/) - [测试设计](/dvw/book/05-life-in-the-virtual-world/05-64-the-whole-picture/05-67-testing-a-design/)