»主站点 你尚未 »登陆 »注册 »帮助 »English Version »中文GB-BIG5转换



 
»加入收藏夹 »订阅主题 »上一篇主题 »下一篇主题
   
Necroz Studio » 文献图书馆 » 电脑游戏结构与设计  
thread topic: 电脑游戏结构与设计 <<  1   2  >>  Pages: ( 2/2 total )
  


 
deen8888
rank: Newbie
essentials: 0  
posts: 21
gem: 1
sp: 103
oge: 0

onlined:2 hours
join date:2008-03-17
last login:2008-04-23
»资料 »短信息 »推荐 »引用 »编辑



第十章　角色及部门







＊拉开卧室的窗帘



＊指派人员



＊提升士气与工作环境



＊分散风险







本书的主题之一，在于游戏产业的急速成长，已经降低了单人乐团，在卧室或是车库工

作这种全世界通用的方式。



现在已经不可能光靠一个人来进行设计、撰写并生产出所有的程式、图案、音乐等一个

游戏所需的其他东西。这表示必须在一个地点进行特别的过程，与先前不同之处，还要

指派每一个人的角色。







指派人员



一个企划成功与否的关键，通常在于您指派的人员上，以及您如何把这些人分配为具有

功能的群组。



当然了，我们在这边运用的角色与分配方式是以［最佳状况］来设定的。在游戏产业中

没有几家公司可以设定成这种状况，不过在游戏产业以外倒是十分常见。大部分的游戏

公司都有主要的分部，但是其中的一些辅助角色从来都没出现过。很悲伤的事情是，大

部分的程式编写早在进行详细的分析之前就开始进行了（在许多状况下，甚至没有这一

道分析的手续）。在游戏产业之外，象这样的企划甚至不可能亮起绿灯。



五个主要的部门中，每一个部门都扮演了数个不同的角色；而表10.1中显示出一个以企

划为主的研发时程表中，所用到的主要角色与部门。请注意，在大部分的公司中还有其

他的角色，但是我们只考虑重要的部分（其他角色主要是支援性质，与游戏生产没有直

接的关系；象是网路管理、接待员以及其他的从属人员）。



这些角色都适用于软体工厂的管理方式，我们将在第11章中讨论有效率的软体设计技巧

。







表10.1　角色与部门



部门

角色



管理与设计

软体规划师



首席结构师



企划管理者



游戏设计者



程式设计

首席程式设计师



程式设计师



美术

首席美术师



美术师



音乐及其他

作曲家



音效技术师



相关技术（象是动作捕捉）



支援及品管

技术支援



首席品管人员



品管技术人员



游戏测试人员



支援技术人员









我们将在接下来的章节中讨论这些部门与角色，在这之后我们再来把软体工厂引进来，

比较另一种使用方式。



在这边描述的角色，并不是指一个个永远坐在这些职位上面的人员。相反的，这些角色

应该是用帽子般的形式看待，只会有人戴上一阵子。一顶帽子可能会有个人戴很长的时

间，而其他的帽子只要戴一阵子就好。员工可以－而且经常性的－同时扮演一个以上的

角色（同时戴二项帽子）。举例来说，同一个人可以扮演软体规划师与首席结构师。







管理与设计部门



这个部门包括了直接关系着游戏性生产的管理阶层。在高层的技术与设计小组的管理下

，低层的管理应该具有模糊化的现象，尤其是在较小的公司，而且每个人都要身兼数个

角色的时候。



这种交错的现象很频繁，尤其在游戏设计方面，其原因主要来自于大部分的人［坚定不

移］的确信自己知道如何设计游戏。很多管理者与总裁相信他们都是最好的游戏设计者

。而这些管理者与总裁中，有一大部分的人原先都是在卧室中工作的程式设计师，从198

0的［单人乐团］方式白手起家。他们设计过游戏而且写得很好，所以这是他们最拿手而

且会紧紧握在手中的事情，也是他们创办公司的原因。



当然，这些家伙中不少人知道如何设计游戏－在Mythos Development公司的Gollop兄弟

就是最好的例子。但是，在大部分的情况下，他们之所以坐在管理的位子上，只是因为

他们任职时间最长，而且他们的名字广为业界所知。



不过，更具技术性管理职位所需要的技巧，在没有一定程度的团队管理经验或是训练之

下，是很难胜任的。不幸的是，通常看到的情况都是没能把正确的人放在正确的位置。

程式设计师晋升为管理阶层的原因，通常在于他们太精通于技术；但是却没考虑到他们

在人际关系的互动能力。







软体规划师



软体规划师的工作是把一份游戏设计打散成一组详细的技术性需求，以及预测完成这些

特色，要花多少的时间与精力。



软体规划师通常与游戏设计者、首席结构师一块工作，以准备详细的规格并完成技术的

结构文件，来符合这个企划所需。







首席结构师



首席结构师的工作是与软体规划师共同合作，从技术需求写出一套模组化之后的规格。



首席结构师负责的是整个企划的整体结构。详细的模组设计通常是交给首席程式设计师

。在某些状况之下，这个工作将会由首席程式设计师的未来小组中，指派其中的一位程

式设计师来负责。



请注意软体结构所需要的知识，与一个经验丰富的程式设计师是不一样的；只不过他们

通常都得具有相当程度的技能。在通常的情况，这个软体结构的工作是全职性的，因为

变更这些规格并回顾写出来的程式码，是一个十分冗长而且很重要的工作。他们很少有

写程式的时间。







企划管理者



企划管理者的工作，是以有效率而有组织的时程表，来安排软体规划师与首席结构师写

出来的工作量。



企划管理者控制了小组人员的互动，以及扮演企划小组、管理阶层和市场部门之间的桥

梁。







游戏设计者



游戏设计者的角色是用来设计小组制作的游戏。游戏设计者写出初始的游戏提案文件，

接下来把它写成更详细的游戏设计文件。



游戏设计者与软体规划师共同合作，来探索游戏设计中的各种可行性。







程式部门



这个部门包括了整个工作小组中，最会抱怨的人员。程式部门至少是以一个接一个的企

划来运作，倾向结合成一个程式设计师的小团队，来进行一个游戏的企划。



这个小组通常会结合成一个很简单的结构，包括一位首席程式设计师（对整个程式结构

负责）再加上四个程式设计师（平均值），每一位都专精于不同的程式领域（象是图象

的子系统、人工智慧引擎，或是控制系统）。他们之间的领域有时会重叠，但在大部分

的情况下，每个程式设计师所负责的领域都划分的十分清楚，就算是全面负责的首席程

式设计师，也不知道每一个子系统中的运作方式。







首席程式设计师



首席程式设计师的角色是协调并监看程式设计小组的成效，以确保能按照时程表进行。



首席程式设计师必须担任与企划管理者之间的桥梁，以确保能照着时程表跑，并把整个

企划的进展回报上去，才能精确的控制时程（而且在发生任何问题时，就可以尽早查出

对策）。



首席程式设计师通常是程式小组中技术最好的程式设计师，而且主要负责的是软体的全

面整合工作。在首席程式设计师的一半到四分之三的时间，都是花在写程式上面，而剩

下的时间则花在管理以及人事问题上（事实上，一些缺乏人际关系技巧或是管理经验的

程式设计师，可能很难胜任这个工作）。首席程式设计师通常是以技术能力来选派，而

非其他的标准。







程式设计师



程式设计师的角色是在研发过程中躲在壕沟中工作。这包括从首席结构师与软体规划师

写好，并分派下来的详细技术规格。



程式设计师通常负责主程式中的一部分，而且在整个企划中该区域的内容都由他来负责

。



程式设计师在标准的研发过程中，也要为所有标准的程式负责，直到单元测试、整合测

试和错误修正。



程式设计师应该知道他（或是她）写出来的成果，是否足以优雅的解决问题，而不用花

费额外的时间来进行整合。这个部分并没有研发人员：这只是个单纯的工作，把详细的

规格转换成程式码。







美术部门



这个部门中包括了一群美术师，他们通常分布在一个以上的计划之中。



艺术是一个适合在轻松环境之下的行为（虽然我知道美术师一定会反对　这种说法），

所以，在大部份的情况下，最好能让一群美术师同时为一个以上的游戏进行图形的绘制

。



并非所有的公司都用这种方式来运作，但一般说来，将一群美术师齐聚一堂的方式，在

花费上面比把一些美术师永久性指派到一个企划中来得节省。







首席美术师



首席美术师的角色与首席程式设计师是平衡的，虽然这种说法只适用于一些定义得十分

松散的方式中。一个美术师完成的作品必须马上能看得出品质，但是首席程式设计师并

不需要密切注意一个程式设计师的表现。



所以，首席美术师的主要角色是与首席程式设计师和游戏设计者，一块确定画出来的作

品适合在游戏中使用。



首席美术师的另一个责任是确保所有美术师的绘制速度，赶得上其他部门的整体运作。

首席美术师有时只会献身于单一的企划，让特定企划中的美术风格能够更为集中；因为

手下的美术师们可能同时参与二个以上的企划，导致风格的混乱。



一位首席美术师应该花费大约10%到15%的时间来进行管理工作，其他时间才进行艺术的

创作。







美术师



美术师的角色是绘制一个以上企划所需的图案。



以这个观念下，所谓的图案可能包括游戏中的图档、背景图案、手册的设计、广告与包

装设计，或是其他相关的工作。



在通常的情况下，美术师会同时参与数个不同的企划。每一个企划均有一位首席美术师

，帮这一群美术师分派工作。这表示每一位美术师可能要与一位以上的首席美术师沟通

，不象程式设计师参与的是一个比较紧密的小组。







音乐及其他



这个部门包括了生产各种杂项元件的人员，象是音乐、声音和研发环境等等，是完成游

戏不可或缺的。







作曲家



作曲家通常与主要的游戏研发分开工作。



创造音乐是一种十分个人的行为，而且在大部分的情况下，作曲家可以接受一段动画或

是一段展示画面，或是甚至一段情绪变化的说明，然后他（或她）才能做出音乐。



如果您需要的是互动式音乐（随着游戏中发生的事情而变更节拍或是情绪），作曲家就

有必要与其他的组员进行密切的沟通。互动音乐通常包括大量可交替、有主题的循环音

乐小调，可以在必要的时候进行切入与切出的行动。这时作曲家角色，就变得比以往更

为突显。随着互动音乐在游戏中更常出现，作曲家的角色将在游戏制作的过程中，变得

更接近核心的地位。







音效技术师



所有的游戏都需要音效。音效技术师的角色就是制作出各种出现的音效与廻路，这是创

造游戏环境不可或缺的，不管这些声音是枪声、按钮的哗声或是异形将死时的声音。



这个角色通常是十分自主的。创造音效所需的资讯与音乐十分相近，游戏设计者可以列

出一张大表，让音效技术师为您创造出所需格式的声音。



在许多例子中，程式设计师可以在测试时先插入一些常见的音效（很多这种测试的例子

，在正式游戏完成前才会移除）。







相关技术人员



要把游戏完成，通常都需要一些技术人员来进行一些其他的工作。



有一些技术人员将会直接参与，而其他人只是以兼职的身份参加。举例来说，象是动作

捕捉的技术人员，将与制作动态有着严密的关系。除非公司中有动作捕捉的现场工作室

（这十分稀少），要不然美术师只能在研发中直接使用一组原形的动作来进行研发，而

动作捕捉的动态将在工作室之外转包，并在后期才加入游戏之中。



其他的外部工作室，所负责的任务可能是公司中想象不到的。不过，如果这些工作都在

公司内完成，将需要一个技术师的角色来负责。这一类角色的范围包括了在其他国家进

行游戏区域化，或是拍摄全萤幕动画（FMV）中的演员。







支援与品管部门



这个部门包括了测试小组，来确保游戏发行时的可玩性与品质。测试一个游戏包括品质

上与数量的程序。



在品质上的概念，在于追求完美的游戏性，相当于追求完美的艺术品，是很难达到的；

遗憾的是，很多游戏都缺乏这个要素。



在数量上的概念，在于臭虫的数量计算以及优先权的排列。这是数量方面的主要工作，

可以用来确定研发早期的品质高低。







品管先导者



品管先导者的角色是监控品管小组，并与企划管理者以及游戏设计者合作，以确保经过

全面的测试；这包括了游戏性以及功能上的完整。



品管先导者会完成一份测试计划，并把不同范围的计划指派给不同的品管技术人员。实

验出来的测试结果，将会回报给企划管理者。







品管技术人员



品管技术人员的角色，在于测试程式小组所写好的程式码。品管技术人员重视的是功能

上的完整，这表示品管小组的计划中，应该要测试程式码每一条路线：所有程式中的分

支，不管它有多简单或是多琐碎。



品管技术人员的角色，是与负责特定模组的程式设计师进行互动，来确定测试计划中包

括每一条分支。



品管技术人员更要了解每一条程式码背后的技术性资料，这样他们才知道测试的重点在

哪边。这是测试过程中最精细的地方，也可以由程式设计师自行展开测试。这个过程称

之为［开箱测试］，因为大家都可以看到测试的内容。与开箱测试相反的作法则称之为

［黑箱测试］。



黑箱测试所针对的是结果，也就是程式作用之后的明显成果。象是检查一个绘制多边形

的常式，是否正确的在画面上绘制出想要的多边形，就是一个例子。黑箱测试可以由任

何测试人员来进行，但记得要给他们一份合适的测试计划来遵循。







游戏测试者



游戏测试者的角色就是：看看游戏玩起来怎么样。在一开始时，游戏测试者就是在这个

企划中的程式设计师与美术师。



不过，越接近游戏企划的结尾，游戏测试的需求将会随之增加。一般来说，您会有四种

游戏测试的选择，而您选择的理由将视数个不同的要素，象是组织的大小以及您可以花

在游戏测试方面的预算多寡。



第一个选择是使用您手边的人员，而他们不适任的原因，在于这些人太清楚、熟悉这个

企划中的内容。另一个有用而且在许多公司中常见的作法是，付点钱给一些大学生，请

他们来玩这个游戏一段时间。



第二个选择是有一群永久性的测试人员。虽然这个选择对大型组织而言是最合适的，它

在数个企划同步进行时，也会是最花钱的解决方案。就算没有足够的企划供一组测试人

员持续的保持忙碌，还是可以把这些测试人员派去负责公司的其他事情。



如果一个贡献良多的测试小组，因为工作量反复无常而不能负责其中一个企划，那另一

个想到的方式就是从外面雇用测试机构。用公司以外的测试机构，好处在于游戏可以在

不同的机器设定之下执行，而且这些经验丰富的测试人员知道游戏中应该有些什么。游

戏测试机构在进行黑箱测试时也是很优秀的；但是在这个阶段，应该出现的只有不同机

器设定与一些不引人注意的问题。



第四个选择是公开测试－这是获得最大编制的好方法，不管规模如何。在公开测试中，

必须提供一个接近完工的版本供所有玩者使用。除了这个版本是测试版以外，软体上面

应该还有其他的限制（举例来说，缺乏一些重要的功能）。



用来进行测试的软体，可以在寄送时交给特定的群组或是选定的测试人员（象是Origin

公司在《网路创世纪》中的作法一样），或是可以透过一些网页以及杂志附赠光碟的方

式来发行（象ID Software在《雷神之鎚》与《雷神之鎚2》中的作法）。在这种状况下

，测试工作可以受到限制并加以控制，公司可以提供一些诱因，象是发行时贡献最多的

测试员可以免费收到一份游戏等等。







支援技术人员



支援技术人员的角色是支援并维护公司中的电脑环境。



这些责任包括了维护公司中的网路，确保所有的机器上面都安装了正确的软体，进行硬

体升级以及其他可以让公司运转得更顺畅的工作。







提升士气以及工作环境



就算是一个过时的管理者，也可以看出雇员的士气以及工作环境的品质，对整个公司都

是很重要的。对一个雇员来说，没有其他更大的理由，会影响到他的生产力。



在这边要传达的讯息很简单：良好的士气+良好的环境＝良好的作品







士气提升



什么会影响到一个员工的士气？



和所有的好问题一样，答案不只一个，而且所有答案都有相同的价值。让人惊讶的是，

士气并不需要利用每一个雇员的冲动来加以培养。事实上，这样的作法可能会伤害到士

气，如同一个什么都可以得到的小孩，最后一定会变成宠坏的捣蛋鬼一样。



我曾经看过一群试图勒索公司的研发人员，因为他们太习惯于使用自己的方法来行事；

在每次受到拒绝之后，他们就中止工作，直到提出的条件达成为止。在这种情况下，我

只能很难过的说这些研发人员得到他们想要的，而他们的行为毁掉了公司的名声。这个

企划最后毫无进展而付诸流水，而所有的研发人员也统统被开除（或许，这个世界上还

是有些公理的）。



维持士气的最好方式（如同生命中的许多东西）就是坚定而公平。



这边的列表（有着特别的顺序），是我发现对士气有帮助的建议。







＊资讯的良好流动



＊把内部的竞争减为最小



＊实际考量的时程表



＊公平的待遇



＊良好的工作关系



＊基础原则



＊最新的配备与软体，所形成的愉快工作环境



＊专业穿着



＊一般工作时间



＊具建设性的好处







有些建议在游戏产业看来可能很不正统，所以我在接下来的章节中，讨论每一个重点并

说出提升士气的理由。







资讯的良好流动



整个小组应该可以尽可能看到整个企划的相关资料。



在这边应该去掉没有必要的秘密：这种作法只会让恼怒不断的升高。所有可实行的消息

，应该透过绘制或是电子的形式，让所有人都能看到；而且应该尽力让每一个雇员，都

知道去哪边找到这些资讯。







把内部的竞争减为最小



内部的竞争是指二个派系－不管他们只是单一的雇员或是整个小组－都只会带来毁灭，

鲜少带来建设。



在大部分的情况下，单纯的竞争会恶化形成敌视，并在对方的背后指指点点；而这种敌

视的心态，将会阻止彼此在计划中的相互需求。



大部的敌视都是来自于不安全。如果一个个体或是小组觉得他们的地位不安全，那他们

就会攻击其他人，来提升他们的地位。这可能是人类的天性，在某些情况下，这种敌视

可以看成代罪羔羊的形式，而其他方面则倾向于好战而不合作。



如果员工觉得安全而舒适，您比较容易看到一个更健康的竞争形态出现：二个小组与个

人之间的友善竞争，有助于提升产品。这种［coopertition］除了对士气提升有很大的

帮助外，有助于提高生产力。







实际考量的时程表



这是一个简单的要点，而且不用说太多。它的概念在其他章节中也有提及。



一个时程表一定要经过实际考量。要研发人员采用一份太积极的时程表，并试着追赶参

与其中的人员，只会让士气象洩气的气球一样直直落下。







公平的待遇



公平的待遇对许多人而言代表了许多事。这是与我切身相关的事。



小组应该以他们的经验，得到公平的薪水。在可能的情况下，一个小组的成员应该可以

从他们的经验与技巧等级，来获得与行情相符的薪资。这这我所说的［与行情相符］指

的是电算工业，而不是薪水较低的游戏产业。



员工不应该免费长时间工作。工作的每一个小时都应该付钱，或是按照比例（也可能是

双方同意的加班时间）来支薪。不要让一个倒霉的员工为一个重要客户想要的展示程式

加班，然后只有一块匹萨来侮辱他的努力成果（这种事真的曾经发生在我身上）。



如果您可以提供的选择包括权利金或是股票，一定要签下权利金的合约，以合法、干净

而明白的条款，来进行所有的扣除与给付。我曾经看过也听过食言而肥的情况，如果您

想拿到您的权利金，那就要拿到一份书面的协议。







良好的工作关系



这是一个很简单的要点，信任。



不同团体之下的员工，必须能够彼此信任并相互尊重。如果不能在这种情况下运作，则

产生的摩擦足以毁掉整个企划，并让工作环境变成一个活生生的地狱。







基本原则



藉由一些明确、简单、容易了解的基本原则，可以让士气以惊人的方式提升。这些原则

应该以行为以及专业方面的预测为前提。



这些原则不应该太严苛或是漫无重点，或是只是为了要有原则而写出来的原则。它们应

该以基本的常识为基础。它们之所以写下来，是要确保每个人都有相同的概念，来建构

出［合理］的行为。不幸的是，常识这种东西，并不一定是普及的东西。



这些原则所定义的行为，必须以所有员工都接受公司薪水为前提；所以这些原则必须抱

持着平等主义。



在一组明确的指引出现之后，没有员工会喜欢看到有人可以做出反抗原则的行为，而觉

得自身受到不公平的对待（象是午餐时间太长或是拥有其他的自由）。这听起来很象高

中校规，但请相信我，破坏这个规则的现象会比较接近无政府乱象。



如果员工够年长而且负责任（您看过的游戏程式设计师，有多少人具有这二种特质？）

，那他们可以在更合适的情况下，来设计适用于他们的原则。即使如此，还是建议全公

司性的指导议会尽早订定午餐开始、结束以及休息的时间范围。



请注意这点，如果开始与结束的时间已经指定了，就应该去尊重它。在准时离开或是到

达时，员工应该要受到鼓励。



最新的配备与软体，所形成的愉快工作环境



愉快环境的重要性不言自明。



在一个狭窄而灰暗的办公室工作会让士气低落；办公室应该很干净、通风良好而且宽敞

，而且每一个员工应该有一个办公室。这不只很有道理，而且有道理到很少人这样做（

传说中微软为所有的研发人员提供私人的办公室，但并没有现金短少）。



不过在最差的情况下，员工应该有一个桌子来提供自己的空莘，让他们有足够的地方来

安置所有需要的配备。我并不相信管理人员应该要一张巨大而昂贵的桌子（只是因为他

们是管理人员），大张的桌子应该是给一位程式设计师，用来放置他的电脑、一堆光碟

、二台萤幕用的。但是这个世界就是这么的不公平。



要让一个办公室成为愉快的工作空间并不难。不太需要照顾的植物可以增加氧气，而且

可以改善光线（不要头上的萤光灯）。自然的光线应该尽可能的加以运用，但是它也应

该可以加以遮挡。没有什么比在太阳光线直射的萤光幕上工作，要更让人气恼的了。



办公室的设计并不困难。除了让一个环境看起来很专业以外，更重要的是让您觉得很专

业。







专业穿着



这一点会很好玩！游戏产业是一个在专业穿着上面恶名昭彰的行业，而且试着向它们建

议一些服装，就象在起皱纹的衣服上面贴羽毛。



不过，专业穿着的实行包括了数个理由。最常见被管理部门祭出来的理由，是一件专业

穿阗（在这些例子中通常是衬衫与领带）可以让您在顾客面前看起来更专业。



呃，这个解释并非到此为止。在游戏研发的例子中，大部分的员工并不需要直接与任何

形式的顾客接触，只有在展示场或是与发行公司签定合约时才会例外。



不过，还有一个专业穿着的深层理由。很重要的一件事情是，工作与家庭是二个不同的

场合。如果一位员工可以在工作场合与家中穿同一套衣服，将会让家庭与工作场所之间

的界限模糊掉。这条界限应该是清楚的：工作是工作，家是家。



我并不是说游戏研发者非穿西装打领带不可，但至少应该有［smart casual］（译著：

时装名词）的水准。重要的是您穿什么东西去工作，应该与您在家中穿的衣服有所不同

。您所穿的衣服将会影响到您的感觉，以及您身边人的态度。



尊重是专业穿着的另一个理由。您穿的越高明，您从其他员工身上自动获得的尊重就越

大。如果公司的每个人都只穿最基本的服装，则在相互关系的压力之下，士气就会越来

越差。



图10.1、10.2与10.3，说明了不同的员工礼貌，以及他们想要的穿着方式。



图10.2中是最基本的程序：［smart casual］。这是一个聪明员工平常穿的服装，足以

表现出与家中服装的不同，而且足以让他（或她）觉得舒舒服服，不会行动不便。我的

意见是一件牛仔裤和有扣子的衬衫，如图。



在图10.3中恰巧是无能的管理阶层，所认为的最佳装束。这对士气而言不会有什么帮助

。







一般工作时间



在游戏产业中，一般倾向于不固定的工作时间，彻夜不睡更是家常便饭。



不合常规的工作时数，在某些状况下是一个时程表安排不良的先兆。在其他的情况下，

表示管理上太过于马马虎虎的征兆。不管哪个理由导致无法正常上下班，在正常时间实

行之后，士气就会回升。



这种现象可能不致于马上出现，但是好处很快就可以看到。如果每个人的工作时间都很

正常，您可以确定所有的小组成员在工作的时候，可以随时找到其他的人员。现在就不

会因为有人彻夜加班，导致上班时间有人在睡觉或是找不到人的状况，让其他人一早来

上班时，看着一堆错综复杂的程式码而不知从何下手。



在严格定义了工作时间之后，也可以减少员工的压力。如果他们很清楚每天要工作多少

时间，他们就可以在这一段时间之中全力以赴，并在合理的时间离开工作。只要他们有

足够的时间休息远离工作，第二天上班时就会精神饱满。







具建设性的好处



如果公司打算为员提供一些好处，这些好处应该是会让员工感激而且会有用处的。



象是分股的选择、保证的权利金、免费的健身房课程、训练课程、免费的相关展览票和

免费的饮料，都是不错的好处。



杯子、笔、七尺高可充气的外星人、海报和其他便宜的碎片都不是好的点子。



如果您想让员工心存感谢之心，别让其他人认为他的价值不过是表现平平，只能得到一

个钥匙环。







提升士气的注意与警告事项



这边有一些行动看来可以在短时间内提升士气，但是在长期看来却是对士气有害的。



这些在之前以宠坏的小孩症状提过。如果您让员工有足够的绳子，他们不只会把自己勒

死，他们也会把您和公司一起拖下水。下面是几个错误的提升士气方式。







＊缺乏专业穿着



＊自由时间



＊临时的工作环境







这些方式可以在刚开始时提升士气，但是接下来就是直直落。



缺乏专业穿着



完全没有专业穿着，可以说是士气的杀手。



当然，在刚开始时看起来很酷。员工觉得很自由而且可以展现出他们的独特之处。他们

会觉得在各种不同的服装中不但轻松而且舒适，一套衣服可以在家中穿也可以穿到办公

室中。



不过，问题在于他们的态度。让员工觉得他们在办公室如同在家中，也表示吸引他们把

家中的行为带入办公室中。对工作而言就是需要一个工作的环境，这是与家庭完全不同

的重要之处。







自由时间



有些公司与组织在工作时间上面，是采用出名的松散态度来看待。



在通常的情况下，这种方式会让工作时间比一般标准时间长得多。12到18小时并不是没

有耳闻，而长的时间会在两方面破坏一个企划。第一个问题很明显：没有人可以在这么

长的时间中，持续以最好的工作方式运作。他们会写出次水准的程式码，而且他们会过

度疲劳。



再继续下去，他们就会燃烧殆尽。在这种情况出现时，他们将请更多天的假甚至是离职

，这将会重创小组，留下一大堆没有人可以接手的程式码。最糟的是，他们会被人们视

为小组中工作最辛苦的人，所以他们的离职会影响到其他组员的士气。



如果他们只是生病或是太累，要花时间来休息，一样也会伤害到小组。整个小组应该在

同一个地点、相同的时间中工作。如果不行的话，他们就不算是个真正的小组。他们将

成为一些独立工作个体的集团，只是做的是同一个企划。







临时的工作环境



很多游戏公司对于工作空间与环境的规则都很宽松，可以放海报、玩具、音响、七尺高

的充气外星人。而且在午餐时打打《雷神之鎚》一路轰到下午。



事实上，所有这类的东西都只是让办公室成为一个十岁小孩的卧室，违反了家庭要与办

公室有所区隔的原则。游戏产业被人看成是一个好玩而且很酷的职位，但还是让我们面

对它吧，在游戏产业中的工作目标是写出一个游戏，而不是玩游戏。



好，现在听起来象是在亵渎神圣的殿堂？我并不是说游戏不该玩，但是在工作时间中玩

游戏并不等于您在生产。您很难把［研究］一个新游戏与［玩］一个新游戏之间划清界

线。



办公室应该是一个专业的环境，因为只有专业的环境才能创造出专业的员工。







分散风险



　　这边所指的风险，主要是小组失去扮演特定角色的人员。在本章节中的角色定义，

与工作职称是不一样的；它们指的是单纯的角色，而一个员工可能同时扮演一个以上的

角色。角色应该当做帽子来看，一个员工可以在工作时戴上不同的帽子。
  


 
deen8888
rank: Newbie
essentials: 0  
posts: 21
gem: 1
sp: 103
oge: 0

onlined:2 hours
join date:2008-03-17
last login:2008-04-23
»资料 »短信息 »推荐 »引用 »编辑



第十一章　软体工厂







＊软体工厂所解决的问题



＊设定一个软体工厂



＊使用一个软体工厂



＊软体工厂的可适性







在第10章中说明了有效研发环境中的角色与部门，这些资源可以组织成许多不同的结构

（但不一定适合用来进行游戏研发）。在这个章节中将解释角色与部门的组织结构（特

别适合创立研发公司时采用），以及说明这个结构如何把效率提升到最佳的层级。



这个结构也可以用在一个刚刚创始的组织，但是这样的作法，通常是因为第一个企划都

会花费较长的时间（至少很可能如此），我们将在这个章节后面再说明。







什么是软体工厂？



软体工厂一词是指一种生产软体的方法学，而使用的技巧类似于标准工厂，象是一个汽

车生产工厂一样。不过，这并不表示用这种方式生产出来的软体都具有同质性、可以无

尽的搅拌，而且缺乏想象与天份。已经有够多的公司曾经努力过，但是他们的创意游戏

也让他们走进了破产的死胡同。在图11.1显示出一个看来很有钱的人（高顶帽与燕尾服

、怀表、雪茄和从裤子口袋中外露的钱）正在转动软体工厂的握把，看来象是一个绞碎

机。游戏设计从上面吃进去，而且不具名、理想的游戏从下面出来。从机器中传出一个

声音：［来吧！你们这些笨蛋！快一点！快一点！］这一类的软体工厂应该可能避免所

有的花费。



随着电脑游戏产业的逐渐成熟，更多复杂的生产方式（象是软体工厂）已经开始实行并

做出新的产品。软体工厂的方法是把特定的共用模组加以简单化与集中化，让它用在数

个不同的产品上。



它运用了大量生产的优势，以容易而更有效的方式来进行特定的工作，而且它会确保核

心使用的工具与程式库不断的维护更新，运用在一系列的产品上面，以取得这方面的好

处。所以，研发续集的作品将更为容易，因为他们会得到更丰富的程式库以及工具组的

支援。



软体工厂已经证实它可以在一系列的企划中，以相同的功能来运作。请记住这种模式对

一个特定的产品而言不一定适用（您和您的同事可能光是靠涂鸦就找出更好的方法）。

不过，软体工厂特别适合生产一系列的作品。



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

行是不可能的！］



这种抗议相当的正确，但是您每次制作游戏时，都想要重写一次画面与音效设定程式、

资料档案读取、程式库压缩、光碟音轨播放、选单程式，或是其他在长串列表上的基本

模组，而这些模组明明可以重复使用程式吗？如果从管理的角度来看，您每次重写一些

现成的特定程式时，又要花掉多少时间与金钱（不只要重写程式，还要经过测试、整合

与除错）？







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



＊资料档案读取



＊硬体安装



＊硬体设定



＊软体设定



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



＊编码与解码



＊视窗与画在特色



＊基本人工智慧元件



＊使用者输入







软体工厂的概念可以简化像是生产通用程式码与工具组的工具，让研发者可以专注与写

好从草稿上想出来的程式码。要让工作速度提高，表示你必须运用已经完成，并经过全

面测试相关功能的模组，来完成你的目标。







为什么要使用软体工厂？



利用软体工厂的模式，与其他的研发模式比较起来，究竟有什么优点与缺点？虽然这里

问题的答案要视特定的情况来决定，不过在表11.1中列出了数个主要的优点与缺点。







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



优点

缺点



平均的企划时程会缩短

第一个企划要花较长的时间



可以让跨平台的制作较简单

可以重复使用的程式库，必须为每一个平台进行改写



程式码较可信赖

程式码将更具共通性，所以更难撰写



程式可以重复使用并加以维护

初期的程式码要花更长的时间研发



相关知识可以在所有研发者之间分享

新的研发人员必须学习不熟悉的程式库



增加了企划进展的可见度

需要更多的管理



加强研发人员的专业能力

技巧上的弹性较不足









在表11.1中，显示出这种模式的确有它的缺点在。不过，在整体上，制作数个不同的企

划时，优点显然要比缺点更多。







解决游戏研发问题



软体工厂的方法有助于解决游戏研发碰上的常见问题、也就是平台的独立性与风险的降

低（靠着知识分享、程式码重复使用以及程式码的维护，等等）。







平台独立性



考虑与DOS相容的PC环境――这是一个可以扩充的系统，而且有着广泛的设定方式。如果

是为了效能的理由，您可能想要直接驱动PC上的硬体，那您会怎么选择？您应该自问要

在哪一种机器上面支援何种研体，而到了最后，这个选择会变成只支援有限的硬体，并

让您的游戏销量受限。您也可以赌上支援各种不同的硬体，但很可能会由于硬体的冲突

与不相容，成为逻辑方面的恶梦。



让我们来看看一个明确的范例。假定您在一台与DOS相容的PC上面，写了一个3D太空战斗

的游戏。您对您的结构设计很有信心，并在界面之下隔离了与所有平台有关的程式码（

在这边用的平台，指的是PC上面的特别硬体）。



您必须分别为想要支援的不同平台，撰写隐藏在界面之下的程式码。您可能选择支援三

种常见的影象卡与三种音效卡。



所以，您接下来要撰写、除错并分别测试六种硬体的相关程式码，接下来系统要在九种

不同的设定之下进行测试，还不包括那些完全没有这些影象卡与音效卡的玩者。让事情

更为困难的是，要让游戏的速度够快，您必须用这种方式来撰写程式库，让它们依赖游

戏的内部知识来达成所有的功能。这是很复杂的工作，没有任何书本可以教会您这一切

。



另一个常见的问题，在于您要如何以最有效的方式，把所有的平台程式码写出来。看来

，您不太可能找到对每一块想支援的影象卡，都具有足够知识的设计者。由于您要写的

程式数量已经够多了，看来您也不会有时间去研究相关的知识。



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

。



为了要把游戏的研发推展到特定的平台，并把硬体的支援责任从游戏研发者手中移到硬

体设计者，微软与苹果公司独立研发了二个解决平台问题的方案：DirectX与Game

Sprockets。在撰写本书的时候，DirectX已经进展到第六版，而且可以直接从微软的网

站下载：一样的，Game Sprockets也可以在苹果的网页进行下载。



DirectX与Game Srockets都是高效能、多媒体的程式库，设计用来自动侦测使用者机器

上，是否有任何加速用的硬体。他们的作用在于程式设计师撰写程式时，只要针对微软

或是苹果定义的应用程式介面（Application Programming Interface,API）就可以了。





这些程式库有助于解决个别硬体的问题，而且除非是透过标准化的方式，程式设计师无

法直接驱动硬体。在DirectX之下，提供了一组常用的功能，可以由硬体呈现或是由软体

来进行模拟。刚开始DirectX在研发人员之中接受度并不高，但是现在您可以去找找看，

哪一个游戏会绕过DirectX的协助。



当然了，DirectX与Game Sprockets仍然是层级很低的多媒体程式库，而且（理所当然）

彼此之间并不相容。要真正达到平台独立的目标，您必须创造出质轻的包复程式码，对

硬体提供统一的界面，不管执行的机器是一台与DOS相容的PC，还是一台麦金塔或是其他

平台。就算您没有打算支援一种以上的平台，包复程式码仍然是很好的点子，因为它可

以简化许多常见的工作。创造这样的包复程式码，是工厂的主要工作之一。







降低风险



在第10章曾经讨论过的一个问题，是关于失去小组中的重要人物。如果您有一位很特别

的小组成员，专精于一个特定领域中的知识或是技能，在整个企划中无人能取代，那这

个人就会成为一个风险。



在这个阶段，您应该问问您自己，愿不愿意把整个企划赌在一个人身上。如果他们跑到

西藏的天空下面生活（或干脆加入其他的游戏公司），这个企划能不能承受得了这种损

失？如果这个企划受得了，又会耗掉多少的时间、金钱与功能？减少无可取代的专业人

士，是一个企划成功的关键。







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



据Bungie Software公司的杰森·瑞吉（Jason Regier）所言，在研发《杀无赦》的时候

，曾经因为关键程式设计师的离职而出现一段痛苦时光。这位人士负责的内容是一个描

述引擎，一个很重要（但幸好不是必要）但却非丢掉不可的模组。在程式设计师离开之

后，描述程式码的基础都还没完成，而且没有人有足够的知识可以接着写下去。更糟的

是，《杀无赦》的小组并不大，结果就是没有多余的人力，来学习这种程式码要如何运

作。



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

在完成的游戏中。



这个特别的问题，就是靠着把这个功能拿掉来解决的。一个描述引擎是一个复杂的重任

，而且通常不是一个关键路线上的模组。在这种情况下，Bungie在考虑了费用与功能这

二个要素之后，决定把它拿掉。如果这个模组是图象引擎，象这种决定是绝对不可能发

生的。



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







软体工厂可以靠着重复使用程式码以及鼓励工作上的性质重复，来减轻这类损失关键人

员的问题。在案例研究11.1中的描述引擎是专门为这个企划而写的。不过，从另一个方

面来看，它也可以写成一个界面，而每一个可以描述的游戏物件，就可以用输出的模式

来支援这个界面。如果这些界面设计得十分普通，那么就会自动重复运用，并在不同的

企划中使用。



如果您是一个道地的游戏研发者，那您在看完最后一段之后可能会觉得不太舒服。标准

化的界面？在加上另一个层面的覆盖之后，难道不会让执行速度慢下来吗？这难道不会

让程式更难写，而且要花更多的时间？



呃，答案是［是］以及［不是］。如果界面设计得很合适，您至少可以和特别整合的元

件获得相同的效率。而且，由于软体工厂强调的是重复使用能力，所以描述引擎可以调

整并修改，来符合数个不同企划的需求。如果您想看看这一类描述界面如何运作的详细

提案，请参阅第20章。



在案例研究11.1中，如果有另一个研发人员一样熟悉描述引擎，而且这些程式码写了详

细的说明时，这些就统统不成问题。在研发过程中，在主要部分加注说明文字是一个好

习惯，但是通常（说明白点，将近百分之百）会被忽略。如果它只要使用一次，为什么

要写一些麻烦的说明文字上去？如果您是唯一要使用这些东西，而且最了解它的人，为

什么还要在程式码或是程序中写下说明？



这些都是原则上可以接受的反应，但是它带出的问题是，您为什么要写一个用完就要丢

掉的程式吗？如果您假定写下这样的程式码是正确的行为，那您为什么突然会觉得您一

定要跑去西藏躲起来？您又怎么确信您是唯一要看得懂这些程式码的人？



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

加上完整的说明。







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



据Zombie公司的魏斯，雷吉威（Wyeth Ridgeway）表示，《风驰电掣》（译注：赛车游

戏）的程式引擎，是从他们的上一个游戏《特种部队》（译注：第三人称动作策略游戏

）中改良而来的，里面没有游戏专属的程式码。这是一个专门设计用来重复使用的模组

。



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

，以及其他东西。



所有元件在他们的手中，都只是工具。这个游戏是由游戏引擎以及游戏相关的资源（画

面、声音以及物件描述）所组合而成的。它的组合是靠着最少量的结合程式码，主要是

用来进行物件描述以及小量的游戏专属程式码，这些是用支援描述并提供一般的框架。





这个引擎设计的方式下，只要有一套不同的资源，一个人就可以打造出完全不同的新游

戏。这种能力在几个非程式设计师的小组人员手中展示，只要一个周末就可以创造出一

个大脚车的赛车展示。这表示只要有合适的规划，一点点游戏研发的基础知识，以及一

份详细而精确的文件，就可以让一个软体工厂在现实中全速运作，开始生产。



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



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







为何要使用软体工厂？



一个软体工厂是设计用来生产一组可以重复使用的核心元件与工具，可以随着数个不同

的产品而进化。从一开始，这些工具与元件是以［可重复］以及［未来可扩充］的想法

来设计的。在研发这些工具与元件时，最重要的是让它们可以作用在游戏上。这些工具

与元件所用的研发采用严密、监控的方式，而且会加上完整的说明资料，以期在未来的

企划中能够重复使用。任何工具或是元件所需的更新动作，必须先经过完整的需求分析

，而且必须能表现出同等的标准。这些工具与元件是整个过程中最重要的部份，他们设

计上，必须让上一个游戏的上架时间，足以完成下一个企划，这是十分重要的一点。



好处是十分明显的：用来进行常见工作的程式码，可以一次又一次的使用，省下研发的

时间与财源。主要的缺点是第一套的工具与元件必须从头开始，而且通常在研发时间上

面，要比直接在企划中，写出想要的功能来得更久。获得通常是在接下来的企划中才显

示出来。



想要让已经发行的企划大幅改进，另一个可行的方式，就是用更新的核心模组再推出一

次。这种作法要多加小心。在这个世界上没有付出就不会有收入，而且，就算理论上所

有修改过的元件都应该可以与早期程式相容，但是这种方式有可能成为测试的重担。如

果您有自信做到这一点，那就去吧！不过，记住微软曾经保证DirectX会向后相容所造成

的麻烦。一直到第五版以前，新的更新程式经常会毁掉进行更新动作之前的系统，导致

最好的情况下系统最佳化不足，最差的情况则是系统完全无法使用。



另一个相似的情况，是建造一艘航海的船只。如果您决定要从第一天就打造您所需的一

切物品，这个小组就得从砍树、木材加工、把木材放干、然后才能开始组合成船只。要

用这种方式做出数艘不同的船只，一定会累死人。



在合理的情况下，您可以安排刚开始的元件以生产线的方式完成（甚至请外面的人来写

），然后让您的小组只要进行组合的工作就好了。这样可以结合小组的优势（热情与动

机）与工厂的模型（有效的运用劳工，并及时完成）。







组织一个软体工厂



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

构成要件。







结构概观



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







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



小组

说明



游戏设计者

想出点子并生产出设计文件



软体结构师

监督整个企划的结构，并在小组中互支动



工具

象是小组用的关卡编辑器…等等



元件

生产出低级、与平台相关的程式码



企划

使用元件与工具小组的结果，生产出真正的程式码



研发

与新的研发科技保持同步，并研究新的点子，然后整合到低级的元件中









在表11.2中是基本工厂的人员列表，并没有彻底的调查，也不是最后的定案。其他的附

属角色可能有其必要，但是在这个列表中只定义出核心的需求。没错，并不是所有的组

织都可以符合这样的崇高目标，但是除了软体结构师的职位（这是一个专精、应该属于

全职性的工作）以外，在群组中可能会有很多的重叠部份，如图11.2所示。很明显的，

您手上有越多的人可以用，则重叠的部分就越小；但是一定程度的重叠通常是有意的，

这有助于把相关的知识，传达到整个小组之中。



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

阶层架构。



在图11.3中是一个粗略的指导方针，但不是死硬的结构。在现实中，这些状况要比静态

图表所表现的更活泼；而这边很少变成死硬关系的原因，是来自小组之间的互动。这些

人与人之间的互动（或是称之为沟通）有助于提供高层的企划可见度。企划可见度是指

可以正确估算企划进展的能力，这种能力对每个重视产品的人而言，是十分重要的；包

括了投资者、发行公司以及小组成员。不过让人惊讶的一点是，良好的可见度也会带来

副作用，这会减少必要性的小组会议。有许多称之为［进度］的会议最后会变成完全二

回事，而且除非计划有大幅的修正，否则很少有中止研发的必要，把时间拿来开会。这

样的会议是最会杀时间的东西，而且会干扰小组的专注力与工作态度。







群组的责任与互动



在软体工厂中的每一个核心群组，都有定义得十分明确的角色与工作。这边只有很少（

如果有的话）的重叠，而且所有的重要群组互动，都是在严密制定的管道中进行。



这些互动是以内部市场系统为概略性的基础。每一个群组都是另一个群组的顾客，所以

应该相互视为重要的客户，彼此提供相同等级的文件与产品支援，如同这个产品已经卖

到市场上面，客户碰到问题的处理方式。



这个［市场系统］结构的重要性，在于确保企划以正确的方式进行追踪；让您的左手知

道右手在做什么事情，都不会有什么坏处。在图11.4中显示了在一个软体工厂之中的群

组互动，而不管外界的影响。在这个图表中，程式设计群组一块待在一个大团体中，因

为他们通常是同一群人所分别担任的。不过，在个别是的程式群组之间产生互动时，他

们还是必须透过合适的管道（这些管道将在第13章说明）。



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

想到的问题：







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



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



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



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







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







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



安迪（Andy）、拜瑞（Barry）、克理斯（Chris）、大卫（Dave）与艾迪（Eddie）都是

一个程式设计小组，目前正在制作的企划是《FlyBusters lll――eyond The Flypaper

》，这是由一位游戏设计老手佛瑞迪（Freddy），所完成的最新企划。



艾迪是首席程式设计师，一个技术上的天才但没有什么人际关系的技巧；安迪是一个见

习者，刚刚从大学毕业；而拜瑞、克理斯与大卫是元件的程式设计师，在游戏产业中有

充分的经验，而《FlyBusters lll》是他们第一个一块共事的企划案。安迪刚刚踏入社

会，而且不太确定所有的东西是如何拼凑起来的。



在进行玩者太空船的物理模型时，他注意到有些角度之下，地形会扭曲的很难看。现在

，艾迪有一个不太好的名声，就是他有点难以打成一片；他最喜欢使用的反应方式，会

暗示他的时间被浪费掉，而且他有很多更重要的事情要做，而不是在那边听取组员对小

问题的哀鸣（安迪在先前向艾迪担到近看时多边形之间有间隙，就被这种现象碰了一鼻

子灰。拜瑞和大卫是多边形引擎的程式设计师，对这种批评程式码的行为做出了强烈的

反弹）。



这一次安迪试了另一个方式，直接反应给克理斯，也就是设计地形引擎的人。虽然克理

斯很忙，还是花了一些时间去看看，并向安迪建议别让玩者直接向正下方来观看地形，

这样问题就不会太明显；因为这个地形引擎还无法支援这种特殊的视角。这是一个小小

的变更，但是要花上数个小时的时间才能把一切搞定，所以安迪就照着凶的建议来做。

艾迪今天特别忙，身上冒出的正是［别靠近我］的光晕，所以安迪想要明天再告诉他，

然后去做下一个工作。



在数个星期之后，艾迪决定该是制作轰炸视角的时候了――这是一个特别的视角，让人

可以轻易的瞄准超级啸声炸弹（可以用十分精确的方式丢在目标上，并随着地形扩散爆

破）。当他决定好视角之后，艾迪不太了解的是，他就算特别指定炸弹应该落下的地点

，炸弹还是不能精确的命中目标；而玩者太空船的位置与定位，使用的正是安迪负责的

物理API。在一点时间的查看之后，他马上就查出了物理引擎无法正确的运作。在严加拷

问安迪，叫他去检查他的程式码是否正确之后，艾迪决定先把这个问题放在一边，因为

他看到物理引擎中的大量完成程式码，变更它的内容会导致独立的程式码碎掉。



二个星期之后，在一个例行的测试中，游戏设计者佛瑞迪注意到很难让炸弹精准的命中

。事实上，这几乎是一个［有投必有失］的过程。他马上要求把这个问题解决掉，并坚

持轰炸的策略是游戏的中心。程式设计小组没有选择，只好在三个区域修改程式码，让

整个企划延后了三个月之久。安迪觉得很不高兴而且没有受到尊重；克理斯觉得好象是

他的错，因为他没能写出够好的地形引擎；拜瑞和大卫因为安迪批评他们的多边形引擎

感到很烦而且暴燥；艾迪觉得很挫败并应该为延期的事情负责；而佛瑞迪认为整个小组

都是一群白痴。团队的士气低落、而游戏上市时间延后了六个月，而且在评论也针对了

轰炸模式的不良以及技术的失败不断攻击。简单的说，他们被炸掉了。



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







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







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



这个小组与案例研究11.3一样，制作的也是同一个游戏《FlyBusters lll》，而且在出

现初期的反抗之后，大家都同意按照沟通管道来交谈，至少先试试看。



当安迪发现了多边形的结合问题时，他登上了公司的内部网路，并以不具名的报告方式

，详细的说明了现在出现的问题。结构群组查看了这个问题，并与游戏设计者佛瑞迪和

艾迪交谈。佛瑞迪询问这种现在出现的问题。结构群组查看了这个问题，并与游戏设计

者佛瑞迪和艾迪交谈。佛瑞迪询问这种现象是不是可以修正，而艾迪在与拜瑞谈过之后

知道这个症状是故意的，为的是让速度获得最佳化；所以他宣布问题可以修正，但解决

方式的代价很高，必须针对每一个多边形与每一条扫瞄线做额外的检查。佛瑞迪询问这

在事实上会出现什么状况，而艾迪解释这会让游戏每秒的贴图数量降低，降低的程度要

看画面上每一个物件有多大，以及同时存在多少个多边形。佛瑞迪不想失去引擎提供的

流畅画面，所以他同意在游戏进行时不需要加入特别的效果。这个问题以［不需要做任

何行动］的决定处理，并把一段简单的理由写在网上。



接下来安迪碰到了俯视的视角，并再次用不具名的报告于网上提出。不过，这一次佛瑞

迪坚持轰炸的视角在游戏中十分重要。在艾迪与克理斯交涉过之后，发现要加入这个真

正的俯视视角，表示他们要写一个分离的次引擎，而且这将要再花掉三到六个月的时间

。这个问题以［开放大家研究］的方式在网上回应，而结构群组与佛瑞迪先行离开，去

想一个解决的方案。在经过数天的慎重考虑之后，佛瑞迪想出了另一个轰炸视角，并不

需要向正下方俯视地形，并把它展现组结构群组。在这个时候，结构群组注意到另一个

企划小组正在制作一个俯视的地图模组，可以很简单的放入《FlyBusters》的企划之中

，因为他们之间的界面是一样的；但是必须利用随附的工具产生额外的图形。现在，佛

瑞迪有二个制作轰炸视角的选择，而且二种都可以让人满意。



这个解决方式选定之后，放在内部的网站上面，而且俯视的视角在几天之后，经由企划

群组的结构规格更新以提供新的功能，平顺的整合到现今的企划中。艾迪经历过足够的

传统企划，知道程序上面的方式不够正确的话，这种事情一定会发生；而且很惊讶的看

到问题能够这么快的获得解决。安迪很高兴看到他提出的问题得到肯定，不管大家知不

知道是他所提出的。克理斯松了一口气，表示他不用大幅度修改他的地形引擎，而拜瑞

很高兴看到他的最佳化放在第一顺位。现在小组的士气提升，而产品也在预定的时间上

市，成为很成功的商品。







在这边最明显的好处，在于增加了整个企划进展的可见度，问题一出现马上就可以处理

。提供不具名沟通管道的好处，在于企划中的每个人都可以看得到，所以每个人对事情

的关切与心声，不需要和人与人之间的关系起冲突，也不用触及礼貌上的问题，那些都

是人性的丑恶面。主要的顾虑还是在于企划的成功与否，而不是被冒犯人类哪种敏感的

情绪。不具名的管道，有助于在这种状况下确保良好的结果。不管怎么样，这个讯息是

从哪边而来的并不重要，重要的是它出现，而且它会以多快的速度出现。



对很多研发者而言（尤其是在游戏产业），在实施这一类定义得十分清楚的小组结构，

刚开始时会带来反对的声浪，主要是因为它看起来限制良多，而且会让创意窒息。您可

能会听到研发人员说这样的程序会让他们的动作变慢，而且降低他们的生产力。这些研

发人员通常（几乎）都是习惯于高速大量制作出程式码，并马上把东西丢到萤幕上。这

些人员也是导致企划中产生大量臭虫，不得不多花数个月的时候来修整的同一群人。事

实上，这些研发人员在抱怨的是，他们现在要做的工作在以前明明可以拖到企划即将结

束时才动手，而且在发行时一样可以过关。在强迫使用程序化的作法时，大部分问题都

可以在早期阶段抓出来。



抓虫



大家都知道一件事：如果能在研发周期中早点把臭虫抓出来（而且这种事可能会发生在

企划的任一个阶段），就会省掉更多的时间与金钱。一个在结构阶段抓出来的臭虫，如

果放着它不管等到游戏即将发行才去处理，可能要花费200倍以上的时间才能解决它。



如果您发觉额外的程序会导致额外的工作与延迟，这不过是一个幻象。对今天的大部份

企划而言，这个工作仍然非完成不可，但是它永远不会排在企划时程表中，而且最后仍

然得在研发过程后期把它做好。在这同时，管理部门急着等候企划的发行，而目前已经

落后了六个月的时间。延后的企划会伤害到员工的士气以及小组在公司中信誉。任何可

以用来侦测并修正这些问题的评估必须尽早运作，已经是不可或缺的事情了。不管怎么

说，您听过多少次［一个游戏已经做了一年半的严密程式撰写，目前企划已经完成90%，

只要再等一年，就可以完成90%以外剩下的东西］？



下列是一些在介绍结构设计程序时，最常听到的反对声浪：没有时间等所有的文件统统

写好，这个企划已经处于一个十分严密而积极的时程表，而且增加这一堆高高在上的东

西，只会让所有东西慢下来，而制作时间却越来越长。看到状况不佳的企划屈服在这些

争议之下，而答案却是没有时间来实施这些提高效率的作法！在长期中节省时间，才有

可能弥补早期任何慢下来的进度。研究一个时程表的步调（并预见问题，在出现之后尽

早把问题解决掉），时间才能在剩余的企划时间中有效的节省下来。



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



现在您知道不同群组之间要限制互动的理由了，接下来的部分会简要的说明这些作法以

及安排这些沟通管道的理由。请注意，就算是透过这些已经安排好的构造，讯息还是会

以其他的方式进行传递：偶尔在走道中的见面，或是在午餐或中场休息时的讨论，都会

打坏讯息传递的重要结构。最重要的是，要把这些问题带入正式的会议之前，必须先透

过正确的管道，才能实行解决问题的行动。这会让所有人关心问题，并有机会让他们想

出好方法。







游戏设计者群组



游戏设计者群组负责的工作，是撰写初步的游戏设计；并在后续的过程中，把研发与测

试过程中发现的游戏关键加以浓缩精炼。象这样的作法，其他小组中的人员可以加入游

戏设计者群组，提供点子并把游戏设计变得更为精微。不过，如同先前讨论过的一样，

游戏设计一般而言比它的外观更为复杂，所以生产初步的设计与规格，最好留给经验丰

富的游戏设计者来完成（或是看过本书第一部的人）。通常这个群组也要负起撰写最终

用户文件的工作，象是游戏的说明书。



游戏设计者群组主要是与软体结构群组进行互动，一般而言他们会倾向依靠预估企划的

可见度，来遵循整个企划的进展，而不是直接去找其他群组要资料。



这个群组的主要时间是花在研究新的设计，并修正目前在研发中的企划。在工具与元件

群组有足够的速度，并为游戏设计者完成了数个有用的工具与元件后，这个群组会发现

他们自己在游戏调整与程式设计的过程中，更具有［实践］上的经验。举例来说，如果

一个简单的人工智慧描述引擎已经完工了，那游戏设计者就可以开始撰写描述档。如果

企划已经使用资料库来研发，以储存各种常见、可调整的参数，那游戏设计者也可以进

行参数的调整工作，把游戏调整为他们心目中的模样。这些参数被公认为［软体结构］

，而且可以在不变更企划要示的硬体结构下，进行多方面的调整。游戏设计者群组的领

域也可以包括直接性的调整结构，但这必须等到有适合的工具，才能让他们完成这个工

作。



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







软体结构群组



软体结构群组的作用如同一个工厂的中枢，而且它是游戏设计者群组和程式设计群组（

工具、元件、企划与研究）的主要界面。这个群组的人员对所有的程式群组来说，就代

表了传统的［首席程式设计师］；不过他们也有可能会做一些较小规模的程式设计工作

。



这个群组主要的责任是把游戏设计转化为技术结构文件，使用现有的元件与工具，并写

下这个企划中的工具与元件需要做何种程度的修改，然后从研究企划的结果，开始研发

新的工具与元件。这个群组的人员也会为游戏设计者提供回馈，以确保这个设计是可行

的，并从游戏设计者想象出来的设计理念，做技术性的游戏设计建议。这个结构的规格

是一个不断进化的过程，可以随着企划的进行而不断的修正。大部份的主要改革，都是

在原型的阶段中，从是否可行性的研究加以整顿出来的。所以任何未来的修改应该都是

以现存的结构为基础，在精微与净化的过程之下更为完美。除非您拥有某些可以看透一

切的神力，否则了解这些是十分重要的（从统计学上来说，而且这些现存的数字都在｛0

，1｝之间――这会更让您搞不清楚），然后在现有的结构中最多只能完成80%，接下来

要等程式开始撰写。最后的20%必须在企划的进行期间完成，一般称之为80/20规则。



软体结构群组全面控制了整个公司的标准结构与程式撰写。这个控制包括了各种类别，

象是档案格式、界面定义的标准、文件标准、目录结构、原始程式码标准控制以及其他

把重复使用与可以维修视为重点的常见范围之下。



程式码回顾是由这个群组的组员来进行的，这是为了确保结构标准可以随着不同的企划

而修正。这个群组也监督了各个元件、工具与企划的个别系统测试。



软体结构群组一般说来，是由公司中技术最好的人员所组成。他们在结构设计上十分专

精，而且可以写出他们能够遵循的详细规格，不会觉得模棱两可，所以用不着去劳烦三

个程式群组的任何一个。这些人在技术上面的能力已经足以回答程式设计师的任何问题

，并解释任何技术上的重点，让他们可以遵循着规格来运作。如果在必要的情况下，训

练应该可以达到这个目的，要不然就引入其他具有技能的软体结构师。







工具群组



工具群组的主要功能，是生产并修护所有其他研发群组使用的工具。在某些情况下，这

些工具是在公司内自行撰写的，而在其他的情况中，可能是比较常见的架上产品，象是3

D Studio MAX与微软的Visual C++。



在可能的情况下，这些工具是设计用在一个以上的企划中。这个考量并不象它听起来这

么困难，举例来说，一个设计得很好的地图编辑器，在各个企划中都应该可以运作得很

好，毕竟地图就是地图；如果想要特殊的功能，它也可以藉由提供资料档中的资讯来定

义。如果真的需要一个外加的功能，就可以去撰写特别的输出模组。某些企划结束后，

有可能非把工具丢掉不可，但是这方面必须多加小心――或许它们在未来的企划中会发

挥作用，或甚至在制作资料片时，这个工具也是不可或缺的。不过，一般来说，把工具

丢掉真的没有什么必要；而且就算如此，程式码与文件的标准，应该还是可以让这些工

具在设计时，是以重复使用为基本功能。







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



据Larian Studios的史温·芬克（Swen Vinke）所言，《LED商业争霸》这个游戏是在另

一个企划《The Lady, The Mage, And The Knight》进行之中的五个月时间完成的。



这二个游戏的风格与基础都是不一样的（前者是即时战争游戏，而后者是一个多人连线

角色扮演游戏），但是它们都有相同的方格地图结构。由于这个相同之处与史温在设计

上面很小心的处理游戏骨架，这二个游戏可以同时使用很多的共通程式吗。史温完成的

应用程式支架品质，可以让他在二个不同的游戏中，同时套用相同的结构；而在共通性

的结果之下，他可以使用相同的编辑器为二个游戏设计关卡，省下了研发另一个工具的

研发成本。



在小心翼翼与深思熟虑之后，这个方式可以用在未来的游戏上，而且一组常用的工具，

可以透过软体工厂来进行设计。



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







元件群组



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

模组包括压缩程式库，以及其他类似的模组。



在刚开始时，这个研发出来的模式看来十分明确而易懂，但是随着小组经验不断的成长

，对额外功能的建议将会加入常见的程式库中。看看案例研究11.2，要想象出一个完全

不同的图象引擎并不困难（举例来说，同样的3D模式），而且也可以不用经过太多的困

难（只要让它绘图）就把它放入定位。



最重要的元件设计目标，是它们应该只做一件事，而且做得很好。这并表示它们应该设

计成不只在一个企划中发挥功能。举例来说，如果您有一个全视角的3D游戏引擎，它应

该只会提供这种功能。一个2D的地图视角，应该是由另一个完全不同的模组来提供的。

每一个模组的界面要完全一致，在这种方式下，如果往后想要把3D的等大地图视角，换

成2D的地图视角时，在理论上只有图象需要重绘，而且新的程式码将可以直接连结进去

。



另一个例子是声音引擎。在大部份的状况下，这个模组不应该同时内建2D（标准左右音

量的变化）与3D定位的功能。3D定位应该在另一个独立的模组中建立，而在界面上与2D

程式库相同。如果有必要的话，2D模组可以加以修整，来支援3D模组中所需的额外功能

，象是办识不同的旗标并递送给第二个创造声音的模式，不过造成的缺点，就是无法与

上一版的2D程式库相容。



记住一个元件最优先的事情就是完成一个工作，而且要做得很好。这会让它在建构企划

的时候，更容易与其他的元件融合与搭配。







企划群组



当一个企划刚刚开始时，企划群组的工作就是负责制作出游戏中所需的技术原型。在大

部分的状况下，一个企划不可能马上进入全速运转；如果没有先做出一个原型，要进行

一个企划会操之过急，除非所有需要的元件都已经由已经由元件群组先写好。那一个企

划要如何开始呢？



一旦一个企划开始跑，第一个工作就是确定所有需要的元件已经研发完成。对每一个企

划而言都是如此，这表示在结构设计完成的接下来三个月，在进行的工作就是元件以及

小量的原型制作工程。这个状况的控管要十分小心，就算是最专业的管理人员，知道这

一段期间看不到真正的游戏，也会觉得有点［抽筋］。游戏原型的制作有时可以消除这

些恐惧，但不一定保证能奏效。另外，原型也可以用来进行可行性的研究。这个点子真

的可以用在游戏中吗？它看起来会好玩吗？在您把企划推到后期，会不会碰上什么技术

性的问题？如果会的话，您要先做什么样的准备？



在原型与元件的研发结束，并假定可行性的研究结果中不包括任何需要回头重做的现象

，那就可以认真的开始进行这个工作了。



企划群组的工作在于把元件定位并堆叠起来，撰写结合程式码，然后把美术与声音小组

提供的图象与音效放入（详见［附属群组］）。这个工作也是受到游戏设计群组的控制

。企划群组在接受资料时，要确定美术与声音群组所提供的档案，是企划所需要的格式

。



企划群组必须与测试群组协力合作，以确保这个企划处于可以发行的状态。什么叫做［

可以发行的状态］？这表示这个企划应该随时处于可以继续建造，也可以发行上市的状

况。没错，并非所有功能都已经完好了，但是至少在使用者选择了一个未履行的选择时

，它不应该就此当机。现存的功能必须正常运作，而且要十分稳定。这个企划将持续性

的进行测试，而且任何回报上去的问题都要马上进行处理（如果必要的话，也要通告结

构群组）。



游戏设计群组禁止透过结构群组与企划群组互动，而且透过群组的方式将在第13章中讨

论。这层限制的作用十分明确：它要预防特色蔓延，并确保时程表是可以达成的。



游戏设计群组可以自由调整游戏，而且有可能透过暴露出来的软体结构来进行调整。只

有在需要变更真正的程式结构本身，才有必要透过结构群组进行必要的互动。变更真正

的程式应该是很少见的现象，所以企划群组应该挡住游戏设计群组的过度行为。



研究群组



研究群组是在结构群组之下，以松散方式来管理的一群人。研究群组的工作（包括所有

事情）在于研发新的科技并制作原型，之后将它放在核心的程式库中，供其他的企划来

运用。



这些研究企划应该是以您想要找出来的重要科技创见为主，用完全相同的注意力与精细

的程序来实行。详细的记录应该留下来查阅，而这些应该经常回顾并查核。由于它的本

质，您必须了解要把研发计划放入时程表，是一件不可能的事。引用一句呆伯特的话：

［逻辑上是不可能把未知排入时程的］。



研究群组的目标是找出未知成为已知，然后从群组的研发路线上，移除单一最大的风险

。因为所有其他群组用的都是已知的东西，文件模组、所有要开放进行研究的东西，都

从重要研发路线上面先行移除了。如果一个企划真正需要的是这一类的研究，那就不要

进行这个企划，直到相关的研究已经有了一个成功的结论，而且随同的模组也在元件群

组的手中完成再行考虑，要不然就是变更这个企划，直到不再需要依赖这个研发成果为

止。举例来说，先使用一个较没有效率的图象引擎，然后在研发出新的版本之后，再切

换到新的版本上面。至少用这种方式，在图象研究完全没有成果（或是尚未完工）的局

面下，您还有一个产品可以在期限的最后一天交出去。



研究群组的大小是看其他小组的需求来决定的。除非是在很紧急的状况下，这边至少应

该有一到二位人员；而且如果您有任何空闲下来的程式设计师（并考虑过其他小组的需

求），您应该指派这些人来进行研究。



该注意的是，研究的项目不一定每次都要朝向新的科技走。它也应该朝提升您公司程式

设计师的平均技术水准而努力。有很多研发可以查出一个组织中，所有程式设计师的平

均水准。很明显的，如果能靠个体人员集中精力，然后在会议中同时提升大家的技能层

级，是一件求之不得的事。



举例来说，一位程式设计师接到的工作，可能是去了解或是提升他的知识，找出如何加

强一些核心模组的功能；或者他可以进行的是阅读并看完一些技术书藉，来强化他在特

定领域中的技能。所以，这些时间并不会浪费掉，任何可以提升公司经难长棒的行为，

都是很有价值的工作。研究群组是一个让这种努力成真的试验场。







附属群组



附属群组是支援性的群组，对一个企划的成功是不可或缺的。附属群组包括了声音、美

术、测试、市场与管理群组，他们对一个特定的企划而言，工作量通常比较少，对其他

小组而言也是如此。但这并不表示他们比较不重要。



美术与声音群组将会为游戏提供美术、音效与音乐。这个群组受到结构群组的指挥，而

且也直接从游戏设计群组手中得到与企划相关的资料，直接隶属于他们正在处理的企划

。在必要的时候，这个群组会受到结构群组的调整，不过并不常见，除非美术群组被要

求进行大量冗长或是没有安排时程的工作。



测试群组与结构群组紧密的连结一块，并直接受到结构群组的控制。任何由测试群组进

行的测试，将会回报给结构群组。要发行软体的每一块――可能是元件、工具或是游戏

――都要经过全面的测试，而且任何明显的缺点或是错误，都会透过臭虫报告提出来检

讨，并在必要的时候进行追踪修正。因为这部份需要把研发过程中写出来的软体进行严

苛测试，所以这个群组的主要功能将在于整合、系统与相容性的测试。



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



市场与管理的结构早就存在于您的公司。所以在这边提到他们的唯一理由，在于他们有

必要知道研发软体的过程已经改用软体工厂的模式。产品将会出现不同的情况，而且为

了增加技术上的可见性与您的企划相关知识，公司所付出的代价并不是一声［哇！］就

可以代表的。这边可能不会有这么多突然跃进的功能，让上层管理人员觉得大吃一惊；

因为这种研发模式使用的是稳定、不断增加的技术来获得最后的产品。在研发过程中缺

乏明显的进展，有时可能会让完全不懂这种作法的市场或是管理人事的部门觉得惊慌。

不过，希望这样的现象不会导致太多的问题，因为管理部门在这一类的问题之前，可能

会达成某些协议。管理上必须注意程序之间的不同，还有标准游戏研发技术和这些不同

所造成的结果。







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



好，您现在知道如何建构一个软体工厂的一切所需知识了。我猜您现在更想知道的，是

如何让它运作――至少我希望您会这样想！接下来的章节中，包括让工厂盖起来并开始

运转的初始阶段，以及后续的过程。







万丈高楼平地起



在这个讨论之中，假设您想要把一个传统的研发环境，转移为一个采用软体工厂的研发

环境，而且您想在混乱最小的情况下完成（如果事情看起来很不稳定，或是没有照着计

划走的情况下，还有回到原先的作法的余地）。



软体工厂可以逐步的进入您的组织，刚开始时只要创造结构与研究群组。类似的群组可

能早就出现在您的组织中，尤其是对研究群组而言。



第一件要做的事情，是创造遍及全公司的研发标准，以及程式与文件的指导方针。这方

面大都是一种常识，而且全公司都要普及；让每一个人吹出来的口哨都是同一个调调，

才能更容易看懂程式码及文件。这也是实施一些企划可见度提高的行动的时机，但是范

围不要太大。提供一个公司内部网站，可以让人们看到规划好时程表的进展，如图11.5

。



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



在做到这一点以后，这些群组可以开始进行元件程式库的研发并制作原型。要开始时，

结构师应该回顾目前企划进展（或是即将完成）的程度，来决定哪些功能比较适合当做

核心元件。特别把精力集中在目前正在制作的企划上面。



在经过可行性的研究并测试元件的原型之后，核心元件就应该要开始起跑了。组成元件

小组，并让研究小组开始进行元件方面的研发。这个程式码不应该从原型延续下来，因

为原型的程式码不具备坚固的程式码基础。原型的程式码只是如它字面所代表的：［原

型］。拒绝进一步使用它的诱惑，可以省掉您不少麻烦。把原型的程式码丢掉并重头开

始，并利用您在运用原型时学会的知识，做出一些可以吓死人的元件。



在完成初始的元件之后，就可以把它们放入正在进行的游戏发挥力量，来撰写尚未完成

的功能。要把已经写好的功能置换掉是很不智的行为，因为它可能包括了重复撰写的程

式码，并造成已经排好的时程表延期。从另一个方面来看，如果一个正在进行的企划中

，还缺一个音乐光碟的播放程式，那么提供他们一个经过测试、有完整文件的播放光碟

模组就是一件好事。确定这个小组了解一件事，就是所有的支援都要经过结构群组，而

不是直接与元件群组中的程式设计师接头。这应该不是什么大问题，因为元件群组在没

有得到结构群组的同意之下，不会做任何特别的变更。







先想，然后再想



先想小的东西，而且不要想太久。从一个可以马上派上用场的元件开始。一旦企划小组

开始接近您想的东西时，就可以开始进行更具基础、具预先思考性的元件，是在后续的

企划中可以发挥强大效用的。



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



现在您已经走了一半的路了，而剩下的过程会自动进行，在企划不断的完结而且更多的

研发人员空下来，让您可以把其他的小组填满，合并成沟通骨架。另外，现在也可以看

出软体工厂是否适合您的组织，或者您该采用的是另一个方式，也可能把这些方式加以

组合。







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



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

资源的有效运用。



很重要的一点是确保每一个小组有足够的人力，可以支援相互依赖的小组。这些人员的

数量得照着您的组织来进行协调。在图11.6中，说明了群组的依赖关系。如果任何的支

援结构很虚弱，整体就会倒塌下来，这很明显要加以避免。小心留意每个群组的强弱，

并避免让结构顶端太重，而导致小组的过度负荷。这只会造成更多的麻烦。



所以，这些群组是如何相互合作的？在图11.7中，是一个小型到中型的组织中，简单的

工作量与时间关系表。



当一个群组的工作量较小，人员可能会移动需要大量人手的群组中，以鼓励知识的转移

。在一个针对初学者的研究中指出，这种群组间的动态，并不一定每次都能象预期的一

样，把资讯适当的扩散开来；换言之，这些资讯不会象流行性感冒一样，自动扩散到新

群组的人员身上。这种情况通常是发生在有些人在较后期才加入这个企划，但是对较大

型的群组而言，群组的本质仍然应该保持原状。每一个小组的人员，应该了解到他们是

一个小组的一份子。逻辑上的部门之所以存在的理由，只是为了确保企划的可见性，仍

然保持在最透明的状况下。



对较大型的组织而言，有可能（有时甚至是有其必要）在二边跑的情况下进行企划。只

要支援基础够强固，这还是不会造成进一步的问题。







轮换并重新指派小组人员



软体工厂另一个强而有力之处，在于它可以让所有的组员分享到相同的知识。这样的作

法并非没有风险，但如果您不这样做，您会冒更大的风险，如案例研究11.6所示。







案例研究11.6　唯我独尊



在一个我最近参与的庞大多人企划（与游戏无关）中，制作中的应用程式极度的依赖一

个外部小组撰写的程式库，而这个小组是在另一个工作地点。这个程式库提供了各种复

杂的计算功能，正是主要应用程式所需的。



每次提到程式库的其中一个特别部份――我不打算讲出名字，因为我不想再入罪――时

，周遭人员都会禁声耳语或是觉得十分敬畏。为什么？这不只是因为这个部份的计算特

别复杂；而且它是由一个程式设计师，在十分慎重而单纯的风格中写出来的，整个公司

中没有任何人知道它是如何运作。这个特别的程式设计师单人负责这个部份的程式，而

且他很早就拒绝撰写相关文件或是说明。



这方面的抵抗是因为他很喜好这种掌握权力的感觉，而事实上他也站在一个十分有权力

的地位。他可以向公司寄出黑函要求他想要的任何东西，因为他知道他们不可能把他开

除。他是不可或缺的，而且在一些场合中，他也直言不讳。



要控制这个问题，我迎合了他的自尊并建议让他获得升职，他拥有了一间私人的办公室

以及一个助理。这个助理是一个从公司外面引进的物件导向专家，他的程式技能让主要

的研发者望尘莫及，而他的工作是学习这个禁区中的程式码，并加上注解，但是行事上

要特别的小心。



在一些刚开始出现的问题后，这个研发者接受了他新拥有的权力。并全面运用这个新指

派给他的助手。但是他不了解的是他太高估本身的不可或缺性。这个专家助手花了六个

月的时间研究他的程式码并加上说明，并很快的觉得他可以把程式重写并把疑点敝清。





在接下来的几个月之后，新功能的规格已经画了出来，之后就开始小心在另一边进行测

试，是否与原来的功能相同。当所有的臭虫都已经除掉（包括一些原来程式码中的修正

），就宣布旧的功能已经可以用新的功能来取代，而且能力更强。当然了，原来的设计

者在惊恐之中尖叫，但是在进行挑战，却无法为他保住旧有程式码的优势之下，他没有

理由告诉大家为何不使用新版的程式――不但干净、具物件导向功能，而且最重要的是

有充份的说明文件，在品质上比原来的程式码好得太多了。



有点让人吃惊的是，在他的权力被移除后，这个研发者成为小组中十分愿意助人的员工

。已经有人很明确的告诉他这一连串的行动为何展开，而且如果他再来一次，会发生什

么样的后果。所以，他被密切的监视，以确保他能服从其他人的要求。



这整段过程不管是哪一个部分，都不是很让人高兴；但是有时候强悍一点的确有必要。

这个风险对企划与公司而言，光是靠一个人而兴盛或是失败实在太过夸张。



在一份相关的记录中，我曾经看过一个研发者对变数的命名方式极不寻常。他会从字母A

开始，然后一路写到Z；当他的字母用完之后，他就开始用AA，然后写到AZ，依此类推。

最惊人的是，他记得每一个双数名称的作用，就算他的程式中没有任何注解，他也可以

在写好数个月以后去修改它，完全不会有问题。当他离开公司时，他写下的所有程式码

统统被丢掉一边去，然后重头再来一次。没有人可以了解他编写程式的，而且一切都已

经太迟了。







在轮换队伍的人员时，很多记载于案例研究11.6中的问题，可以在他们成为大问题时加

以避免。您可以经常性的针对不同核心程式群组来轮换人员，但是选择时间上要十分小

心――在一个企划即将结束时增加人员，会把所有的事情拖下来。



虽然这听起来很危险，但它可以确保不只一个人专精于特定区域中的程式码；而且，因

为文件的撰写过程已经确立，新的研发者要进入状况花不了多少时间。您要的是哪一种

：稍微增加研发时间、还是冒着整个企划无法做完的风险，只因为关键人员离职？



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







一个软体工厂的可适性



软体工厂是适合中型到大型的组织。在这个例子中，出现了五个以上的程式设计师以及

相关的技术人员。这种规模的组织可以容许您用公平而平衡的方式来分派小组，并让组

员的轮换产生良好的效果。



软体工厂也可以轻易的缩小用于较小的组织中。您会失去一些平行效应，而且也无法拥

有奢侈的附属群组，但是在制作第二个或是续作的企划时，您所拥有的优势仍然是显而

易见的。这种方式的技巧可以让您用来研发软体，而且已经在过去五年的时间，在欧洲

不同的客户中，以坚实的C++研发经验打下了基础；°这种状况下的研发速度与效能都十

分出众。在可能的情况下，在各种规模的小组上建造出软体工厂结构，得到的结果也会

让人满意；就算它会让部份的研发人员，在不习惯的情况下产生反抗心理，而且管理部

份也必须等到较为后期才能看到游戏结果，臭虫的修正也有可能拖到游戏发行之后。







最后的讯息



在本章提供的方法并不是宇宙中的万灵丹，软体研发方面也没有捷径。如果您在研发小

组之中找到了基础性的问题，象是技能不足或是经验太浅，那不管是什么方法都帮不了

您，直到您把问题的根源解决掉为止。



另外，您没有必要把这个方法当做戒律。去试试看。看看什么方式有效，哪些无用。把

有用的部份留下来，无用的碎块丢掉。靠着决断――以及大量的努力――就可以看到这

个方法的结果。



很多其他的方法与技术一样适合于游戏设计，大部份（包括这一个）都是靠着传统程式

设计上的努力而发迹。这是一个已经证实可以生产出高品质软体、可以不断的制作续集

的系统，每一阶段的产品周期，就可以一点又一点的朝游戏发行迈进。



游戏研发者的特别之处，在于他们会把任何放在他们工作路线上面的限制，以最快的速

度打掉。当然了，如果所有的企划都可以拥有水准以上的表现，并在规定的时间完成，

这些措施根本就是不需要的。



在各种理由之下，真实世界并非如此，所以在这边传达的讯息应该是［没试过之前给我

乖一点！］不管怎么说，结果可能会让您很高兴。
  


 
deen8888
rank: Newbie
essentials: 0  
posts: 21
gem: 1
sp: 103
oge: 0

onlined:2 hours
join date:2008-03-17
last login:2008-04-23
»资料 »短信息 »推荐 »引用 »编辑



第十二章　里程碑及期限







＊企划的时程安排



＊避免独断的期限



＊破除模糊的里程碑



＊企划的开始







不管我们多喜欢在自由而且没有压力的情况下撰写软体，一些里程碑与期限这是有必要

的。是的，它们是所有［不琐碎软体企划］的常见要素，而且也是许多研发者生命中的

祸根。



在看看所有的里程碑和期限后，很令人惊讶的是，大部分的里程碑规格都是设定在一个

独断的风格之中：而且在大部份的情况下，期限则是定义在一个［期限］的基础上，而

非实际的预估。这个特点来自不同要素的作用，包括市场的影响、没有经验的软体管理

者，而且在某些情况下，包括了极为固执的人。当然了，大部份的人们只是不知道如何

针对软体的研发来预估时程。想要维持公平是一个困难的过程，而且它包括了许多的分

析与计算，才能产生有用的结果。



在游戏产业之外，软体公司使用一个比较严密的方式，而不是［选一天并期望那天做完

］。即使如此，贵重的训练以及指导方针，还是有助于在合理的态度下，定义出里程碑

。



里程碑的作用是把企划分解成可以管理的厚块。最不应该采用的作法，就是列出一长串

想用的功能列表，让研发者一个个查看是不是统统完成：当然了，事实上也不应该建议

这种方式。您可以想象到，在一个企划持续了18个月的时间后，每个星期只能在几个要

件上面打勾，会让士气低落到什么样子？这种做事的方式有可能成功吗？小组要怎样去

集中精神并保持热忱？如同它的荒谬之处，有些企划仍然使用这样的系统来进研发，而

它们的过程可能是软体研发中最无趣的。



在这边呈现的方式可以运用在各种类型的软体上，不管是试算表、资料库或是大型电玩

中的射击游戏。这个章节将告诉您一组以［良好经验］为基础的指导方针，以更实际的

方法来定义里程碑和期限。在本书的后面，我们会解释这些预测是如何进展，并随着企

划的延续而越来越精确。这个越来越精确的现象，可以视为集中性的规则。在讨论企划

的全面结构时，这个章节也可以做为本书未来章节的地图。所以，如果您正在寻找研发

过程的相关资讯，这个章节可以说是您的第一站。







里程碑如何运作



您有多少次，非要用一个［模糊］的里程碑当做目标来工作？对没有经验的人而言（而

且数量不能太多！），一个模糊里程碑是一个有很多解释且具备X种可能完成它的方式，

而这个X代表您想要的任何数字，只要比1大就行。



而且您要怎么样才知道您抵达了一个模糊里程碑？如果这个里程碑的目标十分模糊，在

预想的情况下，它们就是开放性的解释。那谁的解释才算数？当然了，这通常要靠您的

老板才能做出［正确］的解释，而且很可能出现的情况是，他与您的看法完全不同。



试试这个简单的测试。想象您的老板给您一张纸，上面画了五角形的五个点，标示出A、

B、C、D和E，如同图12.1所示。



现在，想象您的老板说：［我今天很忙，而且我需要在一个小时中完成这个工作。我有

很多人要见，所以我只能简要的告诉你我需要你做些什么事。我要你在A和B之间画一条

线，在我从生意上的午餐回来之前做好。



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



如果您直接在A与B之间画一条线（如同图12.2），我很抱歉，但您输了。不过，如果您

先在A与E之间画一条线，然后确定这条线延伸绕着五角形穿过D、E和B，（如同图12.3）

，而且在A与B之间留下空白，那您就成功的达民了里程碑。



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



要走到您的解答，它可能代表您作了太多或是太少的事情；而大部份的情况下，程式设

计师的基本心理一定会倾向后者。这并不表示良好的程式设计师都是懒虫；这只是表示

在普通的原则下，二点之间的最短距离是直线（大部份的良好程式设计师，喜欢以最小

的工作量，产生出规定的结果）。



不过，在前者的情况下（作了太多事）也通常代表错误的工作方式，这表示程式设计师

在解答方面太过热心，提供了不需要或是没有必要的复杂功能。



在完美的情况下，里程碑不应该有这些大的活动空间，但很不幸的是，这一类状况正是

大部分安排时程的问题核心所在。在一个比率公平的企划中，里程碑之间的距离放得太

远，它们之间就可以容许一定程度的偏移；象是进行不必要的工作，或是缺乏集中注意

力的焦点。



一个里程碑应该十分明确而简洁。它应该也很明显，足以一眼就看出这个里程碑是否已

经到达：黑与白、失败与成功。它不应该迎合或是鼓励任何野心的结果或是灰暗的阴影

。没有人可以说一个里程碑完成了90%；一个完成90%的里程碑给人的感觉，好象是一个

灯泡的亮度为90%；这个灯泡只有亮与不亮，里程碑也是如此。



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







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



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



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



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



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



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



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







这个列表是一份更详细的分析文件。这个分析应该详细到没有产生怀疑或是问题的空间

。告诉您如何去解决问题。在这个例子中，还有一个更好的解决方式，而且产生出来的

解答刚好可以想连的点连起来（一语双关）。您可能觉得这样的作法会将程式的创意抹

杀，对这一点，我的回答是［程式并不是发挥创意的空间］，换句话说［有创意性的程

式设计］叫做胡闹。适合发挥创意的地方叫做设计与结构，在我们开始进行系统的程式

撰写时，游戏与结果设计者已经完成了所有创意的部份。这一点可能会削弱自尊，但是

一个程式设计师的工作就是很简单的翻译：拿到详细的设计，把它转换成可以在电脑上

面执行的东西。



我可能已经听到程式设计师的坚决声明，说他们是创意上的天才，我怎么有这种胆子把

他们贬低成只会写程式码的猴子？嗯，只写程式的程式设计师是程式码猴子。一个真正

设计工作中的程式设计，在一个漫长而复杂的过程中，真的只是一个小小的阶段。它是

一个结束的修正，一个微小但重要的详细过程。不过，程式设计师通常有更大的责任，

而不只是写程式码。在大部份的状况下，他们也要为详细的模组设计以及相关的执行工

作负责。这可以让他们把创意移到该去的地方，把创意放入附有详细说明的程式码设计

文件，而不只是在写程式码。



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

提供了我的看法。



我曾经参与过的每一个良好企划，都有意把程式设计的等级降到简单的翻译。这些企划

都平顺的进行，也统统在时间与预算的要求下完工。



相反的，所有我曾经参与的不良企划，都直接从整体的结构设计进入程式码的编写。在

没有例外的情况下，这些企划都超出了原先的预算，而且完成时间向后拉长――如果他

们真的完成的话。



如同在案例研究12.1所示，模糊里程碑会导致企划的延期，而且结果是让那些守着里程

碑的利益团体，出现迷惑以及大量的猜疑。如果没有指出一个明确的中止点与进度，您

就降低了企划的可见度，这表示没有人真正知道这个企划的进度在哪里。所以，延期与

问题成为疾病，在没有人想出一套解决这种问题的方案下，它就这样发生、不受注意，

一天又一天直到它大到无法忽略为止。在统计学上，大部份的企划损失时间导致没能及

时完工：就是因为延期又造成了延期。这样的问题必须及早解决，而且这个状况明明可

以及早矫正。







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



在我很早以专业身份担任第一个游戏的企划时，我刚刚从学校出来，被指派一个看来很

简单的任务：为我们正在进行的游戏，以微软的Visual Basic4写一个关卡编辑器。



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



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

也看不到问题的所在。



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

知识下，我开始工作。



第一个障碍，在于我对问题领域没有足够的知识：我不知道它要的是什么，即使我的老

板和我认为，我们二个脑子中的游戏完成产品想象图是一模一样的。



我在思考的企划（而且我知道我可以在二个星期内完工）是一个用方格为基础的地形编

辑器，可以产生出棋盘式的方块，然后用这些方块拚出有高度的地图。



而在我的老板脑中的企划，需要的是一个地形编辑器，不但有拥有上述的能力，还要能

够自动用乱数或是输入一张代表高度的地图，让从VistaPro（一种地形产生套装软体）

载入的资料来产生出地形，并启动更换地形上面的游戏物件（包括让先前安置的部队自

动产生阵形），自动输入并在输出给美术师时进行分类，而且产生一组完整的关卡档案

，其中所用的色盘将视每个关卡来最佳化。



这二份上述的说明，都是关卡编辑器的描述，但只有一个有可能在二个星期中完成，而

且只有一个（在我老板的意见中）才是对的。不幸的是，我们二个看到的并不是同一个

。



结果，在二个星期后，我以每一个规格完成了地形编辑器，所以达到我的企划目标（这

是我所见到的）。没有人告诉我其他的东西，而且只有一个时间很紧的期限，我在写程

式时没有办法加入任何东西，当然我也不可能提供一个选择，让这些东西在日后再加进

来（换句话说，我在进行软体创造时，用的是［地狱程式码］的方式）。



最后的结果，是要再花十个星期的时间，才能达到里程碑，而且这个程式最后执行起来

慢得让人受不了，因为它用了Visual Basic4，去尝试做太多色盘有关的处理。







模糊里程碑



就象登山者会被人警告不要去吃黄色的雪，您得到的警告则是不要容忍模糊里程碑，这

是一个常识。为什么要在规定的期限内，朝一个您甚至不清楚在哪边的目标前进，而且

在您抵达目标之后，还有可能和别人争执这个目标立在什么地方？模糊正是软体时程安

排上的敌人。



模糊里程碑也会导致在企划进行全面的规格定义之前，先完成里程碑与时程表。因于这

个时候还不清楚问题的领域在那边，里程碑是以概略的通则来定义，而期限则是以独断

的行为，将可用时间予以切割，以直觉般的本能来安置。通常在单一的里程碑中会包括

太多的工作，这代表在到达这个里程碑之前，必须完成所有分散的工作。这就会形成一

个模糊里程碑，而且可以合法的描述成一个（举例来说）半完成的东西（象是要完成这

个东西要二股力量，但只完成了一项）。



在单一的里程碑中填入了太多的东西，会招致反效果。除了很明显让人迷惑的要素外，

它也会导致其他的次要问题。小组会觉得他们要做的事情是达成一个里程碑，但是要到

达这个里程碑之前所花的额外时间，将会影响到士气，而且整个小组的态度也会转换成

一场壕沟战：我们每天都在对抗他们，并在不断的磨擦中降低了前进的速度。一个小组

，应该知道要花掉多少时间，所造成的进展在整个企划中占了多少百分比。



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

作。







里程碑与迷你里程碑



如同定理一样，要踏上一个里程碑所花的最好时间，应该是四到八周。这将提供有限的

目标，可以让里程碑在合理的情况下受到所有人的重视。另一个问题是庞大的模糊里程

碑很难让人专注于其中：有谁会在意四个月之后的期限？这个状况通常会造成前三个月

的时间都没有人在写程式，而最后一个月大家都在地狱中工作。



要解决这种现象（除了把里程碑之间的距离缩短）可以把每一个里程碑分散成迷你里程

碑，或是查核点，大约每星期一次。很明显的，想要做到这一点，您必须把结构规划的

相当好。如果，您发现在目前的处境中，无法公平的定出里程碑和迷你里程碑，那么在

结构的设计上就不够完整到足以开始写程式。在这种情况下，我们可以先确定企划开始

之后的重要阶段中，是否进行着良好的运作，再来解决这些问题。如果一切进行的很好

，要让它们保持运作就比一开始要先修理问题，并勉强运作来得容易得多。一个在里程

碑和迷你里和碑之中良好的工作分配方式，是把迷你里程碑指定成完成特定模组，而把

模组的整合当铸主要的里程碑（有时候把迷你里程碑再加以分割是必要的，但是这将视

您小组以及手中的工作而定）。



在良好的小组之中，迷你里程碑不一定有存在的必要。举例来说，如果小组的经验丰富

到知道解决问题的最好方式，而且成熟到时时留意期限的逼近时，就没有设立的必要。

不过，对新的小组或是一个全新而不熟悉的企划来说，迷你里程碑就可以做为二种用途

：







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



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







第一点中很重要的是不要把里程碑的间隔安置得太远，才能避免人员在企划中漫无目标

的漂流。一个很类似的情况，是想象您手中有一份指示，叫您前往一个您从来没去过的

地方，但是您对这个地区有个模糊的印象。现在有人请您沿途画出一张路线图，并在有

限的时间中抵达。在您上路时，您最花时间的工作是画地图，从现在开始，您会不断的

走走停停，四处看看您的前进方向。



在这个例子中，里程碑就是您走走停停的动作，而企划就是地图。您走走仿停停的次数

越频繁，您在地图上面走错路的可能性就越低。很明显的，这个方式正是［报酬递减法

则］：如果您每走二步就停下来，不只会花更久的时间到达，而且您无法专注于绘制地

图。如何找出这方面的平衡就是关键，这个里程碑不应该如此频繁，导致有效的工作进

行受到损失；但是也不能一次冲刺得太远，然后看到整个企划迷失方向。



一个良好的定则是把迷你里程碑的数量，以小组对这个主题的经验高低来调整；而这个

迷你里程碑少要保持在一或二天。任何比这个数值更小的时段，将需要更频繁的管理，

而且在可见度方面会让坏处多于益处。







何时要使用里程碑



在一般的情况下，每一个程式或模组都是一个独立的企划；而且对大部份的程式而言，

这都该被视为本质相同，而且提供相关规格与说明文件。是什么东西导致程式琐碎并没

有定论，但是在这边的建议，是只有在您能够断言没有其他用途之下，才考虑写一个要

丢弃的程式（即原型程式），这可以减少程式琐碎化的机率。如果您用这个程式继续研

发下去，只会产生一个荒废谬的庞大企划。



一个可以做为例子，并符合上述标准的程式，是那些生产出对照表的程式。它会产生出

预先计算的数值档案，以减少执行时所需的计算（在处理器越来越快的现在，对照表已

经不再受到青睐，但是它们在速度有限的系统上面仍然十分有用）。要研发这一类的产

生方式，将包括撰写常式分析器，可以读取使用者定义的公式来产生表格。在这个特定

的状况下，很明显的要比把计算公式写死在程式中的好。







让您的里程碑正确



为了增加时程表的正确性，我们需要尽可能的把不确定的东西移除掉。这并不表示您可

以移除所有的东西，但是只要您能把不确定的数字降到最低，就等于避开了里程碑的模

糊性。



在案例研究12.1中，问题源自于一个共通性的误解，以及对正确的需求缺乏深度的说明

。之所以没有附上说明用文件的原因，是因为在这个问题领域中没有进行相关的研究。

在给予了严格的期限后，很明显的并没有提供任何相关需求与想法。老板只是假设他想

要的知识会［自动］的从他的脑袋传到我的脑袋中。在混合了这样的想法后，他假定其

他的组员可以在数分钟之内，把他们所需的东西说得一清二楚。



这实在一点道理也没有，但是您会很惊讶而且吓一跳的，是有好几个企划的确就是以这

样的基础来进行。大量的金钱都花在这种预期上，而不把所有可能影响到企划进度的要

素列入计算之中。在一些案例中，期限的设定基础是由市场部门要求的，这可能只有最

没品质的小组才能同意这样的要求。



发行日期很显然是源自市场方面的压力，但它绝对不应该成为时程主题的决定要素。尝

试让小组去尊重市场部门设定的期限是不可能的，尤其是当这些期限设定在独断而不合

理的前提之下，再加上完全不把研发方面的技术要素考虑在内。如果出现了一个市场决

定的期限（象声名狼藉的圣诞佳节大冲突），那就得把功能加以调整，才能让企划符合

规定的期限。这个减少的功能必须在各方面都十分的清楚，碰上这一类情况最有效的回

答，就是要求修整时程表的时间，但是要完成的工作量还是一样（这边的假定是，反正

所有的研发人员都在时程表上面填了一些空间，来让他们的生活轻松点。这是很荒唐的

事，但如果您屈服在这种假定之下，您就是在自找麻烦）。在处理所需的工作量上面，

这个时程表一定要经过最佳化并极为清楚。如果这个工作必须在短时间完成，那就非得

砍掉一些功能不可。我已经看过太多的状况，是企划领导者同意这样的状况，并假定他

们可以在12个月中完成18个月的工作。不得不承认的是，只要足够的超量工作，这并不

是不可能的。尝试让一个研发小组在紧密而且加班情况下工作12个月，处理上吨的工作

并非容易的事（而且绝对不建议这样做）。这会伤害原本高昂的士气，而且这个企划结

束之后，失去您所有技能高超的研发人员，也不是什么怪事。



在案例研究12.1中的程式期限很明确，但是对这种正式的工作而言太短了。在这个企划

中光是收集资讯至少就要一个星期，而且如果先收集到足够的资料，就可以预测出这个

企划需要再花六个星期来撰写。当然了，就算这个预测是靠着其他组员在这段期间的工

作量来判定，您还是要把撰写说明文件的时间，以及说明这个编辑器中所需的功能考虑

在内。这件事可能会得到老板的同意（或是拒绝），但至少这个结果可以让他采取其他

的选择，象是指派更多的人加入这个企划、降低要求、延展时程表、给这个企划一些在

相关领域中经验丰富的人，或是把您开除掉！



在您想要规划并为整个企划安排时程表之前，您有些动作是一定要先完成的。一个企划

的前三个里程碑（如表12.1所示）一定要实行，这可以让您更详细而且更精确的分析出

接下来的每个月，时间要如何运用。







表12.1　前三个里程碑



里程碑

查核点

工作



1

1.0

一般性必备物资收集





1.1

技术性必备物资收集





1.2

资源上必备物资收集



2

2.0

一般可行性研究





2.1

技术可行性研究





2.2

资源可用性研究



3

3.0

结构规格草案





3.1

企划开始









这些里程碑有效的包括早期规划以及可行性的研究。这些阶段的花费，是企划总成本中

最小的一部份，而且它有助于提供良好的资讯，计算出整个企划的总成本、时间以及技

术上的可行性。在第一个里程碑之后的每一步，都让做决策的人有一个很好的地位取消

整个企划，或是让它朝下一个里程碑继续前进。在那三个里程碑完成时表示企划可以开

始运行，那企划就应该可以朝完成的方向迈进（除非它掉入汪洋大海）。如果通过了可

行性的研究再把企划取消掉，那应该视为可行性研发过程的失败，并进一步的调查。



一个企划的初始调查阶段的实行优点十分明显，毕竟接下来是为期15个月的研发过程，

在所有人的身上投入大量的金钱与努力，并假定每个人都可以把这个企划完成（这个情

况有没有让你们听到擂台上的钟敲响了？）取消一个企划对士气的影响，将会随着企划

进行的时间而不断的增大。不过，如果组员有进行过可行性的研究来查看技术与可玩性

方面的需求，那这个伤害就可以降到最低：每个人都可以了解他们做的是一个企划的研

究，看看它是否值得尝试。如果最后的结果是可行，则所有人都会受到鼓舞。不过，如

果所有人都做了各方面的可行性查核，但最后还是有机会被取消时，效果就没有那么好

了。



人们的天性是在舒适安全的位置上时，工作表现会更好。当然了，一个企划早夭的风险

还是无法全面消除，但是它至少可以藉由在进行时，早点解决任何主要的问题把可能性

降到最低，而且要在大量的金钱与人力投注到这个企划前完成。否则，您不只会失去您

的金钱与时间，您还会失去人们对您的尊重。







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



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

。



在一个与热门《Cryptlnvader》系列发行公司，也是Y公司的总裁――司诺先生的会面中

，他声称Y公司最近大约中止了十个企划案，这些都是在做了六个月之后　，结果无法达

到预期的东西，而这些企划案已经进行各种不同阶段的研发，而且都在上面砸了不少钱

。



司诺先生说，这样的作法是为了保证他们推出的软体都具有高度的水准，听起来很有商

场上的味道。据司诺先生表示，这些企划取消的费用（包括《Fatal prison ll》），每

一个企划都将近在￥160000到￥720000之间，对他而言这并不算是大问题。有些人可能

会说，如果您有手中这么多Y公司到处投注的钱财，那您也看不到什么东西叫做问题。不

过，如果您考虑到这笔钱可能全部用在资助四个其他的企划（如果早期的原型阶段执行

的很好），那这就是完全不同的光景。这种努力的浪费不只在金钱上面很可观，而且它

也不利于研发小组的士气（可能有上百人）。







在案例研究12.2中，企划案中止于不同的研发时程。幸运的是，其中有些仍然在原型的

阶段，所以不会花太多钱；就算如此，￥150000美元花在一系列的原型上面，仍然是一

大笔金钱。在现实中，我在一个原型上面的金额不会超过￥75000，这只是看您如何定义

（原型）这个字。在这些案例中，［原型］并不真的是指传统的字面意义，而是完整研

发游戏的部份研发版本。在大部份的状况下，这个游戏将会以普通的方式开始研发，而

且在主要的研发中，分离的原型并没有什么效果（的确如此）。在这些例子中，原型的

程式码是真正游戏所用的程式码。



不过，一个［原型］的意义是这样的：快速而可丢弃。这是一个测试点子与概念的动作

，所以不要与科技研发搞混了。原型阶段的用意在于研究出游戏概念的可行性。在这个

阶段的结尾，需要的科技应该已经完工（或是找到可以取代的方式）。这并不象它听起

来那么限制良多，因为这些元件将会在标准的介面中研发，如果（或是有时）一个新的

科技在真正的企划过程中研发完成，这个新的元件也可以在后期把它插入正确的位置。



这个原型甚至不需要以编译式语言来撰写。通常一系列连续的原型――从纸笔进展到高

等级、快速研发的语言（象是培基语言）――都足以测试这个粗糙的概念。不管怎么说

，它是一个原型，又不是完成的产品，而且如果它与最后的产品是用不同的语言来撰写

，那就可以断绝将［原型］当做［完成产品］的所有可能。



把原型的程式码放入正式产品等于在调制一场灾难，因为通常在定义上面，一个原型并

不具有［产品等级程式码］（译注：真正成品所用的程式码，以下称为［产品程式码］

）的特性。这不只是程式码写得很草率，还包括了写原型时编写程式码的优先程度。举

例来说，游戏执行速度并不是在原型程式码中的第一条件，但是在一些产品程式码中却

是最优先的事项。不要低估把原型程式码放入完整产品的诱惑，那种节省时间的期望相

当于一个危险的陷阱，通常导致的结果是显著的时间延迟以及后期产生的大量问题。所

以，把原型的程式码用在产品程式码是一个不值得尝试的举动，这不但是一个不可能完

成的工作，而且甚至有可能阻碍原型的研发。



在表12.1中的里程碑时程表试图包括上述的所有要点，并包括企划的初始阶段，一直上

溯到可行性的研究。



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







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



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







企划是什么？



很明显的，它是一个游戏，游戏的元件，或是一个有助于游戏生产的工作。但是哪一类

的游戏？目标的客层是什么？为什么会让他们满足？游戏的什么地方、以及这个游戏如

何与公司的远景契合。这些问题的答案，有助于集中这个企划的焦点。



什么样的游戏要写出什么东西，应该不会有什么问题。举例来说，应该探索游戏的外观

及感觉，还有在一般层级中，所有其他足以影响游戏的主题和考量。我个人很讨厌使用

［任务说明］这个字眼，但如果我写的任何企划包括了这个字，那这就是需要定义的地

方。







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



在这个案例中，顾客可以定义成好几个不同的层级。第一种顾客是公司的管理部门，第

二种是发行公司，第三种是媒体，而最后（希望不是最少的）一种是购买的大众。



每一个群组的顾客必须特别迎合他们的需求，而且很麻烦的是，他们的需求与想要的东

西都不见得相同。每一边都可以证明他们具有同等的重要性，所以要让所有人高兴就很

难平衡。举例来说，管理部门与发行公司可能要示一个正式的展示，以及间歇性的推出

先睹为快或是展示。媒体会需要游戏的远景，而且购买大众要的是完成的产品！这些需

求都要先行预期，并放入您的时程表中（至少最后一个少不了）。







需要的最小功能是什么？



很让人惊讶的是，最小的功能正是最重要的考量。虽然我不想去研究这种灰暗的想法，

但是研发时还是要了解它；如同真爱一样，从来不会象预期般平顺。从企划的最早阶段

，就必须定义数个功能上的阶段（这些将在第14章中介绍，并在第三部做进一步的讨论

）。



最低的功能阶段定义了最小的需求：也就是软体已经［有足够的完成度］然后可以发行

到市面。在这个时候的游戏可能不会特别好，但至少它的核心可以运作。达到这一点是

时程表的主要目标，一旦这一点成功的抵达之后，进一步的功能就可以一阶段一阶段的

逐步加入，直到理想中的功能出现，然后产品才能发行。当然了，如果企划碰上了任何

延误，它可能需要的是在所有想要功能加入之前把游戏推出去。在这种情况下，您会很

高兴您采用的是阶段性的方式。



在这个阶段中，您得收集所有与企划相关的必备物资，这可以让您在整个企划中，成为

一般性的指导方针。



这个阶段必备的是游戏提案文件，如果第一部所定义的一样。它的要旨是一份小小的文

件，描述了游戏给人的主要感觉，以及它背后的所有点子。



从这个初始的提案，您可以研发游戏设计文件，如同在第一部所示。一旦游戏设计全面

规格化（80/20规则的发展主题！）那它已经提供了足够的力量，可以进入下一个阶段。









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



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







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



最理想的状况，是在您拥有所有元件的情况下进行研发。接下来这个问题就比较容易回

答了，如果您没有需要的元件，他们是不是可以在一定的时间中轻易完成，还是需要进

行研究，才能把定义出来的功能写好？



如果需要研究的话，那这个企划就不能跳过原型的阶段。很重要的一件事是，必须把它

一直延期直到研究完成为止；只要您打破这个规则，您就在承受一个不能接受的风险。

记住这个研发过程中的物件，已经尽其可能的把风险降低。不依靠研究而硬性认为可以

在固定时间写好，相当于损坏所有已经在进行的方式。千万别做。



如果您确定要研发的技术是可行的（您现在有了应变之道），那您可能想要继续研发出

一个原型。一个应变的例子是，在您想要运用所有硬体支援的3D画面之前，先写好一个

以软体运算的3D程式。就算硬体支援失败了，您还是可以运用软体引擎，虽然有点麻烦

，但至少不会让失败成定局。不过，您应该小心的步步为营。







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



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







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



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



在这方面不要太热衷；否则您可能连厨房的流理台都列了出来。相反的，理性一点。您

的预算可能很有限，而且根据墨菲定律，只要您用掉了您手中的预算，就会推出一个主

要的软体，而您一定买不起。



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



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



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



＊侧写程式（Numega TrueTime）



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



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



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



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



＊2D绘图软体（Adobe Photoshop）



＊格式翻译软体（Okino Polytrans）







（这个列表中的东西，只是以我最熟悉的软体来进行建议，也是目前的研发公司最常使

用的东西。这些软体中有些可能很贵，尤其是在预算有限的状况下。幸好仍有其他的选

择，而且在本书附上的光碟中，也提供了一系列的免费或是共享软体，或是您可以在哪

边搜寻的建议。您可以在附录B找到与软体相关的详细内容。）







血腥的尖端科技



您想要一些有用的建议，或是从痛苦中学到的一点点经验吗？那就是绝对不要用最新版

的软体，直到它已经推出一段时间为止。如果您在一个企划半途转换版本，它也会造成

延期。另外，如果事情进行的不顺利，把软体版本［倒转］回去将是一个很花时间而且

很昂贵的工作。他们叫做［血腥的尖端科技］，自然有其道理。







查核点2.0　一般可行性研究



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







这是一个有价值的企划？



您应该开始探讨游戏性与故事，并把它打磨光亮。很明显的，这并不会马上定案，而是

倾向在研发过程不断的调整与变革；这是把旧点子挥去，并加入新发现、好点子的时刻

。



在这边要提出一个警告：小心特色四处蔓延。很多游戏之所以延期或是取消，是因为低

估了加入的特色。特色的潜行，以及它的预防方式，将在第三部中讨论。







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



这个游戏是否适合目前的市场？这并不表示游戏应该毫无新意，只是模仿市面上已经有

的游戏（如果真的这样，那您就要重新考虑这个企划。有太多的公司生产出没有新意而

且毫无生机的游戏，用不着您再加上一笔。回到第一步，直到您有更具启发性的点子！

）



好，假定您还在这边，那您的游戏设计也通过第一道酸碱测试。下一个问题，是这个游

戏设计到底是个全新的类型，还是目前类型的延伸。如果是一个全新的游戏，那我会建

议您研究一下市场是否能够接受它。在刚开始时，试着询问一群中立、对游戏设计有不

少批评的人们。问问他们这种游戏会不会想玩，并询问他们喜欢与不喜欢的部份。这边

最重要的是得到诚实（虽然一向都很唐突）的答案，然后排除掉家庭、朋友与同事的意

见。一个最常见的建议是，设计一个您会想玩的游戏；这本身并没有什么问题，但是您

冒的最大风险是把游戏做成只有您要玩的东西。当然了，您必须设计一个您也想玩的游

戏，但这绝对不能成为您的指导方针。



如果游戏是以现有的游戏做延伸，那上述的建议仍然有效。除此之外，试着去定义您的

游戏如何加强这个类型。一个最传统的范例是Valve的《战慄时空》，一个第一人称射击

游戏，是以《雷神之鎚2》的引擎来建构的。不过，它在1998年成为最佳游戏时，也有许

多竞争者在同一时段上市（象是《原罪》与《魔域幻境》）。《战慄时空》慎思熟虑之

后，在这个类型中加上了强而有力的故事、敌方不可思议的人工智慧，并十分小心的建

造游戏中的环境。在《战慄时空》中，通常每个面前的问题都有二种解决方式：您可以

用强大的火力轰进去，把眼前会动的东西统统杀光；或是您可以想想下一步怎么做。这

是一个极佳游戏性的典范（不过，这个让人思考的元素在接近游戏尾声时似乎越来越小

，要过关靠的是更为快速的反应与大量的弹药）。



当您考虑到推出一个既有的类型时，试着在现有的内容中加强，而不是遵循传统的［更

多的武器、更多的敌人、更多的爆炸］途径。举个如何不去扩张既有类型的例子，看看

即时战争的类型。在1998年12月，已经出现了停滞的现象，只有一些明珠（象是Blizzar

d的《星海争霸》）可以在这堆垃圾中增加一些新的东西。



运用您的想象力，试着开拓每一个可行性，来收集设计的点子与意见。一般可行性的研

究是在一场研发过场中的最后重点，而重新建造主要的游戏设计，可以在便宜而有效率

的情况下完成，所以在这方面要全力以赴。如果一个想法成不了气候，不要害怕丢掉一

个研发内容中的争执。这可能会因为参与的人员与内部政策而更加的困难，但是最好在

这个阶段承认个人的失败，而不要推出一个差劲的游戏，然后伤害到公司的形象（这会

在大多面前承认您的失败，包括您让一个失败的游戏设计成为漏网之鱼）。



查核点2.1　技术可行性研究



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



什么是效率方面的需求？



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



游戏研发者的运气很好。他们通常使用最好的装备、最快的机器，以及最新的硬体；在

这样的硬体上面，游戏跑得象在飞一样。而一般的使用者，当然了，就没有这么好运了

，而且他们通常用的是普通的机器。研究显示出顾客大约每隔一年就会买一台新的电脑

（这通常是因为领先的游戏，一向需要最新而且最好的硬体）。您的一般顾客可能会在

二到三年的期间换一点PC，同时提升各方面的性能。这本书在我的许多电脑上面撰写，

其中一台二年之久的Pentium 200 MHz MMX，我还觉得很好用。我觉得没必须升级到Pent

ium ll这种怪物级的电脑，在成为不可或缺的设备前，大部份的普通使用者也没有这个

必要（译注：本书出版日期是1998年，以现在的电脑水准而言，想买台Pentium ll只有

到古董去找了）。



当您选定了基础等级的机器后，您应该估算的是二到三年以后的技术，并用此来推算未

来这个基础等级的主机成长到什么程度。如果您指的是更高等的基本配备，那您应该有

一个很好的理由（举例来说，您是ID Software，正准备推出Trinity程式引擎），或是

接受销售上面可能出现的损失。只有最尖端的游戏才能将基本的设定向前推到另一个新

的标准。一般来说，在常见的研发时程（18个月）之后，今天尖端的机器可能只是产品

发行时，只能称为中上等级的电脑。







查核点2.2　资源可用性研究



查核点1.2定义了企划所需的软体以及书藉。而查核点2.2的目标是合并早期几个查核点

的结果，并选择企划群组中的初始人员（如同第11章中定义的）。如果可能的情况下，

企划群组应该选择的人员，尽量以该企划内容范围技术最好的人为主。这个小组的大小

视企划而定。一个小型企划中用二到三人的规模十分合适，但是更大的企划就需要更大

的群组。虽然这一点似乎很明显，但要指派一个企划中的人员，一向比它外表看起来复

杂得多：一个群组人数太多，您冒的就是效率不彰并有额外费用的危险：人数太少则冒

的风险是小组人员工作过量，并会造成延误。主要的观念就是第一次就把状况平衡过来

。在后期再来变更这一点，通常会更为困难，而且要花的钱也更可观（在第21章会更详

细的讨论这一点）。



在查核点1.1中将会决定进行企划之前是否要先进行研究工作，然后这个时刻也是决定您

要不要开始研发这个企划的相关内容。如果答案是否定，这就是这个企划的结束。难以

下咽吗？您可以看看好的一面：很可能现在要做这个企划早了一点（您至少要等全相萤

幕出现在市面上并人手一台，才能做一个用全相萤幕来玩的游戏吧？）所以它可能在往

后才有一鸣惊人的时刻。不过，请记住这个游戏应该还是以游戏性为主，而不是以科技

为优先。不然我们不会叫它为游戏。



如果最后决定要进行研究的话，那这个企划将衍生出更多的研究企划。查核点3.0与3.1

（后述）仍然可以进行，但是从这边开始，我们就得等候企划研究的成果（这些已经在

第11章中讨论过，本书后面会再提及）。







查核点3.0　结构规格草案



第一件要了解的事，就是结构是一个不断演进的怪物。除了一些研发产业中的人员持续

的主张以外，在一个企划开始进行之前，把整个结构全部定出来是很重要的一件事。我

们的老朋友――80/20规则，又再度昂首了。



在合理的预期之下，我们顶多只能在一个企划开始时，完成大约80%的结构；而这个结果

可能会让大部份游戏产业的研发者大吃一惊。虽然在游戏产业以外比较容易看到一个企

划定义到这种程度，但这些都是会成功的企划，而且很受欢迎。一旦结构的完成度觉得

将近有80%，企划就可以开始了。剩下的20%会在企划过程中完成（剩下的20%通常包括了

无法先行处理的东西，这部份在第三部将会进一步的说明）。







查核点3.1　企划开始



这个完成度80%的结构，已经足以安排初步的行程表了。工作将分为逻辑模组，并以合适

的方法分给所有的群组。这个模组将会在小组之间打碎，成为更进一步的时程表。这个

次级的时程表会再分散成一系列的独立工作，然后指派给独立的成员。



研发是一组复杂的独立工作，需要进行组织化才能缩短关键路径的问题。这些工作的分

析以及企划管理时间相互依赖的主要部份，将影响到整个研发过程。与结构一样，时程

表也会在研发过程中不断的更新（这可能包括调整每个人的时程表，并在组员之间交换

个人的工作）。重点是不断持续的追踪过程，将会在企划中不断的进行；而不是在碰上

问题时才来追踪。如同我们将在第14章解释的一样，解决疑难杂症的最佳方式是靠主动

，而不是预防。



研发过程在这个阶段犯下的经常性错误，是把行程表当做刻在石头上的东西；而且这个

概念在游戏产业中占了大多数。如果您好好思考一下这个问题，您就会了角这有多荒谬

：怎么会有任何人可以预测接下来的18个月时间中，每一个人的工作内容？通常只有在

紧急的情况下才会变更时程表：在整个企划陷入危机时的主要调整，也是［太少，太晚

］的例子。



如同在导引一艘船一样，您可以在航行中不断的变更微小的角度，以更好的方式来导引

这艘船，而不是靠近目标再做一次大调整。







下一步



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



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







定义里程碑



一个常见的游戏企划可以分割成数个不同的子企划，这每一个子企划将会逐步具有［企

划间从属关系（interproject dependencies）］与（更精细的）［企划内从属关系（in

traproject dependencies）］



对企划常见的错误是把它们想成等大同尺寸的东西，然后假定里程碑亦是如此：一个二

次空间的列表，可以让您在里程碑A到里程碑B之间，把您目前的进展画出来，依此类推

。您应该要了解的是，这个列表事实上是碎裂在多次元的网状从属关系中。当这个网折

叠成一个直线的列表时，您就失去了所有从属关系方面的资讯，而且在所有的从属关系

中，只有最后的结果还看得到。这会降低整体的弹性，所以能让这些复杂的从属关系处

于可见的状态，而且不断的更新内容才是好的办法。



试着从少数列出来的里程碑，来看清这个复杂的网状资讯，可以比喻成尝试从一个投射

出来的影子，来创造一个复杂的三度空间物件。在影子中已经失去了一些原物件的幅员

；结果过程中将失去重要的资讯。所以您可以看得出来，在进行安置里程碑的工作时，

取得企划从属关系的资讯是极为重要的一环。



第一步是发现并定义出这些从属关系，来为每一个子企划创造出里程碑的时程表。在这

个方式下，一个多层阶级性结构的企划图表，可以从此研发出来。记住，一个企划是一

个庞大而复杂的问题，而且处理这种问题最明显的方式，就是把它打散成数个较小――

而且比较简单的问题。画出一个阶级性的企划（并包括子企划以及他们的相对元件）有

助于您得到一个较好的整体画面，是您和您的小组可以参考的。



在图12.4中显示出一个我使用的全面阶层性图表。您可以轻易的自定这个表格，用于其

他的结构上，但它基本上是用来快速了解一个企划在阶层结构中的位置以及状况。在公

司的内部网站中放置一个这样的表格，如同第11章所说明　的一样，也可以在每部份的

相关元件上面加上超链结。由于它是一个阶层性的图表，它也连结到较大的阶层，象是

连接公司中所有企划后，有助于定义出未来研发的策略。在取得从属关系并创造出阶层

性的图表后，您手中的知识可以轻易的看到整体的画面（指公司远景），然后决定如何

取得已有的资源，并减少不必要的努力。



主管在这个图表公诸于大众后，得到的好处是有效的消除掉公司之间沟通的障碍。每一

个小组中的任一位员工，都可以明确的知道其他小组人员在做什么事。这些资讯拥有高

度的扩展能力，如果必要，可以再钻研得深一点，让整个企划的所有进展可以让所有人

轻易看到。



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



您现在知道庞大的企划需要打碎成里程碑。这通常在明确定义出功能之后变得十分困难

，但是避免让里程碑成为鼓励大家走近路的诱因是十分重要的。相反的，里程碑应该定

义在结构点的附近，才能让这些解决方案保持了结构上的完整。



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







差劲的里程碑



无法提供企划进展任何相关资讯的，就是差劲里程碑。这些里程碑可以用模糊来形容，

也可以是指定了表面的层级，但什么内容都没提到。







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



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



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



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



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



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



＊进入最初的测试阶段。







这边列出的里程碑是出现在现实生活，从不同企划中取材的里程碑。有些一看就知道很

差劲，但其他并不太明显。我会一个个拿出来解释，并说明其中的优点、缺点，以及这

些里程碑应该如何指定。







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



这个里程碑（与案例研究12.1中所示的一样）是为了一个飞行射击游戏所设，要求提供

碎型几何产生的地形。这个里程碑太过于普遍；它并没有提供足够的资讯。这个普及的

里程碑应该改成下面这样的东西：对Visual Basic的关卡编辑器，实行初步的物质收集

以及可行性研究，来决定它是否符合我们游戏的世界设计。



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







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



这一项真的是表中比较好的里程碑。完整的说明是要把所有的16位元的C语言与组合语言

的模式，从16位元的结构进化，才能利用32位元处理器的全部优势。这没有什么大问题

，事实上，它十分的清楚而简明。



不过，这个问题是涵盖了太大的工作区域，而且没有指明转换码的等级在那边。举例来

说，16位元的程式码只要简单透过转址层的运用，就可以从32位元的程式码来呼叫16位

元的功能，并控制所有需要的转换过程，这也是一种［转换］。另外，这个里程碑也可

能代表从头开始撰写所有的程式码，让整个引擎都在32位元的架构下。所以我们有二种

解决方案，每一种都有它的优点与缺点。利用转址层的好处在于可以快速而直接的实施

，坏处在于额外而全面性的Layer是每一个功能呼叫都需要用它来转换变数与回傅值，而

且事实上这些程式码仍然不是全面的32位元（所以很多可能使用慢速的记忆管理呼叫，

在16位元的限制下面动作）。



第二个方法的优点在于，只要能达到这个目标，所有的效能都会提升。主要的缺点在于

这种转换工作通常要花量的时间。



这个里程碑应该以不同的转换来做为说明。事实上，也有另一个可能是不要把所有的程

式码统统加以转换（举例来说，只有最耗时的程式码才有转换的必要，而其他的程式码

――象是载取资料的程式码――大可运用转址层的方式）。



这个里程碑应该分成数个较小的里程碑，以各个不同的模组来完成这个工作。这样做可

以让您对于如何进行转换工作做出更合理的决定，而且也可以彻底的增加进展的可见度

。在现实中，这个里程碑从雷达上面直接消失了将近四个月之久，才又被人找出来进行

。这很明显是一个难以接受的风险，所以才会有查核点的设计来解决这方面的问题。不

过，在这个案例中我们的运气很好。程式设计师在这方面的能力足以胜任，而且对引擎

的了解极为透彻。不过，这种对单一组员的依赖，是一件很糟糕的事情（如同第11章所

示）。







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



这个问题与上二个十分类似：并没有提供足够的的资记讯。不过，这个里程碑中包括了

二个复杂模组的原始码整合（表示在二个引擎之间有标准化之后的资讯在流通），所以

必须先定义出二者之间的界面。这个里程碑以自己的角度描述了整个企划，而不是一个

庞大企划的一部份工作。



想想您要执行这个工作时，要做什么样的步骤。首先，您必须分析出每一个引擎输出的

资讯，才能让二个引擎同时作用。哪个引擎是主要的？要把其中一个当做另一个的次程

式吗？他们之间要如何互动？他们要共享萤幕的暂存区吗？什么样的变更，才能让引擎

使用萤幕暂存区？如果在另一个模组中使用，会产生什么样的冲突？这在未来与其他模

组整合时，又会有什么样的影响？



利用这个章节中的指导方针，您已经能够想象如何列出里程碑和查核点。藉由把问题分

解成原子的厚度，我们可以增加可见度与企划进展正确性的指标。这个点子是以足够的

问号去攻击现有的问题，让软体规划师的意图清晰可见。







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



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



我甚至无法想象这个里程碑有什么用处。这并不是以任何技术或结构为基础的查核点；

它反而象是一个用肉眼来查看的图表进度，象是一台自动机械，以精密的观察车身来检

查您的车子。要真的知道里面的东西如何运作，他需要打开车壳，看看引擎的运转才对

。



象这样的里程碑就会鼓励人们走近路，以取得可见的结果。需要肉眼来查看的里程碑（

象这个例子）就是一个倾向挖墙角的作风。还有，您又如何预测这样的一个里程碑，要

花多少时间来完成？



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

果，并不是里程碑的作用。



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

将是一个可玩的关卡。







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



＊如果完成了关卡编辑的软体，开始载入并转换关卡的档案，成为内部的资料格式（包

括所有待续的参考物件资料档载入，以及任何未知物件的控制）。



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



＊完成以摇桿或是键盘来进行的使用者界面控制，包括以设计文件与基本玩者控制的简

单选单，其中包括了结构文件中的物理系统。







这当然不见得每一个都要达到，但是它应该可以给您一些粗糙的点子，让您知道创造一

个里程碑时，二者间的不同之处。







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



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

是锁死在上一个里程碑的单一测试关卡中）。



不幸的是，结果是比前一个里程碑，包括了一般假设情况下更多的硬性规定；主要是因

为程式设计师可以看到他们必须在有限的时间中，把他们与下一个里程碑之间的东西清

掉。所以他们会运用他们眼中的所有捷径，来冲向原来的里程碑。不用说，这样做以后

有许多程式码得重写，而这些程式明明在第一次就可以写好。



这个里程碑应该是结合之前的目标，然后以技术上的目标分成数个较小的查核点，让最

后的结果可以载入游戏的关卡。







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



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

准的研发与整合测试中，分辨［最初测试阶段］？



在这个阶段我会把［最初测试阶段］定义成所有的元件都处于［界面完成］（所有在这

个企划中使用的模组，都完成了界面的设计）。这不只是个明确的进展，而且至少所有

的元件都可以进行编辑，不会出现链结错误的状况。很明显的，在这个阶段中有特定等

级的功能列表，但是――看到研发以一个方式不断的进展，如同本书所述一样――它也

很可能会有一个很有用的核心功能。







为何这些里程碑有瑕疵



这些范例中举出的里程碑，最基础的问题在于它们的模糊性。大部份都没有清楚的指明

，而且它们可以用许多不同的方式来达成。捷径可以采用、所以在企划附近会不断的繁

殖错误与误解，并越来越庞大。



如同之前声明一样，这些范例中的里程碑用来当做企划的导航点并不会有问题，但是它

们留下了大量有待详细说明、又可以完成的里程碑。它们需要分散成几个较小的里程碑

，每一个都只有二进位基准：开启与关闭。



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







良好里程碑



在看过差劲的里程碑之后，我们现在把注意力转向如何让里程碑变好。很多这方面的成

果，可以靠之前讨论的差劲里程碑加以推演（如果不是坏的，就一定是好的）来获得，

所以我们只要把良好里程碑做一个总结就行了。



一般来说，一个良好里程碑不会留下产生怀疑的空间。它会很清楚、合理、以技术与结

构的角度来说明，而且它是二进制：要不是全面完成，就是全面未完成。



良好里程碑应该详细的进行说明。每一个应该说明的极具深度，尤其是目前进展的是企

划的哪一个部份。预测不应该以充满期望的想法为基础（很严酷），真正的研发时间上

的预期是以经验为底子，而不是市场上的需求。要在圣诞节之前生出一些东西并不重要

，您无法变更物理定律，而且您也无法变更写出良好、严密程式码所无原则的时间。不

过，您可以试着进行预测并排好时程。这样做要比在程式码硬冲或是设定独断期限的赌

局，来得更容易成功。



良好的预测是从创造一份阶层时的图示，来追踪整个企划以及它所有从属东西开始，然

后从头到尾去追踪一条平面的路线，将路上相互影响所造成的延迟最小化。良好里程碑

中必须指明技术等级，而每一个里程碑或查核点都要说明结构模组与次模组的完成阶段

。这可以让里程碑更加鲜明而且定义清楚，也可以提升企划的可见度。为了正确的预测

一个里程碑所需的时间，您必须把里程碑分散成数个次要工作的列表，小到您可以合理

而正确的估算出完成它们所需的时间。这通常表示把工作打散之后可以在一或二天的时

间完成，提供良好的次级里程碑与查核点（如果需要的话）。这是一个很需要技巧的过

程，当您在预估的过程中获得经验之后，您就会发现它成为较容易分散的里程碑，并可

以让您做出精确的预估。



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

工作的微妙感觉。







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



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

念确实可行。



这个案例研究是检视企划中使用的一组真实里程碑，并详述它是如何分割为查核点。它

本身会展示出如何实行技术上的里程碑。



里程碑：



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

度。



备忘录：在朝这个里程碑迈进时，要容许退回标准的绘图运算法则，并考虑目前用来环

绕所有Z－暂存区程式码的假定编译指令。当这此些指令都完成定义之后，Z－暂存区的

程式码会启用，否则这个程式码会采用以前的方式来运作。



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

.5天）



查核点2.0.将物件分类成数量最少的组别。每一组应该包括这些物件，在平面画面的座

标一样的时候，全面重绘其他的东西。旗标将成为这个规则的例外（举例来说，不应该

让透明物件背后的东西看不到）。为每一组物件提供分别的Z－暂存区（1天）



查核点3.0.对每一个有效的种类进行Z－暂存区个体（Member）的［查核］与［设定］。

每一个游戏物件必须拥有这个个体，所以在实行时可以将它们看为画面物件资料库中的

纯粹真实个体。提供一个标准的运作，把一个点带入特定物件组的Z－暂存区中，设定一

个阶层越高越好的参数，并在必要的时候让这个特殊的案例失效（象是透明的物体）（1

天）



查核点4.0.在基础等级的［Prepare To Draw］与［Draw］个体中插入Z－暂存的检查与

设定。在这个阶段中尽快针对失败的Z－暂存区进行测试，让不需要显示出来的物件，只

要花最少的工作量。（1天）



查核点5.0.为测试关卡生产新的计时资讯，并与查核点1中的结果相比对。全面更新模组

设计文件来反应这些变化，并插入新的计时资讯（1天）。



这是一份直接的里程碑与查核点副本（虽然编写得有点简单）。我已经变更了查核点1，

如同它也考虑到回顾并整理这些程式码，来确保所有的说明都是最新撰写，而且所有的

不良程式码统统移除（因为我有一段时间，没有参与特定模组的工作）。这边并不是我

们要考虑的，但是它会让时程表再多花上一天。



在案例研究12.3中，这个特别的里程碑在结构定义之后，已经被插入了一个里程表。这

是一个结构上的变更，才能在速度较慢的显示卡上面，增加系统画面更新的速度（在这

个变更中，有20%的结构无法得知或是猜测）。如您所见，这并不象一般常见的企划里程

碑，因为它是以结构以及常用的英文，以减少技术方面的专用术语（如果这边用了专业

术语，要解释起来就容易得多）。







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

核点大约是二天一次。







研发与期限



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



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



一个期限说明的是固定的日期与时间，由一个小心而充满考量的工作之下所假设出来。

从另一个角度来看，研究是一个探索未知事物的举动。要如何正确的为不知道的事情，

来正确的安排时间？如果不行的话，您可以试着向您身边大部份的企划管理者解释，然

后看看您会得到什么样的反应。



在这个情况下的研究，不应该与必备物资的收集搞混了。研究是一个追寻新的科技与运

算法则，以实现一个点子的过程。必备物资的收集是一个靠着设计文件来找寻您所需要

的东西，用来建造产品的过程。



程式设计师的主要工作，如同前一章所提示的，就是把一组详细的技术规格转换成一个

程式，或是程式模组。这并不是在职位上的研发工作，而且要在期限中完成。研究与期

限通常具有独立性的本质，如果在一个企划的目前阶段需要研究，那在初始的可行性研

究中肯定出了一些大问题（这些可能性应该在事前就探讨过了）。所有的研究都有风险

：您的风险就是没有结果。之后您在一个企划冒着研究的风险时，表示有更多无法接受

的风险随之出现。简而言之，在一个企划中，避免所有不必要的研究。







里程碑的评定



当评定一个里程碑的时候，在完成之前要有数个人签名。至少，这些人包括发行公司、

原公司以及企划管理者。正因为如此，里程碑倾向于以结果为基础，可以在视觉上展现

成果的时刻。如同我们之前所讨论过的，这并不是好事。里程碑的基础如果架在视觉效

果上，表示您通常会看到您想要的：一个有着美丽外观而败絮其中的程式。象是湖上的

天鹅一样，它在水面上表现的流畅而优雅，但是脚掌在水下强烈的拍动。这就是里程碑

在游戏产业中评定的方法（或许这可以解释一些现象，象是游戏现在把风格凌驾在内容

之上）。



整个研发的生命周期是以外表的模样为基准，而不是以内在的结构。虽然这对绘图而言

不错，但显然对复杂的技术工作――象是电脑程式――没有什么好处。如果这些标准用

在盖桥上面，想象一下这会发生什么事：只要结构体上画好颜色之后，就马上宣布盖好

了，那如果有人真的走过去，桥塌了怎么办？



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

最大的利益。



里程碑应该尽可能以科技为主，而且它代表的是目前结构状况的整合。在游戏研发中，

结构是单一最重要的本质；所以，里程碑应该是以它为基础。它可以用骨骼来比喻：它

需要完整的发展，否则不管上面覆盖多美丽的组织，这个生物还是会变形（如果您看过

电影的［变蝇人］一、二集，您就知道我这边讲的是什么意思。真的很不雅观）。



就算您无法在撰写里程碑时避免使用技术性的术语，也尽可能使用大家看得懂的语言。

如果您很小心的撰写，就算是最没有技术能力的人，也可以了解并增加技术里程碑的好

处与可见性，进而延伸到整个企划。一般来说创造者，游戏设计者，与发行公司是最重

要的里程碑回顾者。不偏不倚是十分重要的，而且里程碑也应该直接从强烈的技术观点

，来进行主要的评估。



要为里程碑负责的小组人员，应该以里程碑为何要完成来看待他们的案子，而内部回顾

人员却是要以魔鬼代言人的举动，试着证明里程碑尚未完成。这方面要严格一点：一个

没完成的里程碑，相当于被抛诸于脑后的无味东西，将在日后以最让人意想不到而且最

麻烦的方式出现（未完成的里程碑适用于墨菲定律）。



组员必须全面了解，为什么一个科技里程碑，代表的不一定马上向前迈进一步，尤其是

对不精通科技的人而言。小组的责任包括展示与说明里程碑，连办公室的猫都要能够了

解其中的重要性，以及如何符合广大的计划。
  


 
deen8888
rank: Newbie
essentials: 0  
posts: 21
gem: 1
sp: 103
oge: 0

onlined:2 hours
join date:2008-03-17
last login:2008-04-23
»资料 »短信息 »推荐 »引用 »编辑



第十三章　程序与［过程］







＊程序



＊［过程］



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



＊资讯传递的重要性



＊主动与反应的资讯







在这个章节中，我们将会讨论运用软体工厂的概念之后，若想要在成本效率上有良好的

成绩，必须进行的程序与实行事项。



不过，这些程序与实行事项并非受限于软体工厂的范畴，它们可以在所有非琐碎的研发

中占有优势。大部份在研发中的软体（尤其是游戏软体）在研发方式上面并没有真的程

序化，一般的游戏企划在成长时，只是从［稍有系统］到［很有组织］而已。



这个章节中提及从管理观点来看研发过程，而管理的部份则是藉由状况报告以进行控制

。满足管理部门的兴趣，是程序与实践的主要理由。



管理者想要取得精确的资讯以及状况的报告，然后以这些资讯来判断未来的行动国，不

用打扰研发方面的工作。同样的，研发者不想让管理者不分青红皂白的介入，并在一连

串没有重点、浪费时间的问题下，打断了研发的过程。



这些程序与实践将会包括互动的介面与区域，让资讯可以在随时不断更新的方式之下传

送，并定义出控制流程，用来引导研发的方向。



这个［过程］并不见得象您想象的那么糟糕，它大部份都是与常识有关的。不过，最好

的［常识］，就是把它写下来让每一个人都很清楚这边所指的［常识］究竟是什么。如

果每一个人对常识的概念都不同时，它就会碎裂成不同的看法。



这些过程的执行是否要延伸，端看企划的需求而定。一个很重要的企划，就需要用严格

的方式来进行：而较不重要的，可以用比较轻松的方式来看待。







程序



在这个章节中讨论的程序类别，都是减少劳力浪费的基本控制与方法，并在低品质的成

果污染整企划之前，将不良的部份拔除。



　　



下列的程序列表，是在企划的进行时程中，维持精确企划资讯以及控制的建议事项。每

一个程序都在后面的章节中进一步的说明。







＊设计回顾



＊文件回顾



＊技术回顾



＊程式码回顾



＊单元测试



＊整合测试



＊系统测试



＊设定测试



＊后退测试



整体来说，［回顾］行为在找寻与侦测上面，要比单纯的测试来得好；先决条件是把回

顾力量集中在找出问题，而不是修正问题。另一个附加的好处，在于回顾也倾向于找出

不同类型的错误。







回顾



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



二种类型的回顾有［正式］与［非正式］。要进行哪一种类型的回顾，端看工作的本质

来决定。这个工作与内容有密切的关系，而且正式与非正式的比率，也是由情况来决定

（这一切通常是由企划管理者在分派工作时决定的，但是个体的贡献也有可能影响这个

决定）。不管怎么说，企划管理者知道工作究竟有多复杂，所以他（或她）应该可以说

明哪些东西需要回顾一下比较好，重点是没有什么工作可以不经过查核的手续。回顾通

常是在一个企划受到时间压力时，第一件半途而废的事情；这通常是一件大错误。省下

这一点时间，通常会造成长期有痛苦。



只是把没经过查验的工作插入企划中，然后发现没有倒塌就认为一切OK，算不上什么好

事。这种［方式］并没有在企划时程表中，指出会出现的任何难题，更没有告诉您这些

工作是怎么完成的。回顾可以让您在早期的阶段中，拔除任何明显的错误――在他们进

入企划之前――而且对于预防低于标准以及虚有其表的工作而言，这是最好的方式。



在一个不进行回顾过程的企划中，低水准的工作会变得难以侦测并存在很长的时间。这

种类型的问题会等到很久之后才显现出来，通常是在某些人修护或是更新受影响的地区

时才会发现。在这个时候，又有谁知道这个毒害扩散的范围？后期的工作可能是以这个

反复无常的原始工作为基础，导致邪恶长存。



回顾还有其他的好处：它可以让所有的员工共享并散布相关的知识。由于这个工作会在

一个小组中进行讨论与回顾，这些知识会传播到所有人之间，大量的降低了风险。







非正式的回顾



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



一个非正式的回顾包括了把数个小组成员集合在您的萤幕旁边，然后与他们讨论您的工

作，如果能进行一段排演会更好。



这些回顾可以用数个不同的方式来完成。举例来说，在一个非正式的程式码或是设计的

回顾中，您可以选择几种不同的方式，象是简单的排演与视察，虽然这些作法一样可以

在正式的回顾中运用。



排演是由这个工作的作者来指挥，主要的作用在于可以用很简单而且容易了解的方式进

行回顾工作。排演的优点在于快速而简单，而且它可以忽略掉工作中的科技品质。这并

不是一个真正的评估，比较象是一个评议请求（request for comments,RFC）。这也是

一个分享技术与经验的好机会。如果一个回顾原有更好的点子以及更佳的工作实施方法

，也可以在这边传达给作者。这种交谈也是很正当的；有时候回顾员工会学到一些新的

技巧。



讯息的传递协助了分散大量知识到所有的人身上，所以会降低小组对单一人物的依赖。

在理论上，每一个员工都应该努力淡化本身的地位，没有一个人是绝对重要的。很明显

的，以这种方式来工作，管理阶段不应该在任何人身上加诸压力与紧张；要让一个人做

出更多的事，就在他身上加诸更大的压力，这种观念是错误的。要让人们全力表现出他

们的能耐，他们必须尽可能的放轻松并有安全感，而且还要了解他们在做的事情，需要

在期限之前完成的重要性。这已经造成足够的压力，而不用靠着管理阶层来做额外调整

。



不过，排演并不一定都是乐观的，因为在一个回顾过程中，大多是以最没效率的方式来

进行。在统计学上来看，排演的有效程度有很大的变动，能打到的错误比率可能在30%到

70%之间。



其中的一位回顾员通常是您的技术管理者，而他（或她）可以让您的工作有保证。在这

方面完成之后，只要有任何主题（或是问题）在讨论并解决之后，就可以插入企划的主

要贮藏室之中。这边很重要的一件事是，技术主管不应该在这边以管理的权威施压，否

则在作者觉得有必要让他的作品发扬光大、证明他自己的同时，会让结果变成其他的东

西。这件事并没有发展到这个程度的必要，它的目的只是讨论工作并侦查出任何明显的

错误。



从另一方面来看，视察几乎是排演的相反。这并不是与作者谈论并一路看完工作内容，

而是要技术管理人员拿着韁绳并看着排演进行。这边需要以全新眼光来看工作内容，可\

能有助于发现作者遗漏掉的问题，这是因为作者［太熟悉］作品所导致的。不过，缺点

就是这一类的视察要花漫长的时间来进行，不过至少它有很大的机会找出错误。



如果在回顾的过程中，有人找到了问题并靠着一些动作或是变更修正，那工作内容就需

要原来的回顾员再回顾一次，包括那个第一次提出要求修正事项的人员。这个随后而来

的回顾是否正式，必须靠着它的本质来决定。庞大的变更需要正式的回顾，但是较小的

调整以及改善只要非正式的回顾就行了。至于变更控制，它本身就是一个庞大的主题，

将在第14章中讨论。



非正式回顾的危险在于它们有可能变得太不正式。所以，在一次回顾中经常指派出负责

人员，是一个较好的方式。这个非正式回顾也是正式回顾的一部份。一个没有效率的非

正式回顾可能比完全不回顾还糟糕，它会逐步把错误的安全感小组之中，导致最后出现

大麻烦。







正式回顾



通常在一次回顾中会包括四到五个人。这一个回顾小组的人员，是从合适的群组领导者

中遴选出来，而且先前的负责人员也应该包括在内。只要有任何没效率的东西，就会让

所有东西都没效率。



作者的责任就是确保所有的回顾员都充份了解他们要看的东西，才能展开这场回顾；这

可能包括影印好的工作内容，并回答任何回顾员在进行之前的所有问题。



回顾员的责任就是确保他们十分熟悉要回顾的东西。回顾会议真正的目标并不在这个成

品上面，这会花掉太多的时间。回顾会议的目标是让回顾员在会议之前，详加讨论要回

顾的内容。



所以，在会议之前回顾员应该完成一份回顾表，列出他们想要在这个会议中提出的重点

。视回顾的规模大小，他们应该要花一到二小时的时间，看完相关的资料。一个简单的

回顾将在第15章中提出，其中包括的RTF（Rich Text Format）文件已经附在本书的光碟

片上面。



基本上，回顾表是用来提醒回顾员，让他们不致于忘掉任何要观察的东西。结论将写在

列表中，并以不同程度的严厉眼光来看待，象A是最严重的错误，而E是最小的问题（当

然了，您也可以选择适合您自己的分级方案，但这种方式最为常见，而且最容易了解。

这简直象是回到学校一样！）



工作的内容应该以数个标准来回顾，其中的［符合需求］是最重要的一点。这才是我们

应该要求的东西。能够与企划和公司标准相符也是十分重要的，但是功能很明显是第一

优先事项。



在会议中，回顾表上的每一个要点都要提出来讨论。这个会议将从负责人员的展示开始

进行，这一场展示将会概略性的说明工作内容，并开始讨论其中包涵的东西。



很多人遗漏的一点是，在一个回顾中的批评并不是针对任何人，或是对完成工作的员工

进行人身攻击。回顾的目标是取得第二种意见，把工作中出现的问题拔除。让一群人专

注于一个想法，可能会更容易找出问题所在。这个回顾应该集中力量于找出问题；这个

会议并不是用来讨论解决方案的。这样做只会让所有人分神，目前并没有必要把所有的

问题都解决掉。



回顾会议的真正本质，事实上就是钜细靡遗的找寻错误。它只是在一场独立的回顾会议

中，利用讨论来进行资讯分享的时刻。在回顾的过程中，其中有90%的错误是在会议之前

找到的。



一旦在回顾表上面的所有重点都讨论完之后，他们就可以进入［行动状态］。基本上，

这些要点不是被接受，要不然就是遭到拒绝。如果它们被接受了，那么作者就必须进行

校正的工作，来满足提出这些要求的人。如果有超过一位回顾员提出相同的缺点，只有

其中一个会取得问题的［所有权］。他们考虑到的所有重点都必须合并成一个电子回顾

表，将与工作一块储存起来，以待日后查验。如果这些变更会显著的影响功能（例如它

牵涉到其他的区域），那就有必要召开一个变更控制的会议，讨论任何逆向效果中的控

制与限制。



视需要变更内容的本质，可能必须进行另一次正式的回顾。在这种情况下，应该运用同

一组回顾人员。如果所需要的变更级小，那一场非正式回顾就应该足够了。作者需要让

每一位回顾员在他们指出的要点上签名。一旦这一步完成之后，工作就可以插入企划的

主体中。



这一切听起来象是一场冗长的过程，而且――说实话好了――的确如此。不过，我已经

发现只要能预防次水准的工作进入企划，那就可以大幅节省您花在回顾上的时间。



我也发现了一点，如果有人知道他的工作会被人拿来回顾，他们在工作时就会更加小心

并注意各个细节，而且对他们所做出来的东西更为自豪。这可以增加注意力，对士气有

正面的好处。人们知道他的工作在检查之后即将纳入企划，所以企划代表了更高的标准

（而且风险也会大大的下降）。在这些理由下，回顾大约可以增加20%的生产力。绝对不

要低估提升员工士气对输出结果的正面效果。



由于游戏研发的本质，执行回顾的工作会受到一般性的抵抗。要压制这种抵抗的最有效

方式，就是收集回顾中找到的错误，然后算出找到每个问题的平均时间。把这个统计数

字，与研发后期修正这些错误所要花费的时间（与金钱）相比较，就没有人说得过您了

。







一般测试



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

。



我看过很没有测试效率的企划，而且这些通常很容易发现。当游戏推出后处处都是臭虫

时，它通常有一到二个理由：这个测试就是够不上水准；或是研发小组的时间用光光，

发行公司已经受够了，所以一定要把它丢上市面，不管里面有多少臭虫。在这边，我们

先来考虑第一种剧本：次水准的测试。



测试是找寻错误的过程，您在程式码中预期可以找到多少错误？就算是陪审团也无法得

到一个正确的数字，但是在业界中粗估的平均数字，是每一千行的程式码，会出现15到5

0个错误。在游戏产业方面我会稍微高估一点，虽然这方面可能会视游戏是小型或是中型

企划，而有所不同。



测试是在找寻研发任何阶段中，可能发生的数种错误：但是，一般来说，测试可以侦测

出来的错误，只限于原型与程式设计的阶段中。请牢记这一点，只要一个错误没有被抓

出来，时间越久要修正它的费用就越高。如果在设计阶段出现一个错误，在实施到一半

时才要修正它很显然要比在设计阶段中，把它抓掉更费时费钱。



事实上，这是实施这个过程的主要理由。它可以让您试图去［相位牵制］；不是，这不

是与［星舰迷航记］有关的东西（虽然它应该也是）；这边的相位牵制，表示您要在创

造的阶段去侦测并修正其中的错误。一个标准的统计指出，在创造时发生的错误如果没

有抓出来，事后的修正要花费将近200倍的时间。很明显的，侦测并修正错误的动作越早

做越好。



同时，也要记住测试本身并无法影响软体的品质。尝试藉由测试来加强软体的品质是没

有用的；它的作用只不过是品质的指标。它后面必须附带着决定性的方式，才能加强品

质；让这些额外的效果反应在下一个测试过程中。



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

。







非正式的测试



［非正式的测试］与［非正式回顾］指的并非同一件事。这边并没有必要把一群人聚集

在萤光幕前面，因为非正式测试只是任何研发者，在进行程式码模组研发时做的测试。



每一个研发者在撰写一个程式时，都会周期性的将程式码编辑并进行测试（至少我希望

如此！）这是一个很好的出发点，但是这并不足以预防爬进程式中的臭虫――尤其是在

模组整合的阶段。



大部份我看过的游戏研发企划中，只有运用到这种类型的测试，再来就是让一个有活力

的人进行游戏测试，一直延续到企划结束为止。这通常只能勉强合格。



为了加强非正式的测试，有为数不少的自动错误侦测应用程式（象是Numega

Boundschecker）以及程式设计的技巧，可以用来找出明显的错误。



它真的有用，但是如果能再加上一些基本的测试程序，这个风险可以明显的降低。虽然

是否要进行正式测试，必须看工作的本质来决定，所有在这边讨论的测试阶段，都应该

以一种或是其他的形态来实施。







正式测试



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



一个特殊模组所提供的测试描述，将用来对这个模组的所有功能与特色，进行耗损性测

试。这段描述通常是由该模组研发人员中的软体规划师所撰写。



测试描述是以一种特别的方式来撰写的（一个简单的测试描述将在第15章介绍，而且以R

TF格式的文件放在本书的光碟中）。这个测试应该是设计用来执行这个模组中的每一条

程式路径。因为要完成这个工作并不是简单的事，所以测试描述本身也是回顾的重点之

一．



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



正向的测试是在检查预期的行为，所以这些测试是写来让模组产生预期结果的。一个正

向测试的例子，是对一个专门用来画三角形的模组传递一连串的方位，并预期在画面上

看到正确的三角形。



负向的测试是在检查预期的行为，所以这些测试是写来让模组产生预期结果的。一个正

向测试的例子，是对一个专门用来画三角形的模组传递一连串的方位，并预期在画面上

看到正确的三角形。



负向测试则是查看没有预期到的行为，而且这些测试是针对产生例外而且还能控制的错

误状况。一个负向测试的例子是对一个专门用来画三角形的模组传递三个相同的数值，

或是排成一线的三个点。这时应该可以测试临界的状况，在您送出三个很大的数值（正

值或是负值）时会出现什么情况？那一串很小的数值呢？或是送三个零进去？



在规划测试时，试着考虑各种不同的输入值丢入系统，不管是有效或是无效的数值。这

些物件将以各种可能压迫系统；把您找到的任何东西统统丢进去。您可能发现并非所有

东西都会出错，但是您可以除掉其中最麻烦的问题。



特别测试是乱数的效果。测试者要玩弄模组，并查看他（或她）是否得到预期的结果。

这些测试只是把一些测试者想要的东西丢入模组，举例来说，他可能把一组乱数产生的

点丢入绘制三角形的模组中，并查看输出的三角形是否正确。



很多组织只会使用这三种模组的其中之一，但是要进行真正有效的测试，这三种方式都

该使用。如果一个测试模组已经写好，可以把这三种测试隔离测验，那就应该让测试者

可以任选进行的测试项目。



当您在执行一个测试描述时，结果应该以电子档的方式记录下来。这些测试应该以文字

说明，让结果可以表达出［真］或［假］的回应。在一些例子中，需要进一步的描述才

能得到正确的结果（尤其是在测试失败时）。



如果一项测试失败，那么就要进行下一步的行动。一项测试的失败理由不外乎二项：问

题在于程式码，或是在于测试。这二者所采取的行动都是一样的，测试者站起来回报问

题，并展开修正问题的工作。







单元测试



单位测试是研发者进行的第一波测试行动，而且它是一种开箱测试，表示测试者完全了

解要测试对象的从里到外。从统计学中显示，在平均的情况下，单元测试可以在程式模

组中，找到将近一半的错误。



单元测试通常是以严格的方式来进行，它会设计一个简单的程式，该模组中的每一种功

能动作。这可能简单而且没有互动性，或是它会更为先进并容许设定输入的参数。



单元测试的用途如字面所示：它是在隔离的状况下测试。这可以预防其他方面的互动，

象是容易出错的模组。这就是为何要限制测试环境的原因，而且也是为何这个限制的测

试环境要越简单越好。有好几次我在测试结果中找到错误，最后发现它居然是源自于我

所使用的资料！如果您在程式码中找一个虚幻的问题，最后发现是您输入的测试资料出

错一定会让人心灰意冷（我试着将它看为提升经验的练习，我真的这样做了，但是我不

会建议把这种过程，做为判断您神智清楚的举动）。



单元测试可以在数个不同的层级中施行。如果我们拿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章中的软体工厂模型是相同的。请注意，从主要企划网页中，只留下相关的连

结以保持清晰度。



在最理想的系统下，一个每星期寄发的新闻信件系统，将每星期更新的相关资讯寄给公

司的每一个人。当然了，查看这些资讯是每个人的义务。



其中一个缺点在于，在一个大型的组织中，他们可能得顾用一个专门负责网页更新的设

计师，来进行相关的工作。不过，幸运的是大部份的公司中，都已经雇用了负责网页的

人员。



将所有公司中的文件与过程搬到内部网站上面，并不是一项轻松的工作。它需要小心的

设计，而且还要提供搜寻的功能。如果这方面处理得很好，那公司中的每一个人都可以

看到企划的进行状况。



我曾经在一个我参与的研发企划中实施这个系统，而且将它延伸到加入时程表系统，所

以可以利用单纯的网页界面，指派员工黄鹂不同的工作。员工可以进入特定的网页中，

查看他们工作相关的详细资讯，以及安排个人回顾、会议的相关时程表。



假定这个网页经过谨慎的设计与编排，它应该可以去除每一个研发人员在试图不去查看

相关文件时，最常采用的藉口（包括我自己）：［可是我到处都找不到］
  


 
deen8888
rank: Newbie
essentials: 0  
posts: 21
gem: 1
sp: 103
oge: 0

onlined:2 hours
join date:2008-03-17
last login:2008-04-23
»资料 »短信息 »推荐 »引用 »编辑



第十四章　疑难排解







＊风险



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



＊变更控制



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



＊公制与资讯的收集



＊灾难重建







在这个章节中，我们打算看看您的企划中，究竟有什么事会――而且可能性极大――把

您搞得难飞狗跳。一般的企划只是一个单纯、等候发生的错误列表：时程表的错误、程

式码的错误、过时、个人的问题与疾病――只要您想象得出来，就有可能发生，而且不

要惊讶！不经一番寒彻骨，哪得梅花扑鼻香。您可以把企划安排到无微不至，但是您无

法安排未知的事情。







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



这个章节是叫［疑难排解］没错，但是所佔的大部份都是在提供建议，来预防可能需要

的疑难排解。最具有成本效益的企划，是以高水准软体开始着手，而不是先建一个低水

准的软体，然后再来修正问题。



就算是在一个执行上十分完美的企划中，还是会跳出没有预料到的问题。而成功的小组

与失败小组相比较，差异就在于他们对这些问题的掌握与规划的功夫。



好，我知道您想说什么：您怎么可能不知道的事情做规划？如果您不知道会发生什么事

，您又怎能先做预防来修正它？呃，说实话，您的确办不到。如果我试着告诉您另一个

答案，您就知道我在撒谎。



没有人可以看透未来，所以没有办法知道您的企划会碰上什么样的麻烦。不过，您知道

有些事情必然会发生。只有最天真的企划管理者，才会假定一个企划会顺畅而没有任何

麻烦的进行下去，一直到结束为止。不管您信或不信，我曾经碰到过这处管理者――我

认识一位此一类型的管理者，还会去相信一个长达18个月企划，可以在9个月的时间中完

成。他一直抱着这个想法度过了前面七个月，这时急得不得了的发行公司来重新审查合

约，让这个问题重重的游戏，在二次续约以及一年之后才发行。



这一类难以接受的情况，发生的次数实在相当多――尤其是在游戏产业。为什么？我相

信这是因为游戏产业缺乏普遍规划能力所造成的结果。



整个游戏产业都很不成熟。在主机的世界已经进展到进行庞大的企划，包括了广大的小

组以及上百万条的程式码时，游戏产业还在拔乳牙的阶段。在今天仍然有人采用这些大

型企划处于测试期时所产生出来的结果。当然，有些更会挖苦的人将把这一点，归功于

把它们拔掉不如让它们继续运作来得省钱。在某些程度下可能是真的，但至少他们仍在

运作！那些无法运作的呢？



不过，游戏不象其它有20年生命周期的产业（虽然我很确信有些设计者会喜欢这种状况

），所以规划与安排时程的时候，不需要象其他方面有完整的学问。事实上，由于一般

游戏的生命周期很短，象这一类有组织的施行细则并非必要。



但是，随着戏曲开唱，在时间中产生了变化。游戏企划的规模越来越大，再也不是一个

小型的工作，可以用少数的平台让单一的设计者制作出一些可以迎合大孩子口味的东西

。今天，到处都是动作捕捉、全萤幕动画、电影品质的音轨、电影水准的美术，以及更

多的多边形。



有些人把游戏产业拿来与当代的电影工业相比较。它可能只是少数人无法接受他们只是

软体工程师时，所发展的罗曼蒂克谈话内容：这二种产业的相似之处，在仔细的观察与

分析之下不攻自破。



平心而论，我可以看出相似之处。不过，与大部份的软体企划不同之处，在于他们比起

游戏研发有更大量的艺术元素。这些特别的元素最适合的部署地点是在电影工业，而且

电影与游戏之间仍然有很大的差距。电影主要是艺术――它们的确有很多技术方面的要

素，但是在有所需要的时候，是靠着外来的力量来进行有效而顺畅的控制。除此之外，

并不需要大量的科技研究，与游戏研发是不同的。



不过，一个游戏企划对这些制作艺术、全萤幕动画与音乐的需求，就和电影工业不一样

了，而在这方面就是模仿电影工业的重点：电影的制片通常会从外面的其他公司找寻他

们的需求，而不是把规模限制在昂贵的编制内小组。



如果游戏研发可以真的与电影工业相比，那是不是可以象电影制片一样，雇用新的工程

人员、在每一个企划中安置新的摄影机、重新研发赛璐璐，并修正所有的软体？不是，

今天的电影工业并不是一个好的比喻（虽然过去的电影工业，也就是技术仍然很简单的

时候，勉强可以拿来做比较）。



今天的电影工业已经渡过了这一连串的磨牙问题。它十分成熟，而且再也没有什么需要

进行的基础研究。它已经完工、平稳而且撰写出相关的文件。电影工业已经达到一个平

坦的区域，所需的科技稳定，而且电影画面中的［目标平台］一般而言已经很调和并不

会变动。想想看：除了（应该不会错）微小程度的改善之外，电影在数十年来并没有太

大的变化。



游戏产业并无法达到这种类似的地步。科技不断的演进，所以游戏的科技从来没有稳定

下来，连游乐器也不例外。看来每过个几年，就会在技术方面出现巨大的进展；这种由

摩尔（Moore）预定的著名［定律］（指电脑的能力每18个月左右就会提升一倍）并没有

慢下来的迹象。我并不期望目标平台会趋于稳定，虽然在一个隔离的层面下，象是Direc

tX，可以提供一些轻微的缓冲；阻挡研发人员马上采用新出现的科技。不过，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%的结构与定义得很详细

的内容。



不过，有时候设计与结构已经做了最好的定义，一直到突然出现额外需求。这种情况下

有几个可能，而且我很确定您可以想出更多。某些理由可能是发行公司要求额外的特色

，或是一个类似的游戏已经出现在市面上，导致您［必须］有些别人没有的特色――象

是让您的产品拥有一些最先进的特色（如果之前没有规划的话）。一个例子就是要加上

多人连线的功能，不过现在的游戏应该都支援了。



在这一类的情况下，通常埋头苦干来完成这个变更以外，没有其他的选择。有时候不把

程式码与模组全面修正，是不可能达成这些要求的。如果这一类的修正在财务、合约或

是时间的压力之下变得不可行，那这种情况的出现，通常会导致企划全面取消。不过，

有时候这个状况可以利用保证推出更新档案，来修正其中一部份问题来抢救。照我的看

法，这并不是真正的解决方式；它只是一个紧急应变的海市蜃楼，先把产品推出来再发

行第一波的更新档，在社会大众的眼中会产生负面的效果，进而伤害您公司的名声。不

过，如果二个选择分别为［先找出游戏再推出更新档］与［完全不发行游戏］，那么在1

00个案例中，99个（我不是在强调那个例外）会选择先丢出去再挨骂！



真正能够预防这类混乱的方式，就是先尝试收集您会面对的大部份详细需求，然后再开

始进行结构设计，才能佔有领先地位。当您这样做的时候，其中一个用来计算不断增加

需求的最好方式，是在后期指派一个工作，强迫去查看这些需求中有些什么东西，然后

试着去预期往后的什么方向可能会继续延伸。这并非表示您要在这个阶段，就把这些可

能性建造在您的需求之中；但您至少要好好考虑一下，让真正的规格需求有可能纳入这

些特色，并将这一点转入结构的规格中。



每一个扩张的潜在性，都应该认为有三种可能的结果。第一种是这个潜在性的需求可能

十分重要，所以必须纳入实际的需求之中。第二种结果是，虽然这些需求并不重要，但

它应该有一席之地，而且结构应该以可以容纳它的方式来定义。第三种结果是这个潜在

性的需求，在努力完成之后也不会增加真正的价值；这种东西就是大家熟知的［润饰特

色］，一个有了很好、足以加强产品的东西，但是它的成本效率太高，让您完全不会去

考虑它。



其他的问题可能发生在设计与结构的阶段，由于对80/20规则的误解（这边是指某些人宣

称一定要完成80%的工作，才能进入下一个阶段）。您不可能完成整个设计与结构背后的

理由，只是因为您需要的一些详细状况只有在动手之后才会知道。尝试着去完成所有的

纸上工作是个愚笨的决定，因为您没有办法预期元件之间会造成的相互关系（其他的章

节将会说明相关的理由）。



如果误解了80/20规则，下一个阶段有可能太早开始。在产品说明中的模糊部份，可以预

期它会耗费更多的时间来进行。



模糊的说明会产生几种冲击，第一个而且是最重要的效果，就是行程表会受到相对的影

响。如果企划目前处于很紧的时程表之下，没有空间可以进行这些事情，那就会成为严

重的问题。第二个模糊需求说明的负面效果，在于可行的解决方案不一定能和系统的其

他部份相容，或者甚至无法运作！在这种情况下，就有可能修正部份区域中的工作。



在一些理由之下，研发者的天性会倾向低估他们在未来的工作时间；这些理由的数量很

多。来自同伴的压力也不容忽视：可以在很短的时间完成复杂的工作，也是让人觉得很

酷的特色之一。第二个考量，是管理者不愿意经常听到研发者老是在讲他做的是一个［

公平的估算］。在案例研究14.1中，说明了［对牛弹琴］的情况。







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



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



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

来。］



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

人员的故事。



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

斯继续讲下去。



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



［这个顾客指派了一位管理者，史纳德斯（Snodgrass）；没有人知道他的技术能力，但

是他最出名的就是没有耐性，而且最有名的能力是靠着脸色变紫与爆裂般的言语，让其

他人不得不同意他的话，以免他炸成碎片。］



［在这个应用程式中的一部份需要加以扩展，而且整个新的模组得重新研究、设计并重

头撰写，当然了，这个工作落到了佛瑟基尔的头上，因为他是研发者之中最资深的人员

。］



［这个工作是由史纳德斯指派给佛瑟基尔。佛瑟基尔拿到了备忘录，简要的看了一下，

然后把它放在桌子的另一边；那个时候他正在进行一些非做不可的繁忙修改工作。］



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



［嗯，很正常的反应，华生。史纳德斯在这个案子中充份表现了他的性格，］福尔摩斯

回答，［他想要知道，要完成这个工作要花费多少时间。］



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



［佛瑟基尔说他不知道，因为他还没有好好看过文件。他请史纳德斯在第二天的下午再

来问他，这样他才有时间以怀疑的眼光，好好找出文件中的问题。］



［一个很合理的答案，福尔摩斯，］华生表示，［这个佛瑟基尔一定是位很有原则的人

。］



［嗯，的确如此，］福尔摩斯回复，［不过你听听下面的。在第二天下午，史纳德斯的

确去找佛瑟基尔，并问了同样的问题。而且――如同你刚刚的问题一样――他的回答是

，在看过相关的文件之后，他相信他应该可以在三个月左右的时间完工，而其中预估的

错误解决时间差不多要一个半月；换之，他说应该最少花一个半月，最多四个半月，而

最有可能的时间将是三个月。］



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



［他这样回复，］福尔摩斯回答，［史纳德斯微笑，并说他十分高兴佛瑟基尔可以在一

个半月的时间把它完成。佛瑟基尔被吓呆了。这时史纳德斯已经离开了犯罪现场，向他

的老板回报好消息。］



［这个结果真的太让人不满意了，福尔摩斯，］华生惊愕的表示，［在这种鄙俗的手段

之后，有进行任何方面的研发吗？］



［只不过是史纳德斯在花了三个月再加上一个星期的时间把工作完成后，在他的老板面

前看起来笨拙无比，］福尔摩斯微笑着。



在这个有点想象性质的真实事件中，指出了一个重点：一个很危险的人，只会听到他们

想要听的东西，而且他们会在他们规划时去责怪其他人的错误，但这却是以他们听进去

的东西为基础。







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

经常发生。



除了缺乏详细规格相关资料与实行时的需求，不可能正确预估出时间长短以外，参与的

研发者仍然给了最有可能的评估。管理者选择接受较低的范围，主要是因为它更适合他

的目标，然后忽视掉最精准的预估值，除非在一连串的好运重叠之下，几乎不可能达成

目标。



这些现象不只会降临到一个企划，让结构与设计的阶段中出现困难。在上一个状况中，

很明显的是在设计与结构的领域有模糊的现象，而且没有人遵循80/20规则。



不幸的，当设计者或是结构师在制作出一个过度简单的设计时，运用80/20规则并无法侦

测出来。一个太过简单的设计无法充份处理主要问题，必然会导向一个有企划必须加以

修正与重新施行，以更为强大的型式来符合需求。这是一个很难查出来的问题，在设计

太简单时会很不明显，尤其是在游戏设计的状况下，一个过度简单的游戏却在过程中花

费很长的时间，而这部份通常是由于延长的游戏测试。



唯一可以避免白白努力二年的方式，就是多做一些努力，采用原型的方式把问题找出来

。做一个模型对游戏性通常都有正面的帮助，它不需要十分奢侈、快速或是详细。在我

的许多个企划中，我甚至没有想过要利用电脑来制作初始的游戏原型，而是采用手中的

材料：铅笔、纸、积木、玩具车等等。



这个技巧在其他的案例中也很成功。您的脑中并不会马上弹出合适的名称，但是一些在P

layStation或是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%，这会让人心烦意乱，而且在这些实施

后的结果上，很可能会爆发出研发者与管理者之间的惊慌。对于那些反抗这些作法的人

而言，这通常会被他们用来做为争吵的主题。研发者最经常做的事，就是对抗那些设计

用来追踪他们进度的方法；而游戏研发者似乎对这一点特别感冒，如同他们喜欢保持他

们的［自由心灵］与不用负责的心态，而且把［对权威的不尊重］视为心理健全的一部

份。



可能有更多不满的研发者从头就开始反抗，所以任何危及生产力的现象，都会被用来当

做回到温暖的［老式］制作方法的好理由。这应该极力尽免。



您可以让研发小组为这种事情先做准备，来绕过这一类的反应。对新的方法、工具或是

程式库，都有一定时间的学习曲线，这是免不了的，对不熟悉的知识都会如此。不要让

多疑的人，在还没有足够长的理解时间之前，把任何新东西都敲倒。您所尝试的每一个

东西都不一会有用，但是您从来就不知道，它会不会被一个很难处理的研发者打得混身

是血。



举个例子来说，如果产品（或更可能的情况，企划的一部份）是在低级语言）下实施，

那么它的生产力将会比预期的更低。不过，一般来说在威力强大的机器上，组合语言的

需求程度就越低。一般的主机都已经有足够的能力，让它无英雄用武之地。如果以Penti

um级的中央处理器来执行一个多工作业系统，您可能永远无法确定一段特别的程式码，

要花多少时间来执行。



唯一可以让组合语言发挥长处的主机，是那些记忆体受限、速度不足，象是任天堂Gameb

oy或其他掌上型的游乐器。虽然任天堂（以及其他公司）试着限制研发资讯，让只有签

约的研发者才能取得，但是地下的研究从来没有断过。甚至已经出现给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；那它在完整版本推出之

后还是有出现问题的可能。在测试版中的功能可能还不完整，甚至您在测试版设法绕过

问题的作法，在正式版中会让机器当掉。



如果在一个现有的系统上面，为了相容性而采取严格的需求（举例来说，一个系列的游

戏是依靠同一组基础的资讯，或是一个多人连线游戏需要与第三者线上伺服器的界面相

容），那么系统将比预期的状况，需要更多的测试、设计与施行。一个很好的例子是Bli

zzard的Battle.net伺服器软体，它是免费的网际网路多人连线游戏伺服器，可以提供给

Blizzard的游戏《星海争霸》与二代《暗黑破坏神》（译注：现在又多了《魔兽争霸白

金版》与《魔兽争霸3》）。一般而言，与其他系统的界需需求可能不在小组的控制之下

，而会导致无法预期的测试、设计与施行。



如果您的小组想要的是一个跨平台的相容性，那实行与测试会花上更长的时间。许多事

情可能在跨平台的研发中出问题，包括了微妙的［标准］API与处理器类型的不同。







研究：结果



如同前文提及，研究的本质是无法排入时程的。您无法把本质属于无法预测的行动排上

时间，所以您能做的最佳做法，就是被迫把研发放入您的时程表时定出一个结算日期，

让您有时间想出一个突发的计划，来应付研发结果一片空白的情况。



研发最大的问题在于：要把游戏推到最新的水准时，免不了要把时程表拉长，而且拉长

的程度还无法估计；还有，您无法靠着任何最佳研发人员的保证，来估算出正确的日期

。研究一种研发者可能还不熟悉的新领域元件，可能会花费比预期更长的时间，因为他

们必须先去熟悉那个领域的东西，才能展开工作。



企划的其他区域也可能要依靠研究与研发方面的模组。如果没有合适的突发计划，那唯

一的选择就是让整个企划停下来，等候研究的成果出炉，更容易拉长整个时程表。



整个重点在于您应该避免落入这种局面。在一个企划的时程表中，如果想靠着研究的结

果无异是自找麻烦。这就是为什么研究应该在时程表以外来进行的原因。







过程问题



最后一个章节很详细的讨论了［过程］，而且谈及它如何用来为您的企划提供精确的状

况，而且一般来说可以让您小组中的人们生活轻松点（如果他们一开始就抗议，那不算

！）



我们将要简要的回顾一下这边的主题，并讨论过程是如何误用，对企划最后反而造成伤

害，并让组员活在悲惨的世界之中。







官僚作风与繁文褥节



有些管理者由衷信任过程…不幸的是，太信任了也不好。他们会尝试在您找个喷嚏的时

间，塞给您三大张的文件叫您签名。我曾被一家公司要求，连每天在厕所花多少时间都

要写下来，这样他们才能计算并扣除我每星期应该花在工作上的时数！



过程（在初始的学习曲线以后）从来就不该是个麻烦。它通常不会太难做到；唯一的困

难就是刚开始就［没有过程］到［有些过程］的环境演变。



不过，在某些情况下，要填写的文件可能会过多。如果一个工作产生了不正常的文件作

业，那就应该查看一下流程是怎么跑的。［过程］应该是用来协助员工，而不是妨碍他

们；如果他们在很多地区填写了相关的资料，那这些收集资讯的过程应该加以修改，去

除不必要的部份。您应该用越简单越好的方式来完成文件填写，让它很容易完成，而且

更容易修正。没有人想要重复相同的工作，只是用来填写一样的资讯；所以尽可能的确

定这个过程够合理而且不冗长。太多的纸上工作也可能导致进度的延缓，而您关心的事

项，也应该要包括员工在写给管理部门的报告时，不用花太多的时间：把定期的会议取

消，因为这会花费大量的时间去做进度报告；只要叫大家用电子邮件来回报所有考虑到

的问题，并用同样的方式回复所有人的意见。







误用与制度



如果没能正确的运用，采用的程序再广泛也没有任何意义。研发者的天性就是尝试避免

他们认为没有生产力的工作，而这包括了程序的品质，除非有人向他们精确解释其中的

好处。



这也可能在数种不同的情况下遭到误用。举例来说，如果没有好好进行刚开始的前置品

质保证行动（这将会从想要［省时间］的想法开始蔓延），然后最后的结果很明显会把

［省下来的时间］花在延期耗时的修正上，并让时程表延误。



如果状况与缺席没有正确的追踪回报，那它很可能会忽视掉早期的警讯。而追踪不正确

的结果会导致品质问题，导致时程表受到忽视，一直到企划的晚期才会发现。在这个时

期，一切都可能太迟了。



缺席应该视为十分重要的一组统计值。它也只是在一个企划中，影响知识学习的方法，

所以可能有助于下一波的研发。这个资讯太贵重而不能忽视，所以应该要精确而且持续

的记录下来。如果这些资料无法充份的收集，这将会导致您不知道究竟落后时程表多远

，直到您的企划接近尾声。



如果风险管理的程式并没善加利用缺席，那就有可能无法事先侦测企划中的主要风险，

让企划就此跨台。如果您要买一个烟雾侦测器，就不应该把它放在盒子中，连电池都不

装。







拘于形式的问题



在一般的软体企划中出现的拘于形式，要比游戏产业中常见多了，而这一点对游戏产业

并不是什么好事。



不重视形式（忽视研发过程）会导致缺乏沟通、品质不良的成品、以及大量的修正。不

尊重形式通常要比不采用更糟，它会让员工误以为很安全。如果完全不采用的话，至少

他们知道后面会出现什么。



相反的情况也是问题：过度形式化（过度官僚作风，强调用程序与标准的文字来鞭打员

工）将会导致不必要的时间浪费。员工会把他们的大部份时间，花在填写这些过程的报

告上。



一定程序的过程是个好主意，好处可以为您的企划，在一些额外的工作中获得大量的优

势。技巧在于找到它的平衡点。
  


 
deen8888
rank: Newbie
essentials: 0  
posts: 21
gem: 1
sp: 103
oge: 0

onlined:2 hours
join date:2008-03-17
last login:2008-04-23
»资料 »短信息 »推荐 »引用 »编辑



第十五章　产业的未来







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



＊变动的管理技术



＊电影工业的模型



＊让小组运作



＊产业的成熟



＊线上的革命



＊调整的可能







这个章节包括了我们对游戏产业未来的最佳猜测，以及整个游戏市场中会发生的事。而

如同这个世界没有照预言在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，目前正推出一张光碟，上面包括了一段以他们吉祥物Ed

die为主角的第一人称射击游戏试听音乐。当然了，英国的专业媒体嘲笑这个普通游戏的

每一点，最简单的理由在于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》新游戏

。这应该可以创造出一个别具特色的人物，并具有特定的声音来搭配，而不是光把一个

明星从电影银幕上面搬下来。



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

 



















-----------------------------------------------------------------------------

---

  注册: 2003-12   发帖: 254 积分: 654   状态: offline 5 4 3 2 1 0 -1

-2 -3 -4 -5   1  





tbs005







爱心战士



来自: 发表于: 2004-3-8 19:09:00                          

-----------------------------------------------------------------------------

---



Re: 电脑游戏结构与设计——第十五章



游戏中的暴力



近期游戏中的暴力问题越来越严重，主要是因为技术的提升，真实的暴力将会透过图象

先表现出来。



《真人快打》是一个恶名昭彰的游戏，主要是玩者可以用各种组合的招式，用残暴的方

式让对手以各种不同的方式死亡。其中一个最血腥的画面就是把对手的头骨与脊椎骨拔

出来，然后高高的举在空中。如同画面真实的本质，让这个画面在道德方面倍受争议。





在英国，第一个因为有内容而受到评断的游戏，是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］被延后了二年，以加入一些反抗暴力的场景来取悦道德权威；它最后在193

2年以［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的模型似乎是设计用来创造一种我们正在讨论的［超级研发者］模型。Li

onhead的卫星构造会学习做事的基本方法（无论如何，他们的确有这种潜能）：他们分

享资源，而且他们相互信任执行时的标准。还有，象是彼德·摩利纽斯这样的超级研发

者，可以使用这种结构在一年展开几个企划，而不是每二年只做出一个。假设这个明星

的品质（也就是做出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之下营运，成长到4

60万；要比预期的多出了150万。这个新公司的价值为790万，而且据一些预测看来，应

该很快就会让它的资本结构加倍。它在财务方面的部份似乎是信心十足，而这也是未来

产业的走向。



在线上订购您的游戏，并不表示您可以从线上获得――不管怎么说，没有人想要把小说

下载回来并在家中印出来看，但这并不会影响到Amazon的生意。不过，直接从发行公司

的网站下载回来当然是最好的方式。未来的线上发行公司，象Gameplay一样，将需要找

一个方式来让下载的速度更快、更简单而且没有麻烦。一个方式是提供一些牟取预览的

资料，让这些资料的传输更为快速。我猜，这并不需要是完整可玩的试玩版，象是您现

在从杂志附赠的光碟上所拿到的游戏一样。发行公司有很多产品，而且他们要您尽可能

的看看他们的动画。所以，我们可以看到游戏试玩的出现，将和电影的广告试映一样会

越来越多――将形成一些较小却更完美，足以说明整个游戏是否合您胃口的片断。有兴

趣的顾客会在完整近艺术的评析、全面的试玩以及其他任何东西带领下，被一步步卷入

游戏中。



要解决下载时间的问题（也就是鼓励使用者直接从他们手中购买游戏的方式），线上发

行公司须要建立一个基本的程式库封包，只要下载一次就可以用在所有的游戏上面。然

后，在理想的状况下，只有主要的游戏逻辑与图案需要从《雷神之鎚》中传送过来，就

可以用在《战慄时空》这种相同基础的游戏中。在这方面，必须结合研发公司与超级研

发者，来进行［一次解决］的游戏结构，让他们的游戏可以适应这个架构。在目前，只

有微软有可能执行这种规模的企划。







线上玩游戏



最近，一些专门提供线上内容的公司兴起，象是在恐龙群中出现的哺乳动物一样。或许

他们相信，其他人会和恐龙一样，在无法适应之下死亡。



或许这一点解释了象是Origin公司，逐渐走入线上游戏，提供了《网路创世纪》的原因

，塑造出一个神幻的Britannia世界，让玩者加入其中的社群。不过，这真的只能锁定资

深玩者。







资深的网路创世纪玩者一天大约会玩上六到八小时。您可能花个八小时睡觉，然后一些

时间用在工作与学校上，剩下的时间就是在上网。



――理查·盖瑞特，在PC　Gamer杂志1999年9月的访谈







线上游戏在欧洲会有一段阵痛期，这边的当地电话每分钟都要收取固定的费用。不过，

电话公司会达成协议：如果他们把价格降低，大家都做得到生意――如果他们太贪心，

就抢不到这块大饼。



另一个线上游戏的主要缺点，在于它们很难有大幅的成长。大众市场对每天都要花时间

上网才能玩的游戏没兴趣，他们要的是能够自由选择娱乐时间，而且就算他们没有花时

间去养，也不会有什么关系的游戏。线上游戏会变得很大，但是在这个限制下，它不会

象权威人士想象的那么广。







最适者生存



唯一可以让游戏研发占用经济优势的方法，就是采用本书描述的过程。我们知道的原因

，在于这个方法已经有一个公司在得到发行公司赞助之后，创立采用延续到今日。唯一

可以让研发公司在未来还能生存――在合理化过程上仍有压力――就是采用这本书的技

术。这些方式都经过尝试与测试，而且已经可以看到它们的优点，要比任何其他的方式

更多。



公司现在必须开始实施这些标准与相关的用语，或是直接被丢到路边去。虽然有人会反

抗这个说法，但是整体上再不做一点事，结果就是经济效益不足，让研发公司无法营运

下去。



如果您取得一个明星的大名或是授权，您就可以卖出上百万套的佳绩。如果没有的话，

您顶多能卖到25万套。您的经营计划必须让您能靠着这个成果存活。如果您计算一下的

话，您会看到达到这个目标的合理化过程，让您同时省下金钱并减少上市时间的损失，

而且可以增加内容的充实性。
 
 
Necroz Studio » 文献图书馆 <<  1   2  >>  Pages: ( 2/2 total )
   





Copyright 2006-2011 Necroz Studio

Powered by PHPWind v4.3.2 Code © 2003-06 PHPWind
Time now is:05-13 09:51, Gzip enabled
You can contact us