测试设计

大型虚拟世界是先设计、后实现的 ¹。实现之后，可以用试玩把已经悄悄混进来的许多设计 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 条目，但至少应当考虑它放到设计其余部分里是否行得通。虽然偶尔你真得说一句“哎，先放进去看看效果吧”，但大多数时候不必如此。想想好玩家和坏玩家分别会怎么理解它，你就有答案了。如果一个想法太原创，以至于你没法这么做，那好吧，你可以把它写进设计文档然后祈祷——但务必确保：万一它真的失败了，没有什么重要的东西是靠着它能行得通才成立的。