第十五章　疑难排解

＊风险

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

＊变更控制

＊突发规划――［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的模型。

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

寄送延期

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

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

品质不良

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

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

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

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

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

个人的问题

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

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

关系

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

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

研发过程的痛苦与挫折，可以严重考验人与人之间，在过去数年累积下来的关系。想想看吧，您很有效率，每天只要花八小时工作，一星期用五天，在一个公司的年轻小组中，属于固执的新世代，处于一个压力强大的局面。这并不是一个立意上和平又融洽的环境。在一般的事件与路程中，很可能出现争论与吵架，而这还只发生在组员之间；明显的伤害了生产力。如果小组的人员忙于争执，工作就不会有效的运转；更糟的是，如果争执扩大成为战争，那就难保死伤，通常会在程式码中出现破坏行动或是强迫性的辞职。破坏导致的是失去这一段成果或是品质低落，需要修正。这会造成难以想象的伤害。

虽然在企划的影响下，任何牵扯到这个局面的人，都不会掩饰他每天有多不想回到工作岗位上，想到如果对手实在太笨，就要面对一连串无休止的谩骂。他们应该在学校就把逞威风的习性收起来。

如果您的公司有任何员工，利用逞威风的手段来开路的话，那光靠一句［受害者应该能够处理工作环境中的混战］仍然不够。我对这种状况采用的方式（在我还有决定地位时）是借用了美国人惯用的判断系统：三振您就出局。这方面可能很困难的原因，在于逞威风的人通常是公司中强而有力的研发者，而且通常是［喜怒无常者］的类型，但这一类的行为，在专业的环境中是无法容忍的。

如果组员无法有效率的在一块工作，冲突导致的结果就是沟通不良、设计拙劣、界面错误与额外的修正。如果组员之间的问题没能在出现之后尽快的移除，那他们就会继续这种为害社会的举动，伤害整个小组。

如果这一类的伤害出现在同层级的员工之间，那您可以想象在没有操守而且作威作福的管理者手中，会让这一类的谩骂在员工之间堆积如山。研发者与管理者之间的关系不好，是对士气与生产力的最大伤害。这可能会升级成［我们和他们］的状况，怀疑到小组的整体性，但这一切都是错误的方向。

这些问题的最后结果，就是员工的动机与士气降低，而且生产力不足。小组的成员不再信任企划，而且经常性的不再提供成功所需的效能。我应该不需要再指出后面紧跟而来的灾难，就是在企划还没有完成之前有不满的员工离职。这会对时程表马上造成决定性的效果，让小组必须学习并担起这个（或是这群）离职员工的责任、加长时程表并看着企划的挫折导致小组士气疯狂下落。另一个不甚佳的解决方式就是增加研发的人员；不过如果他是在企划后期才加入，将需要全面性的额外训练与沟通时间，而且也会降低现有的员工的工作效率。

技巧的不足

在游戏产业中，有几种已经可以理解的研发者训练（象是一个3D程式设计师、一个物理程式设计师、一位人工智慧程式设计师等等）。至于这些领域是真实还是想象的，这一类的问题最好留待另一个时候再来讨论。

不过，假设这些领域都是真实而必要的，那甚至是最好的企划人员也会出现技能不足的现象。有时候，一个程式设计师会被叫去处理一些特定领域的问题，是他（或她）不那么熟悉的。

这个问题并不只出现在研发者身上。一般来说，当人们的能力无法胜任赋予他们的工作，问题就出现了。通常这种缺乏专业知识的情况，会增加工作中出现大量错误的机会（象在程式或是其他地方），要重来一次的可能很高。

并非所有的公司都可以为每个需要的人提供全面训练，而且事实上游戏产业中的员工并没有那么多的训练课程，与其他软体产业是不同的。

要解决这些问题，可以采用三种常见的方式。第一个是提供员工额外的时间，来熟悉他（或她）要处理的领域。在某些状况下，这个做法可能十分实际，但是在其他情况（象是时间或金钱有限）下就不见得了。小组的人员选定上，至少必须有一群具有基础能力的人，才能有效的学习新的东西。举例来说，要求一些没有数学专长的程式设计师来设计一个新的3D引擎，是没有用的。

第二个解决方案是鼓励知识的分享（如同软体工厂）。在这种方式下，具有特殊专长的员工，应该受到鼓励，藉由直接的教导把知识散布给其它的员工。另一个更好的方式是由最有能力的人员举办一连串的研讨会，主要的重点就是把他们的经验与技能传递给其他的员工。这要比雇用外来的讲师更为便宜，而且可能更符合您公司的风格。员工喜欢感觉到他们是倍受照顾的一群，而且一个选修性的教育课程，可以让他们了解到公司有考虑到符合他们的需求。

第三个解决方案是给那些没有时间但是手头很宽裕的小组，就是从外面找寻具有相关技能的外包人员。这可能是个很贵的选择，不过如果您对这方面的技能需求十分迫切，您可能根本就没有选择。您也可以要求外包人员教导您的人员，让小组具有相关的技能来弥补这方面的损失。

我已经说过外包人员会很贵。就长期的运用看来的确如此，不过，如果您只是需要在短期完成特定的高等技术工作，那雇用外包人员可能是最符合成本效益的选择。要找寻具有正确能力的外包人员，也比寻求长期员工来得容易。

研发的问题

在这个章节，我们并不是想讨论程式上的问题，这本书并不是程式设计书。所以，我们打算要看的问题，是影响研发人员撰写程式的相关问题。

一般而言，研发人员是一群在环境上不太挑剔的人。您可以把他们放在一个黑暗的办公室，只有萤幕的亮度可以提供微光，只要他们不会受到干扰，他们就可以很快乐的撰写程式，而不用担心他们周边的东西。至少，这在理论上站得住脚；而事实上，也没有太大的差别。

办公室的设施

办公室的问题与延期与否的关系最大。一个办公室的重点，在于提供一个稳定的工作环境，供研发之用。

举例来说，如果办公室的设施没能及时完成，那小组要在哪边工作？好问题，而且没有轻松解决的答案；这仍然要视办公室而定。如果小组是一个大型公司的一部份，那他们可能可以安置到建筑物的另一个部份。如果小组是一个小公司的新成员，或许可以租用一个办公室。没有人愿意在一个企划进行到一半的时候搬家，所以可能要等到这个小组展开另一个新企划（或是在进行第一个企划）时搬移。这表示已经开始的企划有延期的可能，但是如果延期时间不长，应该不会造成太大的麻烦。

如果您的公司完全没有办公室，那您的问题就更大了。您可以随时借用Yost Group的例子（Yos是3D　Studio Max的制作者），第一版的3D Studio Max是把整个小组安排在不同的地点之下完成的。象这样使用虚拟办公室仍然有些问题，主要是利用数据机来传送庞大的档案时颇为不便（译注：本书是1998年完成的，目前台湾地区的ADSI技术普及，传输时的问题就小得多了）；但是因为物件导向的本质，这一类的分割研发仍然可以运作得很好。

如果有设施可用但是某方面还不够完整（举例来说，没有电话线、网路线、桌子和椅子、周边设备或是电脑等等），那您还是有问题。这一类问题的解决方案就是拿出您的支票簿，然后去大采购，但是这用不着我来告诉您！如果您是一个大公司的一部份，那就向您的管理者抱怨设施的不周全，可能会有些帮助。

办公室也可能是个挤满人或是吵得要命的地方，或是在某些方面很混乱。在这些情况下，制定一些基本规则可能有帮助，象是清理桌子的政策（每天桌上都要清干净），以及鼓励安静环境的方法。提供开会的地方也可以让人们不至于在大声讨论时，吵到其他想要静静工作的人。

研发工具以及外来的程式库

研发的一个问题是，您免不了要用到第三者的研发工具与程式库（译注：在这边的［第三者］是指不相关的公司；一般来说第一者是公司本身；第二者是直属关系的公司，象是子公司或是母公司；第三者则是指不相关同业，像AMD与英特尔之间的关系）。如果这些第三者工具与程式库有问题，就会导致延期或是写出来的程式中，有着难以捉摸的错误现象，很难追踪出来。

如果研发工具无法如预期一般的运作，那研发者将需要花费额外的时间，才能为这些错误创造生机。这可能是因为当初选择这些研发工具时，并不是因为它的技术优点，而是因为它比较便宜或是市场上面最酷的东西，但它却没有当初预期的生产力。唯一的选择，就是远离这个目前的工具，换到另一个上面（如果有的话）。这样做经常发生的问题是，它会带出另一组新的问题，更不用提整个企划要顺应新工具并转换资料，所额外花费的时间与努力。

如果程式或是经典的程式库没有足够的品质，那额外的测试、错误的修正以及工作的修正就是免不了的。更糟的是，第三者程式库中的错误通常很难找出来，尤其是在这些程式库没有提供原始码的情况下。有时候，您无法避免要用到第三者的程式库，所以把问题解决掉是没有选择的事。举例来说，您可以想象现在写一个游戏可以不用到DirectX吗？不行？我也办不到！任何出现在DirectX、影响您企划的问题都必须解决掉。回报臭虫可能会获得解决，但是要在您游戏发行之前，得到修正版本的希望却很渺小。假设它真的修正了，使用者的机器上面还是有可能安装了旧版的程式库；就算您可以随着推出游戏时在光碟上面附上目前使用的DirectX版本，您也不能确定每一个人都会为他的研体更新最新的驱动程式（这些通常是由硬体的制作公司推出的）。幸好，虽然早期出现的相容问题真的十分可怕，DirectX目前似乎运作的很好。不过，如果一个您非用不可的程式库在品质上面难以接受，那这些程式码必须进一步的测试、设计、进行工作并修正所有的问题。

设计的误解

即使是在良好的意图下，研发者有时仍会误解设计文件，并生产出一个完全没有任何相似点的软体，与要求不同。这种误解可能是导致于意外或是设计。

有可能是研发者单纯的犯错，而且没有充份了解设计。这一点是可以理解，但却不是可以接受的藉口。如果研发者不确定设计文件中的任何概念，他（或她）应该在开始设计程码之前，要求一份清楚的说明。这是很明显的要点：一个研发者不应该写一些他没有全面了解的东西。

比较严重一点的情况是，这个［错误］中有一部份是研发者故意的。他（或她）可能决定修正或是重写设计，来符合他（或她）的上级的意见。这可能只是小小的变更，也可能是大型的变动；不过结果都是一样的；与程式码及元件产生分歧，是不允许的现象。就算研发人员够认真负责的修改了这部份的设计文件，这些变更也没有透过正式认证的程序，可能与整个企划的剩下部份不相符。还有更糟的，可能有其他的模组以这部份的原始程式码为基础，而不能用变更后的程式码。在这种情况下，研发出错误的软体，必须重新设计并修正。

研发出额外的软体功能并无此必要，否则就是称之为［贴金］的行动，可能会把时程表拉长。在贴金的情况下，研发者已经做出了所要的功能，但觉得有必要增加额外的功能，因为他（或她）觉得它会很有用，而且花不了多少时间就可以做好。研发者之所以这样做，是因为他（或她）认为可以做出更从的功能，而且是免费的。

这边有一堂课，每个人迟早都会学到：就是没有任何东西是免费的。额外的功能并不在规格之中，虽然在这个时候看起来免费而且很容易，但是在后期进行维修与抓臭虫的时候，会增加更多的时间。

符合需求

需求可能是游戏设计者、发行公司、市场以及外来的组织（象是排行或是超商）加诸于产品上面的东西。这些限制是否与产品相随，端看公司的环境政策本质而定，但是就算如此，困难或是有冲突性的需求还是会出现一些问题。

您可能在怀疑为什么超商可以影响到一个游戏，但是著名的事实是Wal-Mart（译注：美国大型连锁超商）是以游戏的内容来决定进货数量；所以被Wal-Mart拒绝的产品对发行商而言，是最严重的问题。如果从Wal-Mart来的人说［不］，那您就可以对一大笔订单说拜拜了。理所当然的，许多发行公司会坚持让他们的产品能够打入超商。

还有更多基本的需要很难达成。举例来说，要达到产品的规模与速度可能需要比预期更多的时间，包括了重新设计与重新实施。如果一个产品基础程式很慢，那么要将它最佳化来符合速度方面的需求，可能是一个令人生厌的过程。

如果游戏在设计时，采用的程式库还在测试版本，象是DirectX；那它在完整版本推出之后还是有出现问题的可能。在测试版中的功能可能还不完整，甚至您在测试版设法绕过问题的作法，在正式版中会让机器当掉。

如果在一个现有的系统上面，为了相容性而采取严格的需求（举例来说，一个系列的游戏是依靠同一组基础的资讯，或是一个多人连线游戏需要与第三者线上伺服器的界面相容），那么系统将比预期的状况，需要更多的测试、设计与施行。一个很好的例子是Blizzard的Battle.net伺服器软体，它是免费的网际网路多人连线游戏伺服器，可以提供给Blizzard的游戏《星海争霸》与二代《暗黑破坏神》（译注：现在又多了《魔兽争霸白金版》与《魔兽争霸3》）。一般而言，与其他系统的界需需求可能不在小组的控制之下，而会导致无法预期的测试、设计与施行。

如果您的小组想要的是一个跨平台的相容性，那实行与测试会花上更长的时间。许多事情可能在跨平台的研发中出问题，包括了微妙的［标准］API与处理器类型的不同。

研究：结果

如同前文提及，研究的本质是无法排入时程的。您无法把本质属于无法预测的行动排上时间，所以您能做的最佳做法，就是被迫把研发放入您的时程表时定出一个结算日期，让您有时间想出一个突发的计划，来应付研发结果一片空白的情况。

研发最大的问题在于：要把游戏推到最新的水准时，免不了要把时程表拉长，而且拉长的程度还无法估计；还有，您无法靠着任何最佳研发人员的保证，来估算出正确的日期。研究一种研发者可能还不熟悉的新领域元件，可能会花费比预期更长的时间，因为他们必须先去熟悉那个领域的东西，才能展开工作。

企划的其他区域也可能要依靠研究与研发方面的模组。如果没有合适的突发计划，那唯一的选择就是让整个企划停下来，等候研究的成果出炉，更容易拉长整个时程表。

整个重点在于您应该避免落入这种局面。在一个企划的时程表中，如果想靠着研究的结果无异是自找麻烦。这就是为什么研究应该在时程表以外来进行的原因。

过程问题

最后一个章节很详细的讨论了［过程］，而且谈及它如何用来为您的企划提供精确的状况，而且一般来说可以让您小组中的人们生活轻松点（如果他们一开始就抗议，那不算！）

我们将要简要的回顾一下这边的主题，并讨论过程是如何误用，对企划最后反而造成伤害，并让组员活在悲惨的世界之中。

官僚作风与繁文褥节

有些管理者由衷信任过程…不幸的是，太信任了也不好。他们会尝试在您找个喷嚏的时间，塞给您三大张的文件叫您签名。我曾被一家公司要求，连每天在厕所花多少时间都要写下来，这样他们才能计算并扣除我每星期应该花在工作上的时数！

过程（在初始的学习曲线以后）从来就不该是个麻烦。它通常不会太难做到；唯一的困难就是刚开始就［没有过程］到［有些过程］的环境演变。

不过，在某些情况下，要填写的文件可能会过多。如果一个工作产生了不正常的文件作业，那就应该查看一下流程是怎么跑的。［过程］应该是用来协助员工，而不是妨碍他们；如果他们在很多地区填写了相关的资料，那这些收集资讯的过程应该加以修改，去除不必要的部份。您应该用越简单越好的方式来完成文件填写，让它很容易完成，而且更容易修正。没有人想要重复相同的工作，只是用来填写一样的资讯；所以尽可能的确定这个过程够合理而且不冗长。太多的纸上工作也可能导致进度的延缓，而您关心的事项，也应该要包括员工在写给管理部门的报告时，不用花太多的时间：把定期的会议取消，因为这会花费大量的时间去做进度报告；只要叫大家用电子邮件来回报所有考虑到的问题，并用同样的方式回复所有人的意见。

误用与制度

如果没能正确的运用，采用的程序再广泛也没有任何意义。研发者的天性就是尝试避免他们认为没有生产力的工作，而这包括了程序的品质，除非有人向他们精确解释其中的好处。

这也可能在数种不同的情况下遭到误用。举例来说，如果没有好好进行刚开始的前置品质保证行动（这将会从想要［省时间］的想法开始蔓延），然后最后的结果很明显会把［省下来的时间］花在延期耗时的修正上，并让时程表延误。

如果状况与缺席没有正确的追踪回报，那它很可能会忽视掉早期的警讯。而追踪不正确的结果会导致品质问题，导致时程表受到忽视，一直到企划的晚期才会发现。在这个时期，一切都可能太迟了。

缺席应该视为十分重要的一组统计值。它也只是在一个企划中，影响知识学习的方法，所以可能有助于下一波的研发。这个资讯太贵重而不能忽视，所以应该要精确而且持续的记录下来。如果这些资料无法充份的收集，这将会导致您不知道究竟落后时程表多远，直到您的企划接近尾声。

如果风险管理的程式并没善加利用缺席，那就有可能无法事先侦测企划中的主要风险，让企划就此跨台。如果您要买一个烟雾侦测器，就不应该把它放在盒子中，连电池都不装。

拘于形式的问题

在一般的软体企划中出现的拘于形式，要比游戏产业中常见多了，而这一点对游戏产业并不是什么好事。

不重视形式（忽视研发过程）会导致缺乏沟通、品质不良的成品、以及大量的修正。不尊重形式通常要比不采用更糟，它会让员工误以为很安全。如果完全不采用的话，至少他们知道后面会出现什么。

相反的情况也是问题：过度形式化（过度官僚作风，强调用程序与标准的文字来鞭打员工）将会导致不必要的时间浪费。员工会把他们的大部份时间，花在填写这些过程的报告上。

一定程序的过程是个好主意，好处可以为您的企划，在一些额外的工作中获得大量的优势。技巧在于找到它的平衡点。

相关日志推荐

• 2009-03-12 — 《电脑游戏结构与设计:理论篇》第十一章 软体工厂【转】
• 2009-03-12 — 《电脑游戏结构与设计:理论篇》【全集】
• 2009-03-12 — 《电脑游戏结构与设计:理论篇》第十四章 产业的未来【转】
• 2009-03-12 — 《电脑游戏结构与设计:理论篇》第十三章 程序与［过程］【转】
• 2009-03-12 — 《电脑游戏结构与设计:理论篇》第十二章 里程碑及期限【转】

© 达达尼昂 for 游戏策划 Game Design, 2009. | 《《电脑游戏结构与设计:理论篇》第十五章 疑难排解【转】》 | 暂无评论 何不沙发 | Add to del.icio.us
Post tags: 游戏企划, 游戏开发, 游戏设计, 电脑游戏结构与设计

第十一章　软体工厂

＊软体工厂所解决的问题

＊设定一个软体工厂

＊使用一个软体工厂

＊软体工厂的可适性

在第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++研发经验打下了基础；°这种状况下的研发速度与效能都十分出众。在可能的情况下，在各种规模的小组上建造出软体工厂结构，得到的结果也会让人满意；就算它会让部份的研发人员，在不习惯的情况下产生反抗心理，而且管理部份也必须等到较为后期才能看到游戏结果，臭虫的修正也有可能拖到游戏发行之后。

最后的讯息

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

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

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

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

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

相关日志推荐

• 2009-03-12 — 《电脑游戏结构与设计:理论篇》第十五章 疑难排解【转】
• 2009-03-12 — 《电脑游戏结构与设计:理论篇》【全集】
• 2009-03-12 — 《电脑游戏结构与设计:理论篇》第十四章 产业的未来【转】
• 2009-03-12 — 《电脑游戏结构与设计:理论篇》第十三章 程序与［过程］【转】
• 2009-03-12 — 《电脑游戏结构与设计:理论篇》第十二章 里程碑及期限【转】

© 达达尼昂 for 游戏策划 Game Design, 2009. | 《《电脑游戏结构与设计:理论篇》第十一章 软体工厂【转】》 | 暂无评论 何不沙发 | Add to del.icio.us
Post tags: 游戏企划, 游戏开发, 游戏设计, 电脑游戏结构与设计, 软件工程