游戏策划 Game Design » 电脑游戏结构与设计

《电脑游戏结构与设计:理论篇》【全集】

达达尼昂 — Thu, 12 Mar 2009 03:21:13 +0000

《电脑游戏结构与设计:理论篇》

《电脑游戏结构与设计:理论篇》第十五章疑难排解【转】

达达尼昂 — Thu, 12 Mar 2009 03:11:25 +0000

电脑游戏结构与设计

第十五章　疑难排解

＊风险

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

＊变更控制

＊突发规划――［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与处理器类型的不同。

研究：结果

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

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

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

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

过程问题

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

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

官僚作风与繁文褥节

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

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

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

误用与制度

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

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

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

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

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

拘于形式的问题

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

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

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

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

《电脑游戏结构与设计:理论篇》第十四章产业的未来【转】

达达尼昂 — Thu, 12 Mar 2009 03:10:24 +0000

电脑游戏结构与设计

第十四章　产业的未来

＊阶层化的［大众化市场］

＊变动的管理技术

＊电影工业的模型

＊让小组运作

＊产业的成熟

＊线上的革命

＊调整的可能

这个章节包括了我们对游戏产业未来的最佳猜测，以及整个游戏市场中会发生的事。而如同这个世界没有照预言在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万套。您的经营计划必须让您能靠着这个成果存活。如果您计算一下的话，您会看到达到这个目标的合理化过程，让您同时省下金钱并减少上市时间的损失，而且可以增加内容的充实性。

游戏策划 Game Design » 电脑游戏结构与设计

《电脑游戏结构与设计:理论篇》【全集】

《电脑游戏结构与设计:理论篇》

《电脑游戏结构与设计:理论篇》第一章基本概念

《电脑游戏结构与设计:理论篇》第二章核心设计

《电脑游戏结构与设计:理论篇》第三章　游戏性

《电脑游戏结构与设计:理论篇》第四章设计详述

《电脑游戏结构与设计:理论篇》第五章游戏平衡

《电脑游戏结构与设计:理论篇》第六章外观及感觉

《电脑游戏结构与设计:理论篇》第七章包装起来

《电脑游戏结构与设计:理论篇》第八章游戏设计的未来

《电脑游戏结构与设计:理论篇》第九章目前的团队管理方式

《电脑游戏结构与设计:理论篇》第十章角色及部门

《电脑游戏结构与设计:理论篇》第十一章软体工厂

《电脑游戏结构与设计:理论篇》第十二章里程碑及期限

《电脑游戏结构与设计:理论篇》第十三章程序与［过程］

《电脑游戏结构与设计:理论篇》第十四章产业的未来

《电脑游戏结构与设计:理论篇》第十五章疑难排解

相关日志推荐

《电脑游戏结构与设计:理论篇》第十五章疑难排解【转】

相关日志推荐

《电脑游戏结构与设计:理论篇》第十四章产业的未来【转】

相关日志推荐

游戏策划 Game Design » 电脑游戏结构与设计

《电脑游戏结构与设计:理论篇》【全集】

《电脑游戏结构与设计:理论篇》

相关日志推荐

《电脑游戏结构与设计:理论篇》第十五章 疑难排解【转】

相关日志推荐

《电脑游戏结构与设计:理论篇》第十四章 产业的未来【转】

相关日志推荐

《电脑游戏结构与设计:理论篇》第十五章疑难排解【转】

《电脑游戏结构与设计:理论篇》第十四章产业的未来【转】