电脑游戏结构与设计——第十三章

tbs005

第十三章　程序与［过程］

  

＊程序

＊［过程］

＊原始码控制与程式码回顾

＊资讯传递的重要性

＊主动与反应的资讯

  

在这个章节中，我们将会讨论运用软体工厂的概念之后，若想要在成本效率上有良好的成绩，必须进行的程序与实行事项。

不过，这些程序与实行事项并非受限于软体工厂的范畴，它们可以在所有非琐碎的研发中占有优势。大部份在研发中的软体（尤其是游戏软体）在研发方式上面并没有真的程序化，一般的游戏企划在成长时，只是从［稍有系统］到［很有组织］而已。

这个章节中提及从管理观点来看研发过程，而管理的部份则是藉由状况报告以进行控制。满足管理部门的兴趣，是程序与实践的主要理由。

管理者想要取得精确的资讯以及状况的报告，然后以这些资讯来判断未来的行动国，不用打扰研发方面的工作。同样的，研发者不想让管理者不分青红皂白的介入，并在一连串没有重点、浪费时间的问题下，打断了研发的过程。

这些程序与实践将会包括互动的介面与区域，让资讯可以在随时不断更新的方式之下传送，并定义出控制流程，用来引导研发的方向。

这个［过程］并不见得象您想象的那么糟糕，它大部份都是与常识有关的。不过，最好的［常识］，就是把它写下来让每一个人都很清楚这边所指的［常识］究竟是什么。如果每一个人对常识的概念都不同时，它就会碎裂成不同的看法。

这些过程的执行是否要延伸，端看企划的需求而定。一个很重要的企划，就需要用严格的方式来进行：而较不重要的，可以用比较轻松的方式来看待。

  

程序

在这个章节中讨论的程序类别，都是减少劳力浪费的基本控制与方法，并在低品质的成果污染整企划之前，将不良的部份拔除。

　　

下列的程序列表，是在企划的进行时程中，维持精确企划资讯以及控制的建议事项。每一个程序都在后面的章节中进一步的说明。

  

＊设计回顾

＊文件回顾

＊技术回顾

＊程式码回顾

＊单元测试

＊整合测试

＊系统测试

＊设定测试

＊后退测试

整体来说，［回顾］行为在找寻与侦测上面，要比单纯的测试来得好；先决条件是把回顾力量集中在找出问题，而不是修正问题。另一个附加的好处，在于回顾也倾向于找出不同类型的错误。

  

回顾

回顾的格式大体是相同的，只不过回顾的东西不一样。

二种类型的回顾有［正式］与［非正式］。要进行哪一种类型的回顾，端看工作的本质来决定。这个工作与内容有密切的关系，而且正式与非正式的比率，也是由情况来决定（这一切通常是由企划管理者在分派工作时决定的，但是个体的贡献也有可能影响这个决定）。不管怎么说，企划管理者知道工作究竟有多复杂，所以他（或她）应该可以说明哪些东西需要回顾一下比较好，重点是没有什么工作可以不经过查核的手续。回顾通常是在一个企划受到时间压力时，第一件半途而废的事情；这通常是一件大错误。省下这一点时间，通常会造成长期有痛苦。

只是把没经过查验的工作插入企划中，然后发现没有倒塌就认为一切OK，算不上什么好事。这种［方式］并没有在企划时程表中，指出会出现的任何难题，更没有告诉您这些工作是怎么完成的。回顾可以让您在早期的阶段中，拔除任何明显的错误??在他们进入企划之前??而且对于预防低于标准以及虚有其表的工作而言，这是最好的方式。

在一个不进行回顾过程的企划中，低水准的工作会变得难以侦测并存在很长的时间。这种类型的问题会等到很久之后才显现出来，通常是在某些人修护或是更新受影响的地区时才会发现。在这个时候，又有谁知道这个毒害扩散的范围？后期的工作可能是以这个反复无常的原始工作为基础，导致邪恶长存。

回顾还有其他的好处：它可以让所有的员工共享并散布相关的知识。由于这个工作会在一个小组中进行讨论与回顾，这些知识会传播到所有人之间，大量的降低了风险。

  

非正式的回顾

非正式回顾很简单，完全没有真实的纸上作业，也没有复杂而耗费时间的会议。

一个非正式的回顾包括了把数个小组成员集合在您的萤幕旁边，然后与他们讨论您的工作，如果能进行一段排演会更好。

这些回顾可以用数个不同的方式来完成。举例来说，在一个非正式的程式码或是设计的回顾中，您可以选择几种不同的方式，象是简单的排演与视察，虽然这些作法一样可以在正式的回顾中运用。

排演是由这个工作的作者来指挥，主要的作用在于可以用很简单而且容易了解的方式进行回顾工作。排演的优点在于快速而简单，而且它可以忽略掉工作中的科技品质。这并不是一个真正的评估，比较象是一个评议请求（request for comments,RFC）。这也是一个分享技术与经验的好机会。如果一个回顾原有更好的点子以及更佳的工作实施方法，也可以在这边传达给作者。这种交谈也是很正当的；有时候回顾员工会学到一些新的技巧。

讯息的传递协助了分散大量知识到所有的人身上，所以会降低小组对单一人物的依赖。在理论上，每一个员工都应该努力淡化本身的地位，没有一个人是绝对重要的。很明显的，以这种方式来工作，管理阶段不应该在任何人身上加诸压力与紧张；要让一个人做出更多的事，就在他身上加诸更大的压力，这种观念是错误的。要让人们全力表现出他们的能耐，他们必须尽可能的放轻松并有安全感，而且还要了解他们在做的事情，需要在期限之前完成的重要性。这已经造成足够的压力，而不用靠着管理阶层来做额外调整。

不过，排演并不一定都是乐观的，因为在一个回顾过程中，大多是以最没效率的方式来进行。在统计学上来看，排演的有效程度有很大的变动，能打到的错误比率可能在30%到70%之间。

其中的一位回顾员通常是您的技术管理者，而他（或她）可以让您的工作有保证。在这方面完成之后，只要有任何主题（或是问题）在讨论并解决之后，就可以插入企划的主要贮藏室之中。这边很重要的一件事是，技术主管不应该在这边以管理的权威施压，否则在作者觉得有必要让他的作品发扬光大、证明他自己的同时，会让结果变成其他的东西。这件事并没有发展到这个程度的必要，它的目的只是讨论工作并侦查出任何明显的错误。

从另一方面来看，视察几乎是排演的相反。这并不是与作者谈论并一路看完工作内容，而是要技术管理人员拿着?绳并看着排演进行。这边需要以全新眼光来看工作内容，可能有助于发现作者遗漏掉的问题，这是因为作者［太熟悉］作品所导致的。不过，缺点就是这一类的视察要花漫长的时间来进行，不过至少它有很大的机会找出错误。

如果在回顾的过程中，有人找到了问题并靠着一些动作或是变更修正，那工作内容就需要原来的回顾员再回顾一次，包括那个第一次提出要求修正事项的人员。这个随后而来的回顾是否正式，必须靠着它的本质来决定。庞大的变更需要正式的回顾，但是较小的调整以及改善只要非正式的回顾就行了。至于变更控制，它本身就是一个庞大的主题，将在第14章中讨论。

非正式回顾的危险在于它们有可能变得太不正式。所以，在一次回顾中经常指派出负责人员，是一个较好的方式。这个非正式回顾也是正式回顾的一部份。一个没有效率的非正式回顾可能比完全不回顾还糟糕，它会逐步把错误的安全感小组之中，导致最后出现大麻烦。

  

正式回顾

通常在一次回顾中会包括四到五个人。这一个回顾小组的人员，是从合适的群组领导者中遴选出来，而且先前的负责人员也应该包括在内。只要有任何没效率的东西，就会让所有东西都没效率。

作者的责任就是确保所有的回顾员都充份了解他们要看的东西，才能展开这场回顾；这可能包括影印好的工作内容，并回答任何回顾员在进行之前的所有问题。

回顾员的责任就是确保他们十分熟悉要回顾的东西。回顾会议真正的目标并不在这个成品上面，这会花掉太多的时间。回顾会议的目标是让回顾员在会议之前，详加讨论要回顾的内容。

所以，在会议之前回顾员应该完成一份回顾表，列出他们想要在这个会议中提出的重点。视回顾的规模大小，他们应该要花一到二小时的时间，看完相关的资料。一个简单的回顾将在第15章中提出，其中包括的RTF（Rich Text Format）文件已经附在本书的光碟片上面。

基本上，回顾表是用来提醒回顾员，让他们不致于忘掉任何要观察的东西。结论将写在列表中，并以不同程度的严厉眼光来看待，象A是最严重的错误，而E是最小的问题（当然了，您也可以选择适合您自己的分级方案，但这种方式最为常见，而且最容易了解。这简直象是回到学校一样！）

工作的内容应该以数个标准来回顾，其中的［符合需求］是最重要的一点。这才是我们应该要求的东西。能够与企划和公司标准相符也是十分重要的，但是功能很明显是第一优先事项。

在会议中，回顾表上的每一个要点都要提出来讨论。这个会议将从负责人员的展示开始进行，这一场展示将会概略性的说明工作内容，并开始讨论其中包涵的东西。

很多人遗漏的一点是，在一个回顾中的批评并不是针对任何人，或是对完成工作的员工进行人身攻击。回顾的目标是取得第二种意见，把工作中出现的问题拔除。让一群人专注于一个想法，可能会更容易找出问题所在。这个回顾应该集中力量于找出问题；这个会议并不是用来讨论解决方案的。这样做只会让所有人分神，目前并没有必要把所有的问题都解决掉。

回顾会议的真正本质，事实上就是钜细靡遗的找寻错误。它只是在一场独立的回顾会议中，利用讨论来进行资讯分享的时刻。在回顾的过程中，其中有90%的错误是在会议之前找到的。

一旦在回顾表上面的所有重点都讨论完之后，他们就可以进入［行动状态］。基本上，这些要点不是被接受，要不然就是遭到拒绝。如果它们被接受了，那么作者就必须进行校正的工作，来满足提出这些要求的人。如果有超过一位回顾员提出相同的缺点，只有其中一个会取得问题的［所有权］。他们考虑到的所有重点都必须合并成一个电子回顾表，将与工作一块储存起来，以待日后查验。如果这些变更会显著的影响功能（例如它牵涉到其他的区域），那就有必要召开一个变更控制的会议，讨论任何逆向效果中的控制与限制。

视需要变更内容的本质，可能必须进行另一次正式的回顾。在这种情况下，应该运用同一组回顾人员。如果所需要的变更级小，那一场非正式回顾就应该足够了。作者需要让每一位回顾员在他们指出的要点上签名。一旦这一步完成之后，工作就可以插入企划的主体中。

这一切听起来象是一场冗长的过程，而且??说实话好了??的确如此。不过，我已经发现只要能预防次水准的工作进入企划，那就可以大幅节省您花在回顾上的时间。

我也发现了一点，如果有人知道他的工作会被人拿来回顾，他们在工作时就会更加小心并注意各个细节，而且对他们所做出来的东西更为自豪。这可以增加注意力，对士气有正面的好处。人们知道他的工作在检查之后即将纳入企划，所以企划代表了更高的标准（而且风险也会大大的下降）。在这些理由下，回顾大约可以增加20%的生产力。绝对不要低估提升员工士气对输出结果的正面效果。

由于游戏研发的本质，执行回顾的工作会受到一般性的抵抗。要压制这种抵抗的最有效方式，就是收集回顾中找到的错误，然后算出找到每个问题的平均时间。把这个统计数字，与研发后期修正这些错误所要花费的时间（与金钱）相比较，就没有人说得过您了。

  

一般测试

如同我看过的很多企划都没有回顾系统一样，我从来没有看过一个没有测试系统的企划。

我看过很没有测试效率的企划，而且这些通常很容易发现。当游戏推出后处处都是臭虫时，它通常有一到二个理由：这个测试就是够不上水准；或是研发小组的时间用光光，发行公司已经受够了，所以一定要把它丢上市面，不管里面有多少臭虫。在这边，我们先来考虑第一种剧本：次水准的测试。

测试是找寻错误的过程，您在程式码中预期可以找到多少错误？就算是陪审团也无法得到一个正确的数字，但是在业界中粗估的平均数字，是每一千行的程式码，会出现15到50个错误。在游戏产业方面我会稍微高估一点，虽然这方面可能会视游戏是小型或是中型企划，而有所不同。

测试是在找寻研发任何阶段中，可能发生的数种错误：但是，一般来说，测试可以侦测出来的错误，只限于原型与程式设计的阶段中。请牢记这一点，只要一个错误没有被抓出来，时间越久要修正它的费用就越高。如果在设计阶段出现一个错误，在实施到一半时才要修正它很显然要比在设计阶段中，把它抓掉更费时费钱。

事实上，这是实施这个过程的主要理由。它可以让您试图去［相位牵制］；不是，这不是与［星舰迷航记］有关的东西（虽然它应该也是）；这边的相位牵制，表示您要在创造的阶段去侦测并修正其中的错误。一个标准的统计指出，在创造时发生的错误如果没有抓出来，事后的修正要花费将近200倍的时间。很明显的，侦测并修正错误的动作越早做越好。

同时，也要记住测试本身并无法影响软体的品质。尝试藉由测试来加强软体的品质是没有用的；它的作用只不过是品质的指标。它后面必须附带着决定性的方式，才能加强品质；让这些额外的效果反应在下一个测试过程中。

在这部份提及的测试，指的是针对程式码；所以下列的章节中，指的就是程式码的测试。

  

非正式的测试

［非正式的测试］与［非正式回顾］指的并非同一件事。这边并没有必要把一群人聚集在萤光幕前面，因为非正式测试只是任何研发者，在进行程式码模组研发时做的测试。

每一个研发者在撰写一个程式时，都会周期性的将程式码编辑并进行测试（至少我希望如此！）这是一个很好的出发点，但是这并不足以预防爬进程式中的臭虫??尤其是在模组整合的阶段。

大部份我看过的游戏研发企划中，只有运用到这种类型的测试，再来就是让一个有活力的人进行游戏测试，一直延续到企划结束为止。这通常只能勉强合格。

为了加强非正式的测试，有为数不少的自动错误侦测应用程式（象是Numega Boundschecker）以及程式设计的技巧，可以用来找出明显的错误。

它真的有用，但是如果能再加上一些基本的测试程序，这个风险可以明显的降低。虽然是否要进行正式测试，必须看工作的本质来决定，所有在这边讨论的测试阶段，都应该以一种或是其他的形态来实施。

  

正式测试

正式测试十分类似非正式测试，只不过它们比较具有结构性。

一个特殊模组所提供的测试描述，将用来对这个模组的所有功能与特色，进行耗损性测试。这段描述通常是由该模组研发人员中的软体规划师所撰写。

测试描述是以一种特别的方式来撰写的（一个简单的测试描述将在第15章介绍，而且以RTF格式的文件放在本书的光碟中）。这个测试应该是设计用来执行这个模组中的每一条程式路径。因为要完成这个工作并不是简单的事，所以测试描述本身也是回顾的重点之一。

三种主要的测试可以用这种方式完成：正向、负向与特别。

正向的测试是在检查预期的行为，所以这些测试是写来让模组产生预期结果的。一个正向测试的例子，是对一个专门用来画三角形的模组传递一连串的方位，并预期在画面上看到正确的三角形。

负向的测试是在检查预期的行为，所以这些测试是写来让模组产生预期结果的。一个正向测试的例子，是对一个专门用来画三角形的模组传递一连串的方位，并预期在画面上看到正确的三角形。

负向测试则是查看没有预期到的行为，而且这些测试是针对产生例外而且还能控制的错误状况。一个负向测试的例子是对一个专门用来画三角形的模组传递三个相同的数值，或是排成一线的三个点。这时应该可以测试临界的状况，在您送出三个很大的数值（正值或是负值）时会出现什么情况？那一串很小的数值呢？或是送三个零进去？

在规划测试时，试着考虑各种不同的输入值丢入系统，不管是有效或是无效的数值。这些物件将以各种可能压迫系统；把您找到的任何东西统统丢进去。您可能发现并非所有东西都会出错，但是您可以除掉其中最麻烦的问题。

特别测试是乱数的效果。测试者要玩弄模组，并查看他（或她）是否得到预期的结果。这些测试只是把一些测试者想要的东西丢入模组，举例来说，他可能把一组乱数产生的点丢入绘制三角形的模组中，并查看输出的三角形是否正确。

很多组织只会使用这三种模组的其中之一，但是要进行真正有效的测试，这三种方式都该使用。如果一个测试模组已经写好，可以把这三种测试隔离测验，那就应该让测试者可以任选进行的测试项目。

当您在执行一个测试描述时，结果应该以电子档的方式记录下来。这些测试应该以文字说明，让结果可以表达出［真］或［假］的回应。在一些例子中，需要进一步的描述才能得到正确的结果（尤其是在测试失败时）。

如果一项测试失败，那么就要进行下一步的行动。一项测试的失败理由不外乎二项：问题在于程式码，或是在于测试。这二者所采取的行动都是一样的，测试者站起来回报问题，并展开修正问题的工作。

  

单元测试

单位测试是研发者进行的第一波测试行动，而且它是一种开箱测试，表示测试者完全了解要测试对象的从里到外。从统计学中显示，在平均的情况下，单元测试可以在程式模组中，找到将近一半的错误。

单元测试通常是以严格的方式来进行，它会设计一个简单的程式，该模组中的每一种功能动作。这可能简单而且没有互动性，或是它会更为先进并容许设定输入的参数。

单元测试的用途如字面所示：它是在隔离的状况下测试。这可以预防其他方面的互动，象是容易出错的模组。这就是为何要限制测试环境的原因，而且也是为何这个限制的测试环境要越简单越好。有好几次我在测试结果中找到错误，最后发现它居然是源自于我所使用的资料！如果您在程式码中找一个虚幻的问题，最后发现是您输入的测试资料出错一定会让人心灰意冷（我试着将它看为提升经验的练习，我真的这样做了，但是我不会建议把这种过程，做为判断您神智清楚的举动）。

单元测试可以在数个不同的层级中施行。如果我们拿C++做为例子，那单元测试可以在模组的层级或是物件层级中进行。对那些不熟悉物件导向科技（您之前看的是什么？）的人而言，一个物件是一个逻辑性的资料与程式码封包，可以用来处理资料。这个程式可以分为许多方法，类似于程序化程式设计的功能。物件等级的测试是一个黑箱测试，而方法层级测试是一个开箱测试。

当然了，测试无法保证模组中不会有任何错误。一个测试只能证明模组中有错误，但这就是要牢牢记住的重要规则。如果一项测试显示出模组中没有错误，那比较可能的情况，是这个测试本身不适用。或许它没有包括了足够的状况，也可能测试本身有问题。

要让研发者的想法倾向完成的东西非测试不可，实在有困难。一个成功的测试可以找出破碎的程式；您所认识的人，又有几个人愿意主动把自己的程式打破？

事实上，这是一个别有含意的问题，而答案应该是所有人。如果不是的话，那这些研发者还不够彻底。不幸的是，我注意到一些研发者在写好程式之后马上宣布他写完了。他们似乎很厌恶在自己的程式码中找出错误，就象这个举动会指出他们的弱点一样。

这一点在游戏产业中特别盛行，让软体之狼四处横行。在某些公司中，指出任何迹象的弱点，象是取得把东西撕碎的特权一样，只留下您被四分五裂的尸体，被兀鹰吃得一干二净。

每个人都会犯错，这是很自然的事，但是它代表的不只是一个错误：您是要在自己的程式码中找寻并修正一个错误（承认您自己的失败），还是要拒绝接受您会犯错的事实，甚至不想全面检查？

研发者应该主动查看并打破自己的程式码。他们需要进行测试，假定程式码是一个有臭虫的?题；事实上，他们应该真的想要找出错误。用这个角度来看吧：您宁愿让谁找出您程式中的错误？您，还是其他人？

如果您先假定不会找到任何问题，那就有可能找不到任何问题。这并不是因为真的没有错误；这是因为研发者不愿意仔细而且努力，去注意该注意的地方。

  

整合测试

整合测试是研发者会进行的下一阶段测试，虽然它也可以由其他的组合来执行。如果由一个测试小组的成员来做这件事，那这就是一个黑箱测试；如果是由研发者来进行测试，就是一个开箱测试（在进行整合测试时如果能由研发者与小组中测试者同时进行更好。不过，整合测试是介于单元测试与系统测试的中途站，所以这并不是一个严格的规则）。

整合测试是测试新的程式模组，与现有程式基础是否能够整合的测试动作。它会造成组译上的问题吗？名称领域是否出现碰撞？它真的有作用吗？

这个程工测试??在必要性上面??并不需要单元测试那么详细，因为在这个测试中，要看的就是模组在程式环境下的运作情况。您几乎可以把它形容为模组的［实战演练］。

整合测试的焦点在于解决一个新模组整合进来的技术问题。在理论上，模组本身应该在单元测试之后已经没有错误。在整合之中，一些在单元测试中没看到的问题，通常会以十分明显的方式出现。这些可能会让人倍感挫折并很难查出来，提供您一个正确的动机，在这个阶段之前把所有的问题尽可能摘掉，而且您绝对不会把这些问题留到系统测试的阶段。如果您觉得在整合阶段进行错误诊断十分困难，那您应该试试到系统测试中找出一些小小的臭虫再来说这句话！

这个测试应该与单元测试差不多，应该写好一个描述，来执行每一条程式路径。

在整合测试中的一个严格的规则是，一次只能整合一个模组。这是一个简单而明显的规则：如果您把二个以上未经测试的模组同时整合进来，在找出问题的来源时，其困难程度将会以指数曲线上升。它们可以到处都是错误，或者它们可能在相互作用之后，以未预期的方式来运作。不管是哪一种，都是您绝对不想踏入的领域。

好消息是，利用物件导向结构的系统整合，并不会比早期的古老日子中，采用程序化的程式设计难到什么地方去。物件导向技术可以让所有的东西都简单点。游戏研发在采用这些技术上已经慢了一步，主要是因为物件导向应用程式被认为是慢火炖煮的软体，而且在编辑时大家都认为产生出来的程式码很没效率。

这些在早期的恶劣日子中或许没错，但是因于现在这个时代已经可以与作业系统合作；如果一直抱着把系统每一分效率都逼出来的想法，会越来越困难。除此之外，靠着物件导向API（象是DirectX）扮演将游戏与基础硬体加以隔离的角色，运用程式语言让研发更为容易，是比较合理的作法。

一旦整合测试完毕，这个模组就可以签名了，它已经是基础程式的一部分了。

  

系统测试

系统测试是一种至少要每天做一次的事；如果这不可行的放在，最少也要每星期进行一次。如果比这个频率更长，系统测试就会失去它的效用。程式码在每星期的变动量实在不小，如果要修复破损的程式码，却有其他的程式已经改变或是其他程式码以它为基础时，就是一件大工程了。系统测试的频率指的就是这种事情，在某些状况下，并不是所有系统都可以进行测试。这通常只有在最大的企划中才有执行的需要，而且大部份的游戏应该可以每日进行系统的测试工作。

为了方便起见，这个软体需要每天都处于可以扩建的状况。事实上，这是最主要的需求，不论系统测试是不是每天都要进行。这个软体应该在可以扩建的状态下，并不是指它要发挥所有功能；子系统可能还没写好，在这种情况下应该把它关掉。在这边指的［关掉］应该是由界面所定义的，但是目前还没有这个功能，所以它必须转换成［关掉功能］并输出一个除错的讯息，或是出现一个预期的错误，视这个界面的重要性而定。这个结构已经大部份都完成全面定义，让研发者可以轻易的取用。

扩建刚开始时，会由测试小组来一个烟雾测试，看看它是不是够稳定。这边的烟雾测试是从电子工程方式中引用而来的，用来测试刚建好的装备，看看它是不是会运作：他们把开关打开，如果它开始冒烟，就表示没有用。

如果没有通过烟雾测试，这个成果就会被退回。研发者在修整这个扩建的东西时，具有最高的优先权。这个东西损毁的时间越久，表示测试小组浪费的时间越多。这并不是一个好状况。

一旦这个成果开始运作，它就可以在资源控制系统中贴上一个标签。所有好的资源控制软体，都可以让您什对内容做一次［快照］，就算它有更新的档案在后期加入也能重新创造。每天制作一个快照是十分重要的，因为它可以确保测试小组在这个成果上面再多花一天的时间。

为这部份安排一个合理的每日行动系统，可以保证所有研发者在下午三点都签好名字。完成的程式码与模组就可以从资源控制系统进行查验，然后进行全面的系统建造工作。

同一个下午就可以进行烟雾测试，而且系统测试也可以在接下来的几天由测试者施行。扩建一个游戏的时间要受到限制，才能让系统测试者有时间进行所有的测试。

系统测试应该在二种层级中运作。第一个层级是执行测试描述，来检查是不是所有完成的功能都如同宣传般运作（这是系统测试中，有效的正向与反向测试）。这些测试的描述写法，很象是按照软体结构撰写的：在这个层级的测试中，主要在于结构设计的错误，而不是低级程式码的错误。当然了，有些在整合测试中没出现的问题会在这个地方冒出来。

第二阶段的系统测试，相当于特别测试。测试者应该玩这个游戏并测试所有的程式功能，看看是不是如预期的表现一样。他们应该看完手册来安装并设定游戏，而且遵循游戏的说明，看看他们能不能进入游戏中。

这样做有二个目的：把可能在程式码中到处乱爬的错误抓住，并提供初步的游戏测试资讯。很明显的，如果游戏仍在很早期的阶段，这一点可能帮不上什么忙；但是随着企划的进展，它会越来越有用。

在系统测试中的结果应该以电子档记录下来，而且任何的错误都要回报给企划管理者，来指派相关的人员去解决。

  

设定测试

设定测试是系统测试中的延伸。它是不同硬体设定之下的测试行动。

这对游戏而言特别重要，因为它们通常比较依赖硬体，而不是标准的应用。测试用的主机范围应该要包括市场上面的常见机种：从尖端的高速怪物，虚弱、年老只有少量资源的Pentiums，还有中间的所有东西。

还有，没错，我知道DirectX与其他的API应该可以解决所有硬体相容的问题。但是，如果您真的相信这一点，您真是有罪到什么东西都会信（如果您真的是这种人，给作者一封电子邮件。我们为您准备了一个投资的好机会！）

老实说，这个等级的设定测试对一个普通的研发工作室而言，通常超出了它能负担的范围。不过，一些独立的测试公司也可以帮助您解决这些问题。

如果这些资源无法在公司内取得，那么一些独立的测试公司可能是您最佳的选择（而且要比推出一个只有靠您研发用的机器来测试的游戏，要好得多）。

  

后退测试

后退测试本身并不是一种测试，相反的，它与这边讨论的所有测试都不一样。

后退测试是把目前相同的测试数据重新执行的动作，不同的地方只有动作的模组是前一个还没修正过的版本。

后退测试的用意是确保模组不会从早期的形态逆转。其中最常见的一种错误，就是再导入之前出现的错误。这个后退测试可以检查出是否有任何老旧的错误出现，而且它可以用在所有先前的测试类型中。

  ==================未完！请继续看下去！===================
[em17] [em17] [em17]

tbs005

［过程］

在开始之前，我们会看看研发的概论。在每一个阶段的研发中，都需要产生出正确的状况讯息。所以，我们这边需要一套程序，也就是之前说明的东西，才能做到这一点。

图13.1　什么是一个［过程］？

在图13.1中，显示出一种目前流行的模糊研发阶段。在现实中，在数个不同的要素相互交织之下，组成的主要研发要来得复杂得多。这个图表并不打算呈现这一点，而它的要点在于指出一个讯息传递界面??所以才需要［过程］这个东西。这个章节的其他部份，将致力于讨论如何实施这些方法，让这个方式不致于成为疯子的举动。

过程通常被大部份的研发社群鄙视为一种高高在上的方法。在研发社群中的游戏撰写部份，更是受到一致的嘲笑。过程被看成全面浪费时间（Waste Of Time,WOT），并会减少真正有用的内容（Really Useful Work,RUW）的完成时间。

一个WOT的例子包括重写一个老旧的程式码，以期与新的程式码相容；重写一个结构；以及无法控制的修正与变更。

这些研发者相信过程是完全没有必要的上层。他们并不把过程可以预防的额外工作，纳入他们的考量之中。

图13.2中显示出他们怎么认为这个工作会干扰到一个标准的企划。企划的工作中只包括了撰写新程式码以及修正旧程式码（RUW），而上层有一小部份的时间，是在处理小组中的动态：会议、重复其他人的工作，以及其他的WOT。

在图13.3中，显示出这些研发者在相信一个企划中要有过程时的表现。他们相信过程可以在一对一的情况下，直接减少RUW。在每一小时的过程下，企划就会损失一小时的RUW。如果这个过程很不适合目前的企划，这是有可能的；但是如果在十分切合的情况下，这个图表中的状况一样是错的。

在图13.4中，显示出一个没有过程的企划中，真正的工作分配状况。在企划变得越来越大，而且越接近完成的时候，WOT的数量会随之增加。增加的比率视在企划中工作的员工能力，以及好运的程度。

在图13.4中显示的是一个普通的企划。WOT的数量会随着加入企划研发者的数量而增加。在小组成员之间越有互动潜力，就更有造成混乱的潜力。

这个过程的效果（图13.5）??如果目前使用的程序是为这个企划精挑细选??就可以增加有效的工作执行并降低WOT。很明显的，这些是无法完全消灭的??没有生产力的工作会一直存在??但是这种良好的程序将足以提供双向检查（以及可见度），把这些降到最低。

这些过程必须随着企划的人员数量而缩减。如果这方面很有效率，那么这个过程的WOT与RUW比率，应该会维持固定的数值。

过程的麻烦之处，在于它真的很难在［过程数量］与［工作数量］之间达到平衡。在许多情况下，严格的制式化程序会在无视［企划的类型］以及［研发者的需要］之下，硬性的发挥作用。在这一类的状况下，这个过程会比不用更糟，因为它对研发者会造成示范的作用。这个过程在这边应该为企划小组所用；企划小组不应该去奴役过程。

  

案例研究13.1　疯狂的过程

在制作一个规模庞大的银行企划时，我发现太多的过程，要比太少的过程更具毁灭性。

这个特别成套的研发过程已经完整的写好相关文件，而且要遵循一个极端复杂的规则，放在一本300页的文件之中。

这实在太荒唐了！三百张纸？哪一种过程需要用300页，来告诉一个研发者如何在一个特定的企划中撰写程式？还有更糟的，这个过程追踪系统是以公司中自制的Word Basic写成的（这是与微软Word软体同时推出的程式语言），完全无法用在这个工作中。

维护一个程式模组，有时候需要超过20页的文件，有时只是一份简短的文章。表格可能需要二页或是三页才印得完。接下来这些东西都要影印出来，分配给至少五个人，然后把电子档案放在不同的目录中，部份文件中的名称还是用神秘的规则来创造，并在300页文件的某处加以定义。

这一切只是为了在核心模组中做一个小小的变动。您可以想象为了要创造一个新的模组，要用掉多少红色的标签，而且我甚至不想把这些标着红色标签的文件，送到测试小组手中。

这些过程真的是太复杂了。这些规则是这么的奥妙而复杂，没有人能够全面理解整个程序。错误发生，捷径横行，而且程序遭到忽视。

这个情况不断的重复，好象完全没有程序一样，因为整个企划的状况没有人猜得出来。由于复杂度的关系，说明文件的撰写状况延期，晚了程式码三个月的时间。模组是变更了，但是相关文件没能来得及赶上，导致下一个可怜虫出现问题。这些问题不断的复合，让整个局面完全无法控制。

这个企划的历史显示出先前发生的情况差不了多少。在刚开始只有一个小型的核心小组，以及最少（如果有的话）的过程。随着企划的复杂程度增加，更多的员工加入，但是用来支援他们的结构与程序严重落后。在这之后，有数个新的员工碰上了严重的麻烦，并出现臭早数量多达200只的危机。一位直觉反应的人体育焦燥的回应：［都是这些严苛的过程造成的］。

可以确信的是这些程序可以保证没有新的臭虫，在步步拔除一些臭虫的时候陆续出现（这可能是真的，但不是好理由！这个程序实在太过复杂，让研发过程慢得象乌龟，几乎无法撰写程式码）。

不幸的，一直到新的管理方式介入，整个情况才有改善。过程的数量被砍掉，而且每一个不必要而且过度庞大的程序被削到最小，以能够保持控制为原则。

在这之后，这个企划开始回到常轨上，而且我们才有可能在程序之间，做一些有用的工作。
在案例研究13.1中，这个［直觉反应］者提出来的问题十分常见。一个刚开始没有进行处理的企划，然后再尝试进行抑制，以确保问题不会在后期的日子中增加，就是这种失调现象的主旨。

这个情况如同图13.6。

整个过程的导入，是在结合了一大堆没完成的工作之后，将整个企划磨到全面停止。这个企划通常会在这个时候取消掉，但是在案例研究13.1中是不可能的，因为这个企划实在太重要了。游戏研发企划不会经常性的碰上这么重要的事，所以这样的一个企划很可能在这个阶段取消。

注意到在图13.6中，显示出企划事实上是在过程与WOT耗到100%的劳力时，才会抵达它的发行日期。用简单的一句话来说，就是这一点可以在企划预设的日期之前就抵达，导致取消的可能性大幅提升，除非采取一些矫正的措施。这一类激烈的行动，将在第14章中说明。

不过，在一般的状况下，如果把过程导入一个［处女小组］，很可能会出现问题。主要的问题，在于他们不了解这个过程是什么东西，以及它的作用是什么，而升起全面抵制的念头（这种精神上的惯性，要花一些时间才能克服）。在强迫他们接受这些看似［没有必要］的程序时，很可能会招致他们的恼怒。过程将在他们的头上监看，这一点，在刚开始是必要的。正式程序的好处，会在这个企划执行了一段时间之后，才会让他们有所感觉。

所以，这些抵抗问题的解决方式，就是要求他们给您一点点的信任。采用其他的系统，并无法真正的控制或是程序化，导致没有效率的工作环境以及差劲的企划可见度。研发者不可能扮演法律的角色，他们为公司工作，而且这个公司的管理部门（相当于您的［顾客］）有十分充份的权利，知道整个企划的进展。

同样的，研发小组也有一样的权利，象管理部门一样知道这个企划是如何进行的。在这个方式下，如果有问题出现，就可以进行预防的工作。如果没有可见度，唯一可以采取的步骤通常是改善发生的问题，而这将会更为激烈、范围更广、风险更高、花费更大。

经验告诉我，在为一个新的企划引入过程的观念时，一般都会导致暂时性的生产力降低。这方面的认知是十分重要的，要不然，它可能迫不及待的成为争吵中所用的弹药，主题就是过程为什么不是好东西。

暂时性生产力下降的原因有二个主要的理由。第一个是不管新东西是什么，都会影响到学习曲线。这个小组必须熟悉程序，才能让它具有效率；换言之程序必须成为整个小组的第二天性。这一点则暗示了程序必须十分简单而明确，可以让所有人轻易的牢记。每一个程序的作用应该让所有人能够了解。就算小组刚开始对程序不太热衷，他们至少应该能够明确的看到潜在的好处。

第二个暂时性生产力下降的理由，是源自于一个企划初始阶段的本质：一切都是新的，所以没有什么空间可以犯错。在刚开始的程序只是纯粹的顶端监看。程序存在的主要理由，是在企划进入一定程度的复杂度以后预防错误发生，而这一点不会在早期阶段出现（参阅图13.5，看看相关的图形）。

  

程序：在哪边使用它们？

在图13.7中，显示出模组研发（左侧）的主要阶段，以及每一个阶段的相关动作（右侧）。注意到表格中二个方框中的举动都是在阶段的转移点界线上。要插入一个程序来控制设计、研发、测试与发行阶段的每一点是有可能的，但很少有这个必要。

一个很好的定则是，在研发周期中所需的过程与要点的数量，必须视企划的大小来加以调整。下列的章节，将讨论要在哪边进行何种程序。
设计阶段

设计阶段包括的企划部份是从游戏设计者将游戏设计形式化开始，转化为整体设计的要点来撰写模组。

对一个单一的企划，这是种一对多的关系。这边只有一个游戏设计，但是这会导致放多模组设计在整体性的结构下，拥有一贯的特质。在图13.8中说明了这个概念。

  

初始概念

这个地方并没有太多的程序要施行。初始概念离可控制的领域还太远，这还在一个想象空间。游戏的初始概念（除非市场部门干涉得很深）是纯粹的创意。

在管理上的幸运之处，在于初始的概念倾向一个企划的起跑点，所以最不欠缺的就是好点子（嗯，事实上在游戏产业中好点子有短缺的现象，但是只有少数的游戏设计者真正注意到这个情况！）

输出：描述游戏用的点子与备忘录。基本的概念图稿与表格。

建议程序：将这个点子展现给保管赌金的团体（管理部门、研发小组、发行公司，或甚至是您的同事）。

  

提案

提案是一份用来定义游戏性的原始宣言，一份文件定义出游戏中的特色，并尝试画出一个游戏的图象，设定小组所要遵循的样式。

输出：一份正式、用来描述游戏的文件（故事、外观及感觉以及基本的运作）。

建议程序：由相关的团体（也就是看过初始概念的同一个团体）来回顾文件。游戏设计应该彻底的检讨，如同一个回顾程序该做的事情一样；而且它应该在下一个阶段之前完成。

  

整体设计

整体设计是第一份详细游戏设计的草稿。这通常都会在制作中另行发展，但是，在进行任何热心的企划相关技术工作前，需要定出这份文件的基准线。整体的设计文件是半科技性的，而且它将说明游戏的运作方式、外观、玩起来的样子，游戏的所有规则以及单位的运作方式。

输出：一份所有单位的人物、策划、物理外观、样式与设定、控制、所有与游戏相关的详细说明。这份文件也可以用来做为游戏说明书的基础。

建议程序：由整个小组来回顾文件，或者至少看过代表用的范例。

  

结构

结构文件是技术文件的初始。这份文件中描述了企划如何建造成模组层级的东西。这应该包括这份企划是如何与公司的结构方针相呼应，包括了重复使用已经完成元件的计划，让元件的使用达到最佳化。

输出：一份说明组成游戏模组，以及模组之间是如何连接的元件。

建议程序：文件由程式设计小组来回顾，或者至少看过代表的范例。

  

模组设计

这个文件是一份要从设计交到研发人员手中的东西，也就是一份写给每一个模组的文件。初始的草稿是由软体规划师或是游戏设计者所撰写的，接下来后续的修正通常是交给研发者来掌控。这个文件是一个高层的技术规格，描述了特定模组的功能，也具有说明书的作用。这个模组设计文件，主要是针对模组所需程式库的相关资讯，而且它另一个重要之处在于重复使用的计划。请注意，一个模组可能有许多种形态，每一个都可以变更它的重要性与重复使用性。举例来说，程式模组可以重复使用，但是美术模组或是游戏的资料档模组，在重复使用上就没有那么方便了。

输出：一份包括了详细指令的文件，说明一个特定的模组功能以及用途，包括了使用上的范例。它必须与模组同时进行维护。

建议程序：由首席程式设计师（如果可能的话）或是设计者来回顾这份技术文件和软体结构（如果文件已经由程式设计师完成的话），而且至少有二位程式设计师随同作业。在合适的情况下，其中一个回顾员应该指派为重复使用元件的负责人，以确保可以尽可能的重复使用所有写好的东西。

  

研发阶段

研发阶段并不只包括撰写程式码的时间，虽然有许多游戏产业中的程式设计师（甚至在游戏产业之外）都是这以觉得。甚至有更多开明的程式设计师觉得，一个附带了说明文件的程式档，就应该足够了。

研发阶段在整个周期之中是最重要的一环，但是撰写程式码只是其中的一小部份。

请注意，这一段讨论只针对了程式码的研发。我并非在谈论美术或是其他游戏所需的模组，虽然它们的原理与程式模组差不多。

  

详细的技术设计

每一个模组都是以纵的方式，写出详细的技术文件上。这可以视为模组设计文件的延伸，但是更为详细。这份文件是用来针对每一个研发人员解释模组运作功能，包括了设计背后的理由以及其他特征的详细说明。

这份文件的效用，在它对模组的重要性影响下，将会变成研发模组的一份日记。这个模组与技术设计文件必须先保持在纵排的方式下。

输出：一份包括了特定模组的详细技术规则文件，象是界面、演绎法、设计上的选择、测试描述、以及测试上的管理等等。

建议程序：设计上的回顾，是由研发者以及软体设计师引导。

  

研发

这个模组通常是从某些型式之下的设计文件研发而来。在美术的情况下，这通常是在风格指引结合了游戏设计的成果；而在程式上，是由详细的技术设计文件而来的。

输出：一个在企划中使用的模组。这可能是一个程式码、一个3D模组、2D图案、一个文字设定档或是其他与企划有关的东西。

建议程序：由研发者来进行程式码的回顾。

  

单元测试

单元测试是在测试研发者写出来的程式码，而且通常是同一个研发者来进行。这个单元测试必须以一个研发者写好的描述为主，也应该是技术设计文件的一部份。

输出：说明单元测试的结果。

建议程序：在单元测试中找到的错误要回报给企划管理者做进一步的指派。视这个错误的本质，指派原先负责的研发者加以修正。

  

整合测试

整合测试通常是研发过程中的最后一次测试。研发者测试完成的模组，看看它是不是建构得相当完整。整合测试应该认为是单元测试的延伸，而且，这个测试本身采用的描述，也是单元测试技术设计文件的其中一部份。

输出：说明整合测试的结果。

建议程序：与单元测试相同。

  

签名

最后阶段要让所有在这个模组上面工作的研发者签名；只在有所有的测试都通过的时候才能做这件事。如果测试没有成功的过关，这个行动就没有任何意义。

输出：一个通过测试、没有错误的企划模组。

建议程序：进入资源控制。

  ================未完！请继续看下去！====================
[em20] [em20] [em20]

tbs005

测试阶段

测试阶段包括了三个主要的测试层级：系统测试、品质保管测试以及游戏测试。

  

系统测试

系统测试通常是越多越好，由于它采取的是黑箱测试，所以生产出的一般性资讯要比单元测试和整合测试更多。

输出：一个系统测试记录。

建议程序：错误将回报给企划管理者，来进一步的指派工作。

  

品质保证

品质保证是一个高等级的测试，这可以确保程式在美术上面有满意的表现。这并不表示它会找到程式上的错误，因为这一类的错误在这个阶段之前，早就该统统拔除了。

品质保证的目的是确保艺术水准（游戏的气氛、选单画面、说明书等等）是对使用者很友善、有条理，并遵循着游戏设计文件中的游戏内格说明。

输出：品质保证报告。

建议程序：结果将回报给企划管理者与游戏设计者，来进行评估。

  

游戏测试

这应该是最后阶段的测试，要测试的是整个游戏玩起来的感觉。它怎么玩？说明书写得好吗？学习上手要多久？有没有什么其他的游戏性？

输出：游戏性报告

建议程序：提出的问题将由游戏设计者与企划管理者做进一步的指派。

  

资源控制与程式码回头：协同合作

对那些不太喜欢查字典的人来说，协同合作的意思就是所有人合力的成果，要比一个人来得庞大。

资源控制与程式码回顾方面，就是协同合作的一个完美案例。

如果您不熟悉资源控制的话，请把它看成一个管理用的应用软体，控制了集中化以后的修正档案资料库。它可以在一个合理的程度下，控制正在受到维护修整的原始程式档，并让完成修正层级的程式码进入测试。如果一个研发者正在处理原始程式档，其他人就不应该插手同一个项目。这可以预防那些我们在采用资源控制之前，所出现的可怕设计错误，也就是二个人在编辑同一个档案，最后产生互要影响的问题。

资源控制在研发过程中成为不可或缺的一部份，可以提供自动化企划历史记录以及在回顾周期中的一般系统追踪控制。让我惊讶的是，游戏产业在采用资源控制时，步调已经很慢了。

  

案例研究13.2　资源控制？我们不需要臭气冲天的资源控制！

朱利安（Julian）是一个老练的技术领导者，有几次换工作的经验，并在他开始进入一个新鲜人所组成的研发团体之前，看到了游戏产业界以外采用的研发技术的成熟度，所以被众人视为保守派的产业界老手。

在他到任之后，他被指派控管二个研发小组的其中一个，进行一个团体合作的运动游戏。这个企划已经进行了几个月的时间，而且没有经过设计的阶段，只有在撰写程式码，所以已经陷入蛛网之中，写出来的程式码在结构上面都很差劲。

［好吧，］朱利安对小组说，［我们来谈谈资源控制吧。］

整个小组半信半疑的看待这件事。他们从来没有听过这个东西，它看来象是穿西装打领带的人，在撰写资料库或是其他无聊东西时，才会用到的。资源控制怎么可能符合不断成长、酷毙了的画面程式编写。

［但是我们不需要资源控制，］其中一个人员大叫，［我们做得很好，而且我们不需要额外的工作。它只是慢了一点！］

［或是，你们应该可以看到好处吧？我们可以不断的在主程式码中持续加上注解。我们会知道这个工作的进展程度，而且是谁、为什么、什么时候要完成。］朱利安回答。

现在轮到另一个组员，约翰（John）发言了。约翰对他程式码的品质觉得有点不安全，而且他不喜欢这个可［查清楚］的点子。

［所以，管理方面想要利用这个软体来监控我们，并查看我们做了多少事，是这样的吗？］他发问之后，整个小组同时附和。

讨论的内容很快恶化到程式设计小组绝对拒绝与任何资源控制牵扯在一块。

由于在交涉上面的利益考量，朱利安决定先放过这个话题。相反的，他去找高层人员，看看这件事要如何推动。

一般人的意见与研发小组十分接近。［为什么我们要买一个软体，是研发小组觉得没有必要的？他们当然知道他们在做什么事，而且如果他们认为这会让他们的创意窒息，那我们就用这一点来决定就好了。］

在这个时候，朱利安了解到他面对的是一个必输的战争，并决定这个时候不要施压。他的推测是：［没有管理部门的支援，我就没有立足点来强迫小组使用资源控制。］

研发象平常一样持续进行，直到有一天，一个年轻的程式设计师安迪（Andy），笨拙的拖着脚步去找朱利安。

［朱利安，我们可能在我们的程式码中碰上一个小问题，］他低声的说。

朱利安坐正，［哪一类的问题？］他抱着不断涨大的怀疑发问。

［嗯，我正在检查其中一个核心的人工智慧档案，而且我发现它有必要整理一下。所以，在过去的几天，我一直在做这件事，］安迪开始解释。

［继续说，］朱利安觉得一道不详的感觉从他的脊椎骨爬上来，坏消息来了，他可以感觉得到。

安迪吞下口水，［呃，嗯…看来好象是约翰也在同样的区域中作事，他在我之后进行工作，但是在我请所有人别碰那个档案时，他好象不在座位上面。］

朱利安好象被打了一记，脑袋一片空白。但是他什么都没说。

安迪继续下去，［结果就是他也在把核心最佳化。现在它的执行速度达到了我们的目标，但是仍然有些演绎法的小问题。他大约花了一个星期的时间来做这件事，但是我把我的档案复制上去，把他的成果盖掉了。

朱利安扁了扁中嘴，安迪很不舒服的改了一下坐姿。［他之前的努力都白废了，而且他对我很生气。他最新的备份差不多是一个星期以前。］

朱利安坐回去并叹了一口气。［所以我才想要进行资源控制。如果我们进行了资源控制的程序，这一切都不会发生。］

  

缺乏程式码回顾的程度，在游戏产业并不是什么罕见的现象。就算一直到最近，甚至连资源控制都是不怎么熟悉的概念。当我在游戏产业中开始工作时，资源控制被视为无法信任的东西。它被人认为是限制良多而且没有必要的。一个对程式人员的隐私权侵犯者。错误会被指出，而且??最可怕的??就是会有人开始责骂。这是一个坏东西，我猜这个态度仍然渗透到游戏产业的黑暗地带，但是我希望未来的作法更具启发性。

程式码回顾已经在这个章节前面讨论过了，所以这个部份将专注于资源控制以及如何正确的运用，尤其在与程式码回顾结合之后。

与任何工具一样，资源控制只有在正确使用之下才会有效率。如果在没有效率的状况下运用，那还不如不用：您可能会失去程式码、文件可能会一团乱，而且没有人可以确定，企划的最新版本究竟在哪边。

  

资源控制应该用来做什么？

最简单的答案是：一切！

研发如同一个模组一样，应该视为一个封包。所有与这个模组相关的电子档案材料??象是设计文件、问题回报、回顾报告??都应该保存起来。所有的资源控制封包可以让您加上说明来加以修正。这些应该可以对目前的变更以及其他的相关区域，提供一个概要的解释。每一个程式码的回顾，应该以一个独特的编号来标示，以便日后在数个档案之中进行追踪。如果采用了这个方式，一个简单的保存区域搜寻，就可以把单一工作的相关资料，统统整理出来。

虽然，并不是所有组织都需要这种精细的检查方式，一些少量的额外工作可以在后期得到效果，也就是在回头查看资料的时候。

在游戏产业中一个很重要的个性是，很少有公司会从错误之中学习。这可能是由于前一个企划的相关资讯，已经找不到的原因。

事实上，在我参与过的大部份企划中，这方面并没有极为耗时的步骤。没有人真的会在收集企划资讯方面花费太多精神，才能在下一个企划中增加成功的机会。

这可能有好几个理由。游戏产业在研发的本质上面，有些很难听的名声。举例来说，重复使用的概念对大部份的研发者而言相当于诅咒。所有的游戏都得看成不同的怪物，所以前一个版本中，没有真正有用的程式码可以重复运用。使用在一个游戏的程式，如果用在新的版本中都会被认为太慢或是太老旧；而不管这是不是事实。

在游戏产业中的研发工作，也象是一个奇怪的生物。最常见的游戏研发者是??扭的天才，会使性子而且保护自己的程式码。他们的弱点不存在，而且没有人敢去质疑研发者的程式能力。简单的说，每一个研发者认为他是小组中最强的人，而且每一个小组都认为他们是产业界中最棒的；只要有人能够给他们一个机会，让他们做出真正想要的游戏就行了。

以下是一个程式设计师的常见笑话。我无法保证它会很好笑，但是它却有效的表达了一些重点。

Q：要多少个程式设计师才能换一个灯泡？

A：所有人，一个人真的去换，而其他的人围着看他做得有多烂，然后讨论如何做得更好。

事实上，这个笑话如果不是真的，保证会更好笑。在案例研究13.3中，描绘了一个很令人惋惜的故事，正是游戏产业经常发生的。

  

案例研究13.3　虚幻的伟大

一个研发小组正在为一家很大的发行公司进行一个新的企划。他们讨论了他们很有希望的游戏，并以市面上已经推出的类似游戏相互比较。

《世纪帝国》是一个特别挑选出来批评的游戏，主要是因为他们认为在人工智慧演绎法上在过于简单。

唐（Don）是游戏设计者，正在与企划管理者杰瑞（Jerry）进行讨论，这二人刚刚从一群研发者的会议中，出来透口气。

［我们可以做得比那个好，］杰瑞说，［他们的人工智慧程式设计师一定是个笨蛋！我们的人说，他可以轻轻松松的就超越他们！］

唐可没有杰瑞那么容易说服。［好，我们把他和其他的人聚集起来。我要知道他为什么认为他可以做得更好。］他之前就已经听过他们讲这件事了。

他们老是在谈论企划，每次主题都在其他已经发行的游戏中有哪些错误上打转。他们说在《星海争霸》那个爆炸不够好，这个程式中的人工智慧很差，在这个程式中的使用者介面不够友善，以及其他程式中出现的问题。他们假定在他们的企划中，一切都是完美无缺。

一场会议召开，而唐询问了克理斯（Chris）这位人工智慧程式设计师，为什么他认为他可以做得更好。

［这实在太明显了，不是吗？］克理斯反问，［我就算闭着眼睛，也可以做得比它更好。我们有很多的时间来做一个企划，而且我可以轻易想出如何做的比它更好。］

［在你说（轻易想出）的时候，你是指研究，对吗？］唐再度发问，［你现在并不是真的了解策略人工智慧的整体运作概念，但是你认为可以想出来。你知道这要花上多少时间吗？］

克理斯想了大约一分钟，然后回答，［嗯嗯，我猜这么该要花上六个星期左右的时间。］

［你是以什么方式来假设的？］唐反问。

［我只是有这个感觉，］克理斯露出狡黠的微笑回答。

［好，］唐说下去，［但是比较可能的情况是什么？他们之所以这样做，只是因为他们不能做得更好：还是他们这样做的原因，是因为这种作法是一个复杂问题的最简单答案，才能让游戏有足够的贴图张数？］

这个问题是针对整个小组发问的。在经过一阵子的思考之后，克理斯说话了［呃，我想这是因为他们无法做得更好。］

小组的其他人点头同意。

  

在案例研究13.3中出现的现象，更不幸之处在于随处可见。就算我也不得不屈服在这个恐怖的摩手这下。

有好几次在我觉得必须更新我数个月以前写的程式码时，我的第一个直觉通常是它应该要比我重写来得容易。这通常是因为我想要花费额外的工作，让我自己重新熟悉老的程式码；而让我转变态度的就是成本/效率比。如果我曾经在以前的程式码中加上说明，并确定相关的文字随着程式码来撰写，那要修改我的程式就不用花费太多的工作时间，比从头再写一次省时。我这时才知道，在程式码中加上说明与文件，对我在修改程式的时候有多在的帮助。

在案例研究13.3中的例子，最主要的错误在于另一种观念之下的游戏简单的要命，而这种现象必须要制作小组来负责，因为他们没有足够的技能做得更好。

这个小组觉得他们可以做一些事情，因为他们之前从来没有做过，所以一定十分简单；但是他们对整个程序只有模糊的认知。当然了，只在您听到一个点子，一切都会变得十分明显。

这是一个明显的［那很简单，我也想得到］症侯群案例。如果全世界程式设计师都有一个共通的特征，那就是高估他们本身的能力。我所知最好的程式设计师是那些会说：［我不知道如何做到这一点］的人。

在一个类似的局面下，看看这个：您可能有办法分辨出解剖刀与骨锯的不同，您甚至也知道它们是用在什么样的情况下，但是只有外科医生才知道它们的正确使用方式。您要一些只会宣称他们知道怎么进行手术的人，在您身上动手术吗？

所有的研发小组都假定他们的企划朝着完美无缺的情况进展。没有人认为有必要妥协这一点，他们一向假设他们会在时间之内完成他们的工作，而且不会有任何问题。在这边得到的教训是天下没有［完美］，所以只要有［够好］就行了。

  

资讯传递的重要性

在研发中，资讯的传递通常是被忽略的悲伤部份，而且它从来不会单独地受人注意。如果您真的考虑过的话，这种假定代表资讯传递很容易发生。

不过，现实上并非如此。如果资讯可以从一个脑袋送入另一个脑袋，那事情就简单得多了。或许目前有人正在研究这方面的科技，但是我在商店的架子上还没看到这种东西。

一直到现在，我们都得依靠一些良好的老旧方式象交谈、撰写、以及利用电子邮件与网页来传递资讯。

事实上，上面这一行列出的沟通顺序并不是巧合；它列出来的是有效的顺序。这边有一些重叠之处，例如电子邮件与打好的文件在顺序上是可以对调的。

大部份的小组都有一些资讯传递的方式，但是它缺乏了应有的效能。大部份的资讯是以口头的方式进行传递，而且它是与每天进行的企划有关。企划的状况说明仍然以口头来进行，而且每一个人都对企划状况有自己的看法。这个资讯的误差可能会导致问题。

在一些情况下，会做出一些象征性的努力让企划仍然上轨道，并进行常态性的状况会议。这些作法在效率上面可能有很大的变动，视执行这些作法的企划管理者经验等级而定。这边主要的问题是要吸引这一类的高手进入游戏产业，在薪水不足的前提下将会十分的困难。

大部份的人在晋级为企划管理人员之前，一般都是程式设计师。一个常见的管理理论在这边出现了：一个在组织中的员工被晋升到他无法胜任的等级中。这很明显是人类天性的副作用。

如果一个员工在他（或是她）的职位上表现出色，他（或她）很可能得到晋升。没过多久，他（或她）就会在一个不是刚好符合他（或她）的技巧能力，就是超过负荷范围的职位上。

象这样的员工接下来可能会留在他的职位上搞得一团乱，直到他们在厌烦之下离开，或是被迫［放逐］到别处碰碰运气。

在这些理由下，您在管理位置上面找到的人，通常都不是最适任的人选。如果他们曾经担任过程式设计师，这可能表示他们的沟通技巧不够完善。

重点在于一个小组的组员，必须看着他们的领导者才知道如何控制自己的言行，而且小组的领导者必须为小组内的沟通设定一套风格。

在管得最好的小组中，沟通的工作在不同的层级上面有效的运作。不只是每天的事件都详细的散播到整个小组，而且技巧与经验也会同时分享。最后的效率净值，就是随着企划的进展，整个小组升到了一个全新的技能等级。一个比较公平的说法是，只有在企划指定的范围才会升级，但是升级的部份十分显著，可以从每个人的身上看出来。

这是最有效的资讯传递方式??知识的分散??靠着数个不同的要素。首先，而且也是最重要的，在这边要用上之前提过的所有沟通方式；第二个是在小组中维持开放性。

如果在心胸狭窄的游戏产业之外，这部份不会成为太大的问题，顶多是研发者猜疑的保护着他们自己的［下一个大东西］。但是在游戏产业中，这可能会由于小组之间的提议冲突而引发战争。

在我们详细讨论到任何特定的建议之前，我们以沟通有效程度的顺序，偏离一下主题。

在图13.9与13.10中，说明了二个小组成员之间，在沟通线上面的因数关系。

当这边有三个成员在一个小组中时，就有三条可以用来进行沟通的线。A可以与B交谈，B可以与C交谈，而C可以与A交谈；这可以轻易的管理。每个研发者只需要与二个其他的人员交谈，这一点不会花掉他（或她）太多时间。

不过，在有四、五甚至是六个组员（如图13.10所示），这个情况将变得极为复杂。

在图13.10中显示出十五条这样的沟通线。这在实质上比原先只有三个人要来得多，所以会花费每一个研发者更多的时间。

当然了，这是一个最恶劣环境下的范例，而且这一类的沟通是不可能发生的，就算是在最松散的组织中，也比这个来得有结构。

图13.11显示出通常会出现的状况。

要把一个大型的群组打散，成为功能上的小型群组，其中一个理由就是把沟通最佳化。在小组之间，将会有n(n-1)/2条的沟通线。

在图13.11中，一个有24位员工的小组分散成四个小群组，每一个小组都有6个员工与小组领导者（如同图13.10所示）。在小组之间的通讯可以由每一个小组的领导人来控管，而且这将有助于降低其他状况下出现的沟通恶梦。在这种设计之下，将有6条小组内部的沟通连结，以及4组每组15条的小组内连结，总菜有66条。

将这个结果与还没分组的24位员工比较，后者将有276条沟通线。您可以很清楚的看出来，这将是每个人花上最多时间的部份，会完成的事情很少，而且很快的就会全部崩溃，成为无政府的状况。

这个系统也可以让资讯的传递变得很有效率，但是这边的效率有不同的意义。这一类的口头沟通在一对一的情况下是必要的，而且这边有许多案例，可以指出一对多的沟通方式更具效率：会议、文件以及内部的网页。当然了，其中的每一项也有它的正反面。

举例来说，会议并不是经常都很有效率。某些管理者似乎对开会有特别的热爱，这几乎很象他们的生活如果没有一天开一次会议，就会出现缺陷一样，所以会是开得越多越好。

我的意见是，会议应该在特别的情况下经常性召开，而且甚至没有必要把每个人都叫进来。在普通的状况下，在一个管理者召唤一次会议时大家都得到，连倒茶的小弟也不能例外。

会议倾向于浪费大量的时间，而且虽然它要比一个个分别讲述来得有效率，在简单的状况报告下很好用，但是采用公司内部网站或是每星期寄发的电子信件，一样可以达到相同的效果。

如果每一件事都进行的十分顺利，会议就没有什么召开的必要。如果出现了问题，或者必须进行变更??举例来说，主动性的新消息必须大范围的分散出去??那一场会议就势在必行。

  

主动与反应的资讯传递

一直到这一步，我们都还没有考虑到资讯是以主动还是反应的方式来进行传递的。这到底指的是什么？

嗯，主动的新知识会直接影响到未来企划。这方面的一个范例是大量的变更。这会影响所有人的潜力，而且可能需要收集一些意见，才能决定未来的走向如何。

主动的资讯通常最好在会议中传递。事实上，在一个执行得很好的软体企划中，我最期待看到的会议就是回顾会议，以及变更控制的会议。除了一些特定的实例之外，其他所有东西都可以在更有效的方式下进行传递。

被动的新消息比什么都有效。一些例子象是回顾者完成的企划状况报千，对手企划中的资讯，或是在企划任何部份发生的101条单调东西。

在我的经验中，我已经发现二个最好方式，来传递这一类的资讯：用电子邮件传送的新闻，或是一个在公司内部网页中的连结文件（或者，更好的状况是二者都用）。最让人困扰的，就是明明这种组合的电子邮件与内部网路，可以提供足够的资讯来取代耗时冗长的会议，却还是得去开会。

每一个企划应该都有自己的网页，如同图13.12所示。

网页的真正结构，与个人的品有很大的关系。示范用的网页显示在图13.3中，采用的方式与第11章中的软体工厂模型是相同的。请注意，从主要企划网页中，只留下相关的连结以保持清晰度。

在最理想的系统下，一个每星期寄发的新闻信件系统，将每星期更新的相关资讯寄给公司的每一个人。当然了，查看这些资讯是每个人的义务。

其中一个缺点在于，在一个大型的组织中，他们可能得顾用一个专门负责网页更新的设计师，来进行相关的工作。不过，幸运的是大部份的公司中，都已经雇用了负责网页的人员。

将所有公司中的文件与过程搬到内部网站上面，并不是一项轻松的工作。它需要小心的设计，而且还要提供搜寻的功能。如果这方面处理得很好，那公司中的每一个人都可以看到企划的进行状况。

我曾经在一个我参与的研发企划中实施这个系统，而且将它延伸到加入时程表系统，所以可以利用单纯的网页界面，指派员工黄鹂不同的工作。员工可以进入特定的网页中，查看他们工作相关的详细资讯，以及安排个人回顾、会议的相关时程表。

假定这个网页经过谨慎的设计与编排，它应该可以去除每一个研发人员在试图不去查看相关文件时，最常采用的藉口（包括我自己）：［可是我到处都找不到］

==================第十三章完！=========================
[em21] [em21] [em21]

tbs005

斑竹 设为精华帖！！！ 自己顶总是觉得有点  。。。。。。。呵呵

rox_tu

顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~顶~~~~