为何这些游戏总是延迟发行？

网络游戏设计者们习惯于把所有他们能够想到的东西都塞进游戏中，作为维持用户进行游戏并且长期付费的诱饵。这种做法造成更多的问题，比它所解决的问题更多，因为游戏中的每个活动部分都会彼此联系起来。在达到一定数量的时候，要对事物行为或是道具进行修改而不牵涉至少两项其他的游戏机制实际上是不可能的。在这种情况下，增加一种新的特征或是游戏机制，很可能会彻底改变游戏的平衡。

一个优秀的制作人和项目经理从一开始就明白设计团队总是走过头。如果任他们自己发挥，到设计者们决定好游戏中想要的东西的时候，就算是耶稣的12门徒到了团队里，也没有任何希望能在你退休前发行游戏。

在开发阶段早期，这些都没问题。尽可能在设计文档中多写些东西是很有意义的，因为到了后期想要增加特征而不破坏游戏整体几乎不可能。在设计文档完成前，你要理智地削减一些特征。可以把这些当作必经之路，而且，在基线确定之前多排几次特征的优先次序对团队实际上是很好的练习。

我们发现，开发延迟最大的原因是，网络游戏团队在设计完成前就开始动手做游戏。尤其是对那些只有草稿就开始作的项目，制作者要要迅速地投入到具体的游戏制作中去，他们幼稚地认为只要做完了1，做2，做完了2，再做3，然后按4、5、6这样的顺序来做这些事就可以完成开发，而不是事先考虑好1、2、3、4、5、6这么多事情和步骤，再来进行开发工作。这种想法是极其错误的；另外，对团队来说可以使用原先上一个项目留下来的代码也是一种难以抗拒的诱惑。他们很容易得到这样一种印象，既然已经有了这样一个“领先”的部分，那么在设计完成前基于执行上的任何错误或是改编都可以轻易修正，就好像已经有了2B，那么2B+2B+2B=2B2B2B这样的十六进制计算就可以实现，这种想法是对以前东西的盲目信任，也是错误的（这就好像宗教行为，领袖判断了一件事件的价值，提出了自己的观点，而追随者们一生都陷入盲从）。这些危险的行为绕过了完成并审查设计的重要步骤，想要创造出一个连贯完整的思路。这就像开始造一辆汽车，而又不知道到底需要多少零件，它们价值多少钱，每一个零件应该按装在汽车的什么位置。有可能在开始时是制造新型雪佛莱，而最后却造出了福特Pinto，然后不得不推翻所有的工作重新开始。

就像上面这种情形一样，这只会在稍后带来更多的工作，并没有省力。由于想要加进游戏中的特征和机制数量太多，大部分团队会离开始时越走越远。如果团队在开始编程时没有一份完整的设计，想像一下当开发进行了6个月，设计师发现某些游戏机制不能采用时会发生什么。就如大概已经猜到的那样，他们不得不挑出一些内容重新整理，这会影响到其他已经做好的内容，或许会造成大量内容必须重做的后果。结果不但没有提前6个月，开发团队发现自己退回到起点（如果是在项目开始时，这会是一个好出发点，但那已经是半年前了，在他们更像是在山洞里呆了6个月）。如果团队在开始制作前能做好设计-----一个过于热情、负荷过多以及特征优先排序进行过评审的设计-----就可以避免重新开发，这将会节省大量时间。

另外两个开发延迟的主要原因是NSS（素材整理综合症）和它的伴随产物“功能悄然蔓延”。由于强制性CCP（更新控制程序）的整体概念对大部分游戏开发者来说十分陌生，开发团队很容易发生NSS和功能悄蔓延现象，然后很快就发现，由于他们试图把所有很“酷”的东西都加进去，导致了自己落后于开发里程碑。然后，他们发现那些没有经过测试就追加到平衡中的机动部分破坏了其他游戏部分，要修正它们需要延迟更久的时间。用汽车来进一步打比方，就像在制造了6个月以后决定要用更强力的汽化器，然后发现新的汽化器需要比原来更大的空间。由于坚持要用新汽化器，制作团队拆开机器，来为新配件腾出更多的空间，然后在零件散满一地的时候发现，有15个旧零件需要重新设计得更小，或是变成不同的形状才能达到目的，还要为每个零件花更多的钱并为项目追加6个月的时间。现在，不仅团队之前花了6个月，还有追加的另外6个月，整整浪费了一年的时间-----天啊！

不切实际的设计也会造成延迟，因为对一个想法着迷并且执着的设计师和开发者对于改变这一点非常抵触，即使在很明显需要做出变更的时候。你不会相信那些开发者能绕出多冗长迂回的理由来回避重新考虑自己喜欢的概念。他们会继续花更多的时间和精力在上面，坚信他们只是还没能计算出细微的差别之处，但这只是时间问题，只要再坚持一下，或者想要的东西马上就会出现了。当很明显这个想法或概念只能留到下一个项目中时，时间已经一个月一个月地过去了。