第十一章　软体工厂 

  

＊软体工厂所解决的问题 

＊设定一个软体工厂 

＊使用一个软体工厂 

＊软体工厂的可适性 

  

在第10章中说明了有效研发环境中的角色与部门，这些资源可以组织成许多不同的结构（但不一定适合用来进行游戏研发）。在这个章节中将解释角色与部门的组织结构（特别适合创立研发公司时采用），以及说明这个结构如何把效率提升到最佳的层级。 

这个结构也可以用在一个刚刚创始的组织，但是这样的作法，通常是因为第一个企划都会花费较长的时间（至少很可能如此），我们将在这个章节后面再说明。 

  

什么是软体工厂？ 

软体工厂一词是指一种生产软体的方法学，而使用的技巧类似于标准工厂，象是一个汽车生产工厂一样。不过，这并不表示用这种方式生产出来的软体都具有同质性、可以无尽的搅拌，而且缺乏想象与天份。已经有够多的公司曾经努力过，但是他们的创意游戏也让他们走进了破产的死胡同。在图11.1显示出一个看来很有钱的人（高顶帽与燕尾服、怀表、雪茄和从裤子口袋中外露的钱）正在转动软体工厂的握把，看来象是一个绞碎机。游戏设计从上面吃进去，而且不具名、理想的游戏从下面出来。从机器中传出一个声音：［来吧！你们这些笨蛋！快一点！快一点！］这一类的软体工厂应该可能避免所有的花费。 

随着电脑游戏产业的逐渐成熟，更多复杂的生产方式（象是软体工厂）已经开始实行并做出新的产品。软体工厂的方法是把特定的共用模组加以简单化与集中化，让它用在数个不同的产品上。 

它运用了大量生产的优势，以容易而更有效的方式来进行特定的工作，而且它会确保核心使用的工具与程式库不断的维护更新，运用在一系列的产品上面，以取得这方面的好处。所以，研发续集的作品将更为容易，因为他们会得到更丰富的程式库以及工具组的支援。 

软体工厂已经证实它可以在一系列的企划中，以相同的功能来运作。请记住这种模式对一个特定的产品而言不一定适用（您和您的同事可能光是靠涂鸦就找出更好的方法）。不过，软体工厂特别适合生产一系列的作品。 

［但这正是我们在期待的游戏！每一个都很特别！要改写程式码、换掉画面再拿出去发行是不可能的！］ 

这种抗议相当的正确，但是您每次制作游戏时，都想要重写一次画面与音效设定程式、资料档案读取、程式库压缩、光碟音轨播放、选单程式，或是其他在长串列表上的基本模组，而这些模组明明可以重复使用程式吗？如果从管理的角度来看，您每次重写一些现成的特定程式时，又要花掉多少时间与金钱（不只要重写程式，还要经过测试、整合与除错）？ 

  

下表中的一些常见工作，应该隶属于可以重复使用的模组： 

＊资料档案读取 

＊硬体安装 

＊硬体设定 

＊软体设定 

＊特定的CODEC（压缩与解压缩） 

＊编码与解码 

＊视窗与画在特色 

＊基本人工智慧元件 

＊使用者输入 

  

软体工厂的概念可以简化像是生产通用程式码与工具组的工具，让研发者可以专注与写好从草稿上想出来的程式码。要让工作速度提高，表示你必须运用已经完成，并经过全面测试相关功能的模组，来完成你的目标。 

  

为什么要使用软体工厂？ 

利用软体工厂的模式，与其他的研发模式比较起来，究竟有什么优点与缺点？虽然这里问题的答案要视特定的情况来决定，不过在表11.1中列出了数个主要的优点与缺点。 

  

表11.1　一个软体工厂的优点与缺点 

优点 
 缺点 
 
平均的企划时程会缩短 
 第一个企划要花较长的时间 
 
可以让跨平台的制作较简单 
 可以重复使用的程式库，必须为每一个平台进行改写 
 
程式码较可信赖 
 程式码将更具共通性，所以更难撰写 
 
程式可以重复使用并加以维护 
 初期的程式码要花更长的时间研发 
 
相关知识可以在所有研发者之间分享 
 新的研发人员必须学习不熟悉的程式库 
 
增加了企划进展的可见度 
 需要更多的管理 
 
加强研发人员的专业能力 
 技巧上的弹性较不足 
 

  

在表11.1中，显示出这种模式的确有它的缺点在。不过，在整体上，制作数个不同的企划时，优点显然要比缺点更多。 

  

解决游戏研发问题 

软体工厂的方法有助于解决游戏研发碰上的常见问题、也就是平台的独立性与风险的降低（靠着知识分享、程式码重复使用以及程式码的维护，等等）。 

  

平台独立性 

考虑与DOS相容的PC环境――这是一个可以扩充的系统，而且有着广泛的设定方式。如果是为了效能的理由，您可能想要直接驱动PC上的硬体，那您会怎么选择？您应该自问要在哪一种机器上面支援何种研体，而到了最后，这个选择会变成只支援有限的硬体，并让您的游戏销量受限。您也可以赌上支援各种不同的硬体，但很可能会由于硬体的冲突与不相容，成为逻辑方面的恶梦。 

让我们来看看一个明确的范例。假定您在一台与DOS相容的PC上面，写了一个3D太空战斗的游戏。您对您的结构设计很有信心，并在界面之下隔离了与所有平台有关的程式码（在这边用的平台，指的是PC上面的特别硬体）。 

您必须分别为想要支援的不同平台，撰写隐藏在界面之下的程式码。您可能选择支援三种常见的影象卡与三种音效卡。 

所以，您接下来要撰写、除错并分别测试六种硬体的相关程式码，接下来系统要在九种不同的设定之下进行测试，还不包括那些完全没有这些影象卡与音效卡的玩者。让事情更为困难的是，要让游戏的速度够快，您必须用这种方式来撰写程式库，让它们依赖游戏的内部知识来达成所有的功能。这是很复杂的工作，没有任何书本可以教会您这一切。 

另一个常见的问题，在于您要如何以最有效的方式，把所有的平台程式码写出来。看来，您不太可能找到对每一块想支援的影象卡，都具有足够知识的设计者。由于您要写的程式数量已经够多了，看来您也不会有时间去研究相关的知识。 

当然了，这是一个策略上的案例，与现实世界并没有关联。在现实世界之中，只有更糟。 

为了要把游戏的研发推展到特定的平台，并把硬体的支援责任从游戏研发者手中移到硬体设计者，微软与苹果公司独立研发了二个解决平台问题的方案：DirectX与Game Sprockets。在撰写本书的时候，DirectX已经进展到第六版，而且可以直接从微软的网站下载：一样的，Game Sprockets也可以在苹果的网页进行下载。 

DirectX与Game Srockets都是高效能、多媒体的程式库，设计用来自动侦测使用者机器上，是否有任何加速用的硬体。他们的作用在于程式设计师撰写程式时，只要针对微软或是苹果定义的应用程式介面（Application Programming Interface,API）就可以了。 

这些程式库有助于解决个别硬体的问题，而且除非是透过标准化的方式，程式设计师无法直接驱动硬体。在DirectX之下，提供了一组常用的功能，可以由硬体呈现或是由软体来进行模拟。刚开始DirectX在研发人员之中接受度并不高，但是现在您可以去找找看，哪一个游戏会绕过DirectX的协助。 

当然了，DirectX与Game Sprockets仍然是层级很低的多媒体程式库，而且（理所当然）彼此之间并不相容。要真正达到平台独立的目标，您必须创造出质轻的包复程式码，对硬体提供统一的界面，不管执行的机器是一台与DOS相容的PC，还是一台麦金塔或是其他平台。就算您没有打算支援一种以上的平台，包复程式码仍然是很好的点子，因为它可以简化许多常见的工作。创造这样的包复程式码，是工厂的主要工作之一。 

  

降低风险 

在第10章曾经讨论过的一个问题，是关于失去小组中的重要人物。如果您有一位很特别的小组成员，专精于一个特定领域中的知识或是技能，在整个企划中无人能取代，那这个人就会成为一个风险。 

在这个阶段，您应该问问您自己，愿不愿意把整个企划赌在一个人身上。如果他们跑到西藏的天空下面生活（或干脆加入其他的游戏公司），这个企划能不能承受得了这种损失？如果这个企划受得了，又会耗掉多少的时间、金钱与功能？减少无可取代的专业人士，是一个企划成功的关键。 

  

案例研究11.1　失去关键人员的后果 

据Bungie Software公司的杰森·瑞吉（Jason Regier）所言，在研发《杀无赦》的时候，曾经因为关键程式设计师的离职而出现一段痛苦时光。这位人士负责的内容是一个描述引擎，一个很重要（但幸好不是必要）但却非丢掉不可的模组。在程式设计师离开之后，描述程式码的基础都还没完成，而且没有人有足够的知识可以接着写下去。更糟的是，《杀无赦》的小组并不大，结果就是没有多余的人力，来学习这种程式码要如何运作。 

描述引擎的作用是提供特定的部队以及地图上的行为。这些特色已公布出去，将会出现在完成的游戏中。 

这个特别的问题，就是靠着把这个功能拿掉来解决的。一个描述引擎是一个复杂的重任，而且通常不是一个关键路线上的模组。在这种情况下，Bungie在考虑了费用与功能这二个要素之后，决定把它拿掉。如果这个模组是图象引擎，象这种决定是绝对不可能发生的。 

引自：游戏研发者杂志（1998年4月） 

  

软体工厂可以靠着重复使用程式码以及鼓励工作上的性质重复，来减轻这类损失关键人员的问题。在案例研究11.1中的描述引擎是专门为这个企划而写的。不过，从另一个方面来看，它也可以写成一个界面，而每一个可以描述的游戏物件，就可以用输出的模式来支援这个界面。如果这些界面设计得十分普通，那么就会自动重复运用，并在不同的企划中使用。 

如果您是一个道地的游戏研发者，那您在看完最后一段之后可能会觉得不太舒服。标准化的界面？在加上另一个层面的覆盖之后，难道不会让执行速度慢下来吗？这难道不会让程式更难写，而且要花更多的时间？ 

呃，答案是［是］以及［不是］。如果界面设计得很合适，您至少可以和特别整合的元件获得相同的效率。而且，由于软体工厂强调的是重复使用能力，所以描述引擎可以调整并修改，来符合数个不同企划的需求。如果您想看看这一类描述界面如何运作的详细提案，请参阅第20章。 

在案例研究11.1中，如果有另一个研发人员一样熟悉描述引擎，而且这些程式码写了详细的说明时，这些就统统不成问题。在研发过程中，在主要部分加注说明文字是一个好习惯，但是通常（说明白点，将近百分之百）会被忽略。如果它只要使用一次，为什么要写一些麻烦的说明文字上去？如果您是唯一要使用这些东西，而且最了解它的人，为什么还要在程式码或是程序中写下说明？ 

这些都是原则上可以接受的反应，但是它带出的问题是，您为什么要写一个用完就要丢掉的程式吗？如果您假定写下这样的程式码是正确的行为，那您为什么突然会觉得您一定要跑去西藏躲起来？您又怎么确信您是唯一要看得懂这些程式码的人？ 

理想的路径是沿着写好的程式码重新检视，看看写程式时能否让脑袋中有一个企划，并加上完整的说明。 

  

案例研究11.2　重复使用程式码 

据Zombie公司的魏斯，雷吉威（Wyeth Ridgeway）表示，《风驰电掣》（译注：赛车游戏）的程式引擎，是从他们的上一个游戏《特种部队》（译注：第三人称动作策略游戏）中改良而来的，里面没有游戏专属的程式码。这是一个专门设计用来重复使用的模组。 

这个引擎中包括了3D成象、一个使用类似LISP语言的物件描述模组，以及一个声音模组，以及其他东西。 

所有元件在他们的手中，都只是工具。这个游戏是由游戏引擎以及游戏相关的资源（画面、声音以及物件描述）所组合而成的。它的组合是靠着最少量的结合程式码，主要是用来进行物件描述以及小量的游戏专属程式码，这些是用支援描述并提供一般的框架。 

这个引擎设计的方式下，只要有一套不同的资源，一个人就可以打造出完全不同的新游戏。这种能力在几个非程式设计师的小组人员手中展示，只要一个周末就可以创造出一个大脚车的赛车展示。这表示只要有合适的规划，一点点游戏研发的基础知识，以及一份详细而精确的文件，就可以让一个软体工厂在现实中全速运作，开始生产。 

这个结果就是软体工厂的目标。 

来源：游戏研发者杂志（1998年6月） 

  

为何要使用软体工厂？ 

一个软体工厂是设计用来生产一组可以重复使用的核心元件与工具，可以随着数个不同的产品而进化。从一开始，这些工具与元件是以［可重复］以及［未来可扩充］的想法来设计的。在研发这些工具与元件时，最重要的是让它们可以作用在游戏上。这些工具与元件所用的研发采用严密、监控的方式，而且会加上完整的说明资料，以期在未来的企划中能够重复使用。任何工具或是元件所需的更新动作，必须先经过完整的需求分析，而且必须能表现出同等的标准。这些工具与元件是整个过程中最重要的部份，他们设计上，必须让上一个游戏的上架时间，足以完成下一个企划，这是十分重要的一点。 

好处是十分明显的：用来进行常见工作的程式码，可以一次又一次的使用，省下研发的时间与财源。主要的缺点是第一套的工具与元件必须从头开始，而且通常在研发时间上面，要比直接在企划中，写出想要的功能来得更久。获得通常是在接下来的企划中才显示出来。 

想要让已经发行的企划大幅改进，另一个可行的方式，就是用更新的核心模组再推出一次。这种作法要多加小心。在这个世界上没有付出就不会有收入，而且，就算理论上所有修改过的元件都应该可以与早期程式相容，但是这种方式有可能成为测试的重担。如果您有自信做到这一点，那就去吧！不过，记住微软曾经保证DirectX会向后相容所造成的麻烦。一直到第五版以前，新的更新程式经常会毁掉进行更新动作之前的系统，导致最好的情况下系统最佳化不足，最差的情况则是系统完全无法使用。 

另一个相似的情况，是建造一艘航海的船只。如果您决定要从第一天就打造您所需的一切物品，这个小组就得从砍树、木材加工、把木材放干、然后才能开始组合成船只。要用这种方式做出数艘不同的船只，一定会累死人。 

在合理的情况下，您可以安排刚开始的元件以生产线的方式完成（甚至请外面的人来写），然后让您的小组只要进行组合的工作就好了。这样可以结合小组的优势（热情与动机）与工厂的模型（有效的运用劳工，并及时完成）。 

  

组织一个软体工厂 

软体工厂的结构与您之前习惯的方式可能有所不同。下列的章节将说明一个软体工厂的构成要件。 

  

结构概观 

在表11.2中，是一个最基础的软体工厂核心需求。 

  

表11.2　软体工厂核心小组的必要群组 

小组 
 说明 
 
游戏设计者 
 想出点子并生产出设计文件 
 
软体结构师 
 监督整个企划的结构，并在小组中互支动 
 
工具 
 象是小组用的关卡编辑器…等等 
 
元件 
 生产出低级、与平台相关的程式码 
 
企划 
 使用元件与工具小组的结果，生产出真正的程式码 
 
研发 
 与新的研发科技保持同步，并研究新的点子，然后整合到低级的元件中 
 

  

在表11.2中是基本工厂的人员列表，并没有彻底的调查，也不是最后的定案。其他的附属角色可能有其必要，但是在这个列表中只定义出核心的需求。没错，并不是所有的组织都可以符合这样的崇高目标，但是除了软体结构师的职位（这是一个专精、应该属于全职性的工作）以外，在群组中可能会有很多的重叠部份，如图11.2所示。很明显的，您手上有越多的人可以用，则重叠的部分就越小；但是一定程度的重叠通常是有意的，这有助于把相关的知识，传达到整个小组之中。 

工厂核心小组的功能与互动，将会加以详细的说明。在图11.3中显示了软体核心工厂的阶层架构。 

在图11.3中是一个粗略的指导方针，但不是死硬的结构。在现实中，这些状况要比静态图表所表现的更活泼；而这边很少变成死硬关系的原因，是来自小组之间的互动。这些人与人之间的互动（或是称之为沟通）有助于提供高层的企划可见度。企划可见度是指可以正确估算企划进展的能力，这种能力对每个重视产品的人而言，是十分重要的；包括了投资者、发行公司以及小组成员。不过让人惊讶的一点是，良好的可见度也会带来副作用，这会减少必要性的小组会议。有许多称之为［进度］的会议最后会变成完全二回事，而且除非计划有大幅的修正，否则很少有中止研发的必要，把时间拿来开会。这样的会议是最会杀时间的东西，而且会干扰小组的专注力与工作态度。 

  

群组的责任与互动 

在软体工厂中的每一个核心群组，都有定义得十分明确的角色与工作。这边只有很少（如果有的话）的重叠，而且所有的重要群组互动，都是在严密制定的管道中进行。 

这些互动是以内部市场系统为概略性的基础。每一个群组都是另一个群组的顾客，所以应该相互视为重要的客户，彼此提供相同等级的文件与产品支援，如同这个产品已经卖到市场上面，客户碰到问题的处理方式。 

这个［市场系统］结构的重要性，在于确保企划以正确的方式进行追踪；让您的左手知道右手在做什么事情，都不会有什么坏处。在图11.4中显示了在一个软体工厂之中的群组互动，而不管外界的影响。在这个图表中，程式设计群组一块待在一个大团体中，因为他们通常是同一群人所分别担任的。不过，在个别是的程式群组之间产生互动时，他们还是必须透过合适的管道（这些管道将在第13章说明）。 

在图11.4中，概略的说明了主要的互动。首先，我们来看看它的限制。这些是您可能会想到的问题： 

  

＊为什么只有结构群组可以进行直接接触？ 

＊如果一个游戏设计者无法直接与程式设计师接触，要如何影响游戏的结果？ 

＊为什么结构群组一定要在一切的中心？ 

＊为什么研发群组直接连到结构群组？ 

  

要回答这些问题，您应该考虑的是一个标准的状况，如案例研究11.3所示。 

  

案例研究11.3　缺乏效率的问题处理行为 

安迪（Andy）、拜瑞（Barry）、克理斯（Chris）、大卫（Dave）与艾迪（Eddie）都是一个程式设计小组，目前正在制作的企划是《FlyBusters lll――eyond The Flypaper》，这是由一位游戏设计老手佛瑞迪（Freddy），所完成的最新企划。 

艾迪是首席程式设计师，一个技术上的天才但没有什么人际关系的技巧；安迪是一个见习者，刚刚从大学毕业；而拜瑞、克理斯与大卫是元件的程式设计师，在游戏产业中有充分的经验，而《FlyBusters lll》是他们第一个一块共事的企划案。安迪刚刚踏入社会，而且不太确定所有的东西是如何拼凑起来的。 

在进行玩者太空船的物理模型时，他注意到有些角度之下，地形会扭曲的很难看。现在，艾迪有一个不太好的名声，就是他有点难以打成一片；他最喜欢使用的反应方式，会暗示他的时间被浪费掉，而且他有很多更重要的事情要做，而不是在那边听取组员对小问题的哀鸣（安迪在先前向艾迪担到近看时多边形之间有间隙，就被这种现象碰了一鼻子灰。拜瑞和大卫是多边形引擎的程式设计师，对这种批评程式码的行为做出了强烈的反弹）。 

这一次安迪试了另一个方式，直接反应给克理斯，也就是设计地形引擎的人。虽然克理斯很忙，还是花了一些时间去看看，并向安迪建议别让玩者直接向正下方来观看地形，这样问题就不会太明显；因为这个地形引擎还无法支援这种特殊的视角。这是一个小小的变更，但是要花上数个小时的时间才能把一切搞定，所以安迪就照着凶的建议来做。艾迪今天特别忙，身上冒出的正是［别靠近我］的光晕，所以安迪想要明天再告诉他，然后去做下一个工作。 

在数个星期之后，艾迪决定该是制作轰炸视角的时候了――这是一个特别的视角，让人可以轻易的瞄准超级啸声炸弹（可以用十分精确的方式丢在目标上，并随着地形扩散爆破）。当他决定好视角之后，艾迪不太了解的是，他就算特别指定炸弹应该落下的地点，炸弹还是不能精确的命中目标；而玩者太空船的位置与定位，使用的正是安迪负责的物理API。在一点时间的查看之后，他马上就查出了物理引擎无法正确的运作。在严加拷问安迪，叫他去检查他的程式码是否正确之后，艾迪决定先把这个问题放在一边，因为他看到物理引擎中的大量完成程式码，变更它的内容会导致独立的程式码碎掉。 

二个星期之后，在一个例行的测试中，游戏设计者佛瑞迪注意到很难让炸弹精准的命中。事实上，这几乎是一个［有投必有失］的过程。他马上要求把这个问题解决掉，并坚持轰炸的策略是游戏的中心。程式设计小组没有选择，只好在三个区域修改程式码，让整个企划延后了三个月之久。安迪觉得很不高兴而且没有受到尊重；克理斯觉得好象是他的错，因为他没能写出够好的地形引擎；拜瑞和大卫因为安迪批评他们的多边形引擎感到很烦而且暴燥；艾迪觉得很挫败并应该为延期的事情负责；而佛瑞迪认为整个小组都是一群白痴。团队的士气低落、而游戏上市时间延后了六个月，而且在评论也针对了轰炸模式的不良以及技术的失败不断攻击。简单的说，他们被炸掉了。 

在快速与骯髒之间，人们很快就会忘掉快速，却一辈子记得它有多髒。 

  

现在我们考虑另一个使用软体工厂结构案例，如案例研究11.4。 

  

案例研究11.4　有效率的问题处理行为 

这个小组与案例研究11.3一样，制作的也是同一个游戏《FlyBusters lll》，而且在出现初期的反抗之后，大家都同意按照沟通管道来交谈，至少先试试看。 

当安迪发现了多边形的结合问题时，他登上了公司的内部网路，并以不具名的报告方式，详细的说明了现在出现的问题。结构群组查看了这个问题，并与游戏设计者佛瑞迪和艾迪交谈。佛瑞迪询问这种现在出现的问题。结构群组查看了这个问题，并与游戏设计者佛瑞迪和艾迪交谈。佛瑞迪询问这种现象是不是可以修正，而艾迪在与拜瑞谈过之后知道这个症状是故意的，为的是让速度获得最佳化；所以他宣布问题可以修正，但解决方式的代价很高，必须针对每一个多边形与每一条扫瞄线做额外的检查。佛瑞迪询问这在事实上会出现什么状况，而艾迪解释这会让游戏每秒的贴图数量降低，降低的程度要看画面上每一个物件有多大，以及同时存在多少个多边形。佛瑞迪不想失去引擎提供的流畅画面，所以他同意在游戏进行时不需要加入特别的效果。这个问题以［不需要做任何行动］的决定处理，并把一段简单的理由写在网上。 

接下来安迪碰到了俯视的视角，并再次用不具名的报告于网上提出。不过，这一次佛瑞迪坚持轰炸的视角在游戏中十分重要。在艾迪与克理斯交涉过之后，发现要加入这个真正的俯视视角，表示他们要写一个分离的次引擎，而且这将要再花掉三到六个月的时间。这个问题以［开放大家研究］的方式在网上回应，而结构群组与佛瑞迪先行离开，去想一个解决的方案。在经过数天的慎重考虑之后，佛瑞迪想出了另一个轰炸视角，并不需要向正下方俯视地形，并把它展现组结构群组。在这个时候，结构群组注意到另一个企划小组正在制作一个俯视的地图模组，可以很简单的放入《FlyBusters》的企划之中，因为他们之间的界面是一样的；但是必须利用随附的工具产生额外的图形。现在，佛瑞迪有二个制作轰炸视角的选择，而且二种都可以让人满意。 

这个解决方式选定之后，放在内部的网站上面，而且俯视的视角在几天之后，经由企划群组的结构规格更新以提供新的功能，平顺的整合到现今的企划中。艾迪经历过足够的传统企划，知道程序上面的方式不够正确的话，这种事情一定会发生；而且很惊讶的看到问题能够这么快的获得解决。安迪很高兴看到他提出的问题得到肯定，不管大家知不知道是他所提出的。克理斯松了一口气，表示他不用大幅度修改他的地形引擎，而拜瑞很高兴看到他的最佳化放在第一顺位。现在小组的士气提升，而产品也在预定的时间上市，成为很成功的商品。 

  

在这边最明显的好处，在于增加了整个企划进展的可见度，问题一出现马上就可以处理。提供不具名沟通管道的好处，在于企划中的每个人都可以看得到，所以每个人对事情的关切与心声，不需要和人与人之间的关系起冲突，也不用触及礼貌上的问题，那些都是人性的丑恶面。主要的顾虑还是在于企划的成功与否，而不是被冒犯人类哪种敏感的情绪。不具名的管道，有助于在这种状况下确保良好的结果。不管怎么样，这个讯息是从哪边而来的并不重要，重要的是它出现，而且它会以多快的速度出现。 

对很多研发者而言（尤其是在游戏产业），在实施这一类定义得十分清楚的小组结构，刚开始时会带来反对的声浪，主要是因为它看起来限制良多，而且会让创意窒息。您可能会听到研发人员说这样的程序会让他们的动作变慢，而且降低他们的生产力。这些研发人员通常（几乎）都是习惯于高速大量制作出程式码，并马上把东西丢到萤幕上。这些人员也是导致企划中产生大量臭虫，不得不多花数个月的时候来修整的同一群人。事实上，这些研发人员在抱怨的是，他们现在要做的工作在以前明明可以拖到企划即将结束时才动手，而且在发行时一样可以过关。在强迫使用程序化的作法时，大部分问题都可以在早期阶段抓出来。 

  ===============未完！继续看下去！=======================

抓虫 

大家都知道一件事：如果能在研发周期中早点把臭虫抓出来（而且这种事可能会发生在企划的任一个阶段），就会省掉更多的时间与金钱。一个在结构阶段抓出来的臭虫，如果放着它不管等到游戏即将发行才去处理，可能要花费200倍以上的时间才能解决它。 

如果您发觉额外的程序会导致额外的工作与延迟，这不过是一个幻象。对今天的大部份企划而言，这个工作仍然非完成不可，但是它永远不会排在企划时程表中，而且最后仍然得在研发过程后期把它做好。在这同时，管理部门急着等候企划的发行，而目前已经落后了六个月的时间。延后的企划会伤害到员工的士气以及小组在公司中信誉。任何可以用来侦测并修正这些问题的评估必须尽早运作，已经是不可或缺的事情了。不管怎么说，您听过多少次［一个游戏已经做了一年半的严密程式撰写，目前企划已经完成90%，只要再等一年，就可以完成90%以外剩下的东西］？ 

下列是一些在介绍结构设计程序时，最常听到的反对声浪：没有时间等所有的文件统统写好，这个企划已经处于一个十分严密而积极的时程表，而且增加这一堆高高在上的东西，只会让所有东西慢下来，而制作时间却越来越长。看到状况不佳的企划屈服在这些争议之下，而答案却是没有时间来实施这些提高效率的作法！在长期中节省时间，才有可能弥补早期任何慢下来的进度。研究一个时程表的步调（并预见问题，在出现之后尽早把问题解决掉），时间才能在剩余的企划时间中有效的节省下来。 

想要知道沟通的方式，请参阅第13章。 

现在您知道不同群组之间要限制互动的理由了，接下来的部分会简要的说明这些作法以及安排这些沟通管道的理由。请注意，就算是透过这些已经安排好的构造，讯息还是会以其他的方式进行传递：偶尔在走道中的见面，或是在午餐或中场休息时的讨论，都会打坏讯息传递的重要结构。最重要的是，要把这些问题带入正式的会议之前，必须先透过正确的管道，才能实行解决问题的行动。这会让所有人关心问题，并有机会让他们想出好方法。 

  

游戏设计者群组 

游戏设计者群组负责的工作，是撰写初步的游戏设计；并在后续的过程中，把研发与测试过程中发现的游戏关键加以浓缩精炼。象这样的作法，其他小组中的人员可以加入游戏设计者群组，提供点子并把游戏设计变得更为精微。不过，如同先前讨论过的一样，游戏设计一般而言比它的外观更为复杂，所以生产初步的设计与规格，最好留给经验丰富的游戏设计者来完成（或是看过本书第一部的人）。通常这个群组也要负起撰写最终用户文件的工作，象是游戏的说明书。 

游戏设计者群组主要是与软体结构群组进行互动，一般而言他们会倾向依靠预估企划的可见度，来遵循整个企划的进展，而不是直接去找其他群组要资料。 

这个群组的主要时间是花在研究新的设计，并修正目前在研发中的企划。在工具与元件群组有足够的速度，并为游戏设计者完成了数个有用的工具与元件后，这个群组会发现他们自己在游戏调整与程式设计的过程中，更具有［实践］上的经验。举例来说，如果一个简单的人工智慧描述引擎已经完工了，那游戏设计者就可以开始撰写描述档。如果企划已经使用资料库来研发，以储存各种常见、可调整的参数，那游戏设计者也可以进行参数的调整工作，把游戏调整为他们心目中的模样。这些参数被公认为［软体结构］，而且可以在不变更企划要示的硬体结构下，进行多方面的调整。游戏设计者群组的领域也可以包括直接性的调整结构，但这必须等到有适合的工具，才能让他们完成这个工作。 

游戏设计者群组也必须与声音和美术群组沟通，以指定游戏的外观及感觉。 

  

软体结构群组 

软体结构群组的作用如同一个工厂的中枢，而且它是游戏设计者群组和程式设计群组（工具、元件、企划与研究）的主要界面。这个群组的人员对所有的程式群组来说，就代表了传统的［首席程式设计师］；不过他们也有可能会做一些较小规模的程式设计工作。 

这个群组主要的责任是把游戏设计转化为技术结构文件，使用现有的元件与工具，并写下这个企划中的工具与元件需要做何种程度的修改，然后从研究企划的结果，开始研发新的工具与元件。这个群组的人员也会为游戏设计者提供回馈，以确保这个设计是可行的，并从游戏设计者想象出来的设计理念，做技术性的游戏设计建议。这个结构的规格是一个不断进化的过程，可以随着企划的进行而不断的修正。大部份的主要改革，都是在原型的阶段中，从是否可行性的研究加以整顿出来的。所以任何未来的修改应该都是以现存的结构为基础，在精微与净化的过程之下更为完美。除非您拥有某些可以看透一切的神力，否则了解这些是十分重要的（从统计学上来说，而且这些现存的数字都在｛0，1｝之间――这会更让您搞不清楚），然后在现有的结构中最多只能完成80%，接下来要等程式开始撰写。最后的20%必须在企划的进行期间完成，一般称之为80/20规则。 

软体结构群组全面控制了整个公司的标准结构与程式撰写。这个控制包括了各种类别，象是档案格式、界面定义的标准、文件标准、目录结构、原始程式码标准控制以及其他把重复使用与可以维修视为重点的常见范围之下。 

程式码回顾是由这个群组的组员来进行的，这是为了确保结构标准可以随着不同的企划而修正。这个群组也监督了各个元件、工具与企划的个别系统测试。 

软体结构群组一般说来，是由公司中技术最好的人员所组成。他们在结构设计上十分专精，而且可以写出他们能够遵循的详细规格，不会觉得模棱两可，所以用不着去劳烦三个程式群组的任何一个。这些人在技术上面的能力已经足以回答程式设计师的任何问题，并解释任何技术上的重点，让他们可以遵循着规格来运作。如果在必要的情况下，训练应该可以达到这个目的，要不然就引入其他具有技能的软体结构师。 

  

工具群组 

工具群组的主要功能，是生产并修护所有其他研发群组使用的工具。在某些情况下，这些工具是在公司内自行撰写的，而在其他的情况中，可能是比较常见的架上产品，象是3D Studio MAX与微软的Visual C++。 

在可能的情况下，这些工具是设计用在一个以上的企划中。这个考量并不象它听起来这么困难，举例来说，一个设计得很好的地图编辑器，在各个企划中都应该可以运作得很好，毕竟地图就是地图；如果想要特殊的功能，它也可以藉由提供资料档中的资讯来定义。如果真的需要一个外加的功能，就可以去撰写特别的输出模组。某些企划结束后，有可能非把工具丢掉不可，但是这方面必须多加小心――或许它们在未来的企划中会发挥作用，或甚至在制作资料片时，这个工具也是不可或缺的。不过，一般来说，把工具丢掉真的没有什么必要；而且就算如此，程式码与文件的标准，应该还是可以让这些工具在设计时，是以重复使用为基本功能。 

  

案例研究11.5　重复使用工具的好处 

据Larian Studios的史温·芬克（Swen Vinke）所言，《LED商业争霸》这个游戏是在另一个企划《The Lady, The Mage, And The Knight》进行之中的五个月时间完成的。 

这二个游戏的风格与基础都是不一样的（前者是即时战争游戏，而后者是一个多人连线角色扮演游戏），但是它们都有相同的方格地图结构。由于这个相同之处与史温在设计上面很小心的处理游戏骨架，这二个游戏可以同时使用很多的共通程式吗。史温完成的应用程式支架品质，可以让他在二个不同的游戏中，同时套用相同的结构；而在共通性的结果之下，他可以使用相同的编辑器为二个游戏设计关卡，省下了研发另一个工具的研发成本。 

在小心翼翼与深思熟虑之后，这个方式可以用在未来的游戏上，而且一组常用的工具，可以透过软体工厂来进行设计。 

来源：游戏研发者杂志（1997年10月） 

  

元件群组 

元件群组创造出的是低级的模组。这些是其他公司以各平台为主的程式库界面；常见的模组包括压缩程式库，以及其他类似的模组。 

在刚开始时，这个研发出来的模式看来十分明确而易懂，但是随着小组经验不断的成长，对额外功能的建议将会加入常见的程式库中。看看案例研究11.2，要想象出一个完全不同的图象引擎并不困难（举例来说，同样的3D模式），而且也可以不用经过太多的困难（只要让它绘图）就把它放入定位。 

最重要的元件设计目标，是它们应该只做一件事，而且做得很好。这并表示它们应该设计成不只在一个企划中发挥功能。举例来说，如果您有一个全视角的3D游戏引擎，它应该只会提供这种功能。一个2D的地图视角，应该是由另一个完全不同的模组来提供的。每一个模组的界面要完全一致，在这种方式下，如果往后想要把3D的等大地图视角，换成2D的地图视角时，在理论上只有图象需要重绘，而且新的程式码将可以直接连结进去。 

另一个例子是声音引擎。在大部份的状况下，这个模组不应该同时内建2D（标准左右音量的变化）与3D定位的功能。3D定位应该在另一个独立的模组中建立，而在界面上与2D程式库相同。如果有必要的话，2D模组可以加以修整，来支援3D模组中所需的额外功能，象是办识不同的旗标并递送给第二个创造声音的模式，不过造成的缺点，就是无法与上一版的2D程式库相容。 

记住一个元件最优先的事情就是完成一个工作，而且要做得很好。这会让它在建构企划的时候，更容易与其他的元件融合与搭配。 

  

企划群组 

当一个企划刚刚开始时，企划群组的工作就是负责制作出游戏中所需的技术原型。在大部分的状况下，一个企划不可能马上进入全速运转；如果没有先做出一个原型，要进行一个企划会操之过急，除非所有需要的元件都已经由已经由元件群组先写好。那一个企划要如何开始呢？ 

一旦一个企划开始跑，第一个工作就是确定所有需要的元件已经研发完成。对每一个企划而言都是如此，这表示在结构设计完成的接下来三个月，在进行的工作就是元件以及小量的原型制作工程。这个状况的控管要十分小心，就算是最专业的管理人员，知道这一段期间看不到真正的游戏，也会觉得有点［抽筋］。游戏原型的制作有时可以消除这些恐惧，但不一定保证能奏效。另外，原型也可以用来进行可行性的研究。这个点子真的可以用在游戏中吗？它看起来会好玩吗？在您把企划推到后期，会不会碰上什么技术性的问题？如果会的话，您要先做什么样的准备？ 

在原型与元件的研发结束，并假定可行性的研究结果中不包括任何需要回头重做的现象，那就可以认真的开始进行这个工作了。 

企划群组的工作在于把元件定位并堆叠起来，撰写结合程式码，然后把美术与声音小组提供的图象与音效放入（详见［附属群组］）。这个工作也是受到游戏设计群组的控制。企划群组在接受资料时，要确定美术与声音群组所提供的档案，是企划所需要的格式。 

企划群组必须与测试群组协力合作，以确保这个企划处于可以发行的状态。什么叫做［可以发行的状态］？这表示这个企划应该随时处于可以继续建造，也可以发行上市的状况。没错，并非所有功能都已经完好了，但是至少在使用者选择了一个未履行的选择时，它不应该就此当机。现存的功能必须正常运作，而且要十分稳定。这个企划将持续性的进行测试，而且任何回报上去的问题都要马上进行处理（如果必要的话，也要通告结构群组）。 

游戏设计群组禁止透过结构群组与企划群组互动，而且透过群组的方式将在第13章中讨论。这层限制的作用十分明确：它要预防特色蔓延，并确保时程表是可以达成的。 

游戏设计群组可以自由调整游戏，而且有可能透过暴露出来的软体结构来进行调整。只有在需要变更真正的程式结构本身，才有必要透过结构群组进行必要的互动。变更真正的程式应该是很少见的现象，所以企划群组应该挡住游戏设计群组的过度行为。 

研究群组 

研究群组是在结构群组之下，以松散方式来管理的一群人。研究群组的工作（包括所有事情）在于研发新的科技并制作原型，之后将它放在核心的程式库中，供其他的企划来运用。 

这些研究企划应该是以您想要找出来的重要科技创见为主，用完全相同的注意力与精细的程序来实行。详细的记录应该留下来查阅，而这些应该经常回顾并查核。由于它的本质，您必须了解要把研发计划放入时程表，是一件不可能的事。引用一句呆伯特的话：［逻辑上是不可能把未知排入时程的］。 

研究群组的目标是找出未知成为已知，然后从群组的研发路线上，移除单一最大的风险。因为所有其他群组用的都是已知的东西，文件模组、所有要开放进行研究的东西，都从重要研发路线上面先行移除了。如果一个企划真正需要的是这一类的研究，那就不要进行这个企划，直到相关的研究已经有了一个成功的结论，而且随同的模组也在元件群组的手中完成再行考虑，要不然就是变更这个企划，直到不再需要依赖这个研发成果为止。举例来说，先使用一个较没有效率的图象引擎，然后在研发出新的版本之后，再切换到新的版本上面。至少用这种方式，在图象研究完全没有成果（或是尚未完工）的局面下，您还有一个产品可以在期限的最后一天交出去。 

研究群组的大小是看其他小组的需求来决定的。除非是在很紧急的状况下，这边至少应该有一到二位人员；而且如果您有任何空闲下来的程式设计师（并考虑过其他小组的需求），您应该指派这些人来进行研究。 

该注意的是，研究的项目不一定每次都要朝向新的科技走。它也应该朝提升您公司程式设计师的平均技术水准而努力。有很多研发可以查出一个组织中，所有程式设计师的平均水准。很明显的，如果能靠个体人员集中精力，然后在会议中同时提升大家的技能层级，是一件求之不得的事。 

举例来说，一位程式设计师接到的工作，可能是去了解或是提升他的知识，找出如何加强一些核心模组的功能；或者他可以进行的是阅读并看完一些技术书藉，来强化他在特定领域中的技能。所以，这些时间并不会浪费掉，任何可以提升公司经难长棒的行为，都是很有价值的工作。研究群组是一个让这种努力成真的试验场。 

  

附属群组 

附属群组是支援性的群组，对一个企划的成功是不可或缺的。附属群组包括了声音、美术、测试、市场与管理群组，他们对一个特定的企划而言，工作量通常比较少，对其他小组而言也是如此。但这并不表示他们比较不重要。 

美术与声音群组将会为游戏提供美术、音效与音乐。这个群组受到结构群组的指挥，而且也直接从游戏设计群组手中得到与企划相关的资料，直接隶属于他们正在处理的企划。在必要的时候，这个群组会受到结构群组的调整，不过并不常见，除非美术群组被要求进行大量冗长或是没有安排时程的工作。 

测试群组与结构群组紧密的连结一块，并直接受到结构群组的控制。任何由测试群组进行的测试，将会回报给结构群组。要发行软体的每一块――可能是元件、工具或是游戏――都要经过全面的测试，而且任何明显的缺点或是错误，都会透过臭虫报告提出来检讨，并在必要的时候进行追踪修正。因为这部份需要把研发过程中写出来的软体进行严苛测试，所以这个群组的主要功能将在于整合、系统与相容性的测试。 

想要得知这些功能的说明，详见本书的第3章。 

市场与管理的结构早就存在于您的公司。所以在这边提到他们的唯一理由，在于他们有必要知道研发软体的过程已经改用软体工厂的模式。产品将会出现不同的情况，而且为了增加技术上的可见性与您的企划相关知识，公司所付出的代价并不是一声［哇！］就可以代表的。这边可能不会有这么多突然跃进的功能，让上层管理人员觉得大吃一惊；因为这种研发模式使用的是稳定、不断增加的技术来获得最后的产品。在研发过程中缺乏明显的进展，有时可能会让完全不懂这种作法的市场或是管理人事的部门觉得惊慌。不过，希望这样的现象不会导致太多的问题，因为管理部门在这一类的问题之前，可能会达成某些协议。管理上必须注意程序之间的不同，还有标准游戏研发技术和这些不同所造成的结果。 

  

运用软体工厂的结构与方法 

好，您现在知道如何建构一个软体工厂的一切所需知识了。我猜您现在更想知道的，是如何让它运作――至少我希望您会这样想！接下来的章节中，包括让工厂盖起来并开始运转的初始阶段，以及后续的过程。 

  

万丈高楼平地起 

在这个讨论之中，假设您想要把一个传统的研发环境，转移为一个采用软体工厂的研发环境，而且您想在混乱最小的情况下完成（如果事情看起来很不稳定，或是没有照着计划走的情况下，还有回到原先的作法的余地）。 

软体工厂可以逐步的进入您的组织，刚开始时只要创造结构与研究群组。类似的群组可能早就出现在您的组织中，尤其是对研究群组而言。 

第一件要做的事情，是创造遍及全公司的研发标准，以及程式与文件的指导方针。这方面大都是一种常识，而且全公司都要普及；让每一个人吹出来的口哨都是同一个调调，才能更容易看懂程式码及文件。这也是实施一些企划可见度提高的行动的时机，但是范围不要太大。提供一个公司内部网站，可以让人们看到规划好时程表的进展，如图11.5。 

想要查阅更多的连贯性建议，详见第13章。 

在做到这一点以后，这些群组可以开始进行元件程式库的研发并制作原型。要开始时，结构师应该回顾目前企划进展（或是即将完成）的程度，来决定哪些功能比较适合当做核心元件。特别把精力集中在目前正在制作的企划上面。 

在经过可行性的研究并测试元件的原型之后，核心元件就应该要开始起跑了。组成元件小组，并让研究小组开始进行元件方面的研发。这个程式码不应该从原型延续下来，因为原型的程式码不具备坚固的程式码基础。原型的程式码只是如它字面所代表的：［原型］。拒绝进一步使用它的诱惑，可以省掉您不少麻烦。把原型的程式码丢掉并重头开始，并利用您在运用原型时学会的知识，做出一些可以吓死人的元件。 

在完成初始的元件之后，就可以把它们放入正在进行的游戏发挥力量，来撰写尚未完成的功能。要把已经写好的功能置换掉是很不智的行为，因为它可能包括了重复撰写的程式码，并造成已经排好的时程表延期。从另一个方面来看，如果一个正在进行的企划中，还缺一个音乐光碟的播放程式，那么提供他们一个经过测试、有完整文件的播放光碟模组就是一件好事。确定这个小组了解一件事，就是所有的支援都要经过结构群组，而不是直接与元件群组中的程式设计师接头。这应该不是什么大问题，因为元件群组在没有得到结构群组的同意之下，不会做任何特别的变更。 

  

先想，然后再想 

先想小的东西，而且不要想太久。从一个可以马上派上用场的元件开始。一旦企划小组开始接近您想的东西时，就可以开始进行更具基础、具预先思考性的元件，是在后续的企划中可以发挥强大效用的。 

在有可用的人力之后，把他们拉进工具群组，并开始制作工具来支援更新奇的元件。 

现在您已经走了一半的路了，而剩下的过程会自动进行，在企划不断的完结而且更多的研发人员空下来，让您可以把其他的小组填满，合并成沟通骨架。另外，现在也可以看出软体工厂是否适合您的组织，或者您该采用的是另一个方式，也可能把这些方式加以组合。 

  

知道使用其他小组的时机－平行研发时间线 

每一个程式小组是以时间刚好的基础来组合的。这可以确保拥有最大的弹性，并有助于资源的有效运用。 

很重要的一点是确保每一个小组有足够的人力，可以支援相互依赖的小组。这些人员的数量得照着您的组织来进行协调。在图11.6中，说明了群组的依赖关系。如果任何的支援结构很虚弱，整体就会倒塌下来，这很明显要加以避免。小心留意每个群组的强弱，并避免让结构顶端太重，而导致小组的过度负荷。这只会造成更多的麻烦。 

所以，这些群组是如何相互合作的？在图11.7中，是一个小型到中型的组织中，简单的工作量与时间关系表。 

当一个群组的工作量较小，人员可能会移动需要大量人手的群组中，以鼓励知识的转移。在一个针对初学者的研究中指出，这种群组间的动态，并不一定每次都能象预期的一样，把资讯适当的扩散开来；换言之，这些资讯不会象流行性感冒一样，自动扩散到新群组的人员身上。这种情况通常是发生在有些人在较后期才加入这个企划，但是对较大型的群组而言，群组的本质仍然应该保持原状。每一个小组的人员，应该了解到他们是一个小组的一份子。逻辑上的部门之所以存在的理由，只是为了确保企划的可见性，仍然保持在最透明的状况下。 

对较大型的组织而言，有可能（有时甚至是有其必要）在二边跑的情况下进行企划。只要支援基础够强固，这还是不会造成进一步的问题。 

  

轮换并重新指派小组人员 

软体工厂另一个强而有力之处，在于它可以让所有的组员分享到相同的知识。这样的作法并非没有风险，但如果您不这样做，您会冒更大的风险，如案例研究11.6所示。 

  

案例研究11.6　唯我独尊 

在一个我最近参与的庞大多人企划（与游戏无关）中，制作中的应用程式极度的依赖一个外部小组撰写的程式库，而这个小组是在另一个工作地点。这个程式库提供了各种复杂的计算功能，正是主要应用程式所需的。 

每次提到程式库的其中一个特别部份――我不打算讲出名字，因为我不想再入罪――时，周遭人员都会禁声耳语或是觉得十分敬畏。为什么？这不只是因为这个部份的计算特别复杂；而且它是由一个程式设计师，在十分慎重而单纯的风格中写出来的，整个公司中没有任何人知道它是如何运作。这个特别的程式设计师单人负责这个部份的程式，而且他很早就拒绝撰写相关文件或是说明。 

这方面的抵抗是因为他很喜好这种掌握权力的感觉，而事实上他也站在一个十分有权力的地位。他可以向公司寄出黑函要求他想要的任何东西，因为他知道他们不可能把他开除。他是不可或缺的，而且在一些场合中，他也直言不讳。 

要控制这个问题，我迎合了他的自尊并建议让他获得升职，他拥有了一间私人的办公室以及一个助理。这个助理是一个从公司外面引进的物件导向专家，他的程式技能让主要的研发者望尘莫及，而他的工作是学习这个禁区中的程式码，并加上注解，但是行事上要特别的小心。 

在一些刚开始出现的问题后，这个研发者接受了他新拥有的权力。并全面运用这个新指派给他的助手。但是他不了解的是他太高估本身的不可或缺性。这个专家助手花了六个月的时间研究他的程式码并加上说明，并很快的觉得他可以把程式重写并把疑点敝清。 

在接下来的几个月之后，新功能的规格已经画了出来，之后就开始小心在另一边进行测试，是否与原来的功能相同。当所有的臭虫都已经除掉（包括一些原来程式码中的修正），就宣布旧的功能已经可以用新的功能来取代，而且能力更强。当然了，原来的设计者在惊恐之中尖叫，但是在进行挑战，却无法为他保住旧有程式码的优势之下，他没有理由告诉大家为何不使用新版的程式――不但干净、具物件导向功能，而且最重要的是有充份的说明文件，在品质上比原来的程式码好得太多了。 

有点让人吃惊的是，在他的权力被移除后，这个研发者成为小组中十分愿意助人的员工。已经有人很明确的告诉他这一连串的行动为何展开，而且如果他再来一次，会发生什么样的后果。所以，他被密切的监视，以确保他能服从其他人的要求。 

这整段过程不管是哪一个部分，都不是很让人高兴；但是有时候强悍一点的确有必要。这个风险对企划与公司而言，光是靠一个人而兴盛或是失败实在太过夸张。 

在一份相关的记录中，我曾经看过一个研发者对变数的命名方式极不寻常。他会从字母A开始，然后一路写到Z；当他的字母用完之后，他就开始用AA，然后写到AZ，依此类推。最惊人的是，他记得每一个双数名称的作用，就算他的程式中没有任何注解，他也可以在写好数个月以后去修改它，完全不会有问题。当他离开公司时，他写下的所有程式码统统被丢掉一边去，然后重头再来一次。没有人可以了解他编写程式的，而且一切都已经太迟了。 

  

在轮换队伍的人员时，很多记载于案例研究11.6中的问题，可以在他们成为大问题时加以避免。您可以经常性的针对不同核心程式群组来轮换人员，但是选择时间上要十分小心――在一个企划即将结束时增加人员，会把所有的事情拖下来。 

虽然这听起来很危险，但它可以确保不只一个人专精于特定区域中的程式码；而且，因为文件的撰写过程已经确立，新的研发者要进入状况花不了多少时间。您要的是哪一种：稍微增加研发时间、还是冒着整个企划无法做完的风险，只因为关键人员离职？ 

把风险尽您所能的分散开来，而且别把您的鸡蛋统统集中在一个篮子里。 

  

一个软体工厂的可适性 

软体工厂是适合中型到大型的组织。在这个例子中，出现了五个以上的程式设计师以及相关的技术人员。这种规模的组织可以容许您用公平而平衡的方式来分派小组，并让组员的轮换产生良好的效果。 

软体工厂也可以轻易的缩小用于较小的组织中。您会失去一些平行效应，而且也无法拥有奢侈的附属群组，但是在制作第二个或是续作的企划时，您所拥有的优势仍然是显而易见的。这种方式的技巧可以让您用来研发软体，而且已经在过去五年的时间，在欧洲不同的客户中，以坚实的C++研发经验打下了基础；°这种状况下的研发速度与效能都十分出众。在可能的情况下，在各种规模的小组上建造出软体工厂结构，得到的结果也会让人满意；就算它会让部份的研发人员，在不习惯的情况下产生反抗心理，而且管理部份也必须等到较为后期才能看到游戏结果，臭虫的修正也有可能拖到游戏发行之后。 

  

最后的讯息 

在本章提供的方法并不是宇宙中的万灵丹，软体研发方面也没有捷径。如果您在研发小组之中找到了基础性的问题，象是技能不足或是经验太浅，那不管是什么方法都帮不了您，直到您把问题的根源解决掉为止。 

另外，您没有必要把这个方法当做戒律。去试试看。看看什么方式有效，哪些无用。把有用的部份留下来，无用的碎块丢掉。靠着决断――以及大量的努力――就可以看到这个方法的结果。 

很多其他的方法与技术一样适合于游戏设计，大部份（包括这一个）都是靠着传统程式设计上的努力而发迹。这是一个已经证实可以生产出高品质软体、可以不断的制作续集的系统，每一阶段的产品周期，就可以一点又一点的朝游戏发行迈进。 

游戏研发者的特别之处，在于他们会把任何放在他们工作路线上面的限制，以最快的速度打掉。当然了，如果所有的企划都可以拥有水准以上的表现，并在规定的时间完成，这些措施根本就是不需要的。 

在各种理由之下，真实世界并非如此，所以在这边传达的讯息应该是［没试过之前给我乖一点！］不管怎么说，结果可能会让您很高兴。

===================第十一章完！=========================

第十二章　里程碑及期限 

  

＊企划的时程安排 

＊避免独断的期限 

＊破除模糊的里程碑 

＊企划的开始 

  

不管我们多喜欢在自由而且没有压力的情况下撰写软体，一些里程碑与期限这是有必要的。是的，它们是所有［不琐碎软体企划］的常见要素，而且也是许多研发者生命中的祸根。 

在看看所有的里程碑和期限后，很令人惊讶的是，大部分的里程碑规格都是设定在一个独断的风格之中：而且在大部份的情况下，期限则是定义在一个［期限］的基础上，而非实际的预估。这个特点来自不同要素的作用，包括市场的影响、没有经验的软体管理者，而且在某些情况下，包括了极为固执的人。当然了，大部份的人们只是不知道如何针对软体的研发来预估时程。想要维持公平是一个困难的过程，而且它包括了许多的分析与计算，才能产生有用的结果。 

在游戏产业之外，软体公司使用一个比较严密的方式，而不是［选一天并期望那天做完］。即使如此，贵重的训练以及指导方针，还是有助于在合理的态度下，定义出里程碑。 

里程碑的作用是把企划分解成可以管理的厚块。最不应该采用的作法，就是列出一长串想用的功能列表，让研发者一个个查看是不是统统完成：当然了，事实上也不应该建议这种方式。您可以想象到，在一个企划持续了18个月的时间后，每个星期只能在几个要件上面打勾，会让士气低落到什么样子？这种做事的方式有可能成功吗？小组要怎样去集中精神并保持热忱？如同它的荒谬之处，有些企划仍然使用这样的系统来进研发，而它们的过程可能是软体研发中最无趣的。 

在这边呈现的方式可以运用在各种类型的软体上，不管是试算表、资料库或是大型电玩中的射击游戏。这个章节将告诉您一组以［良好经验］为基础的指导方针，以更实际的方法来定义里程碑和期限。在本书的后面，我们会解释这些预测是如何进展，并随着企划的延续而越来越精确。这个越来越精确的现象，可以视为集中性的规则。在讨论企划的全面结构时，这个章节也可以做为本书未来章节的地图。所以，如果您正在寻找研发过程的相关资讯，这个章节可以说是您的第一站。 

  

里程碑如何运作 

您有多少次，非要用一个［模糊］的里程碑当做目标来工作？对没有经验的人而言（而且数量不能太多！），一个模糊里程碑是一个有很多解释且具备X种可能完成它的方式，而这个X代表您想要的任何数字，只要比1大就行。 

而且您要怎么样才知道您抵达了一个模糊里程碑？如果这个里程碑的目标十分模糊，在预想的情况下，它们就是开放性的解释。那谁的解释才算数？当然了，这通常要靠您的老板才能做出［正确］的解释，而且很可能出现的情况是，他与您的看法完全不同。 

试试这个简单的测试。想象您的老板给您一张纸，上面画了五角形的五个点，标示出A、B、C、D和E，如同图12.1所示。 

现在，想象您的老板说：［我今天很忙，而且我需要在一个小时中完成这个工作。我有很多人要见，所以我只能简要的告诉你我需要你做些什么事。我要你在A和B之间画一条线，在我从生意上的午餐回来之前做好。 

三个小时之后，您的老板蹒跚的回到办公室，并向您要完成的文件。 

如果您直接在A与B之间画一条线（如同图12.2），我很抱歉，但您输了。不过，如果您先在A与E之间画一条线，然后确定这条线延伸绕着五角形穿过D、E和B，（如同图12.3），而且在A与B之间留下空白，那您就成功的达民了里程碑。 

好吧，您的老板不会叫您做这些琐碎的事，这边的重点是：含糊的里程碑是没用的。 

要走到您的解答，它可能代表您作了太多或是太少的事情；而大部份的情况下，程式设计师的基本心理一定会倾向后者。这并不表示良好的程式设计师都是懒虫；这只是表示在普通的原则下，二点之间的最短距离是直线（大部份的良好程式设计师，喜欢以最小的工作量，产生出规定的结果）。 

不过，在前者的情况下（作了太多事）也通常代表错误的工作方式，这表示程式设计师在解答方面太过热心，提供了不需要或是没有必要的复杂功能。 

在完美的情况下，里程碑不应该有这些大的活动空间，但很不幸的是，这一类状况正是大部分安排时程的问题核心所在。在一个比率公平的企划中，里程碑之间的距离放得太远，它们之间就可以容许一定程度的偏移；象是进行不必要的工作，或是缺乏集中注意力的焦点。 

一个里程碑应该十分明确而简洁。它应该也很明显，足以一眼就看出这个里程碑是否已经到达：黑与白、失败与成功。它不应该迎合或是鼓励任何野心的结果或是灰暗的阴影。没有人可以说一个里程碑完成了90%；一个完成90%的里程碑给人的感觉，好象是一个灯泡的亮度为90%；这个灯泡只有亮与不亮，里程碑也是如此。 

这个要点十分重要。模糊里程碑是在企划中最常见的单一问题。 

  

您老板的五角形工作，应该以下列的方式来说明。 

1．必备工具：尺以及一只黑笔，可以划出连续的细线。 

2．在点A到点E之间，以粗细均匀的黑线相连。 

3．在点E到点D之间，以粗细均匀的黑线相连。 

4．在点D到点C之间，以粗细均匀的黑线相连。 

5．在点C到点B之间，以粗细均匀的黑线相连。 

注意：不要连接点A到点B之间。 

  

这个列表是一份更详细的分析文件。这个分析应该详细到没有产生怀疑或是问题的空间。告诉您如何去解决问题。在这个例子中，还有一个更好的解决方式，而且产生出来的解答刚好可以想连的点连起来（一语双关）。您可能觉得这样的作法会将程式的创意抹杀，对这一点，我的回答是［程式并不是发挥创意的空间］，换句话说［有创意性的程式设计］叫做胡闹。适合发挥创意的地方叫做设计与结构，在我们开始进行系统的程式撰写时，游戏与结果设计者已经完成了所有创意的部份。这一点可能会削弱自尊，但是一个程式设计师的工作就是很简单的翻译：拿到详细的设计，把它转换成可以在电脑上面执行的东西。 

我可能已经听到程式设计师的坚决声明，说他们是创意上的天才，我怎么有这种胆子把他们贬低成只会写程式码的猴子？嗯，只写程式的程式设计师是程式码猴子。一个真正设计工作中的程式设计，在一个漫长而复杂的过程中，真的只是一个小小的阶段。它是一个结束的修正，一个微小但重要的详细过程。不过，程式设计师通常有更大的责任，而不只是写程式码。在大部份的状况下，他们也要为详细的模组设计以及相关的执行工作负责。这可以让他们把创意移到该去的地方，把创意放入附有详细说明的程式码设计文件，而不只是在写程式码。 

对那些还看不懂上述争论的人，请回头看看第11章，将更详细的讨论了上述的重点，并提供了我的看法。 

我曾经参与过的每一个良好企划，都有意把程式设计的等级降到简单的翻译。这些企划都平顺的进行，也统统在时间与预算的要求下完工。 

相反的，所有我曾经参与的不良企划，都直接从整体的结构设计进入程式码的编写。在没有例外的情况下，这些企划都超出了原先的预算，而且完成时间向后拉长――如果他们真的完成的话。 

如同在案例研究12.1所示，模糊里程碑会导致企划的延期，而且结果是让那些守着里程碑的利益团体，出现迷惑以及大量的猜疑。如果没有指出一个明确的中止点与进度，您就降低了企划的可见度，这表示没有人真正知道这个企划的进度在哪里。所以，延期与问题成为疾病，在没有人想出一套解决这种问题的方案下，它就这样发生、不受注意，一天又一天直到它大到无法忽略为止。在统计学上，大部份的企划损失时间导致没能及时完工：就是因为延期又造成了延期。这样的问题必须及早解决，而且这个状况明明可以及早矫正。 

  

案例研究12.1　为何模糊里程碑可以做一个企划 

在我很早以专业身份担任第一个游戏的企划时，我刚刚从学校出来，被指派一个看来很简单的任务：为我们正在进行的游戏，以微软的Visual Basic4写一个关卡编辑器。 

这对一个企划的标题或是任务说明都是好事，但不幸的是，它也成为我的企划里程碑。 

再也没有更难让人看到里程碑的情况了。不过，在那个时候，我并没有什么经验，所以也看不到问题的所在。 

我接到的期限是二个星期，来完成这个特别的企划。在基于上一版Visual Basic的良好知识下，我开始工作。 

第一个障碍，在于我对问题领域没有足够的知识：我不知道它要的是什么，即使我的老板和我认为，我们二个脑子中的游戏完成产品想象图是一模一样的。 

我在思考的企划（而且我知道我可以在二个星期内完工）是一个用方格为基础的地形编辑器，可以产生出棋盘式的方块，然后用这些方块拚出有高度的地图。 

而在我的老板脑中的企划，需要的是一个地形编辑器，不但有拥有上述的能力，还要能够自动用乱数或是输入一张代表高度的地图，让从VistaPro（一种地形产生套装软体）载入的资料来产生出地形，并启动更换地形上面的游戏物件（包括让先前安置的部队自动产生阵形），自动输入并在输出给美术师时进行分类，而且产生一组完整的关卡档案，其中所用的色盘将视每个关卡来最佳化。 

这二份上述的说明，都是关卡编辑器的描述，但只有一个有可能在二个星期中完成，而且只有一个（在我老板的意见中）才是对的。不幸的是，我们二个看到的并不是同一个。 

结果，在二个星期后，我以每一个规格完成了地形编辑器，所以达到我的企划目标（这是我所见到的）。没有人告诉我其他的东西，而且只有一个时间很紧的期限，我在写程式时没有办法加入任何东西，当然我也不可能提供一个选择，让这些东西在日后再加进来（换句话说，我在进行软体创造时，用的是［地狱程式码］的方式）。 

最后的结果，是要再花十个星期的时间，才能达到里程碑，而且这个程式最后执行起来慢得让人受不了，因为它用了Visual Basic4，去尝试做太多色盘有关的处理。 

  

模糊里程碑 

就象登山者会被人警告不要去吃黄色的雪，您得到的警告则是不要容忍模糊里程碑，这是一个常识。为什么要在规定的期限内，朝一个您甚至不清楚在哪边的目标前进，而且在您抵达目标之后，还有可能和别人争执这个目标立在什么地方？模糊正是软体时程安排上的敌人。 

模糊里程碑也会导致在企划进行全面的规格定义之前，先完成里程碑与时程表。因于这个时候还不清楚问题的领域在那边，里程碑是以概略的通则来定义，而期限则是以独断的行为，将可用时间予以切割，以直觉般的本能来安置。通常在单一的里程碑中会包括太多的工作，这代表在到达这个里程碑之前，必须完成所有分散的工作。这就会形成一个模糊里程碑，而且可以合法的描述成一个（举例来说）半完成的东西（象是要完成这个东西要二股力量，但只完成了一项）。 

在单一的里程碑中填入了太多的东西，会招致反效果。除了很明显让人迷惑的要素外，它也会导致其他的次要问题。小组会觉得他们要做的事情是达成一个里程碑，但是要到达这个里程碑之前所花的额外时间，将会影响到士气，而且整个小组的态度也会转换成一场壕沟战：我们每天都在对抗他们，并在不断的磨擦中降低了前进的速度。一个小组，应该知道要花掉多少时间，所造成的进展在整个企划中占了多少百分比。 

这并不是一个不可能的工作，但是它的确需要更多的规划，通常也是一位游戏企划的工作。 

  

里程碑与迷你里程碑 

如同定理一样，要踏上一个里程碑所花的最好时间，应该是四到八周。这将提供有限的目标，可以让里程碑在合理的情况下受到所有人的重视。另一个问题是庞大的模糊里程碑很难让人专注于其中：有谁会在意四个月之后的期限？这个状况通常会造成前三个月的时间都没有人在写程式，而最后一个月大家都在地狱中工作。 

要解决这种现象（除了把里程碑之间的距离缩短）可以把每一个里程碑分散成迷你里程碑，或是查核点，大约每星期一次。很明显的，想要做到这一点，您必须把结构规划的相当好。如果，您发现在目前的处境中，无法公平的定出里程碑和迷你里程碑，那么在结构的设计上就不够完整到足以开始写程式。在这种情况下，我们可以先确定企划开始之后的重要阶段中，是否进行着良好的运作，再来解决这些问题。如果一切进行的很好，要让它们保持运作就比一开始要先修理问题，并勉强运作来得容易得多。一个在里程碑和迷你里和碑之中良好的工作分配方式，是把迷你里程碑指定成完成特定模组，而把模组的整合当铸主要的里程碑（有时候把迷你里程碑再加以分割是必要的，但是这将视您小组以及手中的工作而定）。

在良好的小组之中，迷你里程碑不一定有存在的必要。举例来说，如果小组的经验丰富到知道解决问题的最好方式，而且成熟到时时留意期限的逼近时，就没有设立的必要。不过，对新的小组或是一个全新而不熟悉的企划来说，迷你里程碑就可以做为二种用途： 

  

＊让小组专注于他们手中的工作。 

＊在重要的时间，提供大家已经增加的企划可见度。 

  

第一点中很重要的是不要把里程碑的间隔安置得太远，才能避免人员在企划中漫无目标的漂流。一个很类似的情况，是想象您手中有一份指示，叫您前往一个您从来没去过的地方，但是您对这个地区有个模糊的印象。现在有人请您沿途画出一张路线图，并在有限的时间中抵达。在您上路时，您最花时间的工作是画地图，从现在开始，您会不断的走走停停，四处看看您的前进方向。 

在这个例子中，里程碑就是您走走停停的动作，而企划就是地图。您走走仿停停的次数越频繁，您在地图上面走错路的可能性就越低。很明显的，这个方式正是［报酬递减法则］：如果您每走二步就停下来，不只会花更久的时间到达，而且您无法专注于绘制地图。如何找出这方面的平衡就是关键，这个里程碑不应该如此频繁，导致有效的工作进行受到损失；但是也不能一次冲刺得太远，然后看到整个企划迷失方向。 

一个良好的定则是把迷你里程碑的数量，以小组对这个主题的经验高低来调整；而这个迷你里程碑少要保持在一或二天。任何比这个数值更小的时段，将需要更频繁的管理，而且在可见度方面会让坏处多于益处。 

  

何时要使用里程碑 

在一般的情况下，每一个程式或模组都是一个独立的企划；而且对大部份的程式而言，这都该被视为本质相同，而且提供相关规格与说明文件。是什么东西导致程式琐碎并没有定论，但是在这边的建议，是只有在您能够断言没有其他用途之下，才考虑写一个要丢弃的程式（即原型程式），这可以减少程式琐碎化的机率。如果您用这个程式继续研发下去，只会产生一个荒废谬的庞大企划。 

一个可以做为例子，并符合上述标准的程式，是那些生产出对照表的程式。它会产生出预先计算的数值档案，以减少执行时所需的计算（在处理器越来越快的现在，对照表已经不再受到青睐，但是它们在速度有限的系统上面仍然十分有用）。要研发这一类的产生方式，将包括撰写常式分析器，可以读取使用者定义的公式来产生表格。在这个特定的状况下，很明显的要比把计算公式写死在程式中的好。 

  

让您的里程碑正确 

为了增加时程表的正确性，我们需要尽可能的把不确定的东西移除掉。这并不表示您可以移除所有的东西，但是只要您能把不确定的数字降到最低，就等于避开了里程碑的模糊性。 

在案例研究12.1中，问题源自于一个共通性的误解，以及对正确的需求缺乏深度的说明。之所以没有附上说明用文件的原因，是因为在这个问题领域中没有进行相关的研究。在给予了严格的期限后，很明显的并没有提供任何相关需求与想法。老板只是假设他想要的知识会［自动］的从他的脑袋传到我的脑袋中。在混合了这样的想法后，他假定其他的组员可以在数分钟之内，把他们所需的东西说得一清二楚。 

这实在一点道理也没有，但是您会很惊讶而且吓一跳的，是有好几个企划的确就是以这样的基础来进行。大量的金钱都花在这种预期上，而不把所有可能影响到企划进度的要素列入计算之中。在一些案例中，期限的设定基础是由市场部门要求的，这可能只有最没品质的小组才能同意这样的要求。 

发行日期很显然是源自市场方面的压力，但它绝对不应该成为时程主题的决定要素。尝试让小组去尊重市场部门设定的期限是不可能的，尤其是当这些期限设定在独断而不合理的前提之下，再加上完全不把研发方面的技术要素考虑在内。如果出现了一个市场决定的期限（象声名狼藉的圣诞佳节大冲突），那就得把功能加以调整，才能让企划符合规定的期限。这个减少的功能必须在各方面都十分的清楚，碰上这一类情况最有效的回答，就是要求修整时程表的时间，但是要完成的工作量还是一样（这边的假定是，反正所有的研发人员都在时程表上面填了一些空间，来让他们的生活轻松点。这是很荒唐的事，但如果您屈服在这种假定之下，您就是在自找麻烦）。在处理所需的工作量上面，这个时程表一定要经过最佳化并极为清楚。如果这个工作必须在短时间完成，那就非得砍掉一些功能不可。我已经看过太多的状况，是企划领导者同意这样的状况，并假定他们可以在12个月中完成18个月的工作。不得不承认的是，只要足够的超量工作，这并不是不可能的。尝试让一个研发小组在紧密而且加班情况下工作12个月，处理上吨的工作并非容易的事（而且绝对不建议这样做）。这会伤害原本高昂的士气，而且这个企划结束之后，失去您所有技能高超的研发人员，也不是什么怪事。 

在案例研究12.1中的程式期限很明确，但是对这种正式的工作而言太短了。在这个企划中光是收集资讯至少就要一个星期，而且如果先收集到足够的资料，就可以预测出这个企划需要再花六个星期来撰写。当然了，就算这个预测是靠着其他组员在这段期间的工作量来判定，您还是要把撰写说明文件的时间，以及说明这个编辑器中所需的功能考虑在内。这件事可能会得到老板的同意（或是拒绝），但至少这个结果可以让他采取其他的选择，象是指派更多的人加入这个企划、降低要求、延展时程表、给这个企划一些在相关领域中经验丰富的人，或是把您开除掉！ 

在您想要规划并为整个企划安排时程表之前，您有些动作是一定要先完成的。一个企划的前三个里程碑（如表12.1所示）一定要实行，这可以让您更详细而且更精确的分析出接下来的每个月，时间要如何运用。 

  

表12.1　前三个里程碑 

里程碑 
 查核点 
 工作 
 
1 
 1.0 
 一般性必备物资收集 
 
  
 1.1 
 技术性必备物资收集 
 
  
 1.2 
 资源上必备物资收集 
 
2 
 2.0 
 一般可行性研究 
 
  
 2.1 
 技术可行性研究 
 
  
 2.2 
 资源可用性研究 
 
3 
 3.0 
 结构规格草案 
 
  
 3.1 
 企划开始 
 

  

这些里程碑有效的包括早期规划以及可行性的研究。这些阶段的花费，是企划总成本中最小的一部份，而且它有助于提供良好的资讯，计算出整个企划的总成本、时间以及技术上的可行性。在第一个里程碑之后的每一步，都让做决策的人有一个很好的地位取消整个企划，或是让它朝下一个里程碑继续前进。在那三个里程碑完成时表示企划可以开始运行，那企划就应该可以朝完成的方向迈进（除非它掉入汪洋大海）。如果通过了可行性的研究再把企划取消掉，那应该视为可行性研发过程的失败，并进一步的调查。 

一个企划的初始调查阶段的实行优点十分明显，毕竟接下来是为期15个月的研发过程，在所有人的身上投入大量的金钱与努力，并假定每个人都可以把这个企划完成（这个情况有没有让你们听到擂台上的钟敲响了？）取消一个企划对士气的影响，将会随着企划进行的时间而不断的增大。不过，如果组员有进行过可行性的研究来查看技术与可玩性方面的需求，那这个伤害就可以降到最低：每个人都可以了解他们做的是一个企划的研究，看看它是否值得尝试。如果最后的结果是可行，则所有人都会受到鼓舞。不过，如果所有人都做了各方面的可行性查核，但最后还是有机会被取消时，效果就没有那么好了。 

人们的天性是在舒适安全的位置上时，工作表现会更好。当然了，一个企划早夭的风险还是无法全面消除，但是它至少可以藉由在进行时，早点解决任何主要的问题把可能性降到最低，而且要在大量的金钱与人力投注到这个企划前完成。否则，您不只会失去您的金钱与时间，您还会失去人们对您的尊重。 

  

案例研究12.2　取消企划的代价 

为了保护无辜与那些不见得如此无辜的人们，下列的人名、公司与产品都已经全面改写。 

在一个与热门《Cryptlnvader》系列发行公司，也是Y公司的总裁――司诺先生的会面中，他声称Y公司最近大约中止了十个企划案，这些都是在做了六个月之后　，结果无法达到预期的东西，而这些企划案已经进行各种不同阶段的研发，而且都在上面砸了不少钱。 

司诺先生说，这样的作法是为了保证他们推出的软体都具有高度的水准，听起来很有商场上的味道。据司诺先生表示，这些企划取消的费用（包括《Fatal prison ll》），每一个企划都将近在￥160000到￥720000之间，对他而言这并不算是大问题。有些人可能会说，如果您有手中这么多Y公司到处投注的钱财，那您也看不到什么东西叫做问题。不过，如果您考虑到这笔钱可能全部用在资助四个其他的企划（如果早期的原型阶段执行的很好），那这就是完全不同的光景。这种努力的浪费不只在金钱上面很可观，而且它也不利于研发小组的士气（可能有上百人）。 

  

在案例研究12.2中，企划案中止于不同的研发时程。幸运的是，其中有些仍然在原型的阶段，所以不会花太多钱；就算如此，￥150000美元花在一系列的原型上面，仍然是一大笔金钱。在现实中，我在一个原型上面的金额不会超过￥75000，这只是看您如何定义（原型）这个字。在这些案例中，［原型］并不真的是指传统的字面意义，而是完整研发游戏的部份研发版本。在大部份的状况下，这个游戏将会以普通的方式开始研发，而且在主要的研发中，分离的原型并没有什么效果（的确如此）。在这些例子中，原型的程式码是真正游戏所用的程式码。 

不过，一个［原型］的意义是这样的：快速而可丢弃。这是一个测试点子与概念的动作，所以不要与科技研发搞混了。原型阶段的用意在于研究出游戏概念的可行性。在这个阶段的结尾，需要的科技应该已经完工（或是找到可以取代的方式）。这并不象它听起来那么限制良多，因为这些元件将会在标准的介面中研发，如果（或是有时）一个新的科技在真正的企划过程中研发完成，这个新的元件也可以在后期把它插入正确的位置。 

这个原型甚至不需要以编译式语言来撰写。通常一系列连续的原型――从纸笔进展到高等级、快速研发的语言（象是培基语言）――都足以测试这个粗糙的概念。不管怎么说，它是一个原型，又不是完成的产品，而且如果它与最后的产品是用不同的语言来撰写，那就可以断绝将［原型］当做［完成产品］的所有可能。 

把原型的程式码放入正式产品等于在调制一场灾难，因为通常在定义上面，一个原型并不具有［产品等级程式码］（译注：真正成品所用的程式码，以下称为［产品程式码］）的特性。这不只是程式码写得很草率，还包括了写原型时编写程式码的优先程度。举例来说，游戏执行速度并不是在原型程式码中的第一条件，但是在一些产品程式码中却是最优先的事项。不要低估把原型程式码放入完整产品的诱惑，那种节省时间的期望相当于一个危险的陷阱，通常导致的结果是显著的时间延迟以及后期产生的大量问题。所以，把原型的程式码用在产品程式码是一个不值得尝试的举动，这不但是一个不可能完成的工作，而且甚至有可能阻碍原型的研发。 

在表12.1中的里程碑时程表试图包括上述的所有要点，并包括企划的初始阶段，一直上溯到可行性的研究。 

下列的部份，包括了这些初始里程碑的详细说明。 

  

查核点1.0　一般性必须物资的收集 

这个查核点中应该回复下列的问题： 

  

企划是什么？ 

很明显的，它是一个游戏，游戏的元件，或是一个有助于游戏生产的工作。但是哪一类的游戏？目标的客层是什么？为什么会让他们满足？游戏的什么地方、以及这个游戏如何与公司的远景契合。这些问题的答案，有助于集中这个企划的焦点。 

什么样的游戏要写出什么东西，应该不会有什么问题。举例来说，应该探索游戏的外观及感觉，还有在一般层级中，所有其他足以影响游戏的主题和考量。我个人很讨厌使用［任务说明］这个字眼，但如果我写的任何企划包括了这个字，那这就是需要定义的地方。 

  

［顾客］期待的是什么样的功能？ 

在这个案例中，顾客可以定义成好几个不同的层级。第一种顾客是公司的管理部门，第二种是发行公司，第三种是媒体，而最后（希望不是最少的）一种是购买的大众。 

每一个群组的顾客必须特别迎合他们的需求，而且很麻烦的是，他们的需求与想要的东西都不见得相同。每一边都可以证明他们具有同等的重要性，所以要让所有人高兴就很难平衡。举例来说，管理部门与发行公司可能要示一个正式的展示，以及间歇性的推出先睹为快或是展示。媒体会需要游戏的远景，而且购买大众要的是完成的产品！这些需求都要先行预期，并放入您的时程表中（至少最后一个少不了）。 

  

需要的最小功能是什么？ 

很让人惊讶的是，最小的功能正是最重要的考量。虽然我不想去研究这种灰暗的想法，但是研发时还是要了解它；如同真爱一样，从来不会象预期般平顺。从企划的最早阶段，就必须定义数个功能上的阶段（这些将在第14章中介绍，并在第三部做进一步的讨论）。 

最低的功能阶段定义了最小的需求：也就是软体已经［有足够的完成度］然后可以发行到市面。在这个时候的游戏可能不会特别好，但至少它的核心可以运作。达到这一点是时程表的主要目标，一旦这一点成功的抵达之后，进一步的功能就可以一阶段一阶段的逐步加入，直到理想中的功能出现，然后产品才能发行。当然了，如果企划碰上了任何延误，它可能需要的是在所有想要功能加入之前把游戏推出去。在这种情况下，您会很高兴您采用的是阶段性的方式。 

在这个阶段中，您得收集所有与企划相关的必备物资，这可以让您在整个企划中，成为一般性的指导方针。 

这个阶段必备的是游戏提案文件，如果第一部所定义的一样。它的要旨是一份小小的文件，描述了游戏给人的主要感觉，以及它背后的所有点子。 

从这个初始的提案，您可以研发游戏设计文件，如同在第一部所示。一旦游戏设计全面规格化（80/20规则的发展主题！）那它已经提供了足够的力量，可以进入下一个阶段。 

  

查核点1.1　技术性必须物资的收集 

这个查核点中必须回应下列的问题： 

  

需要的是什么技术与过程？ 

最理想的状况，是在您拥有所有元件的情况下进行研发。接下来这个问题就比较容易回答了，如果您没有需要的元件，他们是不是可以在一定的时间中轻易完成，还是需要进行研究，才能把定义出来的功能写好？ 

如果需要研究的话，那这个企划就不能跳过原型的阶段。很重要的一件事是，必须把它一直延期直到研究完成为止；只要您打破这个规则，您就在承受一个不能接受的风险。记住这个研发过程中的物件，已经尽其可能的把风险降低。不依靠研究而硬性认为可以在固定时间写好，相当于损坏所有已经在进行的方式。千万别做。 

如果您确定要研发的技术是可行的（您现在有了应变之道），那您可能想要继续研发出一个原型。一个应变的例子是，在您想要运用所有硬体支援的3D画面之前，先写好一个以软体运算的3D程式。就算硬体支援失败了，您还是可以运用软体引擎，虽然有点麻烦，但至少不会让失败成定局。不过，您应该小心的步步为营。 

  

查核点1.2　资源上必须物资的收集 

这个查核点中必须回应下列的问题： 

  

企划中所需的资源是什么？ 

针对这个企划，准备一个您目前尚缺的所有软体以及文献列表。 

在这方面不要太热衷；否则您可能连厨房的流理台都列了出来。相反的，理性一点。您的预算可能很有限，而且根据墨菲定律，只要您用掉了您手中的预算，就会推出一个主要的软体，而您一定买不起。 

====================未完！请继续看下去！=================

以下是一些建议的东西（以及例子）： 

＊编辑器（微软Visual C++） 

＊自动侦测错误的软体（Numega BoundsChecker） 

＊侧写程式（Numega TrueTime） 

＊资源控制软体（微软Visual SourceSafe） 

＊时程管理软体（微软Developer） 

＊文书处理软体（微软Word） 

＊3D模组建构程式（Kinetix 3DS Max） 

＊2D绘图软体（Adobe Photoshop） 

＊格式翻译软体（Okino Polytrans） 

  

（这个列表中的东西，只是以我最熟悉的软体来进行建议，也是目前的研发公司最常使用的东西。这些软体中有些可能很贵，尤其是在预算有限的状况下。幸好仍有其他的选择，而且在本书附上的光碟中，也提供了一系列的免费或是共享软体，或是您可以在哪边搜寻的建议。您可以在附录B找到与软体相关的详细内容。） 

  

血腥的尖端科技 

您想要一些有用的建议，或是从痛苦中学到的一点点经验吗？那就是绝对不要用最新版的软体，直到它已经推出一段时间为止。如果您在一个企划半途转换版本，它也会造成延期。另外，如果事情进行的不顺利，把软体版本［倒转］回去将是一个很花时间而且很昂贵的工作。他们叫做［血腥的尖端科技］，自然有其道理。 

  

查核点2.0　一般可行性研究 

这个查核点中必须回应下列的问题： 

  

这是一个有价值的企划？ 

您应该开始探讨游戏性与故事，并把它打磨光亮。很明显的，这并不会马上定案，而是倾向在研发过程不断的调整与变革；这是把旧点子挥去，并加入新发现、好点子的时刻。 

在这边要提出一个警告：小心特色四处蔓延。很多游戏之所以延期或是取消，是因为低估了加入的特色。特色的潜行，以及它的预防方式，将在第三部中讨论。 

  

这个市场准备接受这个游戏了吗？ 

这个游戏是否适合目前的市场？这并不表示游戏应该毫无新意，只是模仿市面上已经有的游戏（如果真的这样，那您就要重新考虑这个企划。有太多的公司生产出没有新意而且毫无生机的游戏，用不着您再加上一笔。回到第一步，直到您有更具启发性的点子！） 

好，假定您还在这边，那您的游戏设计也通过第一道酸碱测试。下一个问题，是这个游戏设计到底是个全新的类型，还是目前类型的延伸。如果是一个全新的游戏，那我会建议您研究一下市场是否能够接受它。在刚开始时，试着询问一群中立、对游戏设计有不少批评的人们。问问他们这种游戏会不会想玩，并询问他们喜欢与不喜欢的部份。这边最重要的是得到诚实（虽然一向都很唐突）的答案，然后排除掉家庭、朋友与同事的意见。一个最常见的建议是，设计一个您会想玩的游戏；这本身并没有什么问题，但是您冒的最大风险是把游戏做成只有您要玩的东西。当然了，您必须设计一个您也想玩的游戏，但这绝对不能成为您的指导方针。 

如果游戏是以现有的游戏做延伸，那上述的建议仍然有效。除此之外，试着去定义您的游戏如何加强这个类型。一个最传统的范例是Valve的《战慄时空》，一个第一人称射击游戏，是以《雷神之鎚2》的引擎来建构的。不过，它在1998年成为最佳游戏时，也有许多竞争者在同一时段上市（象是《原罪》与《魔域幻境》）。《战慄时空》慎思熟虑之后，在这个类型中加上了强而有力的故事、敌方不可思议的人工智慧，并十分小心的建造游戏中的环境。在《战慄时空》中，通常每个面前的问题都有二种解决方式：您可以用强大的火力轰进去，把眼前会动的东西统统杀光；或是您可以想想下一步怎么做。这是一个极佳游戏性的典范（不过，这个让人思考的元素在接近游戏尾声时似乎越来越小，要过关靠的是更为快速的反应与大量的弹药）。 

当您考虑到推出一个既有的类型时，试着在现有的内容中加强，而不是遵循传统的［更多的武器、更多的敌人、更多的爆炸］途径。举个如何不去扩张既有类型的例子，看看即时战争的类型。在1998年12月，已经出现了停滞的现象，只有一些明珠（象是Blizzard的《星海争霸》）可以在这堆垃圾中增加一些新的东西。 

运用您的想象力，试着开拓每一个可行性，来收集设计的点子与意见。一般可行性的研究是在一场研发过场中的最后重点，而重新建造主要的游戏设计，可以在便宜而有效率的情况下完成，所以在这方面要全力以赴。如果一个想法成不了气候，不要害怕丢掉一个研发内容中的争执。这可能会因为参与的人员与内部政策而更加的困难，但是最好在这个阶段承认个人的失败，而不要推出一个差劲的游戏，然后伤害到公司的形象（这会在大多面前承认您的失败，包括您让一个失败的游戏设计成为漏网之鱼）。 

查核点2.1　技术可行性研究 

　　这个查核点中必须回应下列的问题： 

什么是效率方面的需求？ 

一般顾客的电脑设定与等级，是否该纳入游戏可行的技术需求范围？ 

游戏研发者的运气很好。他们通常使用最好的装备、最快的机器，以及最新的硬体；在这样的硬体上面，游戏跑得象在飞一样。而一般的使用者，当然了，就没有这么好运了，而且他们通常用的是普通的机器。研究显示出顾客大约每隔一年就会买一台新的电脑（这通常是因为领先的游戏，一向需要最新而且最好的硬体）。您的一般顾客可能会在二到三年的期间换一点PC，同时提升各方面的性能。这本书在我的许多电脑上面撰写，其中一台二年之久的Pentium 200 MHz MMX，我还觉得很好用。我觉得没必须升级到Pentium ll这种怪物级的电脑，在成为不可或缺的设备前，大部份的普通使用者也没有这个必要（译注：本书出版日期是1998年，以现在的电脑水准而言，想买台Pentium ll只有到古董去找了）。 

当您选定了基础等级的机器后，您应该估算的是二到三年以后的技术，并用此来推算未来这个基础等级的主机成长到什么程度。如果您指的是更高等的基本配备，那您应该有一个很好的理由（举例来说，您是ID Software，正准备推出Trinity程式引擎），或是接受销售上面可能出现的损失。只有最尖端的游戏才能将基本的设定向前推到另一个新的标准。一般来说，在常见的研发时程（18个月）之后，今天尖端的机器可能只是产品发行时，只能称为中上等级的电脑。 

  

查核点2.2　资源可用性研究 

查核点1.2定义了企划所需的软体以及书藉。而查核点2.2的目标是合并早期几个查核点的结果，并选择企划群组中的初始人员（如同第11章中定义的）。如果可能的情况下，企划群组应该选择的人员，尽量以该企划内容范围技术最好的人为主。这个小组的大小视企划而定。一个小型企划中用二到三人的规模十分合适，但是更大的企划就需要更大的群组。虽然这一点似乎很明显，但要指派一个企划中的人员，一向比它外表看起来复杂得多：一个群组人数太多，您冒的就是效率不彰并有额外费用的危险：人数太少则冒的风险是小组人员工作过量，并会造成延误。主要的观念就是第一次就把状况平衡过来。在后期再来变更这一点，通常会更为困难，而且要花的钱也更可观（在第21章会更详细的讨论这一点）。 

在查核点1.1中将会决定进行企划之前是否要先进行研究工作，然后这个时刻也是决定您要不要开始研发这个企划的相关内容。如果答案是否定，这就是这个企划的结束。难以下咽吗？您可以看看好的一面：很可能现在要做这个企划早了一点（您至少要等全相萤幕出现在市面上并人手一台，才能做一个用全相萤幕来玩的游戏吧？）所以它可能在往后才有一鸣惊人的时刻。不过，请记住这个游戏应该还是以游戏性为主，而不是以科技为优先。不然我们不会叫它为游戏。 

如果最后决定要进行研究的话，那这个企划将衍生出更多的研究企划。查核点3.0与3.1（后述）仍然可以进行，但是从这边开始，我们就得等候企划研究的成果（这些已经在第11章中讨论过，本书后面会再提及）。 

  

查核点3.0　结构规格草案 

第一件要了解的事，就是结构是一个不断演进的怪物。除了一些研发产业中的人员持续的主张以外，在一个企划开始进行之前，把整个结构全部定出来是很重要的一件事。我们的老朋友――80/20规则，又再度昂首了。 

在合理的预期之下，我们顶多只能在一个企划开始时，完成大约80%的结构；而这个结果可能会让大部份游戏产业的研发者大吃一惊。虽然在游戏产业以外比较容易看到一个企划定义到这种程度，但这些都是会成功的企划，而且很受欢迎。一旦结构的完成度觉得将近有80%，企划就可以开始了。剩下的20%会在企划过程中完成（剩下的20%通常包括了无法先行处理的东西，这部份在第三部将会进一步的说明）。 

  

查核点3.1　企划开始 

这个完成度80%的结构，已经足以安排初步的行程表了。工作将分为逻辑模组，并以合适的方法分给所有的群组。这个模组将会在小组之间打碎，成为更进一步的时程表。这个次级的时程表会再分散成一系列的独立工作，然后指派给独立的成员。 

研发是一组复杂的独立工作，需要进行组织化才能缩短关键路径的问题。这些工作的分析以及企划管理时间相互依赖的主要部份，将影响到整个研发过程。与结构一样，时程表也会在研发过程中不断的更新（这可能包括调整每个人的时程表，并在组员之间交换个人的工作）。重点是不断持续的追踪过程，将会在企划中不断的进行；而不是在碰上问题时才来追踪。如同我们将在第14章解释的一样，解决疑难杂症的最佳方式是靠主动，而不是预防。 

研发过程在这个阶段犯下的经常性错误，是把行程表当做刻在石头上的东西；而且这个概念在游戏产业中占了大多数。如果您好好思考一下这个问题，您就会了角这有多荒谬：怎么会有任何人可以预测接下来的18个月时间中，每一个人的工作内容？通常只有在紧急的情况下才会变更时程表：在整个企划陷入危机时的主要调整，也是［太少，太晚］的例子。 

如同在导引一艘船一样，您可以在航行中不断的变更微小的角度，以更好的方式来导引这艘船，而不是靠近目标再做一次大调整。 

  

下一步 

在这个阶段，企划已经准备起跑了，所以您需要考虑下一步该怎么走。 

下一个部份解释了如何在企划的剩下时间中，定义出里程碑与查核点。 

  

定义里程碑 

一个常见的游戏企划可以分割成数个不同的子企划，这每一个子企划将会逐步具有［企划间从属关系（interproject dependencies）］与（更精细的）［企划内从属关系（intraproject dependencies）］ 

对企划常见的错误是把它们想成等大同尺寸的东西，然后假定里程碑亦是如此：一个二次空间的列表，可以让您在里程碑A到里程碑B之间，把您目前的进展画出来，依此类推。您应该要了解的是，这个列表事实上是碎裂在多次元的网状从属关系中。当这个网折叠成一个直线的列表时，您就失去了所有从属关系方面的资讯，而且在所有的从属关系中，只有最后的结果还看得到。这会降低整体的弹性，所以能让这些复杂的从属关系处于可见的状态，而且不断的更新内容才是好的办法。 

试着从少数列出来的里程碑，来看清这个复杂的网状资讯，可以比喻成尝试从一个投射出来的影子，来创造一个复杂的三度空间物件。在影子中已经失去了一些原物件的幅员；结果过程中将失去重要的资讯。所以您可以看得出来，在进行安置里程碑的工作时，取得企划从属关系的资讯是极为重要的一环。 

第一步是发现并定义出这些从属关系，来为每一个子企划创造出里程碑的时程表。在这个方式下，一个多层阶级性结构的企划图表，可以从此研发出来。记住，一个企划是一个庞大而复杂的问题，而且处理这种问题最明显的方式，就是把它打散成数个较小――而且比较简单的问题。画出一个阶级性的企划（并包括子企划以及他们的相对元件）有助于您得到一个较好的整体画面，是您和您的小组可以参考的。 

在图12.4中显示出一个我使用的全面阶层性图表。您可以轻易的自定这个表格，用于其他的结构上，但它基本上是用来快速了解一个企划在阶层结构中的位置以及状况。在公司的内部网站中放置一个这样的表格，如同第11章所说明　的一样，也可以在每部份的相关元件上面加上超链结。由于它是一个阶层性的图表，它也连结到较大的阶层，象是连接公司中所有企划后，有助于定义出未来研发的策略。在取得从属关系并创造出阶层性的图表后，您手中的知识可以轻易的看到整体的画面（指公司远景），然后决定如何取得已有的资源，并减少不必要的努力。 

主管在这个图表公诸于大众后，得到的好处是有效的消除掉公司之间沟通的障碍。每一个小组中的任一位员工，都可以明确的知道其他小组人员在做什么事。这些资讯拥有高度的扩展能力，如果必要，可以再钻研得深一点，让整个企划的所有进展可以让所有人轻易看到。 

在图12.5中，显示出《Balls!》企划的阶层性图表。 

您现在知道庞大的企划需要打碎成里程碑。这通常在明确定义出功能之后变得十分困难，但是避免让里程碑成为鼓励大家走近路的诱因是十分重要的。相反的，里程碑应该定义在结构点的附近，才能让这些解决方案保持了结构上的完整。 

要更了解什么原因造成了良好的里程碑，我们应该注意一个什么会造成差劲的里程碑。 

  

差劲的里程碑 

无法提供企划进展任何相关资讯的，就是差劲里程碑。这些里程碑可以用模糊来形容，也可以是指定了表面的层级，但什么内容都没提到。 

  

徒具表面性的里程碑范例包括： 

＊写一个Visual Basic关卡编辑器来设计世界。 

＊将图象引擎转换为32位元。 

＊将二个图象系统整合，所以我们可以同时在画面上看到二者的存在。 

＊做一个可玩的关卡并执行看看。 

＊做好了五个可玩的关卡。 

＊进入最初的测试阶段。 

  

这边列出的里程碑是出现在现实生活，从不同企划中取材的里程碑。有些一看就知道很差劲，但其他并不太明显。我会一个个拿出来解释，并说明其中的优点、缺点，以及这些里程碑应该如何指定。 

  

［写一个Visual Basic关卡编辑器来设计世界…］ 

这个里程碑（与案例研究12.1中所示的一样）是为了一个飞行射击游戏所设，要求提供碎型几何产生的地形。这个里程碑太过于普遍；它并没有提供足够的资讯。这个普及的里程碑应该改成下面这样的东西：对Visual Basic的关卡编辑器，实行初步的物质收集以及可行性研究，来决定它是否符合我们游戏的世界设计。 

从这个地方开始，一个行程表以及一组以结构为基础的未来里程碑，就可以逐步完成。 

  

［将图象引擎转换为32位元…］ 

这一项真的是表中比较好的里程碑。完整的说明是要把所有的16位元的C语言与组合语言的模式，从16位元的结构进化，才能利用32位元处理器的全部优势。这没有什么大问题，事实上，它十分的清楚而简明。 

不过，这个问题是涵盖了太大的工作区域，而且没有指明转换码的等级在那边。举例来说，16位元的程式码只要简单透过转址层的运用，就可以从32位元的程式码来呼叫16位元的功能，并控制所有需要的转换过程，这也是一种［转换］。另外，这个里程碑也可能代表从头开始撰写所有的程式码，让整个引擎都在32位元的架构下。所以我们有二种解决方案，每一种都有它的优点与缺点。利用转址层的好处在于可以快速而直接的实施，坏处在于额外而全面性的Layer是每一个功能呼叫都需要用它来转换变数与回傅值，而且事实上这些程式码仍然不是全面的32位元（所以很多可能使用慢速的记忆管理呼叫，在16位元的限制下面动作）。 

第二个方法的优点在于，只要能达到这个目标，所有的效能都会提升。主要的缺点在于这种转换工作通常要花量的时间。 

这个里程碑应该以不同的转换来做为说明。事实上，也有另一个可能是不要把所有的程式码统统加以转换（举例来说，只有最耗时的程式码才有转换的必要，而其他的程式码――象是载取资料的程式码――大可运用转址层的方式）。 

这个里程碑应该分成数个较小的里程碑，以各个不同的模组来完成这个工作。这样做可以让您对于如何进行转换工作做出更合理的决定，而且也可以彻底的增加进展的可见度。在现实中，这个里程碑从雷达上面直接消失了将近四个月之久，才又被人找出来进行。这很明显是一个难以接受的风险，所以才会有查核点的设计来解决这方面的问题。不过，在这个案例中我们的运气很好。程式设计师在这方面的能力足以胜任，而且对引擎的了解极为透彻。不过，这种对单一组员的依赖，是一件很糟糕的事情（如同第11章所示）。 

  

［将二个图象系统整合，所以我们可以同时在画面上看到二者的存在…］ 

这个问题与上二个十分类似：并没有提供足够的的资记讯。不过，这个里程碑中包括了二个复杂模组的原始码整合（表示在二个引擎之间有标准化之后的资讯在流通），所以必须先定义出二者之间的界面。这个里程碑以自己的角度描述了整个企划，而不是一个庞大企划的一部份工作。 

想想您要执行这个工作时，要做什么样的步骤。首先，您必须分析出每一个引擎输出的资讯，才能让二个引擎同时作用。哪个引擎是主要的？要把其中一个当做另一个的次程式吗？他们之间要如何互动？他们要共享萤幕的暂存区吗？什么样的变更，才能让引擎使用萤幕暂存区？如果在另一个模组中使用，会产生什么样的冲突？这在未来与其他模组整合时，又会有什么样的影响？ 

利用这个章节中的指导方针，您已经能够想象如何列出里程碑和查核点。藉由把问题分解成原子的厚度，我们可以增加可见度与企划进展正确性的指标。这个点子是以足够的问号去攻击现有的问题，让软体规划师的意图清晰可见。 

  

［做一个可玩的关卡并执行看看…］ 

这实在太模糊，事实上完全没有用。究竟什么东西叫做［可玩的关卡？］ 

我甚至无法想象这个里程碑有什么用处。这并不是以任何技术或结构为基础的查核点；它反而象是一个用肉眼来查看的图表进度，象是一台自动机械，以精密的观察车身来检查您的车子。要真的知道里面的东西如何运作，他需要打开车壳，看看引擎的运转才对。 

象这样的里程碑就会鼓励人们走近路，以取得可见的结果。需要肉眼来查看的里程碑（象这个例子）就是一个倾向挖墙角的作风。还有，您又如何预测这样的一个里程碑，要花多少时间来完成？ 

这方面的明显解答，是完全不要使用这一类的里程碑。让视觉效果做为一个里程碑的结果，并不是里程碑的作用。 

从这个例子中，可以得知的结果是：里程碑是以结构为目标。完成里程碑的复合效果，将是一个可玩的关卡。 

  

在这种情况下，下列的里程碑可能随着这一点而达成： 

＊如果完成了关卡编辑的软体，开始载入并转换关卡的档案，成为内部的资料格式（包括所有待续的参考物件资料档载入，以及任何未知物件的控制）。 

＊以载入的资料档案，正确显示出关卡，包括任何未知物件的控制。 

＊完成以摇桿或是键盘来进行的使用者界面控制，包括以设计文件与基本玩者控制的简单选单，其中包括了结构文件中的物理系统。 

  

这当然不见得每一个都要达到，但是它应该可以给您一些粗糙的点子，让您知道创造一个里程碑时，二者间的不同之处。 

  

［做好五个可玩的关卡…］ 

这个里程碑是沿着上一个而来。这个点子是要确保软体可以载入一般定义的关卡（而不是锁死在上一个里程碑的单一测试关卡中）。 

不幸的是，结果是比前一个里程碑，包括了一般假设情况下更多的硬性规定；主要是因为程式设计师可以看到他们必须在有限的时间中，把他们与下一个里程碑之间的东西清掉。所以他们会运用他们眼中的所有捷径，来冲向原来的里程碑。不用说，这样做以后有许多程式码得重写，而这些程式明明在第一次就可以写好。 

这个里程碑应该是结合之前的目标，然后以技术上的目标分成数个较小的查核点，让最后的结果可以载入游戏的关卡。 

  

［进入最初的测试阶段…］ 

这个里程碑讲的不够详细。什么叫做［最初的测试阶段］？我们如何在进行整企划、标准的研发与整合测试中，分辨［最初测试阶段］？ 

在这个阶段我会把［最初测试阶段］定义成所有的元件都处于［界面完成］（所有在这个企划中使用的模组，都完成了界面的设计）。这不只是个明确的进展，而且至少所有的元件都可以进行编辑，不会出现链结错误的状况。很明显的，在这个阶段中有特定等级的功能列表，但是――看到研发以一个方式不断的进展，如同本书所述一样――它也很可能会有一个很有用的核心功能。 

  

为何这些里程碑有瑕疵 

这些范例中举出的里程碑，最基础的问题在于它们的模糊性。大部份都没有清楚的指明，而且它们可以用许多不同的方式来达成。捷径可以采用、所以在企划附近会不断的繁殖错误与误解，并越来越庞大。 

如同之前声明一样，这些范例中的里程碑用来当做企划的导航点并不会有问题，但是它们留下了大量有待详细说明、又可以完成的里程碑。它们需要分散成几个较小的里程碑，每一个都只有二进位基准：开启与关闭。 

下一个部份包括了如何定义出较好里程碑的方法。 

  

良好里程碑 

在看过差劲的里程碑之后，我们现在把注意力转向如何让里程碑变好。很多这方面的成果，可以靠之前讨论的差劲里程碑加以推演（如果不是坏的，就一定是好的）来获得，所以我们只要把良好里程碑做一个总结就行了。 

一般来说，一个良好里程碑不会留下产生怀疑的空间。它会很清楚、合理、以技术与结构的角度来说明，而且它是二进制：要不是全面完成，就是全面未完成。 

良好里程碑应该详细的进行说明。每一个应该说明的极具深度，尤其是目前进展的是企划的哪一个部份。预测不应该以充满期望的想法为基础（很严酷），真正的研发时间上的预期是以经验为底子，而不是市场上的需求。要在圣诞节之前生出一些东西并不重要，您无法变更物理定律，而且您也无法变更写出良好、严密程式码所无原则的时间。不过，您可以试着进行预测并排好时程。这样做要比在程式码硬冲或是设定独断期限的赌局，来得更容易成功。 

良好的预测是从创造一份阶层时的图示，来追踪整个企划以及它所有从属东西开始，然后从头到尾去追踪一条平面的路线，将路上相互影响所造成的延迟最小化。良好里程碑中必须指明技术等级，而每一个里程碑或查核点都要说明结构模组与次模组的完成阶段。这可以让里程碑更加鲜明而且定义清楚，也可以提升企划的可见度。为了正确的预测一个里程碑所需的时间，您必须把里程碑分散成数个次要工作的列表，小到您可以合理而正确的估算出完成它们所需的时间。这通常表示把工作打散之后可以在一或二天的时间完成，提供良好的次级里程碑与查核点（如果需要的话）。这是一个很需要技巧的过程，当您在预估的过程中获得经验之后，您就会发现它成为较容易分散的里程碑，并可以让您做出精确的预估。 

一个良好里程碑可以强化企划的可见度，而且在完成之后，可以让一个人拥有完成这种工作的微妙感觉。 

  

案例研究12.3　一个真实的里程碑 

《Balls！》是一个为本书撰写的展示用企划，主要是用来证明本书所有的研发方式与概念确实可行。 

这个案例研究是检视企划中使用的一组真实里程碑，并详述它是如何分割为查核点。它本身会展示出如何实行技术上的里程碑。 

里程碑： 

概要：实行一个物件层级的Z暂存区，藉由减少不必要的画面贴图，来增加画面的更新速度。 

备忘录：在朝这个里程碑迈进时，要容许退回标准的绘图运算法则，并考虑目前用来环绕所有Z－暂存区程式码的假定编译指令。当这此些指令都完成定义之后，Z－暂存区的程式码会启用，否则这个程式码会采用以前的方式来运作。 

查核点1.0.采用标准的测试层级并启动计时的程式码，以计算每一个画面的绘制速度（0.5天） 

查核点2.0.将物件分类成数量最少的组别。每一组应该包括这些物件，在平面画面的座标一样的时候，全面重绘其他的东西。旗标将成为这个规则的例外（举例来说，不应该让透明物件背后的东西看不到）。为每一组物件提供分别的Z－暂存区（1天） 

查核点3.0.对每一个有效的种类进行Z－暂存区个体（Member）的［查核］与［设定］。每一个游戏物件必须拥有这个个体，所以在实行时可以将它们看为画面物件资料库中的纯粹真实个体。提供一个标准的运作，把一个点带入特定物件组的Z－暂存区中，设定一个阶层越高越好的参数，并在必要的时候让这个特殊的案例失效（象是透明的物体）（1天） 

查核点4.0.在基础等级的［Prepare To Draw］与［Draw］个体中插入Z－暂存的检查与设定。在这个阶段中尽快针对失败的Z－暂存区进行测试，让不需要显示出来的物件，只要花最少的工作量。（1天） 

查核点5.0.为测试关卡生产新的计时资讯，并与查核点1中的结果相比对。全面更新模组设计文件来反应这些变化，并插入新的计时资讯（1天）。 

这是一份直接的里程碑与查核点副本（虽然编写得有点简单）。我已经变更了查核点1，如同它也考虑到回顾并整理这些程式码，来确保所有的说明都是最新撰写，而且所有的不良程式码统统移除（因为我有一段时间，没有参与特定模组的工作）。这边并不是我们要考虑的，但是它会让时程表再多花上一天。 

在案例研究12.3中，这个特别的里程碑在结构定义之后，已经被插入了一个里程表。这是一个结构上的变更，才能在速度较慢的显示卡上面，增加系统画面更新的速度（在这个变更中，有20%的结构无法得知或是猜测）。如您所见，这并不象一般常见的企划里程碑，因为它是以结构以及常用的英文，以减少技术方面的专用术语（如果这边用了专业术语，要解释起来就容易得多）。 

  

由于一个示范企划中具有高度的模组化本质，这个里程碑通常以二个星期为一次，而查核点大约是二天一次。 

  

研发与期限 

在这个阶段，我们偏离一下主题快速讨论一下研究里程碑，是很有价值的。 

让我们先把话说清楚：研究里程碑是一种矛盾的说法。 

一个期限说明的是固定的日期与时间，由一个小心而充满考量的工作之下所假设出来。从另一个角度来看，研究是一个探索未知事物的举动。要如何正确的为不知道的事情，来正确的安排时间？如果不行的话，您可以试着向您身边大部份的企划管理者解释，然后看看您会得到什么样的反应。 

在这个情况下的研究，不应该与必备物资的收集搞混了。研究是一个追寻新的科技与运算法则，以实现一个点子的过程。必备物资的收集是一个靠着设计文件来找寻您所需要的东西，用来建造产品的过程。 

程式设计师的主要工作，如同前一章所提示的，就是把一组详细的技术规格转换成一个程式，或是程式模组。这并不是在职位上的研发工作，而且要在期限中完成。研究与期限通常具有独立性的本质，如果在一个企划的目前阶段需要研究，那在初始的可行性研究中肯定出了一些大问题（这些可能性应该在事前就探讨过了）。所有的研究都有风险：您的风险就是没有结果。之后您在一个企划冒着研究的风险时，表示有更多无法接受的风险随之出现。简而言之，在一个企划中，避免所有不必要的研究。 

  

里程碑的评定 

当评定一个里程碑的时候，在完成之前要有数个人签名。至少，这些人包括发行公司、原公司以及企划管理者。正因为如此，里程碑倾向于以结果为基础，可以在视觉上展现成果的时刻。如同我们之前所讨论过的，这并不是好事。里程碑的基础如果架在视觉效果上，表示您通常会看到您想要的：一个有着美丽外观而败絮其中的程式。象是湖上的天鹅一样，它在水面上表现的流畅而优雅，但是脚掌在水下强烈的拍动。这就是里程碑在游戏产业中评定的方法（或许这可以解释一些现象，象是游戏现在把风格凌驾在内容之上）。 

整个研发的生命周期是以外表的模样为基准，而不是以内在的结构。虽然这对绘图而言不错，但显然对复杂的技术工作――象是电脑程式――没有什么好处。如果这些标准用在盖桥上面，想象一下这会发生什么事：只要结构体上画好颜色之后，就马上宣布盖好了，那如果有人真的走过去，桥塌了怎么办？ 

对于那些评定里程碑的人而言，只有接受时程表必须以结构上的规格为基础，才能保有最大的利益。 

里程碑应该尽可能以科技为主，而且它代表的是目前结构状况的整合。在游戏研发中，结构是单一最重要的本质；所以，里程碑应该是以它为基础。它可以用骨骼来比喻：它需要完整的发展，否则不管上面覆盖多美丽的组织，这个生物还是会变形（如果您看过电影的［变蝇人］一、二集，您就知道我这边讲的是什么意思。真的很不雅观）。 

就算您无法在撰写里程碑时避免使用技术性的术语，也尽可能使用大家看得懂的语言。如果您很小心的撰写，就算是最没有技术能力的人，也可以了解并增加技术里程碑的好处与可见性，进而延伸到整个企划。一般来说创造者，游戏设计者，与发行公司是最重要的里程碑回顾者。不偏不倚是十分重要的，而且里程碑也应该直接从强烈的技术观点，来进行主要的评估。 

要为里程碑负责的小组人员，应该以里程碑为何要完成来看待他们的案子，而内部回顾人员却是要以魔鬼代言人的举动，试着证明里程碑尚未完成。这方面要严格一点：一个没完成的里程碑，相当于被抛诸于脑后的无味东西，将在日后以最让人意想不到而且最麻烦的方式出现（未完成的里程碑适用于墨菲定律）。 

组员必须全面了解，为什么一个科技里程碑，代表的不一定马上向前迈进一步，尤其是对不精通科技的人而言。小组的责任包括展示与说明里程碑，连办公室的猫都要能够了解其中的重要性，以及如何符合广大的计划。 

==============第十二章完！~============================

第十三章　程序与［过程］ 

  

＊程序 

＊［过程］ 

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

＊资讯传递的重要性 

＊主动与反应的资讯 

  

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

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

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

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

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

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

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

  

程序 

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

　　 

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

  

＊设计回顾 

＊文件回顾 

＊技术回顾 

＊程式码回顾 

＊单元测试 

＊整合测试 

＊系统测试 

＊设定测试 

＊后退测试 

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

  

回顾 

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

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

只是把没经过查验的工作插入企划中，然后发现没有倒塌就认为一切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应该可以解决所有硬体相容的问题。但是，如果您真的相信这一点，您真是有罪到什么东西都会信（如果您真的是这种人，给作者一封电子邮件。我们为您准备了一个投资的好机会！） 

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

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

  

后退测试 

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

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

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

  ==================未完！请继续看下去！===================

［过程］ 

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

图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图案、一个文字设定档或是其他与企划有关的东西。 

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

  

单元测试 

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

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

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

  

整合测试 

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

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

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

  

签名 

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

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

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

  ================未完！请继续看下去！====================

测试阶段 

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

  

系统测试 

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

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

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

  

品质保证 

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

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

输出：品质保证报告。 

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

  

游戏测试 

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

输出：游戏性报告 

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

  

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

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

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

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

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

  

案例研究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章中的软体工厂模型是相同的。请注意，从主要企划网页中，只留下相关的连结以保持清晰度。 

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

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

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

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

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

==================第十三章完！=========================

第十四章　疑难排解 

  

＊风险 

＊主动与反应式的疑难排解 

＊变更控制 

＊突发规划――［B计划］ 

＊公制与资讯的收集 

＊灾难重建 

  

在这个章节中，我们打算看看您的企划中，究竟有什么事会――而且可能性极大――把您搞得难飞狗跳。一般的企划只是一个单纯、等候发生的错误列表：时程表的错误、程式码的错误、过时、个人的问题与疾病――只要您想象得出来，就有可能发生，而且不要惊讶！不经一番寒彻骨，哪得梅花扑鼻香。您可以把企划安排到无微不至，但是您无法安排未知的事情。 

  

疑难排解（名词）。追踪并修正组织中的错误，等等。 

这个章节是叫［疑难排解］没错，但是所佔的大部份都是在提供建议，来预防可能需要的疑难排解。最具有成本效益的企划，是以高水准软体开始着手，而不是先建一个低水准的软体，然后再来修正问题。 

就算是在一个执行上十分完美的企划中，还是会跳出没有预料到的问题。而成功的小组与失败小组相比较，差异就在于他们对这些问题的掌握与规划的功夫。 

好，我知道您想说什么：您怎么可能不知道的事情做规划？如果您不知道会发生什么事，您又怎能先做预防来修正它？呃，说实话，您的确办不到。如果我试着告诉您另一个答案，您就知道我在撒谎。 

没有人可以看透未来，所以没有办法知道您的企划会碰上什么样的麻烦。不过，您知道有些事情必然会发生。只有最天真的企划管理者，才会假定一个企划会顺畅而没有任何麻烦的进行下去，一直到结束为止。不管您信或不信，我曾经碰到过这处管理者――我认识一位此一类型的管理者，还会去相信一个长达18个月企划，可以在9个月的时间中完成。他一直抱着这个想法度过了前面七个月，这时急得不得了的发行公司来重新审查合约，让这个问题重重的游戏，在二次续约以及一年之后才发行。 

这一类难以接受的情况，发生的次数实在相当多――尤其是在游戏产业。为什么？我相信这是因为游戏产业缺乏普遍规划能力所造成的结果。 

整个游戏产业都很不成熟。在主机的世界已经进展到进行庞大的企划，包括了广大的小组以及上百万条的程式码时，游戏产业还在拔乳牙的阶段。在今天仍然有人采用这些大型企划处于测试期时所产生出来的结果。当然，有些更会挖苦的人将把这一点，归功于把它们拔掉不如让它们继续运作来得省钱。在某些程度下可能是真的，但至少他们仍在运作！那些无法运作的呢？ 

不过，游戏不象其它有20年生命周期的产业（虽然我很确信有些设计者会喜欢这种状况），所以规划与安排时程的时候，不需要象其他方面有完整的学问。事实上，由于一般游戏的生命周期很短，象这一类有组织的施行细则并非必要。 

但是，随着戏曲开唱，在时间中产生了变化。游戏企划的规模越来越大，再也不是一个小型的工作，可以用少数的平台让单一的设计者制作出一些可以迎合大孩子口味的东西。今天，到处都是动作捕捉、全萤幕动画、电影品质的音轨、电影水准的美术，以及更多的多边形。 

有些人把游戏产业拿来与当代的电影工业相比较。它可能只是少数人无法接受他们只是软体工程师时，所发展的罗曼蒂克谈话内容：这二种产业的相似之处，在仔细的观察与分析之下不攻自破。 

平心而论，我可以看出相似之处。不过，与大部份的软体企划不同之处，在于他们比起游戏研发有更大量的艺术元素。这些特别的元素最适合的部署地点是在电影工业，而且电影与游戏之间仍然有很大的差距。电影主要是艺术――它们的确有很多技术方面的要素，但是在有所需要的时候，是靠着外来的力量来进行有效而顺畅的控制。除此之外，并不需要大量的科技研究，与游戏研发是不同的。 

不过，一个游戏企划对这些制作艺术、全萤幕动画与音乐的需求，就和电影工业不一样了，而在这方面就是模仿电影工业的重点：电影的制片通常会从外面的其他公司找寻他们的需求，而不是把规模限制在昂贵的编制内小组。 

如果游戏研发可以真的与电影工业相比，那是不是可以象电影制片一样，雇用新的工程人员、在每一个企划中安置新的摄影机、重新研发赛璐璐，并修正所有的软体？不是，今天的电影工业并不是一个好的比喻（虽然过去的电影工业，也就是技术仍然很简单的时候，勉强可以拿来做比较）。 

今天的电影工业已经渡过了这一连串的磨牙问题。它十分成熟，而且再也没有什么需要进行的基础研究。它已经完工、平稳而且撰写出相关的文件。电影工业已经达到一个平坦的区域，所需的科技稳定，而且电影画面中的［目标平台］一般而言已经很调和并不会变动。想想看：除了（应该不会错）微小程度的改善之外，电影在数十年来并没有太大的变化。 

游戏产业并无法达到这种类似的地步。科技不断的演进，所以游戏的科技从来没有稳定下来，连游乐器也不例外。看来每过个几年，就会在技术方面出现巨大的进展；这种由摩尔（Moore）预定的著名［定律］（指电脑的能力每18个月左右就会提升一倍）并没有慢下来的迹象。我并不期望目标平台会趋于稳定，虽然在一个隔离的层面下，象是DirectX，可以提供一些轻微的缓冲；阻挡研发人员马上采用新出现的科技。不过，DirectX也是年年更新，才能跟得上科技。 

我猜，如果这一切都在继续的前进，有一天就会出现一个产业标准的游戏研发工具，包括了所有需要的元件（象是图象引擎、人工智慧引擎、描述引擎），可以让完全没有技术能力的游戏设计者，直接产生出一个游戏，象是电影导演在拍电影一样。游戏设计者可以从外面取用图象、音乐，而且甚至可以购买人工智慧模组，来扩增目前正在进行的游戏设计［描述］。在那个时候，很可能有不同的包装，适用于不同类型的游戏，而不是目前任何类型演进而来的（举例来说，第一人称的3D视角，并不是一个多单位策略游戏的理想平台）。 

不过，目前的游戏研发仍然是以工程为基础，限制了艺术方面的看法。如果有任何现代的领域，可以有效的与游戏产业做比较的话，应该是建造桥樑。在建造一道桥梁时，设计图必须先画出来，工作必须按照时程表来完工，而且偶然的规划必须十分严肃的进行。当然了，盖桥与游戏研发的不同之处，在于桥梁的建造者如果不够小心，可能会影响到其他人的身家性命。 

不管是盖桥或是游戏研发方面的学问，都是以［艺术工作］为最后的结果，而且二者都需要广泛的规划，才有希望在时间与预算的压力之下完成。 

当然了，如果盖桥象研发一样，可以让负责的人员突然丢下他们的工具，成为桥梁的设计者，那什么桥都盖不成。您可以想象一道桥梁在建造时集合一百个工程师，每个人给几百吨的金属和一些工具，然后在完全不规划的情况下叫他们开工，只让他们知道这座桥盖好时长得象什么样子，然后含糊的告诉他们桥梁要延伸到河流另一边的什么地点吗？这是［地狱建筑］学校中的盖桥法吗？我不这么认为。这种方式从黑暗时代之后就没人用了！或许，如果游戏研发中的一项要素是人的生命，那就会比较注意一点！ 

不管怎么样，您可以用二种常见的方式来面对问题：在它发生之前，或在它发生之后。现在，哪一种比较好？ 

虽然我真的很想在这方面撒谎，我必须承认要预测并事先看出所有可能出现的问题是不可能的；老实说，这种方式也不值得建议。要面对着资助者解释［为什么偶尔落下的流星刚好把他的钱砸得一干二净］这件事，对一般的企划规划人员而言可能有点困难。 

管理者有时候可以了解您为什么想要在一些可能永远不会发生的事情上面花钱的原因。他们可能会称呼您为扫把星或是末日杀手。不过，您应该坚定立场。这些突发性规划行动所耗费的额外工作，将成为您企划中的［保险］。 

您应该向负责的人解释，几乎每一个企划中都有一定程度的风险，不管是过去或是今日，而且忽视掉这些教训，将是您手中企划成功的最大风险。在花费一些小量的努力，为这些问题建造可以回复的保证，您就可以彻底的增加企划成功的机会。 

在找寻潜在问题方面，最好用各个不同的观点来查看整个企划，并尝试分辨出哪边可能会发生问题。它可能是一个实验性的结构，一个有风险或是未经证实的技术、人员的短缺、资金的问题，或是其他类似的困难（这将在本章后文中详细描述）。 

这些情况不可能先行规划，必须靠着理性的方式来解决。 

有些事情实在是太奇特而超出预想，而这种现象必须纳入考量。技巧是找到这些问题的主要基础，象童子军一样，先行准备。 

到目前为止，我们已经确立了二种疑难排解的方式：主动与反应。主动式疑难排解自然比较受人青睐，但却不一定可行。反应式疑难排解通常不是最好的方法，但却不一定躲得开。 

反应式疑难排解比较常被人称之为［救火队］，或是任何表示［问题在已经浮现作乱时才被发现］的词句。在这个时候，当然了，这个问题已经影响到企划。疑难排解的有效程度视您的侦测问题能力而定，必须在它的效力太大之前把它解决。 

不幸的是，侦测这些问题通常都不单纯，而且有几个理由。第一个是因为太过熟悉而变得盲目；当您在同一个企划中日复一日的工作，重复相同的事情，眼光变得狭隘是很正常的事；有时您只是没有注意到问题在您身边爬来爬去。除非您可以在一切都太迟之前把问题找出来，在您发现的时候它可能已经大到您无法忽视的程度了。 

第二个理由与担任管理者人员的名声有很大的关系。人们愿意告诉他（或她）问题所在吗？管理者会砍杀来使吗（译注：二国相争，不斩［来使］）？这是为什么管理者的行为特质要很容易亲近的主因。 

如果这听起来象是一个您认识的管理者，那么他（或她）不知道早期发生的问题是很正常的。明显的，这是一个缺点，这不会让小组尽快把裂缝补起来，并把问题先拿出来解决。有时一个不具名的回报管道可以避开这个现象，但是这样的系统，必须看提供者的可信程度而定，因为所有人的名字都不会列出来。 

很悲哀的事情是，企划管理者在突发性的规划中并不够认真：而且证据到处都是。游戏不断的遭到取消或是延期，而且在它们发行时，通常只具有次等水准而且充满了臭虫，需要数次的更新档才能把游戏带到一个可以接受的标准，这些都是没有好好进行突发性规划的征兆。游戏之所以延期，通常是在被动式疑难排解下的牺牲品。没有办法预见问题并进行处理，而且这些问题在出现之后，就急着把它解决掉（一个比较容易了解的比喻，就是在马匹狂奔时把马廄的门关起来）。 

还有更糟的，许多管理者没有能够好好进行突发性规划，让一个企划在这方面没做多少事。事实上，突发性规划的目标在于拯救时间与金钱。藉由为另一个可能浮现的问题，准备另一个解决方式，就可以评估并准备好这个对企划的冲击。所以，这个企划才能获得回复的能力。 

这个章节的重点在于把这个悲惨的状况好好整顿一下。如果在您那众所皆知的［制作小组］真的伤害了爱好者时，这些指引方针与建议可能救不了您的企划；但至少它可以让您先蹲下来，并在事发之后沿着准备好的路线飞快逃走。 

  

风险 

当您在处理企划的时候，最重要的事情就是考虑免不了的风险。在您进行企划的每一天，您都会碰上新的风险，需要小心的监看并查核。这个部份将会给您一些提示，告诉您如何实施一些合理而实际的风险管理计划，才能尽可能的避开这些风险；并在避无可避的情况下，控制整个局面。 

在现今的软体研发企划中，风险管理（如果有的话）并没有发挥实质上的功效。这并不是说没人在考虑这件事，在不同的方法之下，普天下每一个企划都考虑过风险的问题。不过，他们通常被认为是另一个过程，而且没有指明它们的地位；通常不会有人直接去面对风险，而是采取次要的行动来处理它。 

这种方式对企划管理者与他的小组而言，风险仍然是附骨之蛆；一直到风险大到足以妨碍正常的工作时，才会直接去面对它。因为没有人去正视它，风险都是在危及另一个范围中的工作才去面对。举例来说，当一个企划管理者在安排一个时程表时，他也会查看这个时程表延期的风险，以及一定程度之下的人事问题。当一个研发者在撰写程式码时，他也在查看程式码资料库中出现臭虫的风险，并检查任何已经存在的问题。风险只有扩大到另一个区域时，才会被处理到。 

不过，从这些丰富的例子中可以看出：由于在一个工作范围中风险从来不会被指出来，到目前为止已经不知道有多少没考虑到的，掉落而穿入裂缝之中。这就是为什么风险管理的范围是如此重要，每个人都应该谇为它该拥有自己的地位。 

在您试着把一部份的企划劳力纳入风险管理时，您在这个过程中会进行得比什么都顺利。在一个不假设会出现风险的企划中，企划（以及小组）通常是以外来观察者（有时也会成为内部的观察者，然后您就知道这个企划真的碰上了大麻烦）的地位，看着一个个危机把它弄得东倒西歪，一直到所有的动力耗尽；接下来可能是跑不到终点线，或是在不幸之下懒懒散散，从此销声匿迹。 

风险管理的目标是让整个企划的路线平顺，就算是行经汹涌的海域也尽可能的愉快。在图14.2中说明了这个要点。 

风险管理是一个具有特定地位的学问，需要格外的重视；但是如我之前所说，它通常被人们所忽视。所以，您要如何在您的企划中，教导人们使用一个风险管理的程式？ 

第一件事是想出在哪边――以及如何――看待风险。这是一个实际上的工作，所以您应该严格考虑指派一个人成为［风险审查员］，让这件事成为他（或她）工作的一部份。这个职位可以每隔一个星期、二个星期或是每月，由不同的组员来担任。 

风险审查员的工作就是对任何可能威协到企划的东西保持警觉。风险审查员应该紧密的监看每一个企划的［正面］，而做这件事的好方式是不断的更新［前十大风险排行榜］，这至少应该每星期更新一次。在这个列表上应该排定风险的优先顺序，并以它们的困难程度来分级。 

在一开始由于心理效果的影响，这方面通常是正向的。这种持续找寻风险并在风险出现时面对它的现象，将会鼓舞一个小组的士气。任何可以鼓舞小组士气的事都是好事，不管这个方式是否直接。 

对每一个列表上面具有高度优先权的项目，应该决定出一个决议；而且在这个小组有可能处理并消除风险时，列为最优先的事项。在一些情况下，在面对一些更没有预期以及更极端的风险时，就有必要从雇员中组织［攻击小组］，把他们从原有的工作拉下来，处理这个问题。 

这将会是一个很吓人的提议，而且它需要以十分小心的方式来控制，才能避免让人们惊慌失措。有时候，在很不幸的情况下，这种形式的正向行动可能被视为负面的征兆。人们将不会以［有效反应企划中所需的变更］来看待这件事，可能在资讯贫乏的情况下被视为［无头苍蝇］。任何有这种反应的人，都需要再度进行教育，告诉他们您想达到的是什么目标。 

说得公平点，如果风险管理计划没有小心想清楚再实施，那它可能退化成为没有目标的攻击。如果只用琐碎而不必要的行动来处理表列的风险，它可能会让人们从企划中所需的真正工作中分神。在任何行动实施之前，提议的风险控制计划必须由相关的团队来进行批准，而影响的范围将视风险的本质而变化。举例来说，如果风险包括了改变部份的系统，那么它就会指向全面变更控制。 

风险审查员的工作可以总和成一句话：他（或她）是那个在企划每一个地方嗅出问题的人。他（或她）的效率是以挖出这些麻烦，来节省未来耗费时间、效率和（最重要的）金钱来计算的。 

下列的列表，是此类事情的范例；也是您很可能在您的前十大列表中出现的内容。 

  

企划X：前十大风险列表 

1．目前实施的资料封包编码演绎法在即时的网路上面太慢。如果我们要把它拿掉，这将导致我们的点对点网路游戏，暴露在被人入侵的情况下。 

2．主要人物的美术工作要花太久的时间。动画程式设计师被贴图数量不足，以及这些贴图的相关资讯卡住。 

3．小组被地图设计工具的延期卡在半路上。我们需要尽快开始设计新的关卡，否则我们会落后时程表。 

4．一个新版本的C++编译器刚刚出现，这需要进行分析，看看是否修正了任何我们企划中会出现问题的部份。 

5．在图象绘制模组中有一只臭虫，会导致画面在每几格之后碎裂。这并不是致命性的错误，但是已经引人注目而且很烦人。 

6．没有足够的人员来完成目前的工作量。我们开始出现工作时数不够的问题，而这对士气有不利的影响。 

7．我们目前得使用的压缩模组都是臭虫而且很难维护。在测试中已经显示出它的压缩错误率很高，会毁掉上百位元组的资料。 

8．3D绘图模组刚刚被核心小组更新，而且我们需要修改一些程式才能使用它。这方面的好处在于画面的更新更快更平顺，而且支援了最新的硬体功能。 

9．我们需要一个新的组员――这件事越快越好，才能让他开始上工。这应该可以减轻第6贴图的问题。 

10．人工智慧模组所需的测试，得在新的功能中加以更新。我们想要使用里面提供的全新的模糊概念逻辑，因为它可能有助于加强敌人面对玩者的人工智慧。 

  

并不是表上的所有要点都有价值或是值得尝试，而且它们的顺序也有争议之处。有些风险可能是风险审查员的个人意见（这就是这个职位有轮替必要的好理由之一，或者至少先在一些人身上试试看，是否能够公平不倚）。 

问题演变成哪些有必要处理，而哪些并不是主观的意见，与企划目前的状况有很大的关系：不同的优先权将会视目前的状况而一一浮现出来。举例来说，最优先的事可能是先把游戏做好；在这方面，企划管理者可能不想在这个阶段，冒险引进新的技术（象是新的3D引擎，如同3D　Realms所做的事情一样，将《Quke Nukem Forever》这个冒险的程式引擎从《雷神之鎚2》引擎换到《魔域幻境》的引擎）。某些管理者会考虑平行研发方式，其中一边使用老式的引擎而另一边用新的引擎，来预防他们下错赌注。如果新的引擎成功了，而且这二个程式库并没在过渡时期差得太远，就可以继续做下去。如果程式码资料加全面分离，那这个整合步骤就成为一个很大的风险。在这个理由下，我不会建议任何人冒这种危险。这种要保住二边努力成果的事情，只有最勇敢（或是最愚笨）的人才会做。 

不过，如果企划还没到最后的阶段，那一个新的3D引擎可能就是第一优先。在游戏的发行日期，技术已经更为行进，所以它在最新技术的支援下，将会在商场上面更具优势。推出用老式引擎所撰写的游戏，可能会让游戏看起来与其他货架上的东西差不多。任何在3D引擎方面的问题，都必须在发行之前解决掉，所以在列出这些要点时，很可能已经得到最高的优先权。 

在前一个列表中的项目，可以分组成数个类别，以他们影响的区域来分类。这些区域并非包括一切，而是包括了问题的主要部份，影响到每天的企划进行。其中有些是风险审查员找不出来的，因为他们影响的是比较高层的管理。有些人必须在公司的层面看着所有事情，但是这部份通常对管理而言不致于太困难，只是请他们把这些事情看清楚一点而已。危险的区域比较倾向企划层级，这个地方人人都在忙着手中的树苗长成森林，或甚至是挥舞着炼锯的伐木工在他们之间来去。 

下列的几个章节，将会讨论一些此类的风险，并提出他们如何证明自己能够掌控的范例。 

  

设计与结构问题 

一个企划中的程式与设计问题，可以说是最诡诈而且最难以处理的。这在每一个企划的根源与基础都是难题，而且应该在可行的时候尽快把它处理掉。 

这一类的问题具有的潜在能力，极有可能会导致企划全面修正。很明显的，这会十分的花钱，所以这将是您要极力避免的问题之一。 

变更基准的要求 

变更他们已经签定的正式需求，可以导致一个企划中的功能，在整合与契合方面出现问题。 

这些变动可以靠着数种不同的方式显露出来。有时候它们会因为小组中的人员提出了［好点子］（通常是由个性最强的人所提出，而且这些人会采用强而有力的个性，试图强迫他们的点子获得所有人的认同）。使用变更控制的会议有助于降低强势个性，但偶尔在强迫取消这些点子时，也会导致这些人不满。 

当然了，有时候有其他的理由：发行公司或是外来的组织（象是一个评议会议或是主要的发行公司）会要求变更（举例来说，要求游戏中出现的血腥场面少一点）。这一类的要求通常与财务的问题有关，象是通路商拒绝发行这个游戏，或是发行公司（也可能是评议会）会阻止发行。不管是哪一种，通常只有一个选择，就是跟着路线完成他们的要求，不管设计者与小组有多么不喜欢他们的大作被人稀释！ 

  

定义拙劣的需求 

如果需求被定义得很拙劣，它们很可能完全不符合这个企划。如果是这个状况，很容易确信的一点就是未来需要重新定义一次，才能弥补这些缺乏的东西。 

对于缺乏需求的定义与再定义，很可能增加企划的范围；如果范围真的扩大了，那它就很可能（事实上通常都会）得修正已经在进行的工作，才能符合这些新的需求。当然了，您永远不可能在进行结构设计之前定义出所有的需求，因为有些事情在您插入真正的工作之前，永远都不会知道。 

重点是至少要先定义出80%的需求，而且在任何人真正进行结构方面的工作之前，是越详细越好。最好的情况是真正进行建造的工作之前，至少要完成80%的结构与定义得很详细的内容。 

不过，有时候设计与结构已经做了最好的定义，一直到突然出现额外需求。这种情况下有几个可能，而且我很确定您可以想出更多。某些理由可能是发行公司要求额外的特色，或是一个类似的游戏已经出现在市面上，导致您［必须］有些别人没有的特色――象是让您的产品拥有一些最先进的特色（如果之前没有规划的话）。一个例子就是要加上多人连线的功能，不过现在的游戏应该都支援了。 

在这一类的情况下，通常埋头苦干来完成这个变更以外，没有其他的选择。有时候不把程式码与模组全面修正，是不可能达成这些要求的。如果这一类的修正在财务、合约或是时间的压力之下变得不可行，那这种情况的出现，通常会导致企划全面取消。不过，有时候这个状况可以利用保证推出更新档案，来修正其中一部份问题来抢救。照我的看法，这并不是真正的解决方式；它只是一个紧急应变的海市蜃楼，先把产品推出来再发行第一波的更新档，在社会大众的眼中会产生负面的效果，进而伤害您公司的名声。不过，如果二个选择分别为［先找出游戏再推出更新档］与［完全不发行游戏］，那么在100个案例中，99个（我不是在强调那个例外）会选择先丢出去再挨骂！ 

真正能够预防这类混乱的方式，就是先尝试收集您会面对的大部份详细需求，然后再开始进行结构设计，才能佔有领先地位。当您这样做的时候，其中一个用来计算不断增加需求的最好方式，是在后期指派一个工作，强迫去查看这些需求中有些什么东西，然后试着去预期往后的什么方向可能会继续延伸。这并非表示您要在这个阶段，就把这些可能性建造在您的需求之中；但您至少要好好考虑一下，让真正的规格需求有可能纳入这些特色，并将这一点转入结构的规格中。 

每一个扩张的潜在性，都应该认为有三种可能的结果。第一种是这个潜在性的需求可能十分重要，所以必须纳入实际的需求之中。第二种结果是，虽然这些需求并不重要，但它应该有一席之地，而且结构应该以可以容纳它的方式来定义。第三种结果是这个潜在性的需求，在努力完成之后也不会增加真正的价值；这种东西就是大家熟知的［润饰特色］，一个有了很好、足以加强产品的东西，但是它的成本效率太高，让您完全不会去考虑它。 

其他的问题可能发生在设计与结构的阶段，由于对80/20规则的误解（这边是指某些人宣称一定要完成80%的工作，才能进入下一个阶段）。您不可能完成整个设计与结构背后的理由，只是因为您需要的一些详细状况只有在动手之后才会知道。尝试着去完成所有的纸上工作是个愚笨的决定，因为您没有办法预期元件之间会造成的相互关系（其他的章节将会说明相关的理由）。 

如果误解了80/20规则，下一个阶段有可能太早开始。在产品说明中的模糊部份，可以预期它会耗费更多的时间来进行。 

模糊的说明会产生几种冲击，第一个而且是最重要的效果，就是行程表会受到相对的影响。如果企划目前处于很紧的时程表之下，没有空间可以进行这些事情，那就会成为严重的问题。第二个模糊需求说明的负面效果，在于可行的解决方案不一定能和系统的其他部份相容，或者甚至无法运作！在这种情况下，就有可能修正部份区域中的工作。 

在一些理由之下，研发者的天性会倾向低估他们在未来的工作时间；这些理由的数量很多。来自同伴的压力也不容忽视：可以在很短的时间完成复杂的工作，也是让人觉得很酷的特色之一。第二个考量，是管理者不愿意经常听到研发者老是在讲他做的是一个［公平的估算］。在案例研究14.1中，说明了［对牛弹琴］的情况。 

  

案例研究14.1　听不到的管理者 

［这真是有趣的情况，］福尔摩斯（Holmes）说，［我是指听不到的管理者。］ 

［那真奇怪，］华生（Watson）一边说，脸上一边浮出了疑云，［我怎么一样也想不起来。］ 

华生坐回他的椅子，这时福尔摩斯详述了他与佛瑟基尔（Fothergill），一个资深研发人员的故事。 

［佛瑟基尔正在为欧洲的客户，在一个复杂的应用程式中做一些修改的工作，］福尔摩斯继续讲下去。 

［继续，］华生一边说，一边在迅速的在记事簿上面挥毫。 

［这个顾客指派了一位管理者，史纳德斯（Snodgrass）；没有人知道他的技术能力，但是他最出名的就是没有耐性，而且最有名的能力是靠着脸色变紫与爆裂般的言语，让其他人不得不同意他的话，以免他炸成碎片。］ 

［在这个应用程式中的一部份需要加以扩展，而且整个新的模组得重新研究、设计并重头撰写，当然了，这个工作落到了佛瑟基尔的头上，因为他是研发者之中最资深的人员。］ 

［这个工作是由史纳德斯指派给佛瑟基尔。佛瑟基尔拿到了备忘录，简要的看了一下，然后把它放在桌子的另一边；那个时候他正在进行一些非做不可的繁忙修改工作。］ 

［真有趣，福尔摩斯，］华生说，［那史纳德斯对这件事的反应是什么？］ 

［嗯，很正常的反应，华生。史纳德斯在这个案子中充份表现了他的性格，］福尔摩斯回答，［他想要知道，要完成这个工作要花费多少时间。］ 

［而回复是？］华生问道。 

［佛瑟基尔说他不知道，因为他还没有好好看过文件。他请史纳德斯在第二天的下午再来问他，这样他才有时间以怀疑的眼光，好好找出文件中的问题。］ 

［一个很合理的答案，福尔摩斯，］华生表示，［这个佛瑟基尔一定是位很有原则的人。］ 
  
==============未完！请继续看下去！========================

［嗯，的确如此，］福尔摩斯回复，［不过你听听下面的。在第二天下午，史纳德斯的确去找佛瑟基尔，并问了同样的问题。而且――如同你刚刚的问题一样――他的回答是，在看过相关的文件之后，他相信他应该可以在三个月左右的时间完工，而其中预估的错误解决时间差不多要一个半月；换之，他说应该最少花一个半月，最多四个半月，而最有可能的时间将是三个月。］ 

［很有趣，福尔摩斯。那史纳德斯如何回复这一点？］华生询问。 

［他这样回复，］福尔摩斯回答，［史纳德斯微笑，并说他十分高兴佛瑟基尔可以在一个半月的时间把它完成。佛瑟基尔被吓呆了。这时史纳德斯已经离开了犯罪现场，向他的老板回报好消息。］ 

［这个结果真的太让人不满意了，福尔摩斯，］华生惊愕的表示，［在这种鄙俗的手段之后，有进行任何方面的研发吗？］ 

［只不过是史纳德斯在花了三个月再加上一个星期的时间把工作完成后，在他的老板面前看起来笨拙无比，］福尔摩斯微笑着。 

在这个有点想象性质的真实事件中，指出了一个重点：一个很危险的人，只会听到他们想要听的东西，而且他们会在他们规划时去责怪其他人的错误，但这却是以他们听进去的东西为基础。 

  

在案例研究14.1中，虽然它的表现方式并不那么真实，但却是塌实而不幸的事件，而且经常发生。 

除了缺乏详细规格相关资料与实行时的需求，不可能正确预估出时间长短以外，参与的研发者仍然给了最有可能的评估。管理者选择接受较低的范围，主要是因为它更适合他的目标，然后忽视掉最精准的预估值，除非在一连串的好运重叠之下，几乎不可能达成目标。 

这些现象不只会降临到一个企划，让结构与设计的阶段中出现困难。在上一个状况中，很明显的是在设计与结构的领域有模糊的现象，而且没有人遵循80/20规则。 

不幸的，当设计者或是结构师在制作出一个过度简单的设计时，运用80/20规则并无法侦测出来。一个太过简单的设计无法充份处理主要问题，必然会导向一个有企划必须加以修正与重新施行，以更为强大的型式来符合需求。这是一个很难查出来的问题，在设计太简单时会很不明显，尤其是在游戏设计的状况下，一个过度简单的游戏却在过程中花费很长的时间，而这部份通常是由于延长的游戏测试。 

唯一可以避免白白努力二年的方式，就是多做一些努力，采用原型的方式把问题找出来。做一个模型对游戏性通常都有正面的帮助，它不需要十分奢侈、快速或是详细。在我的许多个企划中，我甚至没有想过要利用电脑来制作初始的游戏原型，而是采用手中的材料：铅笔、纸、积木、玩具车等等。 

这个技巧在其他的案例中也很成功。您的脑中并不会马上弹出合适的名称，但是一些在PlayStation或是PC上成功的俯视赛车游戏，就是用玩具车以及很庞大的地板设计出来的。 

有时可以采用桌上游戏来做为游戏的原型，或是用纸笔来设计角色扮演游戏，才能想出正确的运作方式，加入其他的选择。最近有些更为先进的原型解决方案出现在市场上面，这些都是应用程式，可以提供一个虚拟的测试台看出相互关系以及行为方式。一个特别好用的工具（而且，事实上，是我目前使用的是Virtools制作的NemoDev，可以在他们的网站中找到详细的内容www.nemosoftware.com）。这个套装可以提供一个完整的3D世界，并把角色放在其中，在有必要的时候也可以利用C++的界面，来扩展原有的行为积木。 

我并没有机会尽量的运用这个套装程式，但这似乎是另一个制作原型的好方向，而且它也可以为最后完成的产品提供相关的资讯。这并不是唯一可用的产品：其他类似的产品也有在市面上出现，但是不管它们的技术能力多好，在市场上面并不出名。 

我在这方面的个人理论是以游戏研发者的本质为基础。研发者――尤其是游戏研发者――都具有很高的竞争性。我记得之前对一家软体公司示范一个以Voxel为基础的图象技术（这是全新而且之前从来没有人做过的）。这家公司的总企划派了他的一位程式设计师，来看看这个展示程式。在没有错误之下，当时的展示让人留下深刻的印象――3D加速卡这种东西只是地平线上的一个远方小点，我的技术史无前例的，在同一个画面中显示了数个高品质的3D物件。程式设计师在看到展示时的反应十分震惊，然后下一个评语是这种效果很容易做出来，而且他的言下之间是他一个人就能办到。我对这件事的回应是马上问他，为什么他现在却做不到。 

我稍后从总企划那边得知，有一个特别的研发者想要靠自己组成一个研发小组，并以自由作家的方式来工作。而他对于任何有那种想法的人表示出极度的憎恶。 

这个重点在于游戏研发者一向想要［自个来］。他们宁愿不相信外面研发者所完成的程式码与元件，这一点现今很难判定，因为所有游戏研发（掌上型游乐器，象Gameboy是一个例外）都是透过软体界面，象是PC上的DirectX。 

不过，虽然这些软体界面看来避无可避，游戏研发者仍有特定的毛病。对这些研发者而言，这些软体界面已经成为新的［金属］，也就是他们能够接触到的最下层系统。他们之中，没有人想让任何人插手于他们与系统最低层级（也就是系统应用程式，API）之间。 

真希望这种态度会随着时间而不断软化，尤其是当程式设计师了解到外来的程式模组，远比他们在任何时段中写出来的东西都要好之后。 

这已经开始发生了。在看到了《雷神之鎚》与《雷神之鎚2》引擎的成功之后，他们授权给许多的研发者，并用来设计出很成功的游戏，象是《战慄时空》。不过，《雷神之鎚》引擎是这个规则中的例外。在ID　Software中的程式设计师，都被人认为是产业界中制作3D引擎的高手，而这正是《雷神之鎚》与《雷神之鎚2》的成功所带来的名声，这导致这些引擎能够散布得这么广（译注：这也与ID Software公司惯于利用所有法律途径保护他们的程式码，再全面对外公开的做法有关，这会让很多人去研究他们的程式库与3D技术，并以此为基础来制作游戏）。 

希望这一类摆架子的行为会在研发方面的技术更为纯熟之后慢慢降低；而且游戏产业的进展将朝向更愿意使用模组，如同电影工业会从外面找寻常用的元件一样。在这个时候，我们已经离这一点有一段距离了，但游戏研发将会越来越复杂。很快的，它在财务上面再也不会容许您重写核心元件，从外面取材将成为必要的方式；这对所有的研发公司而言已经不再是一个选择（只有资金雄厚的公司除外）。即使如此，大型的公司也可能遵循这一套作法，因为成本效益十分明显。 

新的公司诞生仍是有可能的，尤其是专门设计让游戏研发者使用的元件，Virtools可能就是其中的一家公司。还有，CyberLife（这是Creatures系列产品的发行公司）也有可能参与这个角色。在撰写本书的同时，他们目前正在研发Gaia,一个人工生命的研发工具，设计用来研发有智慧的虚拟生物，很可能可以在游戏中运用，或是用在其他的应用程式中。 

如果结构与设计相反，太过于简单，那出现的问题将会完全不同。一个过度简单的结构在基础上已经碎裂，并需要尽快的加以矫正。如果这个结构无法提供所需的功能，那就没有快速的解决方案。通常都无法靠着把破损的部份修好，然后继续进行那么单纯。一个过度简单的结构甚至不应该通过回顾的阶段！ 

唯一真正的解答就是重复评估结构，并把次水准的部份挑出来修正。视错误的本质，它可能有必要增加所需要的界面才能继续工作。一个该方面的琐碎范例，就是一个光碟播放模组无法容许一条音轨进乱数存取。这个功能要加上去可能十分简单，而且不需要打破目前使用的任何模组。 

不过，如果过度简单的部份太接近基础，象是想要设计一个从平面地图上面抓取资讯，并延伸到3D环境中运用的界面，那么问题就更为困难了。在这个情况下，加上一个简单的额外功能可能还不够。整个模组的结构以及它潜在的资料，将需要修正才能符合新的规格。 

当然了，相对的状况就是设计与（或）结构上太过复杂。一个过度复杂的设计在游戏市场上面似乎很常见，但是单纯认为一个游戏设计过度复杂，就是十分主观的事了。 

水能载舟、亦能覆舟。《星海争霸》对一般的玩者而言可能太过复杂（那简直象怪物），但是对战争游戏的高手而言，它可能还太过简单。 

不同类型的游戏可以接受一定的复杂度，这方面看来象是由全体性的意见所设定。这种复杂度会在每一个同类型的新游戏推出时增加，而且也会有越来越多的研发者赶这个流行。这种现象在近几年变得十分明显，一旦出现一个大卖的游戏类型，其他公司的类似产品马上跟进，而且大部份在设计方面只会更差。我只能假定（而且我有明显的证据）这个设计过程是环绕着一些成功游戏的外型，然后讲一些象是［如果有更多的部队，不是会变得更酷吗？］或是［如果你能更精确的控制这些部队，不就更酷了吗？］ 

不变的情况是，这些变化并不会让它更酷。有时候加入了太过复杂的东西，游戏就会变成使用者与界面为敌。为什么这些设计师无法了解界面就是要故意做得简单，因为游戏可以在电脑负责一定程度的控制之下，进行的更为流畅。这种点子对玩者而言，不过是种冗长的感受。在《模拟城市2000》中恶名昭彰的输水管供水就是这方面的例子。对那些没有玩过游戏的人而言，这个游戏要您切到下水道的地图，然后安置水管把所有的建筑区连接到供水站去。这个特色受到不少媒体以及网际网路的批评，因为它真的不必要，而且减少游戏中的乐趣。既然供水管是必要的，为什么不让它自动安置？为什么会有人把一块地区的供水管拿掉？这完全没道理（译注：补充一下，在这个游戏中有铺供水管的地区，可以加速繁荣）。 

扩展与重新定义一个类型，并不是光靠增加复杂性就可以办到的。如果真的是如此，那么，当即时战争游戏《Warwind》在《魔兽争霸2》之后没多久发行，一定会成为热卖产品。没错，《Warwind》有一些很好的特点，但问题是它容许玩者控制游戏中各单位的种种研发角度，而且在使用者界面上面十分模糊。对一个普通的玩者而言，要掌握的事情实在太多了。媒体在评析中的看法都让人不得不同意。 

我个人在玩《魔兽争霸2》的前一天就玩到了《Warwind》但我依然同意媒体的观点。虽然《星海争霸》游戏的运作、使用者界面，以及部队的控制方式仍然与《魔兽争霸2》雷同；这显然是Blizzard Software蓄意造成的结果，而且是好结果。比较一下《魔兽争霸2》与《星海争霸》的销售表，与其他即时策略游戏的成果，都可以支持这个论点。 

这并不表示您必须把您的游戏设计弄得过度简单，才能让它容易上手。这只是表示您应该小心的考虑一下您的［酷点子］列表，然后决定您这些点子之所以很酷，究竟是因为它们执行时很好玩，还是它们玩起来很好玩？如果您很客观的做这件事，那您可能很惊訝的发现表上没剩几个东西。 

您游戏的任何复杂性都需要加以管理。您可以用很多不同的方法来做这件事，象是隐藏在使用者界面下，或是把复杂性降低到可接受的范围内。 

最好的一块复杂性是互动式的复杂性，它是靠着简单的规则组合，来产生复杂的结果；象是分子或原子堆在一块，形成水晶一样。这方面的最典型例子就是康威（Conway）的生命游戏（Game of Life）。这部份可能没有介绍的必要，不过对刚刚进入这一行的人而言，我还是简单的说一下。游戏的玩者是在一块平坦的格子中，每一格有八个邻居；格子可能是活的或是死去。游戏的每一回合都代表了一个世代，而每一格的世代都是以下列的规则，源自于上一代： 

  

1．如果一个活着的格子有二个或是三个活着的邻居，这个格子就得以活到下一代（延续）。 

2．如果一个死去的格子有三个活着的邻居，它就会活过来（诞生）。 

3．活着的格子除了上述的规则以外，都活不到下一代（死亡，表示人数太少或是太多）。 

　　 

如果您很熟悉这个游戏，那您就知道从这三条简单的规则中，会出现多少复杂的建造方式，象是［shooters］和［trackers］。这就是互动之下产生的复杂性。 

在生命游戏中的规则十分简单。不过，从所有可能的过程中进行排列并选择这些规则，是经过深思熟虑的。规则是十分易碎的，任何变更都会导致他们中止运行。有些人尝试将这些规则加以变化（象是生存与否视颜色而定，或是延伸到3D），但这些规则没有一个象原作那么成功。 

这边的重点是告诉您，在游戏中表露出没有必要的复杂性，并非什么好事。游戏设计的过程是复杂的，但是游戏设计本身的结果不应该如此。如果这种情况真的出现，那我建议您重写。任何让游戏性复杂的部份，都应该是源自一组简单、持续运作的规则，在互动之下产生。您在把一个本质复杂的系统藏到一个简单的界面之下，要想什么都保留下来是不可能的。在这个地方我会强烈怀疑，［规则基础的复杂性］是否与［游戏中所需的使用者界面］有关；而这一点应该在游戏的设计过程，不断的提醒自己。 

一个过度复杂的结构是完全不同的状况，直接导致的结果，就是错误的增加。 

一个过度复杂的结构，会产生出不必要而且没有生产力的实行方式。结构是企划的骨架，而程式码就是它的血肉。如果骨架的形状不正，那您培育出来的小孩就会很难看。 

如果坚持保留过度复杂的结构，设计者就是在降低整个小组的效率：要达到一个层级中的工作，要花费更多的努力。在这些努力过程中，将会有更多的错误出现，并导致企划在程式码的复杂性上，更难加以维护。这也表示企划中将有更多［知识相关］的东西，而它相当于让任一研发者更难了解全局。 

  

不熟悉或是困难的方法、工具与程式库 

使用不熟悉的方法，随后而来的就是额外的训练时间，以及修正第一次尝试这种方法的错误结果。 

本书中说明的技术，也需要花一些时间才能适应；您不能期望在您采用了一套全新的程序与技术之后，还能要整个小组马上而且完美无缺的执行它。 

当这些方式第一次导入时很可能让生产力下跌25%，这会让人心烦意乱，而且在这些实施后的结果上，很可能会爆发出研发者与管理者之间的惊慌。对于那些反抗这些作法的人而言，这通常会被他们用来做为争吵的主题。研发者最经常做的事，就是对抗那些设计用来追踪他们进度的方法；而游戏研发者似乎对这一点特别感冒，如同他们喜欢保持他们的［自由心灵］与不用负责的心态，而且把［对权威的不尊重］视为心理健全的一部份。 

可能有更多不满的研发者从头就开始反抗，所以任何危及生产力的现象，都会被用来当做回到温暖的［老式］制作方法的好理由。这应该极力尽免。 

您可以让研发小组为这种事情先做准备，来绕过这一类的反应。对新的方法、工具或是程式库，都有一定时间的学习曲线，这是免不了的，对不熟悉的知识都会如此。不要让多疑的人，在还没有足够长的理解时间之前，把任何新东西都敲倒。您所尝试的每一个东西都不一会有用，但是您从来就不知道，它会不会被一个很难处理的研发者打得混身是血。 

举个例子来说，如果产品（或更可能的情况，企划的一部份）是在低级语言）下实施，那么它的生产力将会比预期的更低。不过，一般来说在威力强大的机器上，组合语言的需求程度就越低。一般的主机都已经有足够的能力，让它无英雄用武之地。如果以Pentium级的中央处理器来执行一个多工作业系统，您可能永远无法确定一段特别的程式码，要花多少时间来执行。 

唯一可以让组合语言发挥长处的主机，是那些记忆体受限、速度不足，象是任天堂Gameboy或其他掌上型的游乐器。虽然任天堂（以及其他公司）试着限制研发资讯，让只有签约的研发者才能取得，但是地下的研究从来没有断过。甚至已经出现给Gameboy使用的免费C语言编辑器，以及许多可以用来除错的模拟器。 

在这些机器上的研发时间，要比成熟的PC与游乐器企划短得多；除了规格受限的原因外，另一个主因在于程式也小得多。Gameboy似乎是唯一可以让单人进行游戏的设计与生产，并与一群大孩子做出来的游戏相较量的平台。 

  

结构整合的问题 

在分别进行元件研发的主要危险之一（如同我们在软体工厂模型中所建议的），就是如果这些程序没有在极度小心的情况下进行，在整合时可能会十分困难。如果分别研发的元件无法轻易的整合在一块，那就需要重新设计与修正元件，才能发挥它们的功能。 

这个问题并不只影响到游戏产业；它影响的是整个软体工业，也是增加可接受的物件版本技术――象是COM（Component Object Model，元件物件模型）与CORBA（Common Object Request Broker Architecture，共通物件需求中介架构）――的主因。这些在理论上，是用来进行游戏研发的好模型，除非您的目标是跨足多平台的游戏。 

在PC的研发方面，COM是很值得考虑采用的。您不用担心它在效率上有不当的表现，因为整个DirectX程式库就是以COM系统为基础。虽然这部份在本书第三部有更进一步的说明，不过COM可以遵照研发者的要求来进行物件改写，以保证一个物件界面的作用仍然保持原状。所有的物件在执行时都必须找齐，而且是透过标准功能，以保证在界面上每个物品的号码都是独一无二的。如果界面需要加以更新，那就会指派一个新的界面编号，而且如它的重要性一样，老的界面仍然不会有所更动。这可以更新一台机器上面的共享元件，而不用打碎用在早期版本上的界面。COM当然不是一个万灵丹，但是它可以解决一些整合元件上最常见的问题。 

目前COM只能在视窗为主的作业系统上运作，但是微软已经保证会把COM带入其他的平台。先不管谈论独占主义的趋势，COM很可能在未来成为产业界的标准，而且甚至适合进行跨平台的研发工人和。 

  

行程表的协迫 

行程表的协迫是很令人厌恶而且通常是最诡诈的威协，也是最难去侦测与控制的问题。 

通常，只要有机会，研发者会把他们延误的行程表藏起来免得丢脸。就算是要一个经验丰富或是很有责任感的研发者，承认他（或她）落后进度也是很困难的。就算这不是研发者直接造成的错误，也无助于改善这个现象，因为他（或她）通常都要为这个延缓的时程表负责。 

行程表的延误并不一定是研发者的错。这个责任的连锁会一路延着命令的阶层向上跑，而且谴责可能会落在这个阶层的任何地方。下列的章节将会提出一些延误的例子，指出原因，并如何修正。主要问题是，延误有时是难以注意的。当所有东西都比期限慢了一点点，然后某一天全部加总起来，就会突然变成时程表延误了数星期，甚至是数个月。 

  

过紧的时程表 

由于财务与商业上面的束缚，大部份的时程表都是很紧密的。给一个小组太多而且没有必要的时间，可能会让您到达您想要的完美境界；就算是有足够的财源让一个小组可以放声说：［它在准备好之后就会发行］，一个严密的控制还是有其必要，来确保时间不会白白浪费掉。 

期限并无法提供集中力。一个员工在得知他得在一定的时间之中，达成短期的目标并无法让他更为专注。不幸的是，在很多的理由之下有时是一种压榨，尤其是管理者采取极端措施，决定要把时程表变得紧到想勒死人，藉以刺激那些［懒惰］的研发者开始行动的情况下。这种方式一向都有负面效果，研发者很聪明，如果不够聪明，他们就不会在这边。 

从一开始就排得过紧的时程表，有好几个理由。有时候，时程表可能是因为外表的理由而修正完工时间，象圣诞节就是一个常见的理由。我知道这应该是一个充满希望的神奇节日，但是就算如此，在年初就诞生数个完全没有希望的乐天派时程表，试着在圣诞节大卖仍然让我高兴不起来。 

对于一个修改过的时程表，唯一解决方式就是减少产品的规格，增加可用的资源，或是增加可用的时间。这三个属性（需求、资源与时间）都是在平衡的状况下。您在变更其中一个时无法不影响其他二个。 

这三个属性可以视为三角形的三个点；与图14.4所示十分类似。如果您打算让这个三角形与中心点保持平衡，那很明显您不能变更光靠改变一个角的［权重］，而不去变更其他二个角。为了保持三角形不致于崩毁，您必须让重心保持在中心点。所以，如果您的时程表变短，您可以增加资源或是简化规格；如果您减少了资源，规则就必须切掉一些，否则时程表就要拉长，依此类推。 

这是一个不变的定律，没有什么其他替代方式。如果管理者不喜欢这个结果，那就是一场硬仗，一定要给一些东西；否则光是叫员工长时间工作，来达成不可能的时程表只会招致反效果。他们不只会蜡蠋二头煤，而且也对士气有负面的影响。他们可能离开公司，而结果就是挑战管理者的责任，一样会造成大量的金钱流失。 

另一个原因是采用［有可能］的时程表。这部份在本章前文已经提示过（见案例研究14.1）而且产生出来的时程表很不精确，除非一切都是处于最佳状况的［完全状况］，但事实上的结果是［预期状况］中的时程表。 

这些［有可能］的时程表通常在二种理由之下发生。第一种是遵循时程表的员工没有经验。在这种状况下，他（或她）通常都尝试做出一个管理部门很想看到的程式表，以博取较好的印象。这个时程表的设计都是假定研发过程一切都在没有问题的情况下。第二种更糟，就是［有可能］时程表出现的原因，在于管理者倍受压力下要求砍掉时刻表后段，最后就是一个［不可能］的时程表。 

这种事不会有人喜欢，而且它通常导致研发小组在时程表延误上倍受责难。要解决这种问题没有简单的方法，唯一的方式就是在有效率的现实考量中，要负责人第一次就把真实的时程表做出来；然后在管理部门要求减少时间的时候坚定立场。这通常是假定所有研发者反正都会在时程表中灌水，所以他们可以切掉一些灌水的部份然后做出［真正］的时程表。这种让人迷惑的争论必须不计一切代价的加以反抗，您不可能光是削掉一部份的时程，然后期待制作时间加快，来完成等量的工作。这边一定要争取到一些东西，而且这些东西不是要能与企划相符，要不就是指派更多的资源。 

当我被人要求减少不合理的时程表时，我试着让他人从我的角度来看事情。他们可以快点拿到东西，但是这会让他们花更多的钱与较少的功能，而且伴随而来的是更高的风险。这暗示着更多的金钱、减少的功能以及增加风险，可以让他们马上集中精神，最后通常可以达成其他方面的妥协。 

  

不完整的时程表 

在排定时程表的人经验不足时，另一个可能出现的问题就是他们会省略掉时程表的一部份。或许他们会忘掉的有的图档需要进一步的处理，也可能忘掉游戏需要有安装与解除安装的程序。不过，要预测二年时间中的工作列表，也不是一件简单的事。 

事实是，如果一个工作没有出现在工作列表中，它就不会排入时程。这个结果就是让一个不完整的企划成为恶梦般的局面，因为照时程表来看，它应该完工了才对！唯一的解决方案就是埋头苦干把工作完成，让时程表过头，为额外的工作取得额外的资源；或是降低企划的标准。这将会视他们的花费与劣势来决定，如同我先前说明的一样。 

  

缺乏的资源 

如果时程表的安排是以特定的组员为基础，而且这些组员无法运作，那就是一个大问题了。 

如果特定的组员拥有所需的技能，而且他（或她）正在忙其他东西，那除了等候以外并没有其他的选择。不过，更重要的一点是，这种情况根本就不应该发生。让一个人独占一种特定的技能是极度危险的事情，万一他（或她）决定要离职呢？您应该做的是鼓励技能在您的员工之间传递，全面预防碰上这种局面。 

记住，一个企划在理论上都有最少量的需求。如果您变更了任何一点，那么另一点或是另外二点都需要以相反的方式进行修正。这也是一个不变的道理，所以尝试去违反它并没有什么意义。这样做只是导致另一个问题，例如研发者力竭、企划延期或是取消、甚至是一个次水准的产品。 

==============未完 ！ 请继续看下去！=======================

高估省下的时程表时间 

如果采用了特定的生产工具（象是行进的原型工具），他们通常被视为一种［新世界］风格的希望与敬畏。 

通常，要不是因为没有场所可以让研发者操作一连串的旋钮与按钮，否则他们都会认为自己做到超人般的水准，从高楼上面弹跳而下，从倒塌中的建筑中救出孤儿，并能够在荒谬的短时间之中，单手做出完整又可以动作的游戏原型。好吧，我在高楼弹跳救援方面撒了谎，但是一个全新、美妙工具的能力通常被人高估，尤其是当它们完全不象小组用过的东西时。 

有时候，工具会以［充满各种所需特色，让您可以做到各种想做的事情］面貌出现。问题就在当工具提供您更多的［解决］之道，它就更会催促您采用它的方法来做事。经常发生的是，除非您的运气超好，否则它并不完全是您想要的，而且您会把大量的时间花在有明显缺点的工具上。视工具的本质，做这件事的困难度可能从稍微费力到完全不可能。是的，大部份重量级的工具都可以让设计者制作出一个外掛的模组，但它会把设计卷入一个模组，去符合一个不熟悉的结构，学习新的API，并发现在一个不熟悉的设计程式中受限时，如何真正进行工作。这是一个吸引人的工作，因为它可能会［错误的］假定，因为它是采用了象C++这样的标准语言来创造外掛程式，一个很好的C++程式设计师应该可以很快的把它纳入使用的范围。问题是，要得知这个延伸系统的运作方式，所花的时间通常会被加成。 

这个解答可能是重排时程容许学习时间，或是切掉使用这些有错的［强化生产］工具。当然了，您可以把这二种作法并用的想法丢掉。 

  

预估不精确的时程表 

在一些情况下（而且我很确定我们讨论过），一些时程表看起来可能很正确。它可能把每一个工作都标出来，考虑到每一个风险，而且每一个研发者都会保持忙碌，不会产生冲突。但是，在它进入实行过程时，一个或是更多的范围就与时程表脱节。举例来说，不熟悉的生产范围可能要花费比预期更多的时间来设计或是实行，或者一个工作中的延期可能会导致更多独立的工作同时向后延。 

这可能是因为产品要比预期的更为庞大，或是需要的努力与工时要比预期的更高。这将假设这些困难单纯来自于解决方式的技术复杂性，而且与工作中进行的研究没有关系。如果是后者，那就没有解决方式。您只能坐下来然后静候研究结止，或是干脆把这个功能砍掉。不管哪一种解答通常都令人无法忍受，但这是您必须为排定时程的研发，所付出的代价。您无法把研发排定时程：这个行动完全无法预测。您难道不知道安排六个月的时间，附上精确的查核点与里程碑，来研究反地心引力的驱动器有多荒谬吗？您必须完全了解问题与解答的所有知识，您才有可能精确的预估要多久的时间才能完成。研究的本质，就是探索未知；安排未知的时程表？您一定是在开玩笑！ 

不过，如果这个问题是源自于未预期的复杂度，那这一类的问题通常只有三种解决方式。一个是切掉功能，这个解决方式能不能实施，看您的需求而定。第二个方式是重新安排企划时程表，把额外所需的时间排进去。第三种解答是以软体工厂的方法，从程式库找一个可以相容的元件替换掉（不过能力可能比较差），这种方式不一定会与整个游戏契合，但是如果其他的方法统统失败了，您还有一个可以运作的产品。 

不过，这并不是重点；真正的重点在于就算您插入的元件无法提供全部您所需的功能，它至少也可以在新元件完成之前，做为应急的举动。其他部份的企划仍然可以进行。如果再多加小心，光是等候一个重要的元件完工，不用花费太多的时间。 

说服人们拉长工作时间是另一个选择。如果一个企划中的努力只有稍微的延期，那短时间的加班可能是个赶回进度的好方法，只要研发者能够负担的起就行。 

不幸的，这个系统在游戏产业中长期受到滥用。我听说过一些可怕的故事，研发者被迫每星期工作80小是地，长达一个月，而且没有额外的金钱方面奖励（除了每周末的匹萨，以及在企划完成后低劣的T恤）。这实在太荒唐了，我坚定的相信人们绝对不应该被强迫工作，一天甚至不该工作超过八个小时。这会招致反效果，而且您通常会得到的不过是次水准的游戏，一群不满的、烧焦了的研发人员。 

管理部门对这种滥用事件的最大藉口（而且注意一下，管理者本身很少周末待在公司）就是写一个游戏与牺牲奉献有关，或者是一些相关的谎言。无聊！这是一个工作，单纯而简单，而且任何想要说服您的人，都是想骗您（或是要靠您的牺牲来赚大钱）。总归一句话，志愿加班在短时间不会有问题，只要研发者能从中得到合理的费用就好。 

  

时程表调整的错误 

为一些没有预期的延迟来调整一个时程表，通常会出现错误。有时候重新仨计来应付时程表的延误是过度乐观或是忽视企划历史，也可能是从其他企划中引用的缺席。 

要确保这些错误不致于发生的最佳方法，就是使用过去的资讯与自然的制度，并用在员工的身上。 

在案例研究14.2中说明了这些程序的真正状况。 

  

案例研究14.2　重新调整一个已经实行的时程表 

当我在一个误点的企划中担任了疑难排解人员的角色时，我被人指派分析目前的时程表，并以当时的企划状况为基础，把它重新调整成正做的预估值。 

如果不从小组身上先取得他们的缺席，要做这件事是不可能的。为了做到这一点，我观察了每一个人指派的工作，以及他们分配到的工作时间。刚开始，我很确定他们不会因为企划中的问题而遭到责难，所以我再评估了时程表，并做了更精确的预测。其中一个理由是企划已经碰上了麻烦，随着加诸的压力他们放弃了程序，试图赶上期限（这部份在本章后再讨论）。而这样做的结果，当然了，加重了问题并导致更多的臭虫，最后是时程表延误。在这个阶段，我们中止了任何新的研发，只专心于把企划带回可以接受的程度。这个工作已经做了二个月之久，而且几乎完成了。 

现在正是调整时程表的好时机，因为新的研发正准备开始。如果我试着预先准备，这个结果可能会没有用，因为需要先处理的，是老旧程式码资料库中的问题，而额外的工作势在必行。 

小组的人员被指派了新的工作，每一个人（按照时程表）的预期工作时间是一到二天。小组被要求要紧密的维持程序。我强调这并不是一场比赛，而且他们也不是被评定为精通这方面的高手。每个人都有不同的工作量，而且程式员的速度快也不代表他真的很棒。我想要的资讯是他们个人的工作速度，因为我需要以他们的工作速度，来调整时程表。 

在这些指示之下，我观察并收集小组中的制度，进行了差不多一个星期的时间。我发现在没有例外的情况下，所有的小组都无法在期限内完成时程表的工作；这个时程表太贪心。 

对每一个组员来说，我找出他们做一些简单行动真正花费的时间，以及时程表安排的时间。在完成这一点后，我拿着工作列表走到每一个员工身边，然后把安排的时间乘上这个比率来算出更精确的预测时间。在小组的指导下，我把工作洗牌一次，并确保每一个人员都有平衡的工作列表。 

整个过程又重复了一个星期，而且在每一周的末尾再度计算这个比率，并把工作重洗牌。 

在第三个星期，我们发现研发者持续的符合期限要求，并紧密的维持程序。在这个阶段的士气已经很明显的提升，小组开始怀疑他们之前为什么这么慢而且没有效率，并了解到他们先前工作的时程表是达不到的。 

下一个障碍就是对急迫的管理者解释，这个新的时程表预期的完成以及发行游戏时间，要比他们希望的晚二个月。我接到的要求是，看看我能不能把时程表切掉二个月，赶上发行的时间。 

这一点让我有点惊愕，因为这种思考方式就是他们搞得一团糟的主因。我在白板上面画了一个三角形（如图14.4中所示十分类似），并开始解释完全的平衡行动必须靠着资源、规格与时程表来达成。我无法把时程表切掉，因为现在已经没有可以操控的空间。他们不是要增加资源，要不就是砍掉功能，并准备迎接在企划后期阶段所带来的抱怨。 

对他们而言，增加资源或是砍掉功能都无法接受，因为他们已经将特色用来签定合约并取得预算；所以在最后，他们没有其他选择，只有按照我的建议来行事。 

这个企划在我新安排的行程表中，提早了一个星期左右完工，而顾客也被安抚完毕。 

  

一个无法达成的时程表所加诸的压力会降低生产力，主要是因为研发者的士气会不断下降，如同他们明明全力以赴，本身的进度还是不断落后。这种状况的唯一解决方式，就是考虑一下在案例研究14.2中采取的方法。 

组织上的问题 

组织性的问题是我的最爱，不过，它们在处理上也是最没效率的。它们之所以成为我的最爱主因，是因为这些问题通常源自于管理上的错误，而且把这些问题丢回给老板都是好事！它们之所以最难处理，是因为您要想办法告诉您的老板他犯了一个错误――这也是最快前往大门的路，如同图14.5所示。 

这种状况要极端小心的处理，光是告诉您的上司并不一定有用，因为如果是个坏消息，他（或她）可能会觉得把这个消息告诉他的大老板将危及他（或她）的事业！每个人都喜欢［杀人灭口］。 

不过，如果站在老板的立场想想，您想听到的是有可能要多花数个月制作初始的模型，还是在游戏已经延了数个月还没有上市，然后听到有人一年前就想要告诉您这个问题，但却被这个人的上司挡了下来？ 

这个特别情况的解答，就是透过不具名的管道。利用这种方法，任何人都可以把问题回报上去，而不用担心事业受到危害。 

  

管理引发的困难 

管理会导致组织方面的问题。这句声明不是想要打击管理阶段，它只是反应出管理对一个企划组织天生负有的责任。嘿，他们总该负一些责任吧！ 

举例来说，管理部门（甚至是市场部门）可能坚持一个技术上的决定，导致时程表延长。很不幸的是市场受到科技的驱使，但我们却无能为力。这可能是一个委托加工合约的一部份，要求一个产品能够全面支援一块特殊的显示卡，而不是单纯透过类似DirectX的常API等等，诸如此类。 

在某些情况下，管理部门会坚持一些回顾性的决策，象是购买、预算的同意、合法的事情等等。这个状况通常在一个庞大的发行公司，出资提供一家较小的游戏公司时较容易出现。其中一个状况是这些发行公司会插手于［否决权］的运用。这表示每一个影响到产品的决定，必须受到母公司的批准。如果母公司有许多的附属公司，那造成严重延期的可能性就大为增加（当然了，您必须了解，发行公司在电话中对您的管理者大声咆哮，要求知道游戏为什么要比行程表晚三个月才会上市，一定会忘掉一些事情）。 

这一类的事情会影响到您小组的士气，其他管理上的决策也可以让士气降低，象是这类长时间不断延伸的权力，或是在没有好理由之下的特权，以及没有效率的小组结构，都可能在未来降低生产力。 

很惊人的是，就算是在良好的管理决策（至少暂时性）下也有降低士气的可能；象是负担程序并定义出实际上的研发。这方面源自于人们对于这些变更无法适应。这方面必须利用［慢慢来］的方式，而且不能妄用。如果您打算强制让他们负担加班的重任，并预期他们一天要工作十小时，进行程序让小组以更有效率的方式来进行，可以说是一点道理也没有。在研发过程的严格实行重点，在于让这个小组更有效率，并为个人省下漫长的工作小时。如果管理部门打算实施的作法，会导致小组的士气下降，那最好让您的小组有一个可见的好处，而且要出现得快一点。 

有些早期的管理学校可能还不了解程序所带来的平稳作风。您应该记住游戏产业背后的坏习惯已经有数十年以上，没有办法一夕改观。有些管理者会对延误而稳定的步伐感到紧张，然后越来越沮丧。他们可能想要看到一些更尖端的勇者，带着漂亮的展示与明显可见的进度，而不是看着稳定的工作持续进行，但短期内只有一片漆黑的画面。如果要解决这个状况，整个小组必须把重心转移到企划的特定部份中，才能够让管理者满足；接下来研发过程的平衡会打破，导致未来的工作中出现捷径与不必要的妥协。这是一种破坏良好状态的研发，只专注于外表、从底部挖除小组侦测并修正问题的能力，而妨碍了精确的状况回报。 

在企划尝试着做出一个结论，但是小组却发现重要的子系统可能还没完工不见了，很可能造成额外的压力。在这一类的状况下，在时间压力之下企划中的计划很可能被忽视掉，最后变成一团乱、没有效率的研发，如同案例研究14.2。 

  

承包商的问题 

很惊人的（或者不奇怪，只要看看其他产业平均薪水，就知道游戏产业薪水奇低），通常承包商都不熟悉游戏产业中的事物。在游戏产业之外，通常会听到一个组织，象是银行，按惯例雇用了一个签约的程式设计师，来进行一个企划；但这种事在游戏公司中却从来没听过。 

通常承包商在游戏产业中使用的方法，是找一整群的单位来进行工作，象是全萤幕动画的制作、动作捕捉、游戏测试与设定测试；把一个已经做好的游戏转到另一个平台，或是设计一个3D的模型。 

如同我已经说过的一样，有些更大的公司在与较小的公司签定合约时，有时候您会发现母公司会要求您使用另一个子公司研发出来的引擎，做出一个新的产品。这时，将会出现下列的问题： 

  

寄送延期 

如果承包商没能在同意的那一天把双方同意的特定元件寄出来，那您的小组要运用它就会出现问题。可能会出现改变意见的看法，而这一点可能会让企划卡住。 

不良的效果会伴随着寄送延期出现，就算是一个在纸上的好点子，也会变成反效果。除非有十分严峻的压力，否则光是靠一点点的诱因，很难让工作继续推动。当然了，这一招也不能一直用。最好的预防方式，就是从刚开始就避免这种现象。如果此事不可为，那您需要的就是捏把冷汗然后开始等，计算您的损失，然后取消合约（如果您找不到一个可以用来替代的元件时，整个企划都有危险），或是开始靠您自己来制作一个替代用的元件。 

  

品质不良 

经常出现的是，承包商会采用他（或她）自己的研发标准与做事方法。您完全没有办法保证这个工作会及时到达，而且具有可接受的品质。 

在这种状况下，时程表上的时间必须增加，才有可能去提升品质。换句话说，这和他们寄送延期的结果是一样的。换言之东西寄得晚，再加上品质不良就是一场恶梦，让您连想都不敢去想。 

要解决这个问题并不容易，但是有些方法可以尝试，是在初始的合约中把品质的要求陈述得十分清楚、明确而且列出全套的规格。这方面的困难，在于定义不够充份时，有时很难把需求写得十分完整；或者有些特色在变更了需求之后四处爬行。确定您的需求十分明确，才不会招致误解。鼓励承包商保留一段撰写这些规格者的会谈，才能不断的监看并修正整个过程。 

不要光把需求丢出您的大门，然后期望看到您真正想要的东西，在几个月之后滚回来。这样做只会让您失望透顶。 

另一个重点在于确保承包商有足够的动机（通常是在财务方面）来进行要求的工作。在这边的危险，是指如果承包商在动机不足的情况下，没有在企划中投钱，那他们就不会提供所需的执行效能。 

  

个人的问题 

个人的问题是免不了的。您不可能预期会有人愿意付出他所有的时间；古人说得好，［您可以时时取悦少数人，您可以偶尔取悦所有人，但您不能时时取悦所有人。］ 

这就是研发生命中的真实，习惯它吧！ 

  

关系 

研发一个游戏经常与生育来做比较。我并不知道这是不是真的，因为我永远生不出小孩，而且我也不想。我很确定如果您去问任何女人其中的相似与相异处，您可能会得到一个很尖锐的答案，而不应该写出来。 

不管怎么说，游戏研发的过程是否能够与生育相比较，并不是这个地方的重点。重点在于研发中包含了大量的痛苦（这种情况经常出现在研发中，而不只是在游戏研发。任何身为游戏研发者要承担的额外痛苦，倾向于受到虐待。或许您该去看精神医师了！） 

================未完！请继续看下去！======================