Posted: 三月 12th, 2009 | Author: 达达尼昂 | Filed under: 资料收藏 | Tags: 游戏企划, 游戏开发, 游戏设计, 电脑游戏结构与设计 | No Comments »
电脑游戏结构与设计
第十五章 疑难排解
＊风险
＊主动与反应式的疑难排解
＊变更控制
＊突发规划――［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与处理器类型的不同。
研究：结果
如同前文提及，研究的本质是无法排入时程的。您无法把本质属于无法预测的行动排上时间，所以您能做的最佳做法，就是被迫把研发放入您的时程表时定出一个结算日期，让您有时间想出一个突发的计划，来应付研发结果一片空白的情况。
研发最大的问题在于：要把游戏推到最新的水准时，免不了要把时程表拉长，而且拉长的程度还无法估计；还有，您无法靠着任何最佳研发人员的保证，来估算出正确的日期。研究一种研发者可能还不熟悉的新领域元件，可能会花费比预期更长的时间，因为他们必须先去熟悉那个领域的东西，才能展开工作。
企划的其他区域也可能要依靠研究与研发方面的模组。如果没有合适的突发计划，那唯一的选择就是让整个企划停下来，等候研究的成果出炉，更容易拉长整个时程表。
整个重点在于您应该避免落入这种局面。在一个企划的时程表中，如果想靠着研究的结果无异是自找麻烦。这就是为什么研究应该在时程表以外来进行的原因。
过程问题
最后一个章节很详细的讨论了［过程］，而且谈及它如何用来为您的企划提供精确的状况，而且一般来说可以让您小组中的人们生活轻松点（如果他们一开始就抗议，那不算！）
我们将要简要的回顾一下这边的主题，并讨论过程是如何误用，对企划最后反而造成伤害，并让组员活在悲惨的世界之中。
官僚作风与繁文褥节
有些管理者由衷信任过程…不幸的是，太信任了也不好。他们会尝试在您找个喷嚏的时间，塞给您三大张的文件叫您签名。我曾被一家公司要求，连每天在厕所花多少时间都要写下来，这样他们才能计算并扣除我每星期应该花在工作上的时数！
过程（在初始的学习曲线以后）从来就不该是个麻烦。它通常不会太难做到；唯一的困难就是刚开始就［没有过程］到［有些过程］的环境演变。
不过，在某些情况下，要填写的文件可能会过多。如果一个工作产生了不正常的文件作业，那就应该查看一下流程是怎么跑的。［过程］应该是用来协助员工，而不是妨碍他们；如果他们在很多地区填写了相关的资料，那这些收集资讯的过程应该加以修改，去除不必要的部份。您应该用越简单越好的方式来完成文件填写，让它很容易完成，而且更容易修正。没有人想要重复相同的工作，只是用来填写一样的资讯；所以尽可能的确定这个过程够合理而且不冗长。太多的纸上工作也可能导致进度的延缓，而您关心的事项，也应该要包括员工在写给管理部门的报告时，不用花太多的时间：把定期的会议取消，因为这会花费大量的时间去做进度报告；只要叫大家用电子邮件来回报所有考虑到的问题，并用同样的方式回复所有人的意见。
误用与制度
如果没能正确的运用，采用的程序再广泛也没有任何意义。研发者的天性就是尝试避免他们认为没有生产力的工作，而这包括了程序的品质，除非有人向他们精确解释其中的好处。
这也可能在数种不同的情况下遭到误用。举例来说，如果没有好好进行刚开始的前置品质保证行动（这将会从想要［省时间］的想法开始蔓延），然后最后的结果很明显会把［省下来的时间］花在延期耗时的修正上，并让时程表延误。
如果状况与缺席没有正确的追踪回报，那它很可能会忽视掉早期的警讯。而追踪不正确的结果会导致品质问题，导致时程表受到忽视，一直到企划的晚期才会发现。在这个时期，一切都可能太迟了。
缺席应该视为十分重要的一组统计值。它也只是在一个企划中，影响知识学习的方法，所以可能有助于下一波的研发。这个资讯太贵重而不能忽视，所以应该要精确而且持续的记录下来。如果这些资料无法充份的收集，这将会导致您不知道究竟落后时程表多远，直到您的企划接近尾声。
如果风险管理的程式并没善加利用缺席，那就有可能无法事先侦测企划中的主要风险，让企划就此跨台。如果您要买一个烟雾侦测器，就不应该把它放在盒子中，连电池都不装。
拘于形式的问题
在一般的软体企划中出现的拘于形式，要比游戏产业中常见多了，而这一点对游戏产业并不是什么好事。
不重视形式（忽视研发过程）会导致缺乏沟通、品质不良的成品、以及大量的修正。不尊重形式通常要比不采用更糟，它会让员工误以为很安全。如果完全不采用的话，至少他们知道后面会出现什么。
相反的情况也是问题：过度形式化（过度官僚作风，强调用程序与标准的文字来鞭打员工）将会导致不必要的时间浪费。员工会把他们的大部份时间，花在填写这些过程的报告上。
一定程序的过程是个好主意，好处可以为您的企划，在一些额外的工作中获得大量的优势。技巧在于找到它的平衡点。
Posted: 三月 12th, 2009 | Author: 达达尼昂 | Filed under: 资料收藏 | Tags: 游戏产业, 游戏开发, 游戏设计, 电脑游戏结构与设计 | No Comments »
电脑游戏结构与设计
第十四章 产业的未来
＊阶层化的［大众化市场］
＊变动的管理技术
＊电影工业的模型
＊让小组运作
＊产业的成熟
＊线上的革命
＊调整的可能
这个章节包括了我们对游戏产业未来的最佳猜测，以及整个游戏市场中会发生的事。而如同这个世界没有照预言在1999年7月走进世界末日，没有人能够成功的预测未来――至少不是现在。
我会在这个章节中，以我相信未来产业会发生的事，试着为企划找出一些可行的方向。
我猜的每一步统统都错是很有可能的；但是，如果平均法则仍然有用，那至少我会猜中几件事。而且，不管怎么样，有些事情是无可避免的；象是线上游戏社群的发展。
游戏产业仍然很年轻。我们已经渡过了［长牙时期］与［可怕的两岁期］（译注：这是指二岁小孩老是把［不要］掛在嘴边的作乱时期）：我们已经越过了黄金年代，那个人人都可以设计并撰写热门游戏，而且什么都可以尝试的时期。我们甚至超越了在卧室工作的程式设计师以及辨称自己将成为百万级程式设计师（大部份都是没有失败过又想出风头的人）的年代。
现在，我们已经到达了这个产业的青年期。一切仍然又美又酷，但我们却不太愿意去尝试一些奇异的点子，而且我们开始把眼睛放在愚笨的商业主义上――这主要是源自于市场的统一与巩固，与电影工业的流行倾向十分类似。
产业的状况
如果我真的百分百诚实，我必须说我对目前的产业状况失望透顶。早期的独创性与热烈似乎已经烧得一干二净。
最近的科技似乎都聚集向同一点。在最新的游乐器中，所有的游戏都出现了类似的外观。三度空间的多边形似乎成为现今的体制，即使是在最谦虚的系统上亦然。
第一纪元
很多有才能的人建造了这个产业。在早先的日子中 ，一个很有热忱的人可以在他的空闲时间策划一个游戏，然后用合适的金钱把它卖出去产。这些日子中可以规划出各种千奇百怪的点子：几乎什么点子都可以卖钱――只要是个好游戏。
不过，并非所有的公司都产出好的产品。有些公司想要推出冒充的产品，在新的家电电脑游戏上面换取现金。随着家中电脑市场的成长，其中相互竞争的公司增加，导致一些较没有效率的组织被挤出了市场。
首先，这是一件好事。会买游戏的人大多很清楚内容或是电脑方面的专家，而且知道他们在买些什么。任何只会生产出低品质游戏的公司，很快就会发现他们的产品不在购买的风潮中，并把他们逼到破产。落到这个局面的公司并不多。
剩下最合适生存与最强而有力的公司，开始在眼光敏锐的市场上展开竞争。这些公司必须找出一个方式，让他们的产品与对手不一样――才能如他们想要的一样，在货架上面一支独秀。
最恶名昭彰的方式就是取得搭售的授权：源自电影的游戏，以及源自小说的电影。没多久，几乎每一个产品都获得其他行业的授权；而且几乎没有例外的是，这些东西都可以用一名［平庸］来形容，产品在冲刺之中完成，以搭上电影销售的列车。在高耸入云的疯狂授权下，各种产品象是洋竽片、榖片或是汽水一样的出现。如果只看独创性，这时的业界水准可以说是最差的时期。
不过，这仍然有一个好处，就是替未来把差劲的公司除掉，只留下最菁华的部份，足以制作出技术精湛（如果他们的游戏亦非原创）的作品。
这就是家用电脑第一纪元的结束。靠着即将来临、威力强大的主机与大型市场的游乐器，事情已经开始变化…变糟。
第二纪元
在大众市场中游乐器的进展，象是Sega Master System与任天堂红白机提供了广大的平台，也增加了销售的潜力。强大的16位元主机――象是Amiga和Atari ST，在大众的心中提升了游戏的名声。
除了区域性的授权以外，在新的游乐器上真的有不错的表现。一波全新原创以及惊人的软体在市场上出现――更多冷眼旁观公司发现，只有几种游戏特别适合出现在游乐器上。然后一波又一波的平庸游戏不断出笼，几乎要把这个市场毁掉。
同样的情况也出现在次世代主机，象是超级任天堂与Sega Genesis（译注：在台湾、欧洲及日本称为Megadrive）。很重要的一点是，不象最近的游乐器朝向3D加速的方向发展，这些较早期的游乐器在硬体上面并没有太大的特色。
不过，持续不断的平台游戏（一向如此）证明了在这些系统上面，可以用最简单的方式来进行游戏研发，所以市场再度掀起大洪水。或许在未来可以预测平台的死亡预兆。以一个塞尔特传说中的女妖精来做比喻，平台之死将会在大量的平台游戏推出之后上演（或者是不管那一种游戏，在该主机上面特别容易设计）。
大约在同一个时间，授权的金矿挖得差不多了。在时间上的增加，会导致游戏的研发越发困难，很难确保游戏能与电影同时上市。如果把电影造势的优点从游戏上面拿掉，游戏就得靠它自己的长处生存下来。很少有这一类的产品成功，而且大部份负责的公司，对这种徒劳无功的表现也很失望。
第三纪元
第三纪元（现今）的游戏产业似乎无法改变增加多边形的现象。3D技术已经占据了社会大众的心智与大脑，而大众市场对游戏的要求，几乎就在我们的身上。
在PlayStation（以及一些PC）上的成功，已经让游戏更容易在主流中撑竿缓行。
亲眼看到《猎鹿人》游戏成为很热门的产品后，这个东西的成功可能会打破所有人的眼镜：所有的权威很高兴的对它大力批评，准备将它打入冷宫；但是再看到它达到的销售数量，游戏世界对它的地位不得不另眼相看。
看来大众市场的玩者――也就是游戏产业一直在追踪的神秘巨兽――对过度科技所搭建的光荣产品没什么兴趣，反而钟情于一个简单、普通的打猎游戏。结论是，这是一个可以取悦完全不同市场人们的产品，而这些人甚至不一定算得上玩者――而且它很便宜。这是一个适合在圣诞节或是父亲节，送给爸爸的好礼物。
有人说，如果您目前产业的状况，要把一个游戏卖出去，能做的游戏类型就没几项。基本上，如果您想要确保您在美国市场的成功，理论上您就该去做一个打猎游戏或运动游戏。事实可能是您该写一个可以被大众市场所接受――象是《猎鹿人》――而不要期待大众市场突然之间对古神或是电浆砲有兴趣。
在英国和欧洲，打猎并不是那么盛行，您唯一可以获得绝对保证的游戏类型就是足球。美商艺电在每年大赛前都会推出一系列的足球游戏，而且行之有年。一些毒舌派的评析人员会暗示今年的游戏不过是去年的装修版本，但这个特定的足球系列，仍然会受到平时不买游戏的玩者青睐，而且它卖得好的另一个原因，在于他们与足球协会签下了许多的运动名星。
同样的事情也出现在美国人的运动中，约翰·乔丹（John Madden）的橄榄球游戏也会在每季热赛时有惊人的销量，但是它的评语和英国的足球游戏也是一样的。
当然了，运动与打猎游戏并不是目前市场上唯一的成功者。产业的一部份越来越清楚，另一个卖游戏的方式在于争论。这是一个吸引全球一般人注意的方法。不过，它就象是大众市场的圣环一样，并不是直接靠着争论来达成的――大部份的人并不想要残暴的谋杀、拟态的人类或是外星人――这只是一个让游戏穿入意识的方法。在这个领域中有二个成功的物件课程，分别为《快乐天堂》和《模拟城市》系列。今天，《快乐天堂》销量超过了400万套，而《模拟城市3000》就有超过200万套的销量，更不用提先前的《模拟城市》与《模拟城市2000》。
名声的挑战
在电脑游戏上的一个新趋势，在于利用名声来推销游戏。这些名声可能是真实或是虚拟的。
在虚拟的名声上，我们有很多方面的选择：玛琍欧、音速小子、罗拉、《萨尔达传说》中的林克、《太空战士》中的克劳德以及一堆东西。玛琍欧和音速小子是分别在任天堂与Sega上面的知名人物。
在《古墓奇兵》中，我们看到的主流人物是萝拉。如果《古墓奇兵》系列没有萝拉·卡芙特与她那庞大的产业，这个游戏会成为文化上面的表征吗？如果萝拉换成另象是印北安那·瓊斯的人物，那电视广告还会把这个人换成世俗中的萝拉吗？我想不会。
Eidos已经利用萝拉的商品来赚取了不少金钱，并在他们制作其他游戏时，同时推销他们的人物。一般媒体对《古墓奇兵》的看法骒，这个游戏已经在光芒中迷失了自我；但是还有很多潜在性的商机。在撰写本书时候，已经准备拍摄一部萝拉·卡芙特的电影（译注：电影已经在台湾下档了），提供了一个不单单把游戏搬到电影的模式（玛俐欧、快打旋风、真人快打），而是把Eidos的金鹅送进去。
但是，随着每一个成功的虚拟名声出现，就把前一个打下去。还有人记得Zool或是Bubsy吗？只要其他公司看到了玛俐欧与音速小子的成功，他们就会想要参一脚。太多可爱但是自大的人物出现，而且――幸好――大部份都在路上死气沉沉，死绝湮灭。
最近，这个倾向让Rare公司设计出Banjo熊、Kazooie鸟以及其他东西。这表示我们会看到另一波可爱的人物？
嗯，有可能，虽然这必须看Rare在产品中如何运用这些人物。可爱而容易一眼看出来的人物（像玛俐欧）可以抓住年轻人的心。不过，游戏的品质与这方面完全无关。玛俐欧与音速小子是定义明确又讨喜的人物，不过如果游戏不够出色，这些人物也不会这么成功。
［这个点子是看你能不能耗掉每一个玛俐欧的物品，如果你可以穿着一件玛俐欧兄弟的运动衫，围巾上面是玛俐欧兄弟的零食，透过一些神秘的方式你可以变形成玛俐欧，或者至少拥有他的部份能力。这有点象是逆向动作的小木偶――有上百万的真正小孩，每天都想要成为数位化的玛俐欧。］
――J.C Hertz,写于1997年Joystick Nation
是的，这就是虚拟的名声。那么真实的名声呢？如果不算那些出现在运动游戏中的明星运动员（这太明显了！），我们可以想到的，只是一些打进游戏市场的人物。
英国的重金属乐团Iron Maiden，目前正推出一张光碟，上面包括了一段以他们吉祥物Eddie为主角的第一人称射击游戏试听音乐。当然了，英国的专业媒体嘲笑这个普通游戏的每一点，最简单的理由在于Iron Maiden不再是流行的尖端。
我一直对英国的专业媒体人员抱持着意见（其中只有象Edge这本负责的媒体除外），他们并不象他们的美国近亲那么成熟。为了这本研究性的书藉，我旅行经过了欧洲与美国，一路上阅读专业媒体的文章。我发现美国人的媒体很具有成人导向，内容倾向平衡而合理的文章；而英国媒体似乎是针对青春期以前的年轻人，写的都是不敬的类似言语。这种角度是美国人产业环节中极力避免的，所以大众市场当然不会乐接受英国的游戏角度。
道格拉斯·亚当（Douglas Adams）是［银河顺风车旅行指南］小说的作者，最近跨足于电脑游戏协助创办了The Digital Village。这个研发者的第一个产品是潦草的冒险游戏《Starship Titanic》，由亚当斯所设计，设定在一个前往一场灾难的星舰上。
汤姆·克兰西（Tom Clancy）是许多政治悬念小说的作者，也在游戏产业中有一片天。相关的成功作品是《虹彩六号》，一个以小说的跨国性秘密行动组织为背景的游戏。
并不只是作者打算来试试身手：著名的［侏罗纪公园］创造者迈克·凱基顿（Michael Crichton），也与游戏界中的Timeline Studios结盟，来设计一个尚未公布的游戏。您可以打赌这个游戏在制作中会不断传出恐龙的叫声。
甚至是老牌明星大卫·鲍伊（David Bowie）与皇后合唱团（Queen）也在《恶灵都市》中小试身手（现在被人冠上了游戏的绰号）。
这些方式都有用吗？大卫，鲍伊真的有办法吸引下赌注的人吗？呃，时间会告诉我们答案。我的观点是娱乐软体现在很新而且具有不同的媒介，可以创造出它自己的明星。如同范伦铁诺（Valentino）与齐柏林（Chaplin）在无声电影的时代都是明星，但是都不会转型到有声电影一样。迪士尼的确在［玩具总动员］中立起了名声，而且其他电影也是，但这都是好玩的，真的。举例来说，他们不会把汤姆·汉克扮演伍迪的声音拿出来当做大卖点。一个名声响亮的动画特色只是有助于提升他们在市场上的形象；它不会变更任何人对它的观感。用好莱坞的说法，可以打开真人拍摄影片市场的明星，没必要去碰动画市场的大门。
在电脑游戏时空中的明星，通常都是虚拟的明星，象是萝拉·卡芙特，而不是真正生活中的名字。凱特·史雷德（来自《时空英豪》）是一个拥有自己意识的人，而且游戏就算找来象布鲁斯·威利（Bruce Willis）这样的大明星来为他配音，也不会让游戏更出色。如果说要有什么，可能一份不调和的备忘录，上面提醒我们［这只是个游戏］，因为布鲁斯·威利的声音实在太好认了：我们知道他不是游戏中的人物。而为史雷德配音的演员大卫·加斯曼（David Gasman）表现的很好，而且事实上正因为他没有那么响亮的名声，协助我们相信这个人物的真实性。这方面的软体媒体需求，可能要避免的是远离象相片般真实的人物，而转向比较有个人风格，象是在好卡通或是漫画中的表现一样。想想蝙蝠侠的电影与卡通的区别，或是看看Rhame这个别具风格的英雄人物，由托比·加德（Toby Gard，也就是萝拉·卡芙特的设计者）所设计的另一个《Galleon》新游戏。这应该可以创造出一个别具特色的人物，并具有特定的声音来搭配，而不是光把一个明星从电影银幕上面搬下来。
游戏中的暴力
近期游戏中的暴力问题越来越严重，主要是因为技术的提升，真实的暴力将会透过图象先表现出来。
《真人快打》是一个恶名昭彰的游戏，主要是玩者可以用各种组合的招式，用残暴的方式让对手以各种不同的方式死亡。其中一个最血腥的画面就是把对手的头骨与脊椎骨拔出来，然后高高的举在空中。如同画面真实的本质，让这个画面在道德方面倍受争议。
在英国，第一个因为有内容而受到评断的游戏，是ZX Spectrum电脑上面的《科学怪人》。一部份的发行者为游戏宣传完全是出于自愿，这个（而不是冷嘲热讽）方式在之后的几年，也套用在数个不同的游戏上。象是《侠盗猎车手》（一个从高空俯视的游戏，可以让您杀伤任何人）因为它的丑名而在法院以［限18岁］以上才能玩，反而声名大噪；甚至英国的公关专家麦克·克里福（Max Cllifford）也被叫来为这个游戏宣传。他靠着在报纸上大幅刊登的冷酷文章，以及［禁止这个下流东西，现在！（Ban this fith,now!）］的标题，让销售竄升到屋顶去。
为了宣传他们的盗匪游戏《流氓大亨》，Eidos雇用了［疯子］法兰基·福拉瑟（“Mad”Frankie Frazer，在［Kray Gang］中一个恶名昭彰的成员，曾经在1960年入狱）出现在欧洲电脑贸易表（ECTS）。这个作法受到媒体的唾弃，被视为下流的大众宣传手段。为了回应这一点，福拉瑟马上减少出现在大众面前的次数。不管这种出风头所产生的效果，强迫《流氓大亨》映入大众的眼中有可能妨碍或是帮助游戏的销售。
《终结狂飙》虽然是受到Paul Bartel的电影《2000年死亡大赛》（Death Race 2000）的激发，不过该电影以讽刺社会的手法，让观众从暴力之中引出娱乐效果，这个讽刺手法在游戏中却看不出来。刚开始，发行公司不得不把徒步的行人换成喷绿血的僵尸，因为审查员认为红血太过真实了。他们指出您车辆在地面留下的红色轮胎纹太具攻击性，而且在游戏完成修正之前拒绝推出。
专业媒体对这个作法发出嘘声不满，要求他们的游戏要有鲜血与内脏。以怀旧的眼光来看，这并不是好点子，因为它只会对整个产业造成负面的影响。如果产业界无法自我约束，那就必须接受外来的审查，这不只让发行公司高兴不起来，而且也无法为顾客提供良好的产品。
《终结狂飙》的发行公司显然是要对抗审查小组的决定，而且他们真的把对方打翻，让他们推出了完整的血腥版本。但是，在看到一些业界的人员已经［非官方］的推出了鲜血更新档，这还是有点过头。我个人还是比较倾向僵尸版本的气氛。
很有趣的，当微软在近期推出了一个赶时间的赛车游戏《疯狂城市赛车》之后，英国方面的专业媒体中，有一些较不负责的人员居然抱怨他们不能开上人行道去压人。他们老是打算在最后一刻跳出正轨，采用70年代的车辆电影观，象是［Cannonball Run］。
这还真的在数篇评析中被列为缺点，而玩者不能开上人行道去压人成为最大的缺点。这真的有点病态：让玩者去压死路人并无法让游戏变得更好，而且也不影响游戏中驾车的感觉。如果杂志的评析人员觉得他们的评语有正确的理由，那他们可能看电脑萤幕太久了。我会建议他们出去吸点新鲜空气，感觉真正的世界，直到心情好一点为止。在对照之下，美国的媒体觉得游戏中不致命的本质，是可以加分的特点。
《喋血街头》这个游戏是以一个真实的导陋事件来命名的。这个事件中邮局工人回到他之前的工作场所，然后用枪枝攻击任何视线中的人，并不是为了现金而是为了暴力。
这个游戏的广告中包括了所有媒体加诸的责难，并用来当做大家该买游戏的理由。不管如何，媒体并没有让《喋血街头》符合任何大众市场的喜好――在刚开始的兴趣以后，销售很快的跌落。
一个祖父级的真实暴力游戏《毁灭战士》，被人批评导致美国许多学校枪击事件。这让道德权威人士大声疾呼，必须把电脑游戏中的所有暴力连根拔除，而数个集体诉讼的法律案件，也对着数家发行公司展开。
一个电脑游戏不可能把一个理性的人转变成一具杀人机械。唯一的可能是这个人本身就有问题。
不过，在发生了让人悔恨的悲剧之后，这些回应只是合理的反应了。在发生了让我们忿怒而且惊惧的悲剧时，四处找寻目标来加以责难，是人类的正常本性。
据我所知，大部份在地球上的人都玩过《毁灭战士》。这是一个发行最广、玩者最多的游戏：我当然也在空闲时玩这个游戏，但是我不会觉得十分暴燥，想要拿出散弹枪或是链锯来攻击别人。
再说一次：游戏并不会导致暴力。它们可能让一个有问题的人，具有较强的暴力倾向，但是一本书、一份报纸上的文章，或是电视影集、一部电影以及我们每天可以看到的上百种酒精饮料一样可以达到相同的效果。事实上，如果是个人的问题，什么东西都有可能成为引暴点。
在1999年7月的日本，一个年轻人手持小刀劫了一台飞机，并以割喉的手法杀死了机长。为什么？因为他要象微软《模拟飞行98》一样，从下面穿过东京的彩虹大桥，而驾驶员拒绝这样做。
这是否表示模拟飞行游戏应该禁止？微软应该被市场控告，因为他们写出危险的产品？
不。这实在太荒谬了。一个民主社会的基石，在于人们对他们的行为具有理性的判断。光是靠着［是恶魔要我这样做的］做为答辩，应该是在耶路撒冷女巫审判时讲的话，如果目前还在那个年代，这句话或许还有用。这基本上每次都会出现一些新东西。在17世纪的英格兰，奥立佛·克伦威尔（Oliver Cromwell）的政府关闭了剧院，因为他们认为戏剧是一种颠覆的技术，会导致人们坠落。在早期的戏剧中，黑帮的电影倍受攻击，是因为他们相信美其名的暴力会导致社会上的问题。哈沃·霍克（Howard Hawks）的电影［Scarface］被延后了二年，以加入一些反抗暴力的场景来取悦道德权威；它最后在1932年以［Scarface:Shame of a Nation］推出，还是受到各方面的责难――但这在今天却以经典看待。电视与漫画书也受到相同的待遇，被骂成社会的疾病（早期的1950年评论家把电视看为［一个吓人的潘朵拉之盒］），现在轮到电脑游戏了。
图15.1显示出目前市场的结构。游戏高手的市场只会购买到顶尖的好游戏。接下来是一个庞大浮动玩者的基础，只有在他们透过任何管道看到有兴趣的游戏时，才会买一个游戏，象是相关产品一样。最庞大的区域，大众市场，是哪些在普通情况下不买游戏的人。这些人是游戏产业视为金牛的人们――而暴力游戏并非打入这个市场的路线。同样的，超级暴力的日本动漫画电影也不受大众市场的青睐，在游戏中的暴力行动是一种特别的品味，只有狂热者才会欣赏。它只是刚好成为大部份玩者，在这个时候成为同一个狂热的党派。如果您想要人们把您请入他们的家中（这与他们购买您的游戏一样的），您很明显的需要承诺可以用合理的方式来取悦他们。大众市场绝对不想把会冒犯并吓到他们的游戏带回家。
产业在未来描写真实性的暴力时，采取的态度应该越严肃越好。电脑游戏在生活中占的成份越来越重，而且有更多的家庭会参与；游戏也不再只是15到20岁年轻人的专利品。事实上，传统非电脑基础的公司，在进入这个市场之后也有很成功的产品（象是乐高与芭比产品）。虽然它们受到高手级的研发人员所嫌恶，但的确表现出业界在这几年来的变化。
适合家庭的内容需求与日俱增，而且这表示暴力的内容最好经常受限，才能保护年轻人，并让父母安心。
推出象是《黑街太保》的游戏，显示出游戏在描述暴力上比以前更为主动，而且也更为真实。不管这种方向会不会增加游戏性，我个人宁愿让它在游戏性上有销售的价值，而不是比较里面的尸体数量。
如果一个游戏中有适度的暴力，我并不觉得有任何不妥，只要它处理得很好。举例来说，在《时空英豪》中的英雄对抗的是军事议会，采用暴力的高压手段来控制和平的人们。这个英雄是海豹部队的成员，而且对武器十分专精，而且从背景故事来看，他很明显没有任何暴力倾向，而是一个负责任的士兵，只有在没有任何选择的情况下才会运用暴力。在目前，电脑游戏中的暴力都是不平衡的――与道德有关的暴力很少拿来使用，只是让免费的暴力四处散布。把这一点与戏剧或是文学相对照之下，暴力最后也会落在猎杀者，甚至是受害者身上。暴力的出现一定与道德有关，而这一点应该是任何游戏运用暴力的一部份（另外提一下，要表达出道德与暴力之间的关系，并不是指您一定要在游戏中处罚任何使用暴力的人，那是游乐场中的道德。一个成熟的艺术，可以利用各种方式来呈现一个困难的主题，并在不说教的情况下探索每一个主题）。
［游戏在历史上十分依赖暴力，有二个理由。首先，游戏玩者大部份都是青少年（至少第一代是如此）；第二，技术限制了游戏的环境，让太复杂的互动难以实现…所以Sony的下一代PlayStation2处理晶片，叫做情感引擎（Emotion Engine）不是没有道理的］。
――引用自1999年9月Edge，丹米斯·哈撒比斯（Demis Hassabis）文章
每天的生活中都有暴力。您会在电视上、报纸上看到。身为一个顾客，我在这方面不觉得有问题，但是我觉得会有问题――而且我认为在未来是件大事的是――对于暴力的美化与赞扬。如果您的目标市场只是一小群的青少年还好，但那不再是我们的市场了。我们的市场现在包括了很关心的父母与祖父母，而且您可以确定的是他们不会欣赏过度的暴力。当他们知道游戏的内容可能会引发麻烦，当然不会在孙子的生日去买一套《黑街太保》当礼物。
［刚开始在画面还十分基础时，您能做的就是给人物一把枪，然后看看他可以打倒多少人。随着科技越来越进步，游戏将拥有更多的想象，将有更多的有趣剧本，而不是更普遍的暴力。］
――丹米斯·哈撒比斯（Demis Hassabis），《快乐天堂》的创造者，也是Elixir的创始人之一
我已经指出百事达中的电影并不一定要避开暴力，不过在一个电脑游戏中，玩者参与的感觉要比电影来得强烈。但是，电脑游戏有可能更有严格管理的必要，因它和电视一样都是家中的东西，所以成人会很困扰的就是他们的小孩也会暴露其中。还有，电脑游戏是互动的――当我们看到电影中的暴力时，那只是导演把我们卷入的手法与技巧；但是在一个电脑游戏中（如同现实生活一样），除了自己以外，没有人会尊重我们的行动。
孩童产品
一个目前被大家所忽略的市场是孩童市场。只有少数几家公司，试着扭转这个可能性。
这是我认为具有最大成长潜力的区域。并不是因为这些［育教于乐］的产品――他们尝试的教育方式乏味至极――而是二个分离的孩童教育产品与娱乐产品。
我在这边可能有错。很多人看来象［育教于乐］型，但是我个人认为这对孩子而言并不公平。最近，我有一个机会在这方面做了一些研究，我把一个二岁大的孩子放在PC前面，提供一些芝麻街方面的教育软体，让他的母亲玩几个星期。当我回来查看他在二星期之后的测试进度时，我很惊讶的看到这个二岁大的小孩很有自信的在使用者介面中四处游走，点选游乐街的地点并全面沉浸在其中。不过，我并没有她的母亲来得惊讶，她告诉我他已经可以分辨出画面上的数字0到9。
这个广大的市场仍然没有人把门给敲开，而且我很确定的预测，孩童的市场在接下来的几年应该是具有最大幅度成长的区域。不管您给成年人的东西有多酷，这都是您没看到的珍珠。
就算是类似Cyberlife的公司（《Creatures》与《Creatures2》）也正在尝试利用简单版的《Creatures》游戏打开这道门，称之为《Creatures Adventures》。
［《Creatures Adventures》设计在哲学中到处游走，您的目标是教导并指引您的生物，来应付这个世界的其他东西。这个产品提供了积木般的方块，可以让你建造他们的经验，而不用强迫他们按照你的模式来走动。］
――摘自于Edge杂志1999年9月号，设计者班·辛普森（Ben Simpson）所言
不管他们采用了正确的方式，或是掉到［帮助Roger Raccoon拯救他的礼物，只要用数字木头来算出总和就行了］的老掉牙方式，我对这方面的特定产品抱着很大的希望。这个人工生命为基础的《Creatures Adventures》表示小孩可以自由的探索并实验自己的步调，避免过去孩童软体中，老是用同样的架构加诸于孩子的身上。
研发者的新模型
目前正是困难的局面。如果一个研发公司光想靠着他们的游戏来赚钱是十分困难的。关键在于成功是要靠影响力。这可能靠着技术本身来达成（象是把引擎授权给其他的游戏公司，或是非游戏界的公司），也可以靠着创意的IP（智慧财产权）――《黑街太保》出售相关的服装，萝拉·寇芙特出现在漫画与商业行为，依此类推。
在这个时候，以现有授权为基础的游戏（象007黄金眼）要比用人物为基础的自制游戏（象是《神通鬼大》）卖得好，有三个理由（摘自：研发者杂志）。不过，您必须记得您的授权是花钱买的，而您可以期望利用自己自制的智慧财产权来生钱。
一个对照是流行产业，在巴黎服装秀中的设计永远都不是给大众市场大师消费用的；不过它们会获取注意力，展现出才华，而且描述了这一季的主要流行驱向。如果服装秀成功会有加分的效果，但这并不是主要的；凡赛斯（Versace）可以在一场展示之后把所有的服装秀服装统统丢开，还是可以赚进上百万。
我在看到象是Valve的《战慄时空》这种游戏时，真是感到十分的自豪。他们是在我们的基础上面建造，而且做了十分壮丽的表现。我并不是光坐在这边然后想：［我们也做的到这一点］；相反的，我们想［嘿，我们有从里面抽授权金。］
――摘自于Edge杂志1999年4月，约翰·卡麦克（John Carmack）
影响力也可能来自内部。对一个小型的研发公司而言，重复使用是唯一可行的方法――您完成了一个游戏的时候，您目前使用的技术可能已经很旧了。所以连续使用之下的价值就会很差，但是同样进行（也就是把相同的科技、设计理念，甚至是图案在数个企划上面并行）就是不只是优势，在经济看来也是必要的。
很明显的，一个单独的研发公司，里面只有20位员工很难达到内部同时运行的目标。所以，在接下来的几年中，我们将会开始看到产业间的统合。少数的［超强发行公司］将会出现（我们现在已经看到第一家了），而且将会进展为一个很接近拍摄电影的系统。这包括了一个中央集中或是资源收集的中心。
有二个更具启发性的方式是Gathering of Developers（以下简称GoD）联合系统以及由彼德·摩利纽斯的公司Lionhead Studios，所采用的卫星结构。这二家公司采用的方式，是集结一些佔优势的研发人员，并对着附属的研发小组社群，提供支援与协助。
案例研究15.1Gathering of Developers的宣言
下列的内容是摘自Gathering Of Developers(www.godgames.com)的网站。
Gathering of Developers，一个位于德州的电脑与游乐器发行公司，创始于1998年1月，基于产业需要一个能够了解并尊重独立的游戏研发者，而设立的发行公司。在得到他们过去的发行经验与坐挫折的协助之下，数个经验丰富的热门游戏研发公司结合在一块，形成了The Gathering，一相关的发行公司，以［专业娱乐艺术家］的眼光，来看待研发者。
目标签名
The Gathering的任务并不是建立自己的品牌，而是建立公司与合作公司的价值，以推广研发者及其游戏。我们的主旨很简单…把研发者与它的创造建立品牌，让顾客可以轻易的辨认出有品质的产品。
独立特色
在专注于品质而非数量之下，The Gathering可以提供研发者全面性的AAA级市场高手，以及在他们产品的销售上面，提供一个有利的折算率。
因为The Gathering的根源，从创始开始就源自于游戏研发，公司在产品的领域与研发部份提供了非平行的专家意见，并以决定合适的研发与里程碑周期来进行认可。
在选择过程的部份以其优点、追踪记录和技术与商业上的可行性来决定。公司也尊重研发者的权利，并鼓励他们保留他们本身的智慧财产，而不要以金钱为优先。游戏研发者应该拥有不可剥夺的权力。
要把这个模型想成一个没有希望的乌托邦并不难，很象1919年是United Artists对公开的艺术的看法：
（电影）Mary Pickford,Douglas Fairbanks与Charlie Chaplin和D W Griffith导演，创始了UnitedArtists，成为一个合作组织以发行他们独立完成的产品。United Artists绝对不会拥有制片工作室；相反的，它所发行的特色影片是由制片家在他们本身或是租用工厂中完成。
――接自Cinemania中的［United Artists］（微软，1997）
如果您把United Artists原来创始者的出发点，视为创意远景方面的失败，就表示您没有看到重点所在。这种联盟的优点很多，最重要的一点是，从商业上的观点来看，可以分享技术性资源与管理，所以任何的参与者可以在经济上的销售获利（举例为说，有多少小型的独资研发公司，可以担得起一个动作捕捉系统的费用？）其次，这个建立出来的中央工作室太傘，将可以在下面培育新人：就算是个最优秀的研发小组，在刚开始时仍然得面对许多问题（确保投资、说服房东给他们办公室的空间，安排银行中的贷款），小组这部份的问题得以缓解。第三，中央工作定可以把有才华的结果保留下来，所以在这个系统中的个体绝对不会被闲置。第四，在把研发财务问题与发行公司脱鉤之后，研发小组可以确保得到更多更高的权利金（详见案例研究15.2），而且至少工作室可以保护他们的品质控制，这一点对发行商或是顾客而都是好事（所以GoD强调的重点在于竖立品牌）。
案例研究15.2 研发者难为
一年之前，我被拉入了一个小组之中，并为商业计划之下的初生研发公司，设计结构上面的规则。他们从一个发行公司手中获得了开创时的初步资金，所以看看他们谈好的发行合约，来推算销售与收入预估是很有趣的。
他们的权利金从20%起跳，在卖到35万套时升到25%。这让他们大约在卖到37万5千套时才开始获益。在把这一点与发行公司谈过之后，他们设定了一个补偿，让游戏在20万套之后可以回本。
发行公司不这样安排实在没道理。不管怎么说，这个风险应该由他们来担――这可是他们的二百万元！结果是，他们只是建立了自我保护的措施，象是银行的投资必须象放款一样有利息收入，或是冒险资本中的风险一样。
公司的创办人有一些对自己事业的创意。在确保了发行公司的稳定利益之后，他们可以安排自己的投资（从生意上的后台老板）以取得稳健而公平的股权。这甚至可以让他们把完成的产品与其他顶尖的产品竟标，可以把授权金飙到将近45%。顺便提一下，这个后台老板也可能为一个游戏而设立一个特定的公司，就象好莱坞的模式一样，每一部电影都有可能成立一个新的公司。这表示研发小组也可以成长到担下另一个企划，而不用在一开始就对一个游戏［出卖灵魂］。
为了在卫星结构中取得全面的优势，独立的小组会全面运用分享出来的资源，如同我们在软体工厂所建议的方法一样。找数个独立的小组在技术分享的合作结构下，并无法达成它原先的希望：唯一的方式就是正统程序。
这种方式类似电影工业的研发模型，拥有一个中心的创意核心，然后被踢除的设计与研发，将雇用独立的人员或是承包商的小组，来进行程式上的筹备工作。不过，您不会想要在您的产品中，采用没有足够资料或是非您所要的元件。这表示：
＊创意核心必须监督企划。某个从创意核心而来的人，必须保留全面控制权。传统上，我们可能期望这个人是本产品的制作人，但更可能的方式是转由设计导向的控制方式，所以我们或许可以预期是由企划来领导，比较接近一部电影中的导演角色。我会预期这种工作方式（每个人都可以扮好自己的角色），在您与一些先前合作过而且可以信任的独立小组时有最好的效果，或者您可以把承包商带入您的位置，以取得各种资源。
＊必须有一个标准化的设计方式、程式库与相关东西。如果我在拍电影，我可以和我手下的导演看到分镜，并讨论光线的安排，这样我才能确定他会照我想要的方式来拍。我们需要在研发中有同等的普遍标准。还有（最特别的），有些研发者会慎重的选择，以定义出他们的独特标准――您把只有出现在Navajo字典中的东西拿出来，去怀疑福尔摩斯电视网为什么不这样讲，是没有办法帮您找到工作的！
GoD与Lionhead的模型似乎是设计用来创造一种我们正在讨论的［超级研发者］模型。Lionhead的卫星构造会学习做事的基本方法（无论如何，他们的确有这种潜能）：他们分享资源，而且他们相互信任执行时的标准。还有，象是彼德·摩利纽斯这样的超级研发者，可以使用这种结构在一年展开几个企划，而不是每二年只做出一个。假设这个明星的品质（也就是做出AAA级产品的能力）让发行公司愿意付钱，那么让指导的天才不会绑在一个企划，去注意每一个细节是很合理的做法（当然了，这会让研发公司更容易了解全面的设计是少不了的。尤其是他们必须认识测试台是设计阶段用的东西，而不是研发阶段的产品）。
［超级研发者］之所以成为领导方针，是因为发行者（或是他们的股东）已经要求：［为什么我们要在研发中绑这么多的钱？我们是从发行来赚钱的！我们不是在开银行！］在几年以前，很多发行公司直接在内部研发上投资。这表示要养大量的研发人员，任何时候都在烧钱，对一个中型的发行公司而言，相当于上百万美元。少数倾向部份资助独立的研发工作室，或是（从一个发行公司的角度来看）只是购买一个完成的游戏，然后在没有风险的情况下送入市场。
所以，我们会看到一种类似电影工业财务结构的倾向，由发行公司或是主要的工作室来提供自信。Sony公司的总裁最近举例，在世界上面只有五个研发者。这些超级研发者将会与环球或是派拉蒙齐名。这些研发者会构成才能的创意核心，象是软体工厂的在大规模时的设计与结构模式一样。当然了，并非所有的人员都必须是长期员工，就象作者可以从一本书的发行公司换到另一家一样。如果您刚好是投资的银行家，这方面的课题已经很清楚了：您可以在一个超级研发者身上丢个二千五百万，但是不要在一个小的研发小组中浪费掉二万块，因为在这么高的风险下，您永远都不会有回收的。
有些企划是源自于超级研发者的［工作室］。这方面的优势如同我们在案例研究15.2中看到的一样，就是您不用找投资者（后台老板或是其他人）来直接购买您公司的股份。他们想要投资《Shudder》这个游戏时，就直接把钱丢进［Shudder公司］；在这种基础上面，并不会稀释掉您的核心部份（如果《Shudder》卖得很好，他们可以从续集以及人物的授权上面持续获利，从投资的观点来看十分理想）。
其他的游戏将会以较小而初生的小组带入公司。举例来说，一个设计者、规划师以及首席程式设计师，可能对一个工作室的老板们做一个概念与技术上的展示，象是导演、剧作家与明星在好莱坞签定合约一样。在接受了一封来自工作室的信函（［我们很有兴趣制作这个游戏…］）后，他们接下来可以从一个银行得到资助并组织一整个小组（象是拍片的人员）。这是共同合作的好例子，也是经济学上面我们称之为［合作优势定理］的东西：投资者有钱但是没有专业的知识，告诉他们这是一个好游戏。工作室有专业的知识但是不想投资比所需要数字更多的金钱，因为他们要守住优先购买权。研发者只是想要开始完成他们的游戏。
但是超级研发者如何赚钱？就算是50%的权利金，在全面的销售价格下滑之下，您将需要卖到30万套，才能吸引投资者的眼光。嗯，首先，销售游戏的收入并不是超级研发者建立出来的唯一资产；它们会拥有很多的IP。除此之外，研发对他们而言十分低廉（这边又是规模经济），而且他们可以负担起多重的企划研究工作，而这一点对小的研发者而言是不可能的。最后，如我们所见，创意上的巨星可以利用这种模式生产出更多的企划。假设席德·梅尔个人每二、三年可能会想出一个游戏，还是他可以每六个月就策划出一个，然后把一部份的工作委托他信任的亲信。您可能认为游戏的品质会受损（如果采用合理的研发程序，我就不这样认为），但是就算真的受损，象这样的名声仍然可以让市场的力量维持健康的状况。
那承包商呢（这些承包商是由超级研发者所雇用的，他们不只负责程式工作，经常也是包括12到20人的小型研发公司）？他们如何赚钱？最简短的答案是他们不赚钱（至少不象权利金那么可观）！他们只是拿薪水的，好处在于这些薪水将要可以与资讯科技产业的主流等值。我们可以举一个类似的情况，在于作曲家用他们的作品换钱；或是在电影方面：导演和制片与明星可以获得丰厚的权利镏金，但是如果您是一个摄影机的操作师，您必须拿薪水才会工作。
那发行公司呢？他们的优势在于买了一个产品，而且这个大家都知道这个名称代表的是具有创意的力量（我可能就是那种人，象是威尔·怀特，或是其他众人皆知的品牌，象是Blizzard）。他们知道这将遵循品质上的标准交准时交件，而且在新的模型中提供的额外信任与减少风险，将值得把权利金加倍。发行公司会继续以很低的风险赚进大笔的钞票，不管零售商尖叫着他们办不到。不过，如同保证会上线或是在网页上面的购买行为一样，发行公司的损失将会越来越小。最后，就逻辑来看，我们只会看到一家大型（以网路为基础）的游戏发行公司。
线上的革命
在十年之后，我看不到人们从商店中购买游戏。如果您有一台电脑（如果您要买游戏的话，应该早就有这个东西），那您为什么不从网页上面直接购买？这不只更为容易，而且您还可以利用观看动画或是试玩的方式，过滤出您想要买的游戏。
线上买游戏
目前的科技趋势，在于让游戏执行的速度加快，而下载游戏的速度仍然不足，产生了一个科技上的空隙。不过，在二、三年之后，它有可能在玩者越来越倾向于网上购买游戏，而让零售业慢慢的消失。
由BT、ICE、电子邮件订购单所看准的Wireplay,正是新创立公司Gameplay.com的着眼点，目前已经出现在AIM市场下面数个月的时间了。Gameplay计划升到310万。Gamplay.com将会提供客户一个完整的线上游戏环境。在与Futuregamer.com合作后，将会为Gameplay网站宣传并提供链结让玩者互相较劲，并透过线上机制与Wireplay的技术来购买游戏，并由ICE来运送。
――摘自1999年7月16日的MCV
Gameplay.com在1999年8月份开始在Alternative investment Market之下营运，成长到460万；要比预期的多出了150万。这个新公司的价值为790万，而且据一些预测看来，应该很快就会让它的资本结构加倍。它在财务方面的部份似乎是信心十足，而这也是未来产业的走向。
在线上订购您的游戏，并不表示您可以从线上获得――不管怎么说，没有人想要把小说下载回来并在家中印出来看，但这并不会影响到Amazon的生意。不过，直接从发行公司的网站下载回来当然是最好的方式。未来的线上发行公司，象Gameplay一样，将需要找一个方式来让下载的速度更快、更简单而且没有麻烦。一个方式是提供一些牟取预览的资料，让这些资料的传输更为快速。我猜，这并不需要是完整可玩的试玩版，象是您现在从杂志附赠的光碟上所拿到的游戏一样。发行公司有很多产品，而且他们要您尽可能的看看他们的动画。所以，我们可以看到游戏试玩的出现，将和电影的广告试映一样会越来越多――将形成一些较小却更完美，足以说明整个游戏是否合您胃口的片断。有兴趣的顾客会在完整近艺术的评析、全面的试玩以及其他任何东西带领下，被一步步卷入游戏中。
要解决下载时间的问题（也就是鼓励使用者直接从他们手中购买游戏的方式），线上发行公司须要建立一个基本的程式库封包，只要下载一次就可以用在所有的游戏上面。然后，在理想的状况下，只有主要的游戏逻辑与图案需要从《雷神之鎚》中传送过来，就可以用在《战慄时空》这种相同基础的游戏中。在这方面，必须结合研发公司与超级研发者，来进行［一次解决］的游戏结构，让他们的游戏可以适应这个架构。在目前，只有微软有可能执行这种规模的企划。
线上玩游戏
最近，一些专门提供线上内容的公司兴起，象是在恐龙群中出现的哺乳动物一样。或许他们相信，其他人会和恐龙一样，在无法适应之下死亡。
或许这一点解释了象是Origin公司，逐渐走入线上游戏，提供了《网路创世纪》的原因，塑造出一个神幻的Britannia世界，让玩者加入其中的社群。不过，这真的只能锁定资深玩者。
资深的网路创世纪玩者一天大约会玩上六到八小时。您可能花个八小时睡觉，然后一些时间用在工作与学校上，剩下的时间就是在上网。
――理查·盖瑞特，在PC Gamer杂志1999年9月的访谈
线上游戏在欧洲会有一段阵痛期，这边的当地电话每分钟都要收取固定的费用。不过，电话公司会达成协议：如果他们把价格降低，大家都做得到生意――如果他们太贪心，就抢不到这块大饼。
另一个线上游戏的主要缺点，在于它们很难有大幅的成长。大众市场对每天都要花时间上网才能玩的游戏没兴趣，他们要的是能够自由选择娱乐时间，而且就算他们没有花时间去养，也不会有什么关系的游戏。线上游戏会变得很大，但是在这个限制下，它不会象权威人士想象的那么广。
最适者生存
唯一可以让游戏研发占用经济优势的方法，就是采用本书描述的过程。我们知道的原因，在于这个方法已经有一个公司在得到发行公司赞助之后，创立采用延续到今日。唯一可以让研发公司在未来还能生存――在合理化过程上仍有压力――就是采用这本书的技术。这些方式都经过尝试与测试，而且已经可以看到它们的优点，要比任何其他的方式更多。
公司现在必须开始实施这些标准与相关的用语，或是直接被丢到路边去。虽然有人会反抗这个说法，但是整体上再不做一点事，结果就是经济效益不足，让研发公司无法营运下去。
如果您取得一个明星的大名或是授权，您就可以卖出上百万套的佳绩。如果没有的话，您顶多能卖到25万套。您的经营计划必须让您能靠着这个成果存活。如果您计算一下的话，您会看到达到这个目标的合理化过程，让您同时省下金钱并减少上市时间的损失，而且可以增加内容的充实性。
Posted: 三月 12th, 2009 | Author: 达达尼昂 | Filed under: 资料收藏 | Tags: 游戏开发, 游戏设计, 电脑游戏结构与设计 | No Comments »
电脑游戏结构与设计
第十三章 程序与［过程］
＊程序
＊［过程］
＊原始码控制与程式码回顾
＊资讯传递的重要性
＊主动与反应的资讯
在这个章节中，我们将会讨论运用软体工厂的概念之后，若想要在成本效率上有良好的成绩，必须进行的程序与实行事项。
不过，这些程序与实行事项并非受限于软体工厂的范畴，它们可以在所有非琐碎的研发中占有优势。大部份在研发中的软体（尤其是游戏软体）在研发方式上面并没有真的程序化，一般的游戏企划在成长时，只是从［稍有系统］到［很有组织］而已。
这个章节中提及从管理观点来看研发过程，而管理的部份则是藉由状况报告以进行控制。满足管理部门的兴趣，是程序与实践的主要理由。
管理者想要取得精确的资讯以及状况的报告，然后以这些资讯来判断未来的行动国，不用打扰研发方面的工作。同样的，研发者不想让管理者不分青红皂白的介入，并在一连串没有重点、浪费时间的问题下，打断了研发的过程。
这些程序与实践将会包括互动的介面与区域，让资讯可以在随时不断更新的方式之下传送，并定义出控制流程，用来引导研发的方向。
这个［过程］并不见得象您想象的那么糟糕，它大部份都是与常识有关的。不过，最好的［常识］，就是把它写下来让每一个人都很清楚这边所指的［常识］究竟是什么。如果每一个人对常识的概念都不同时，它就会碎裂成不同的看法。
这些过程的执行是否要延伸，端看企划的需求而定。一个很重要的企划，就需要用严格的方式来进行：而较不重要的，可以用比较轻松的方式来看待。
程序
在这个章节中讨论的程序类别，都是减少劳力浪费的基本控制与方法，并在低品质的成果污染整企划之前，将不良的部份拔除。
下列的程序列表，是在企划的进行时程中，维持精确企划资讯以及控制的建议事项。每一个程序都在后面的章节中进一步的说明。
＊设计回顾
＊文件回顾
＊技术回顾
＊程式码回顾
＊单元测试
＊整合测试
＊系统测试
＊设定测试
＊后退测试
整体来说，［回顾］行为在找寻与侦测上面，要比单纯的测试来得好；先决条件是把回顾力量集中在找出问题，而不是修正问题。另一个附加的好处，在于回顾也倾向于找出不同类型的错误。
回顾
回顾的格式大体是相同的，只不过回顾的东西不一样。
二种类型的回顾有［正式］与［非正式］。要进行哪一种类型的回顾，端看工作的本质来决定。这个工作与内容有密切的关系，而且正式与非正式的比率，也是由情况来决定（这一切通常是由企划管理者在分派工作时决定的，但是个体的贡献也有可能影响这个决定）。不管怎么说，企划管理者知道工作究竟有多复杂，所以他（或她）应该可以说明哪些东西需要回顾一下比较好，重点是没有什么工作可以不经过查核的手续。回顾通常是在一个企划受到时间压力时，第一件半途而废的事情；这通常是一件大错误。省下这一点时间，通常会造成长期有痛苦。
只是把没经过查验的工作插入企划中，然后发现没有倒塌就认为一切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章中的软体工厂模型是相同的。请注意，从主要企划网页中，只留下相关的连结以保持清晰度。
在最理想的系统下，一个每星期寄发的新闻信件系统，将每星期更新的相关资讯寄给公司的每一个人。当然了，查看这些资讯是每个人的义务。
其中一个缺点在于，在一个大型的组织中，他们可能得顾用一个专门负责网页更新的设计师，来进行相关的工作。不过，幸运的是大部份的公司中，都已经雇用了负责网页的人员。
将所有公司中的文件与过程搬到内部网站上面，并不是一项轻松的工作。它需要小心的设计，而且还要提供搜寻的功能。如果这方面处理得很好，那公司中的每一个人都可以看到企划的进行状况。
我曾经在一个我参与的研发企划中实施这个系统，而且将它延伸到加入时程表系统，所以可以利用单纯的网页界面，指派员工黄鹂不同的工作。员工可以进入特定的网页中，查看他们工作相关的详细资讯，以及安排个人回顾、会议的相关时程表。
假定这个网页经过谨慎的设计与编排，它应该可以去除每一个研发人员在试图不去查看相关文件时，最常采用的藉口（包括我自己）：［可是我到处都找不到］！
最新评论