游戏策划 Design Inside

达达尼昂 | 游戏开发[资料] | 2009-03-12

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

电脑游戏结构与设计  

第十一章　软体工厂

 

＊软体工厂所解决的问题

＊设定一个软体工厂

＊使用一个软体工厂

＊软体工厂的可适性

 

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

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

 

什么是软体工厂？

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

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

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

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

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

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

 

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

＊资料档案读取

＊硬体安装

＊硬体设定

＊软体设定

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

＊编码与解码

＊视窗与画在特色

＊基本人工智慧元件

＊使用者输入

 

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

 

为什么要使用软体工厂？

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

 

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

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

 

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

 

解决游戏研发问题

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

 

平台独立性

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

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

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

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

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

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

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

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

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

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

 

降低风险

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

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

 

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

为何要使用软体工厂？

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

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

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

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

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

 

组织一个软体工厂

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

 

结构概观

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

 

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

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

 

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

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

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

 

群组的责任与互动

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

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

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

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

 

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

 

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

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

 

抓虫

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

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

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

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

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

 

游戏设计者群组

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

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

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

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

 

软体结构群组

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

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

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

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

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

 

工具群组

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

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

 

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

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

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

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

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

 

元件群组

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

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

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

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

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

 

企划群组

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

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

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

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

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

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

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

研究群组

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

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

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

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

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

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

 

附属群组

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

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

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

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

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

 

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

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

 

万丈高楼平地起

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

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

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

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

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

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

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

 

先想，然后再想

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

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

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

 

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

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

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

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

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

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

 

轮换并重新指派小组人员

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

 

案例研究11.6　唯我独尊

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

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

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

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

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

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

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

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

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

 

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

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

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

 

一个软体工厂的可适性

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

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

 

最后的讯息

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

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

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

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

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

达达尼昂 | 游戏开发[资料] |

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

电脑游戏结构与设计  

第十章　角色及部门

 

＊拉开卧室的窗帘

＊指派人员

＊提升士气与工作环境

＊分散风险

 

本书的主题之一，在于游戏产业的急速成长，已经降低了单人乐团，在卧室或是车库工作这种全世界通用的方式。

现在已经不可能光靠一个人来进行设计、撰写并生产出所有的程式、图案、音乐等一个游戏所需的其他东西。这表示必须在一个地点进行特别的过程，与先前不同之处，还要指派每一个人的角色。

 

指派人员

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

当然了，我们在这边运用的角色与分配方式是以［最佳状况］来设定的。在游戏产业中没有几家公司可以设定成这种状况，不过在游戏产业以外倒是十分常见。大部分的游戏公司都有主要的分部，但是其中的一些辅助角色从来都没出现过。很悲伤的事情是，大部分的程式编写早在进行详细的分析之前就开始进行了（在许多状况下，甚至没有这一道分析的手续）。在游戏产业之外，象这样的企划甚至不可能亮起绿灯。

五个主要的部门中，每一个部门都扮演了数个不同的角色；而表10.1中显示出一个以企划为主的研发时程表中，所用到的主要角色与部门。请注意，在大部分的公司中还有其他的角色，但是我们只考虑重要的部分（其他角色主要是支援性质，与游戏生产没有直接的关系；象是网路管理、接待员以及其他的从属人员）。

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

 

表10.1　角色与部门

部门	角色
管理与设计	软体规划师 首席结构师 企划管理者 游戏设计者
程式设计	首席程式设计师 程式设计师
美术	首席美术师 美术师
音乐及其他	作曲家 音效技术师 相关技术（象是动作捕捉）
支援及品管	技术支援 首席品管人员 品管技术人员 游戏测试人员 支援技术人员

 

我们将在接下来的章节中讨论这些部门与角色，在这之后我们再来把软体工厂引进来，比较另一种使用方式。

在这边描述的角色，并不是指一个个永远坐在这些职位上面的人员。相反的，这些角色应该是用帽子般的形式看待，只会有人戴上一阵子。一顶帽子可能会有个人戴很长的时间，而其他的帽子只要戴一阵子就好。员工可以－而且经常性的－同时扮演一个以上的角色（同时戴二项帽子）。举例来说，同一个人可以扮演软体规划师与首席结构师。

 

管理与设计部门

这个部门包括了直接关系着游戏性生产的管理阶层。在高层的技术与设计小组的管理下，低层的管理应该具有模糊化的现象，尤其是在较小的公司，而且每个人都要身兼数个角色的时候。

这种交错的现象很频繁，尤其在游戏设计方面，其原因主要来自于大部分的人［坚定不移］的确信自己知道如何设计游戏。很多管理者与总裁相信他们都是最好的游戏设计者。而这些管理者与总裁中，有一大部分的人原先都是在卧室中工作的程式设计师，从1980的［单人乐团］方式白手起家。他们设计过游戏而且写得很好，所以这是他们最拿手而且会紧紧握在手中的事情，也是他们创办公司的原因。

当然，这些家伙中不少人知道如何设计游戏－在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小时并不是没有耳闻，而长的时间会在两方面破坏一个企划。第一个问题很明显：没有人可以在这么长的时间中，持续以最好的工作方式运作。他们会写出次水准的程式码，而且他们会过度疲劳。

再继续下去，他们就会燃烧殆尽。在这种情况出现时，他们将请更多天的假甚至是离职，这将会重创小组，留下一大堆没有人可以接手的程式码。最糟的是，他们会被人们视为小组中工作最辛苦的人，所以他们的离职会影响到其他组员的士气。

如果他们只是生病或是太累，要花时间来休息，一样也会伤害到小组。整个小组应该在同一个地点、相同的时间中工作。如果不行的话，他们就不算是个真正的小组。他们将成为一些独立工作个体的集团，只是做的是同一个企划。

 

临时的工作环境

很多游戏公司对于工作空间与环境的规则都很宽松，可以放海报、玩具、音响、七尺高的充气外星人。而且在午餐时打打《雷神之鎚》一路轰到下午。

事实上，所有这类的东西都只是让办公室成为一个十岁小孩的卧室，违反了家庭要与办公室有所区隔的原则。游戏产业被人看成是一个好玩而且很酷的职位，但还是让我们面对它吧，在游戏产业中的工作目标是写出一个游戏，而不是玩游戏。

好，现在听起来象是在亵渎神圣的殿堂？我并不是说游戏不该玩，但是在工作时间中玩游戏并不等于您在生产。您很难把［研究］一个新游戏与［玩］一个新游戏之间划清界线。

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

 

分散风险

　　这边所指的风险，主要是小组失去扮演特定角色的人员。在本章节中的角色定义，与工作职称是不一样的；它们指的是单纯的角色，而一个员工可能同时扮演一个以上的角色。角色应该当做帽子来看，一个员工可以在工作时戴上不同的帽子。

达达尼昂 | 游戏开发[资料] |

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

电脑游戏结构与设计  

第九章　目前的团队管理方式

 

＊游戏研发简史

＊今天游戏如何研发的

＊目前方式的问题

＊组员的类别

＊规则的例外

 

在这个章节中，我们将讨论目前管理游戏研发的方式。虽然整体来说，游戏的研发模型在最近几年不断的改进，它仍然保留了很多初期的［卧室］特性。

在这个章节中描述了游戏研发的简单历史，并引用了一些平行但是更为平衡，用于游戏产业界以外的模式（举例来说，包括了研发资料库的方式）来做一个比较。虽然听起来没有什么关系，您可以想象成一个游戏中，运用即时的资料库与令人惊奇的界面。

当然，这样的说法可能过度简单，但是二种不同类型的研发基础，并不会有太大的差异。这个道理将在这个章节的后期说明，而且我们会看看一些例子，来证明二者之间的差异不大。

 

目前的研发模型

除了一些开明的游戏研发公司以外，一般的软体研发密诀包括了：

 

1．找出四或是五位可用的研发人员，试着确定他们的专长得以平均的分布，象是一位人工智慧专家、一位画面程式设计高手、一位声音制作高手、一个［多才多艺］的人员，以及缺乏的人才。

2．指定一位善变的天才成为首席程式设计师，这通常是因为这种人可以在睡觉时完成《雷神之鎚3》的程式码，而且无所不知（详见第11章）。

3．把他们放在一个小房间中，里面有可供他们驱策的制作小组群。

4．文火慢燉18个月的时间，每隔一段时间进入激励他们一下，并加入饮料与披萨来调味。

5．随时准备多余的时间闷煮，不过还是要有开锅后半生不熟的心理准备；也有可能研发人员被烤得过头。

 

又一个看来过份简单的东西，但是您会惊讶的发现，这就是电脑游戏产业界中最常见的模式。一般来说，管理阶层很少有干涉查验的动作，而且这一类的计划很少先写好。不过，在没有干涉的情况下，最后写出来的可能是一堆［地狱程式码］。

 

产业的来源

电脑游戏产业界中的革命，可以与香烟工业做一个比较，二者都是从单独的工人起家，但是在工业革命之前都是默默无闻，之后才进入机械化并开始大量生产以降低成本，取得经济上面的优势。

拿陶瓷工业做一个例子。

别担心：我们很快就可以把电脑拿回来！

陶瓷工业是从单人制作一系列的壶、盘这一类的东西开始，统统是靠手工。其中的成功者很快发现了一件事，想要扩展并增加他们的生意，他们必须在特定过程中有更强大的优势。这并不只是单纯靠着雇用更多人，而是在制陶方面采用自动化与组织化，减少人工的使用；并使用设计者在中央管理。

当然了，在独立生产与特定产品上，并不是没有自己的空间；但是每一个单位的花费将比利用工厂廉价销售方式生产的还要昂贵。这种单一生产出来的产品，就是不能成为效率工厂生产出来的东西。

 

从那时候开始…

电脑游戏工业研发，全世界都可能是在［车库］或是［卧室］中完成，但主要是美国或是英国。这些程式设计师都是具有热忱的业余人士，用来写程式的机器包括了ZX Spectrum、Commodore64和Amstrad464，与现今的电脑比较起来，能力实在低到很荒谬的程度。

所以，他们的游戏企划，要比今天的格局小得多。

这些限制让一个程式设计师在想出可用的设计之后，可以在六个星期中写出一个游戏，而且还不需要用到上一个计划中写好的程式。由于早期电脑中的记忆体很少，所以每个游戏最好重头写起，把每个位元的空间挤出来，才能增加系统的效率与空间。最重要的是，整个［小组］就只有一个程式设计师、一个美术家（如果程式设计师不想挑战艺术的话），再加上一个偶尔出现的自由音乐作家。在这种情况下的团队合作，只是一群人在各种不同的部分，写好一个程式所需的东西，每个人甚至都不需要接触其他人制作的内容。一个人就可以把整个游戏的设计蓝图放入脑袋中，而不需要写在纸上。

硬体的限制太大，而设计者要强调的不再是展示而是游戏性。一样的，程式方面强调的又小又有效率的程式码，没有作业系统需要沟通，而且由于硬体方面的共通性，设计者完全不需要担心硬体不相容以及色层这些抽象的问题。

 

就是现在！

现今电脑的成长速度如同产业界所预期，我们开始看到程式设计小组维持一个很小的格局，以良好的方式管理他们的计划，并开始将他们已经写好的程式码做更好的运用。不过，电脑游戏产业对重复使用程式码，已经有了［践踏本质］的态度。不过，这种态度的主因可能在于需求，而不是出于自愿。

在MS－DOS　PC与麦金塔出现之前，写程式几乎可以（有时是绝对必要）完全忽略掉作业系统，并撰写直接驱动硬体的程式来取得最高的速度。今天，把作业系统丢在一旁并直接去驱动硬体无异是笨蛋的作法。将程式码的每一行最佳化已经不再重要；现在强调的是写出一个能在作业系统下面执行的［干净］程式码。要写出这种程式，必须靠着作业系统的应用程式界面（Application Programming Interface,API）来提供一定程度的标准化，所以只要一些额外的功夫，就可以让程式码能重复使用，并具有模组化的结果。

与各种产业相比，游戏产业仍然是年轻而具开发性的。相较之下，更年长的程式设计产业，只是没有时间来研发更行进而且值得信任的技术。这是因为游戏的一般本质与游戏的研发，会让架构好的研发科技只能维持个数年。现在游戏被认为是一个小型到中型的计划。

现在硬体也更为行进，事实上已经达到无尽的储存空间与记忆体，作业系统也更为卓越而且更能适应使用者的需求。与之前的研发中，作业系统是第一个要丢掉的东西相比较起来，现在与作业系统共存已经成为更具优势而且绝对必要的条件。

这些科技的进展有时会成为双面刃。不断提升的处理能力、记忆体与储存空间，表示这些计划在管理上的复杂度，在很短的时间会更为庞大而且是以指数成长。利用老式的方法来进行研发工作，可以说是举步维艰（指没多久以前）：现在必须勇敢利用行进的研发技术踏入新世界，并使用世界上各种反常的［合理无聊］技术，来进行游戏的研发。

由于计划的不断增加，必须参与游戏研发的人员数量也会相对提升。要管理不断增加的小组人员，更好的管理结构以及沟通管道也随这产生。团队合作不再只是专业术语：这是绝对必要的。

 

游戏研发者的麻烦

这部分媒体要负很大的责任，因为他们广泛接纳了程式设计师与其他电脑工作者，提高了他们在杂耍与表现的层级，要求做出很酷的东西。另一个媒体要负责的，在于他们大量出现在电脑、办公室与学校（这些都是好事）。

不过，每件事必有负面影响，而在这个局面之中，媒体实在太过分了！

现在的游戏产业被人认为是酷王之王。您现在可以在社交场合说您在研发电脑游戏，五年以前，您可能最后只能坐在角落与其他弱鸡坐在一块，讨论着游戏性的优点与组合语言程式技巧。现在甚至是呆伯特这种弱鸡之王，也酷得要命。

所以，这个业界吸引的人，都是本质上自傲得不得了的人。这听起来很熟悉吗？您有多少同事，在自尊上面差不多比地球小一点？其中有多少人不断的说服他们自己，写出来的程式码除了Ada Lovelace以外无人能及？他们之间有多少人幼稚而不理性的抵抗批评，保护他们自己的程式码以及点子，就算已经有人证明它的错误而且把更好的解决方式摊在他的面前（象是您的方式）？

游戏研发者倾向于个人主义。游戏产业倾向把［创意天才］这种名词冠在他们的头上，其自由度甚至超过了理智，让整个小组表面充满活力（或是讲得更明白点［死气沉沉］），我相信您很熟悉这种现象。

 

谁来带头？

当您把一群自我本位而且聪明的人们齐聚一个房间时，通常只表示一个可以预期的结果：麻烦。

由于每个人都具有传统［本位主义］与［自我中心］的游戏研发者心态，内部的竞争会逐步提升，随后而来的问题就是：［谁来带头？］看看谁能骗到这个位置。游戏产业是我看过，唯一具有强大嫉妒心与内部竞争的研发空间。当然了，任何地方都可能出现竞争，但是这种盛行于游戏产业内部的竞争，已经造成毁灭性的本质。在其他类型的研发中，竞争通常是以较为合作的方式出现的：研发者大部份倾向于从其他人身上学习，并接受开放式的批评找出新的点子。好吧，在这之后的动机可能更为自私――研发出一个著名的技能，有助于他们未来的事业――但最后的结果都是一样的：技能的共享与不断提升的点子，将会在有组织的情况下不断的增加。

微软为这方面起了一个名字：［Coopertition］（译注：这是英文［合作］的字首与［竞争］的字尾组合而成的新字，如同英特尔的Pentium一样。在此保留原文――硬要直译的话也可以译为［合作竞争］），或是利用竞争的本能，把您的同事推到极限，但限于小组的一部份。

当然，推展到极限时，对整个小组都有好处。再也不需要特立独行的明星。

这整个［很酷的要素］都会招致反效果。游戏研发将会深植于年轻人的文化，尝试插入较为成熟的研发技术与标准，将被视为守旧而且无趣，所以通常会招致不同程度的反抗。记住，这些想要成为游戏研发者的个体，可能是因为其中注入了［自由］与［很酷］的要素（这也可能是［为什么游戏研发者在整个研发工业中的薪水最低］的原因，但那是另一个故事）。

游戏研发者试着反抗严格技术所带来的重担；藉由尖端的技术成长而远越过一个［酷］字（就算如此，这段历程还是十分痛苦）。您就是搞不懂这些试算表程式设计师造成的问题！当然了，并非所有严格的东西都是好的，但是在特定的领域中，严格制定的协议是绝对必要的，要不然看看它与研发风险相关，会导致整个企划的中止的一面…这可就一点也不酷了。您可以把这些程序与练习，当做是在烫您的裤子一样。它可以让您在接下来的漫长时间舒服点，但是要先花一点时间和功夫。

游戏研发者似乎也会认为他们在本质上面，比其他类型的研发者更为强大（如果您怀疑的话，请看看案例研究9.1）。

让我们看看这个传统的老式想法。表面上［高手先生］这一位游戏研发者，是一个全方面的创意天才，而且具有极强的最佳化能力，可以在早餐之前快速写好一个严密的程式（通常还要再花半天的时间，才能把一个写好的伟大程式除虫完毕）；与他比较之下，撰写资料库程式的人对灰色的西装早已厌倦，而且觉得没有什么自己的生活。很奇怪的是，我发现在交谈之后，马上就能证实资料库的研发者知道他们做的事情必须在一定的时间之内完成，这与写一个游戏比较起来，不见得更没创意或是更困难，而且他通常站在科技的先端（只不过，这个工作可能不会那么吸引人）。更重要的是，他们的生活要比我所知的任何游戏研发者更好，因为他们只是在标准时间中完成一个工作，不需要花掉所有的时间。用更少的时间、赚更多的金钱，取得更多的空间时间来花钱，听起来不是比较迷人？

 

那这是一场战争吗？

尖端科技这个老词是个好玩的地方，而且大部份的游戏研发小组觉得就站在那个尖端上面、撕开包袱、打破界限，并完成其他有胆量的事。当然，这都是真的：他们所撰写的通常是最新的科技（虽然都要透过隔离性的API层，所以并不算是一份完全没探索过的领域）。

不幸的，这个事实通常转移成科技要比游戏性更为重要，这是游戏产业目前所面对的最大问题。有上打的例子，可以说明研发案例明明没有必要踏上这个地雷，却屡试不爽。只要您下楼到超商逛逛架子上面的东西，就可以证明这一点了。

随着科技的提升，游戏的制作变成了一场科技力量的竞赛：更大、更好、更快以及其他。如果这个走向持续不变，那游戏就会越来越不好玩，只会对越来越强大的科技留下印象。如果有人想要看一场漂亮的动态影片，他们大可去电影院。如果有人想要进入娱乐的互动世界，他们会玩游戏。《雷神之鎚》曾经遭受过这一场浩劫，成为有效的科技表现工具，之后才调整成一个游戏。幸运的是，《雷神之鎚3》修正了它的伟大风格，彻底改变了第一代的作法。

不过在我的看法下，这个［多一点科技、少一点游戏性］的倾向并没有持续下去。这个希望在于同样的作用会招致反抗，如同互动式电影在数年前污染软体货架，遭到反抗的结果一样。

这并不表示游戏会成为科技上的挑战。重点将会集中在游戏性，而延伸的科技将成为第二重要（至少，这是我希望发现的情况）的东西。1998年Blizzard Software设计的《星海争霸》是个很有趣的例子，它是一个充满科技元技的游戏，但是具有良好的平衡性与故事线。这应该可以告诉您一些东西。

本书的重点在于缩短游戏产业与其他年长而可信赖的研发科技之间的距离，让其他方面的技术可以更广泛的应用。在案例研究9.1中，显示出研发者在对抗的是什么。

 

案例研究9.1　游戏研发者如何自视

这是一份浓缩过的文件摘录。这份文件是由一群研发者被问到如何加快研发过程，并可以为公司使用的作法时，所写下的文字。为了保护无辜和没有那么无辜的人，所有的名字与地点都经过了变更。

世界上最好的游戏研发公司

 

＊正确的环境：程式设计师不是办公室的职员。他们有创意。他们有困扰。他们通常是成年人。

 

这表示他们会晚到。这表示他们通常一直工作到清晨五点钟。这表示他们花了整个周末的时间坐在电脑前面，才想到他们还有老婆、答应的事以及其他不在游戏之中的生活。

一个研发公司最好别象公司。它不是一个让人从早上九点工作到下午五点的地方。这是个给年轻、有才气、受内心驱策的人们，花费不可思议的时间来创造以及玩游戏之处。这表示我们的工作地点象是卧室，我们的咖啡间是一个厨房，而我们最常去的地方是洗衣间。

一个象这样的地点，是全世界最容易写出好游戏的地方。这是我们想要的环境。

 

＊正确的态度：执行长要公司车、行动电话、个人助理、分红以及国际旅游。

 

研发人员要游戏、小雕象、T恤、玩具和最新的硬体（虽然没梦到分享权利金、红利以及国际旅游：这还是一个事业）。

重点是一个小小的推动，可以在游戏研发方面持续很长的效果。买个七尺高、可充气又诡异的外星人东西：那真酷。星期五下午在冰箱中塞满啤酒，并提供游戏室一些游乐器与球类运动。

 

＊正确的人们：游戏产业竞争惨烈，这包括在货架以及面试室。有技巧的研发者永远都不够，而且有才能的研发者甚至更为稀少。

＊正确的地点：以下地点最好散步五分钟就可以到达：最近的车站、酒吧与酒馆、超级市场、披萨站、24小时超商、银行、停车场与健身房。

＊正确的办公室：一间厨房、一个私人电话、一个沐浴室、睡眠用设备。

＊正确的工作区：没有直射的光线，庞大的桌面，有白板的墙壁、会议室等等。椅子应该用沙发，而木板桌应该换成咖啡桌。应该有垫子、大型电玩和撞球室，再加上连上网际网路的电脑与讨论群组。

 

这一份修改而浓缩过的文件提出了一些重点，象是讨论到办公室的空间以及光线（这些结论都有它的价值――如果一个很有钱的公司觉得有点不真实的话，他们可以从比较实际的层面开始）。

一直进行批评并把不良之处表现出来并不公平，这也是为什么我们在这边提出纸上讨论的办公室以及一个研发环境，而这一切的意图与用意并不难发现。在案例研究9.1中，表现出的就是损及游戏研发者自尊的事。

他们宣称程式设计师并不是办公室的职员――他们有创意、困扰，通常是成年人――是一个他们心中渴望的东西，就是这些东西在研发者的自尊中嘎嘎作响。好吧，他们的行为的确象是成年人；很好，但是您现在站在工作地点，该是您承担一些责任的时候。程式设计师自许为创意人员，但是程式设计并不是发挥创意的地方。有创意的程式设计师，最出名的一种叫做骇客，而骇客在团队合作的环境中，并没有容身之处。

上班的时间太晚，表示缺乏自制能力。每天上班时间很晚，然后待到早上五点有什么意义？身为团队的一份子，表示您应该尽量和团队待在一块，也代表了小组的管理层面。没有人会感谢您熬夜工作，写出大量没脑袋的程式码，而这些工作换了一个设计师，可能一个小时就可以解译出来，而且还完全不用您的协助（因为您整个晚上都昏昏欲睡，毫无效率可言）。这并不是良好的团队合作。象这样的研发者，这样阻碍团队合作的人员，要比其他正常上班、从早上九点工作到下午五点的人员还要花钱。

接下来讨论到睡眠设备以及厨房设施的羡慕，显示出游戏研发中的主要问题。为什么他们要自动假定他们会在办公室待这么久的时间，所以非在这边吃睡不可？那他们甚至需要考虑一下，是不是在研发过程有什么大问题。这似乎是一个很常见的情况，而不是例外。成功的企划并不一定要花上大量的时间。事实上，我比较经常看到花了漫长时间的失败企划，而成功的数量少得多。办公室不是一个家，没有人需要在这边长时间睡眠，您应该回家去做那些事情。

更确定的一件事，是研发者用不着私人电话（这种东西也是应该放在家中的）。上班就是上班，您来这边是要负责您的工作，而这就是老板付您钱的原因。撞球台和大型电玩？去搭电梯！回家，出去见见其他人。您什么事都可以去做，就是不要每天坐在办公室12到18小时，只做出一些次水准的内容。

您怎么确定您做出来的东西是次水准？很明显的，没有人可以在12小时中每一秒都聚精会神，您的精神会疲劳，这一段时间中您无在您的工作中运用您的技巧。这方面会花掉很多时间，只有在家中才能获得完全的休息。当他们第二天回到办公室时（如果他们真的回了家），他们仍然会试着让他们承担下这个工作。一直花长时间来生产较无用的工作，与每天持续工作八个小时，然后出去把所有工作从脑袋中清掉的程式设计师比较起来；在大部分的情况下，这个每天工作18小时的程式设计师，不会比每天工作八小时的程式设计师，写出更有用的东西。

当然，有时候加班是势在必行的，在这种情况下，工作较长的时间可以增加生产力。管理上的危险之处在于短时间的冲刺可以增加良好的生产力量，所以让他们（或是强迫）这些研发人员长时间进行长期的长时间工作，应该可以持续这种生产力量，完成更惊人的成果。抱歉，不是这样。［报酬递减法则］会在研发者想出一个新的流程时进行报复，结果是让他们只需花费较少的工作时间，来产生出较低品质的作品，并提高了花费。

如果有任何人知道他们想要的［七尺高可充气外星人］到底是什么鬼东西，请写个电子邮件给作者。

 

标准的游戏研发者

虽然这可能很老套，但是描述几种标准的游戏研发者还是有必要性。

这些模式可能有些描述与您的组员一模一样，或者它们的组合可以用来表现您的组员之一。当然了，也可能完全都不象。有问题的游戏研发者类型分别为特立独行者、喜怒无常者、害羞者、沉睡者和博而不精者。这些人刚开始都会受到小组的欢迎，但是当他们越来越难交出东西的时候，就会造成生产速度降低的麻烦。这通常不是技术能力的问题，因为技术能力不足的人，通常在他们造成真正的问题之前就可以拔掉。问题是这些人造成的麻烦既微妙又很难发现，也是主要问题的另一部分。

这些问题的类型在全世界的游戏研发小组中都十分常见。事实上，游戏产业真的对这种个体很有吸引力。唯一的方式就是在面试时进行彻底的剔除，小心的看出他们的个性，或许或以使用一些心理学侧写的技巧。小心的追查任何参考线索（您可以马上剔掉任何曾经在游戏产业中工作，但是不能提供任何证明的人）。还有，试着找出（如果可行）应征者在证明文件上提到的其他公司人士，有时刚好就是这个应征者的好朋友！

现在我们来看看这些惹麻烦的类型：

 

特立独行者

特立独行者是一个很有才气的个体，而且是每一个人都会信任而依靠他的人。如果您碰上一个很麻烦的工作，那您需要的就是特立独行者。

在融合了高度的技术能力以及广范围的基本知识后，特立独行者通常是站在发号施令的位置――直到有问题出现为止。特立独行者会全面占有他的程式码，而且禁止任何人靠近。在特立独行者的观点中，没有人值得信任，更不用说可以碰他的东西。没有其他人员具有足够的技能或是知识，任何人的接触只会玷污它的纯净，所以最好别让任何人碰到它（至少特立独行者是这样想）。这种行为只有在特立独行者极度的自信而且极具才干时，才有可能发生。经常发生的事情是，事实上这个程式码除了特立独行者以外，很难有人看得懂。这些技术说明对他而言算是［工作机密］。

不过，在事情出现问题时，会发生什么事？由于没有人看得懂程式码，每个人只能坐下来干焦急，直到特立独行者解开他的困难为止。这表示整个小组现在得全部停下来，只是为了等一个人。这是一个风险，而且并不是一个好的局面。如果特立独行者失败了，他会把整个小组一块拉倒。

那如果特立独行者辞职，留下大量的原始程式档呢？要看得懂就已经很困难，更不用说是要维护时，又是什么情况？唯一的选择将是试着指派其他小组的人员，对特立独行者的程式码进行［逆向工程］并试着了解它。还有其他的选择，但是它们都是食之无味而不可取的（象是从现有的东西重写程式码，或是把整个可以用的机能统统砍掉）。不幸的是，这些选择不一定可行，因为特立独行者倾向于在特定领域中全面负责。如果不可能把整个机能在合理或是理想下的状况下拿掉，那唯一的选择就是把它搞清楚，而且接受特立独行者离职所造成的时间延迟（案例研究11.1是一个最好的例子）。

 

喜怒无常者

他是工作狂。这个家伙知道他是最好的，而且任何想要批评他的人都得承受他的忿怒。每个人都必须了解喜怒无常者，这种人拥有的就是巨大而易碎的自尊。他的点子一向是最好的。他的程式码永远是完美的。和特立独行者一样，喜怒无常者也不知道如何去接受批评。

喜怒无常者通常十分聪明，而且技术很好。不过，缺乏人际关系的技巧，老是用错误的方式来对待他人，这都是他的特征。他把世界上的人分为二类：那些比他笨一点的人，以及他的威协。一般而言，他会因为先天的才能，成为一个企划的领导者。不幸的是，从这个地方开始，就是一个小组结构上最危险的起源。

喜怒无常者会攻击任何他察觉是威协的人，并污辱他们的智慧与技能。其他人只是单纯赶不上他的技术水准，让他觉得完全没有资格共事。并不是每个人（尤其是内向型的程式设计师）都可以受得了这一类的攻击，这将会导致小组产生很令人不舒服的动乱。一位喜怒无常者是一个小组最大的危险，当一个小组因为喜怒无常者的古怪行为而导致分裂时，您可以预期失去二到三位最好的成员。

喜怒无常者通常在基本上是一个控制上的狂热者，因为他会怀疑每个人的能力，并以轻蔑的态度看着每个人的成果。

 

害羞者

害羞者是老式的电脑杂耍演员。您可以在80年代的电脑相关电影中，看到很多这一类的人（您知道这种人：没有个性的学生或是电脑上的杂耍人员，可以在拯救全世界后让学校的橄榄球英雄汗颜）。

害羞者倾向经常性的缩手，而且一种接一种的沟通问题要花上一整天。对害羞者发表批评是十分困难的；事实上，对他提出任何的建议也是十分困难的，与基本的沟通概念一样。这些人们似乎只有待在电脑中才会觉得舒服，所以或许和他们沟通的最佳方式，就是发送电子邮件。

害羞者对整个小组所造成的危险并不明显，因为他不但没有直接性的威协，而且害羞者不会有摧毁整个小组的行为。只是他们从来就不会参与。最大的问题在于他们缺乏沟通能力，所以对整个企划的可见程度会完全消失，所以会成为大型企划中的不定时风险炸弹。

 

沉睡者

沉睡者看起来象是一个小组中的普通（有时是很棒）成员，至少表面上是如此。在表面之下，他们并非这么有用，惹出其他组员在管理上的争议。

拒绝掉这种人的理由很多，其中一个最常见的是纯粹的混乱：沉睡者在接受权威方面就是有障碍，所以潜意识之中会用任何可行的方式去挖墙角。其他的理由包括尝试破坏组员之间，来组织独立的小组，或是觉得他们受到不公平的待遇，想要确定其他的组员也接受相同的待遇等等。

沉睡者在一个小组中之所以是危险的人物，是因为他非常难侦测出来。沉睡者不会让他被管理阶层发现，而且通常只有在他所信任、而且一样会和他感到不满的研发人员面前才会显露出他的本性。利用不具名的回报管道，可以提供一个可行的方式，找出这种有问题的研发人员。

博而不精者

博而不精者是指他在各方面都懂一些，但没有一项专精的。

这些是最有用的［负面］研发类型人员，而且在一些情况下，可以视为正面的。博而不精者是唯一具有坚忍不拔特质的问题研发人员，只要他们能够学会克服本身的缺点，他们就可以成为很有用的组员。

博而不精者最主要的缺点，在于他们会十分确定自己的技能，有时会太过自信。

在他们的技能与他们对本身技巧的自信之间有一道鸿沟，但是他们通常看不到，等到发现时已经太晚了，让他们在可信度上已经受到严重的伤害。这是因为他们一直想要推销自己去（这方面他们的确很强）担任一个职位，而这个职位是他们现有技能无法应付的。在无法承受他们的失败时，虚张声势所写出来的次水准程式码以及技术能力，只有比他技术更差或是经验不足的小组才会接受他的解释。

 

过度的漫长时间，代表一个不成功的企划

如果您预期在一个企划中工作很长的时间，会耗掉您的社会生活，表示这边有些事情真的很不对劲，而且通常是一或二个主要的理由（或是二者的混合体）：

 

1．  这个企划的时程表排的很差，太多的工作试图在很短的时间中完成。

2．这个企划在刚开始的时程表没问题，但是主要的研发问题并没有查出来，而且及时修正；现在整个企划必须迎头赶上。

 

第一个理由是无法原谅的。没有任何理由可以解释，为什么研发小组应该在一个完全不合实际的时程表之下工作。不过，在现实的生活中，事情通常都没有表面那么简单。无法安排时程表的常见理由，是因为来自发行公司的压力，或是另一个（不管您相不相信），时节不对。

让我们假设发行公司需要在特定的日期发行（这可能包括任何其他理由：足球游戏要在世界杯举行时期同步发行，一个与电影相关的游戏需要搭上宣传的列车，或是这个游戏是新平台上市的同步发行游戏之一）。当然了，有时候，期限的设定日期并没有什么理由，只不过是契约上的义务。一家公司（我曾经在里面任职）签下了一份合约，要在九个月的时间内完成一个产品――而且是从头开始。幸运的是，他们很快就了解这是个不可能的任务，而且飞快的与发行公司重新签定合约。最后，这个产品的推出时间晚了将近一年（由于初期写的可怕程式码，是以九个月的期限赶工写出来的）。很明显的，这并不是什么好的结果。

时节的压力通常来自于一件事：圣诞节。每家公司都想把手中的游戏换成钱，因为总是有人想要为可受的小孩添购新电脑并附上几个游戏。这也可以解释在圣诞节前的一个月，市面上为什么到处都是游戏（其他游戏随后就到），而一年的其他时间却什么游戏都没有。

在1998年后期，一群发行公司齐聚一堂，看看他们之间是否能达成协议，完成一个比较平顺的年度发行表，以免发生每年这种疯狂上市的举动。在这本书发行之后，各位去看看最后的结果应该很有意思。如果这件事真的达成协议，那么圣诞节游戏尽出的恶梦可能会稍微缓解下来（这是一件好事，因为没有人可以把圣诞节延后让东西做完，不过我猜还是会有人会想试试看）。

规则的例外

不过，每一个规则都有例外。在一些很少见的现象下，游戏研发公司在工作中会碰上研发模式方面的问题。这通常都不会是好事，事实上几乎都会造成交件延迟的结果。不过，在这些例子中，这些延迟都是属于［好方面］的延迟。从刚开始产就预期会有这种现象。这也不是因为人员能力不足或是程式码的问题，更不是臭虫太多除不完。它们是源自于研发人员调整游戏，或是调校人工智慧，并（在其中的一个情况下）换掉整个图象引擎。

这些公司的运气不错。他们站在值得让人称羡的地位，是因为他们还有调整期限的能力。这个地位可以让他们说：［我们还没有准备发行这个游戏。在我们满意之后，我们就推出。］

这些公司可以容许这种自由度，是因为他们是这个领域中的先驱，他们做出来的游戏，是所有人的榜样。这就是为何他们有资格成为例外的原因。

 

案例研究9.2　《雷神之鎚》、《星海争霸》与《幽浮：太空拦截者》

这些游戏是许多游戏之中的少数杰出案例，在研上面获得很成功的结果。

 

《雷神之鎚》（ID Software）

《雷神之鎚》的研发是一个完美的案例，每一个公司都想让他们的小组用这种方式完工：除了他们自行制定的时间以外没有期限，没有发行公司追着他们一路跑，要求他们把保证套数的灵敏嗅觉一直掛在鼻子上。小组有时间进行研发并让技术尽善尽美。另外，由于有充份的资金（来自于《毁灭战士》的成功与《雷神之鎚》的发行权），小组可以用很多的时间以及所需的资源，让他们的产品达到完美的程度。小组的结构让约翰·罗梅欧（Jon Romero）主导整个结构与设计。他亲自解决了许多争论，不过严格来说，仍然有些程式码的所有权是他的。可是，这样的安排对任何工作小组而言都很难运作。ID Software是一个真正的例外，而且有很多人想要尝试他们的作风，却统统失败了。

 

《星海争霸》（Blizzard Software）

《星海争霸》原先只是采用在《魔兽争霸2》中的画面成象引擎。在研发过程中，另一个公司的分部Blizzard North研发完成并推出了《暗黑破坏神》，而他们使用的图象引擎要比《星海争霸》中使用的更为行进。这些在Blizzard制作《星海争霸》的人员马上决定集中他们的研发经验来设计一个新的图象引擎，才能加强《星海争霸》的外观。这些决定并不是做一些小事情，而且显著增加了产品的研发时间。这个延期也有一部份是因为Blizzard在调整并改进游戏的设计，并平衡其中的游戏性。最后的结果是冒着难以避免的危险（这在本章前面提过），成为1998年最佳的畅销游戏之一。

 

《幽浮：太空拦截者》（Microprose Software）

《幽浮：太空拦截者》是《XCOM》系列的新发展。整个系列中都环绕着利用不同的外星人，找出外星人想要从人类手中取得的东西。基本的游戏架构包括了高度的策略、研发新型的武器与科技，才能抵抗外星人的威协。这些代表了任务目标的变更，而这也是《太空拦截者》与系列中其他作品的最大差异。《太空拦截者》以太空战机取代了上队编制的作战，而最引人注目之处在于它的水准很高，而且时程上面抓得刚刚好（这个成果甚至出现在游戏的谢幕之中）。研发人员最自豪的就是在时间与预算之中完成了这个游戏：证明了一个献身而专注的小组概念是可行的。

在案例研究9.2中的游戏，都是在期限中完成，或是做出了足以当做他人榜样的新标准，并利用明智的程序来确定整个企划在控制之下。为什么这些游戏可以成为例外？这三个例子都是成功而且拥有自主权的游戏（尤其《雷神之鎚》和《星海争霸》）。难道您认为这是因为一个超人种族派他们子孙前来，利用先进的科技来引导我们制作游戏的研发？（嗯，按照我之前的自尊问题，我承认有人真的会这样想）

但是并非如此。这比较象是他们抓紧了研发的技术，以及他们所需要的团队合作。在过程中他们拥有的是适合研发与变更控制的程序，而在这些案例中，得到很漂亮的结果。

如果这些研发小组可以得到这么好的结果，那您和您的制作小组，在下一个企划中就没有理由做不到。

达达尼昂 | 游戏开发[资料] |

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

电脑游戏结构与设计  

第八章           游戏设计的未来

 

＊　设计的好处

＊　良好设计元件的检查表

＊　现在游戏在哪边

＊　下一个游戏在哪边

 

在这个章节中，我们将会回顾基本的主要游戏性，然后从推论的角度来看游戏概念与设计如何在未来演进。不过，首先我们会揭开一些环绕着正式设计的迷雾，以及它在创意过程方面的效果。

 

设计的必要性

我将引用一段话，可能是你觉得很熟悉的：［在这些公司中，有一个设计者都是靠着文字来指挥，很少或是从来不曾亲身参与撰写程式码的工作。设计师对其他的组员说：（用这种和这种方式，把这个特色写出来），然后他们就不管了。］

这象不象你之前听过的论调？一些难以接受改变的研发者还认为正式设计并非必要，现在我们将来看看他们以传统方式运作时，可能碰上的争议。不过，首先我必须承认，上面引用的文句与真实状况还是有些出入。其中的［设计者］可以改为［企划者］；而［撰写程式码］可以换成［切石头］。

这些名词是从13世纪来的，而且是在一个石匠为［过去的美好时光］（指21世纪）痛哭时讲的话，只因为他没有照着建筑师的计划来建造一间大教堂。回到今日，我们已经有很好的理由来丢弃这种错误尝试的过程。建造一间大教学是个要花上数十年、每组人马将近上百人的计划；另外，大教堂曾经是以直观、完全不规则，［看看该怎么盖］的方式来兴建，这是无法让人放心的；换言之，有些东西会掉下来。与软体不一样的地方，只在于倒下来的教堂会压死人。

我猜这段话表示人们一直为需要变革而痛哭，因为变革一般都会朝向让事情更正式、更有逻辑而且更安全的方向前进。拓荒者在成为大教堂的建筑者、电影工作者、士兵和太空人时，并不在乎这些；而这边的拓荒者，自然也包括游戏制作者。

 

别害怕规则

在我1995年第一次进入游戏产业，开始在电脑游戏中工作时，业界对详细设计以及正统研发程序仍然采取相当反对的态度。一般来说，我与美术人员共处的经验是谈得很融洽，几乎要相互拥抱并期待变革，但程式设计师则很害怕。程式设计师们提出的几个反对理由包括了［我们不要让设计高高在上］，还有［你可以设计一个商业应用程式，没问题――但是游戏的一切都是全新的企划。］

［害怕］这个字眼可能用得强烈了点。这些都是充满智慧、有才能、经验丰富的人们；而且他们在本能上，就对改变他们做事方法的事物，采取十分谨慎的态度。如同案例研究8.1所示，他们反抗详细设计的概念，主要是因为游戏研发工作中，在历史上有一段时好时坏的日子。把设计刻在石板上面，并指明它要花18个月的研发时间，似乎不合情理（这边出现了一个很好的理由：不合理）。我们在第5章讨论过，游戏规格书是一份不断进展的文件。它并不是圣经；相反的，它是一个远景的陈述，一份蓝图，而且它正等着接受变革。

案例研究8.1　用设计来节省时间

在数年之前，我正在制作一个模拟类型的产品（我们称之为《Catastrophe》），让玩者去建造并管理一个王国。在早期的设计过程中，我开始考虑一群天然城市的原始状况，利用其中的数个要素，来决定这个城市效忠的对象，包括玩者部队的大致人数（尤其是军事部队）以及每个玩者管理城市经济能力的手腕。

在这个阶段中，只有一个程式设计师指派到这个企划。我问他能不能把先把游戏结果在一个快速测试台上面模拟出来。［只要在画面上用不同颜色的点阵，来表现出效忠的对象就好了，］我说，［我要从这方面得到一个粗略的效果，看看它扩张得多快，因为这会回应到玩者的经济体系之中。如果我最后得到的是无法控制的后果，我现在设计时就要加入延缓的要素――或者在完全不合用的前提之下，干脆把这个点子丢掉。］

在几天之后，我期望他会做出一个充满点阵的画面，但是他们什么事都没做。［我没有那么多的时间，因为我现在忙着DirectX的问题，］他告诉我，［反正这个游戏的引擎要几个月之后才会写好，难道我们不能到那个时候再测试吗？］

［我希望现在就可以完成所有实验性的过程。我现在就需要一个估计的数值，放入我的设计规格之中。］

［噢，］他说，［嗯，反正我们很难把规格写出来，那你干吗要担心？］

 

让我们回来看这些反对设计过程的说法：它会抹杀编写程式码的有趣之处，而且在逻辑上，要计划出一个新的东西也是不可能的。

当乔治·卢卡斯在拍星际大战时，你可以打赌他手上已经有脚本、分镜与拍摄时程表。每一个在团队中的人员都知道他们是来拍电影的，每天每一个小时都要工作。你觉得这些会抹杀掉有趣之处？你觉得详细计划会让人们的创意窒息？才不会，永远都有即席创作的空间。最有名的就是在［帝国大反击］中，莉亚公证说他受上汉，索罗时的对白，是哈理遜·福特在聚光灯下面临时想出来的。在不同的演员拍摄电影时，永远都会在摄影时增加许多不同角度的看法，而且在后制作中也会变更更多的内容。脚本并不是一种束缚：它是一个有远见的骨架，而且可以用创意来填补。

记住（我在第4章提过）设计的存在，并不表示设计者非孤军奋战不可。正式设计当然不表示研发人员要成为辛劳的农奴，无法控制他们的命运。最好的方式可能是来自脑力激荡，让所有人都能贡献一已之力。设计［可以］而且很［欢迎］在研发过程加以变更，如同规格是可以不断进展的文件一样。

那么，当你的游戏是一个前所未有的新游戏时，写下一份计划书会碰上什么困难？有人会争论这种事在逻辑上是不可能的，如果真的不可能，为这个新概念撰写说明也是不可行的，因为在第一步的设计提案只会有五页的空间――但事实并非如此。

在这边，又出现了［设计］应该达成目标的误解，以及错误的推断。我得再次强调设计（尤其是在一个互动研发中的设计）从来没有想要一开始就100%正确。相反的，初步设计所提供的是一个最有可能的［猜测］，由于它一般都会用掉单人12个月的工作时数，与整体160小时的工作时间比较起来，大概只会有15%是正确的（照我的估算，一个良好的企划――就算是一个很革命性的企划中，最后产品也只有80%的同质性）。

所以，扼要的说，为什么需要设计文件？因为不断逼近研发者的日期，如同中古世纪的炼金术。他们喘着气说：［创造无法先行规划！］但事实上是可以的，而且身为研发人员，我们应该追求的是科学，而不是让我们被迷信所限制。从你开始设计时，你就可以靠着游戏理论与说故事的技巧来做为你的法则。这些法则可以为你省掉上百小时的研发时间――而且这表示上万美元的金钱。

 

为什么设计是好的？

良好设计的好处，在于它对士气、预算与游戏都具有正面的影响。

 

士气

小组是以强烈的热情，来追求大家都看得到的远景与明显的目标，并在事成之后可以得到他们努力的奖赏。

 

［当人们有了使命，他们将会安排事物来完成。缺了它，什么都不会发生。］

――黑夜的礼物（1999年）DC Comics，由保罗·查德伟克（Paul Chadwick）与约翰·鲍顿（John Bolton）绘制

 

这就是一个详细设计的作用：一个大家看得到的远景，可以让整个小组进行分析与批评。本书提倡的这个阶段式设计系统，可以让整个小组在各个阶段专注于创造出游戏。一个月或是二个月的转变，表示每一个阶段代表一个可以达成的目标，可以让小组人员贡献心力之后，马上看到结果。

这与会议程式设计师害怕的过程是完全不同的，他们只是简单的把每个星期工作内容列出来。不可思议之处在于这样的系统一直到最近，才被主要的大发行商注意并用于内部的研发工作。原先的方式与我定义出来的详细设计是完全相反的，因为它会让设计不透明而且缺乏连贯性，象Gedanken-experimentation的解决方式，在于鼓励以阶段为基础的设计与研发工作。

 

预算

罗柏特·H·丹恩（Robert H Dunn）在［移除软体瑕疵（Software Defect Removal，1984）］一书中，推算设计上所留下的错误，会在进行十次（平均值）测试之后才有办法校正，而这是可以在设计时一次就调整过来的。在今天这样的庞大企划中，这种状况可能更糟，想象所有的问题在你发行前一个月统统跳出来。有些人模拟为什么老资格的研发管理人员，会认为游戏只有靠着在写程式码阶段，抓出打瞌睡的人才能让游戏顺利发行。但是只要在设计阶段中用比较好的方式来控制，很多这一类的问题明明可以避免－而且研发者可以有更多的工作时间。

任何详细的设计可以容许排定时程、利用资源进行研究、控制与追踪。少了这些，就不可能精确控制企划的预算，而且没有精确的预算，这个企划就不太可能获得资金――除非你有位很有钱而且很宽大的长辈。

 

游戏

一个互动或是阶段性为主的设计，甚至要比任何合并或没试过的特色更为重要。如果你绝对要在特定的日期推出游戏，这个阶段怀系统也可以让你把设计内容调整到相对的日期上。如果研发过程延缓，你可能想要除掉一些特色（或甚至把它们完全砍掉），但是在设计中原有的模组化功能，可以让你在做这件事时仍然拥有控制权。案例研究8.2中强调了把所有设计在期限中完成的重要性。

如果你没有设计，你会发现你在游戏发行的前一天，狂乱的变更了游戏性。这样的作法从来就不是好事，如果你没有早点把事情做对，你又怎能在最后一刻把东西改好？明确设计的好处，不只是让它描述并计划出你预期的游戏性特色，也包括了让你在合理的骨架上，完成任何需要的变革。

 

案例研究8.2　别让设计过时

在几年以前，瑞秋（Rachel）以电脑角色扮演游戏设计顾问入了这一行，负责的游戏称之为《Golem》。这个企划已经研发了将近一年的时间，而且没有什么显著的进展，在看到这个游戏没有什么凝聚力，也缺乏强而有力之处，任何人都觉得它随时会失败之后。研发部的指挥者希望，如果他们可以在设计方面更紧密，那在软体部份的问题可能更容易控制。

在与小组交谈并看看他们现有的东西后，瑞秋把设计规格带回家中研究。在她完工之后写了三页的问卷，但不确定她看到的是最后版本的规格书。［这边描述的是一个第三人称的游戏，］她对首席程式师说，［但我看到的是第一人称。］

［我们需要把画面上的多边形减少，］他解释，［第一人称可以少画一个人。］

［好，但是界面的设计也改变了。］

他同意。［设计师比尔（Bill）说，我们在界面上还要下点功夫。］

接下来，瑞秋与比尔交谈。她很喜欢他的规格，而且明白的告诉他这一点。［这里面有些很棒的特色。我特别喜欢玩者可以装填法术随时使用的点子，这是把多功能换成速度的好方式。］

［多谢，］他说，［提醒你一下，我受不了电脑角色扮演游戏。我真的想要做的是个第一人称的射击游戏。］

［我想它在朝这个方向前进这。还有，其中一位美术师告诉我，目前战士与小偷人物的进度很可能落后，所以你只能玩女法师？］

［是的，没错。第一人称的视角可以省掉人物的美术，但是有太多的问题蹦了出来；不只是设计关卡的复杂性，还要考虑到三个人物职业。］

［这是组合数量庞大的老问题，］瑞秋说，［这三个人物表示要做九次的工作。］

［至少，新的设计要简单得多了。］

［好，］我们至少有点进展了，她想。［我确信一定得有一个新的设计。你影印一份给我吗？］

［在这边！］比尔笑着，敲敲他的头，［我们目前已经落后太多，你不会认为我有时间把想要的东西全部写出来吧？嗯？］

 

最可怕的事情，就是比尔并不是在开玩笑。从那一天开始，他们就再也没有进一步的设计文件，只有程式设计师在做技术方面的规格。瑞秋建议全面修整游戏设计，来符合目前的状况；才能把未来的变动放入可控制的范围中。公司决定在这么后期才来变更这些基础太过花钱。事实上，这个无法完成的失败游戏，已经是他们太会花钱的鉴证：在一年以及￥750000的代价后，《Golem》被丢入垃圾桶。

 

不可或缺的游戏设计

在我们开始想出娱乐软体的方向前，我们先回顾一下游戏设计中不可或缺的部份。你可以靠着几个有用的问题，来做一次酸碱性测试。

 

它有独创性吗？

很少有游戏具有独创性。如同我们在第1章讨论过的一样，在任何状况之下，独创性只是一个相对性的名词。但如果你的设计有研发的价值，它一定有一些特色，是其他同类游戏所没有尝试过的。

当然了，这些特色将是你在研发中最大的挑战。就算这些特色在另一个类型的游戏中很容易了解，但是在导入你的游戏之后就会拥有新的效果――这也是你为什么要在设计过程的一开始，就把它讲得很清楚的主因。如同我在这个部份一直重复讲述的一样，研发必然要负担起设计内容的变更，不过知道它们的主要特色所在――并预期它们在创造时可能会碰到的困难――要比完全没有计划、浮燥容易犯错好得多。

原创的特色并非一定要在游戏性上。象是在战争游戏中加入好玩的卡通人物，就可以简单的达成这个目标。有何不可？不管怎么样，光靠外观及感觉就可以让游戏有所不同。只要有些东西可以让你的游戏有所区别，你就知道自己在研发中该把注意力集中在哪边，并让完成的游戏与市场上的其他游戏独立开来。

在渡过了一开始的提案阶段后，收集一些独特的销售点（独特卖点）来定义出你的游戏概念与其他游戏的不同之处。这些是让你的游戏特殊的地方，而且研发小组将会在这方面花上一或二年的时间。如果这些概念并没有原创性的特色，就丢掉。这个世界并不需要另一个随身带二把大枪的女考古学家。让它完全不同，不然就别做。

 

它有条理吗？

良好的游戏设计是建构在核心的远景周围，象个水晶的种子一样。在游戏开始建造后，如果有变更的必要，核心远景将会锁定它们，成为最后的目标。这可以确立游戏特色的作用，如同一个共通的主题。举例来说，如果你打算制作一个策略游戏，在协助玩者规划攻击方式上，你想要做的是双层的界面；不但具原创性，而且对核心远景而言，可以发挥容易使用的特点。

一个核心远景，也可以把游戏的外观及感觉拉在一块。这不只让润饰特色的元件可以相互支援，应该也可以增加游戏中的感觉。当所有的游戏元件都在全力合作时，你可以拥有的产品就在内部进行共鸣，来确保它的外观具艺术价值。从另一个角度来说，一个前后不连贯的游戏特色与美术风格，只是一团糟。

 

它是互动的吗？

比兹拉·庞德（Ezra Pound）有一段格言，而他很喜欢引用诗集来说明：［在散文中可以表现的，一定可以用散文表现得更好（Whatever can be said well in prose can be said better prose.）］。他试着不要去赋诗，而不是做一些不适合的事，来降低诗文在文章中的地位。在相同的方式下，未来的娱乐软体也很有可能从其他的媒体中脱离，象电影一样定义出本身该做什么事才是最好的――尤其在提供最大的互动性方面。

我们在第3章中讨论过特别类型的互动。在高度互动与低度互动之间，仍然有一个宽广而有用的分类方式。

今天大部份的电脑游戏都运用了高度互动，玩者在游戏中都以强烈的主动，来扮演一个角色。故事应该直接从玩者的所做所为而不断进展，因为玩者预期他的角色会主动，就表示他将不会有耐性坐下来，什么都不做的看着故事一幕幕的在他面前展开。最好的设计是避免冗长的对话、大量而拙劣的主题，以及把玩者控制权拔掉的全萤幕动画。要述说一个故事，并不是没有又能省钱又不让玩者反弹的方法，所以你根本不需要大量的对话。想象你进入一艘飘浮的太空船，其中一个冷冻舱已经坏掉，而且一个死掉很久的尸体从附近的桌子上面碰的一声掉下来，手中握着一个放满药丸的瓶子。你不用把话讲出来，故事已经在里面了。

低度互动，从另一个角度来说，是反应出来的。在它的最简单程度中，代表了观众在看电影时的反应，发出嘶声、不满声或是欢呼――只要演员可以注意到，就是了！你在安排音乐光碟的播放顺序，或是切换电视频道时都是如此。

低度互动是让娱乐软体迈入更大市场的方式，因为更多的人们选择反应空闲（reactive leisure）（象是看电脑或是一场足球赛）而不去选择主动空闲（proactive leisure）（表演或是参与一场球赛）。在更多与故事有关的类型中，将包括了今天的冒险游戏，我们应该看看具有弹性的叙述手法，让观众能沉浸在他们想要的互动之中。

 

它有趣吗？

在第3章中，我们看过席德·梅尔对游戏的说明是［一连串有趣的选择］。我们也看到有趣的选择是困难的选择。其中一个效果是游戏设计得越好，要为它撰写人工智慧就越困难，因为一个好游戏，表示它可以让你在很高明的情况下打赢。幸运的是，人工智慧会越来越好，举例来说，如同你有《雷神之鎚》中，可以看到那些Bots（译注：电脑控制的人物）的行为越来越让人害怕一样。这也是一个好处，因为游戏在未来的需求，将会把人工智慧推到它的极限。

在基础的逻辑概念中，可以告诉我们：所有有趣的选择都是困难的，但并不表示所有困难的选择都是有趣的。如果你有了六个宝箱，其中五个都安装了致命的陷阱，而且没有任何线索可以引导你找出来，就表示这是困难的选择，但同时也缺乏良好的游戏性（而且还没有好故事）。

所以，不要把一个只会烦扰玩者的特色放入游戏之中。良好游戏特色的设计原理，必须让玩者看出它的好处与坏处，每一面都有可能因为其他的要素而变更。所以要找出好的选择并不容易，但是在玩者找到正确的方法后，他就可以得到成功的奖励，并得到更多的选择。

 

它好玩吗？

你只能在游戏中加入这些东西，所以重点是确定这些东西，都可以用来加强玩者的娱乐。

举个例子，考虑一下人工生命，这个数年前流行于产业界的用语。我们现在开始看到有一堆游戏做出了他们在人工生命方面的成绩。我本身对这个技术很有兴趣，但对一个年纪太大的设计者而言有一个明显的缺点，因为有时人工生命（与真实的生命一样）并不好玩。

一个连线角色扮演游戏的世界，只要玩者的人物与经济体系无关，则游戏中千辛万苦完成的塌实经济体系就没有任何意义。在一个策略游戏中，如果因为士兵会十分胆怯而且常常觉得被遗弃，导致你得一直去照顾你的士兵，这简直愚不可及。在一个冒险游戏中，玩者得时时记得处罚你的英雄人物，否则他可能会不听话…嗯，这事实上可能很好玩――算是一个［老教条式的天神游戏］――而且它可以加强你与游戏人物的关系。但它有价值之处仅止于这个理由，而不是它在新科技上面的好范例。

这个课程要告诉我们科技与其他的东西一样，必须在游戏中提供它的作用，而且包括了玩者的需求。绝对不要让你自己从［很酷的点子］、［新的科技］与［惊人的效果］旁边拉开，持续的问问你自己：这样好玩吗？

 

设计的未来

假设你要成为一个游戏设计者，你得先在事业经营、人工智慧、文学创作、电脑科学、游戏理论方面都够水准――如果这是真的，那就不会有那么多的游戏设计者，而且我们将无法找到最好的游戏概念――我们能做出来、想象到的东西，可能只会比温度计好一点。

用另一个角度来看。假设在历史中只有小说家非接受打字训练不可，他们其中可能有些人会写出有趣的小说，天才般的作品等等。但这些杰作的数量一定不多，因为有些人在打字方面不行，作品就不够多。

在1980年，游戏程式设计师很可能也是游戏的设计者（他们也打算做美术，这可以解释一些象光谱般的游戏画面是怎么来的）。1980年代的经典游戏就是这样作出来的，而且没有人认为这些事情不该是程式设计者的工作，而该交给拥有相关技术、知识的设计人员。这只是让不良才能的范围牵涉得越来越广。有创意的程式设计师仍然会继续进行设计，就象一些操控摄影机的人，会继续写电影脚本一样。

在未来，我们应该看到更多的个体，象是剧本家、美术师、小说家以及桌上游戏设计者进入电脑游戏的设计行列，将会对我们所知的娱乐软体产生革命性的效果。这些人之中，有不少人完全不了解科技的限制：但这不是一个设计师应该要担心的事，至少不是在初始的设计阶段。在不知道什么事是做不到的时候，他们就会进而要求，提出一个挑战，让游戏具有惊人的不同，而这些都是我们以前从来看不到的。

［大部分游戏设计者都是程式设计师，而且十分熟悉目前的技术。程式设计师会在创意、美术方面造成障碍，他们知道科技的限制。］

――摘自游戏设计101期，罗博特·威廉斯，《国王密使》创作者。

 

让设计更一般化

如果在游戏设计方面会出现一个最主要的革命，我会说它一定是朝向一般性的设计走。这与软体工厂模型是一致的（而且在逻辑上的结果也一样）。这样的设计，可以让设计者从一般的事情争论到特定事情，让设计的概念更具可携性（Portable），并且更强而有力。

所以，与其开始设计游戏中象是食物、木材、金钱和信仰等特定资源，到不如开始定义这些资源的属性。我可能会说这些资源可以区域化（存在于游戏世界的某些地方）或是非区域化（玩者本质上就拥有的东西，所以不是敌人要争夺的项目）。它们可能具有收集性（等着被人拿取）或是创造性（需要一些动作才能生产出来），而且他们可能具有腐败的特性（随着时间而消散）或是坚若盘石（打不坏），依此类推。

在这个模型中，信仰是非区域性、可创造、而且无法毁坏的；而食物则是区域性、可收集，容易腐败的东西。在我进入我的下一个游戏时，好处就出现了――在另一个战争游戏中，时空设定在现代，而且加入了游击部队与军事政权，我决定了其中的一项资源是士气，你可以随时用来修复受损的建筑物；而广播站可以用来提升士气。友军的损失或是敌人的传道可以削弱它，而且只要你把士兵留在你的街道上面，它就会不断的下降。现在我不需要从头开始设计这一项资源，结构小组已经有一个可以描述它的样板了：非区域化、可收集、会腐坏。在实际上，这个资源的样板可能更为复杂、拥有更多的属性，因为它的目标是在任何游戏之中，可以拥有全面自定的资源。

现在，这可能表示有许多属性的栏位，但它们实际上是以不同类别形成的团体（属性与存在性、持久性有关，等等）。在许多游戏中，这些属性的栏位永远不会出现，或是简单预设在一些高等级的类别中。好处在于你可以（在理论上）把一个部队从恐怖分子的中拿出来，然后把它丢进第一个游戏中，而且还可以期望它们发挥作用――如果你期望的是任何关卡都可以重复使用，这无疑的十分有益。

 

非象征性的设计

如果你丢出一枚球，并在它飞行时拍下许多高速的照片，我会看到这枚球在空中划出一个抛物线的轨道。但是球并没有直线飞出，是因为地心引力造成这个抛物线。抛物线正是一个在数学分析领域中的象征性概念，而且宇宙并不知道任何数学、分析或象征；因为这是人类的概念。在现实中有大量的物理性运作，所以球在一个位置时，是重力叫球的速度变更，速度则改变了球的位置。

这与大部分软体应用程式的方法是相反的。在这边运作的力量是很贵重的，所以你能越明征性的结构，就越好。缺点是在你的象征性［捷径］缺少一些要一步步来发展的东西时，软体很可能就这样当掉。

人工生命的研发者，说明了一个类似的问题：

［经典的人工智慧方式饱受争议，因为用来规划与决定的象征与相关结构，在现实世界中是不存在的。问题是想要明确把感官资料解码成一种象征，并把一个命令转成一个没有错误的意图，是不可能的。］

――勒克·史提尔（Luc Steels），人工生命中的人工智慧根源（MIT Press,1997）

 

这边还有一个例子：假设我在我的新［科学怪人］冒险游戏中放入了一个怪物，而点子是在玩者进入实验室时，它会从它的桶子之中跳出来。与其为它设计一个很复杂的人工智慧，让它以侦测玩者并把玩者杀掉为目标，我可能选择另一个［捷径］，就是在实验室的门上装一个开关。当玩者触动这个机关，怪物就会出现并攻击。

到目前为止都没问题，但如果玩者用了一些抓鉤般的工具，从塔顶进入这个房间，并安全的着地时该怎么办？现在他可以安全的探索实验室，取得所有工具，然后看看这个怪物的相关日记（这本来是设计让玩者与怪物作战，并把他宰了之后看到，让玩者后悔莫及；否则没有任何意义）。只有在玩者想从这个地方的大门离开时，怪物才会爬出来并大吼：［你不应该偷取我主人的秘密！］

在过去，这种非象征性、一步步的方式并不实际。这个过程的能力，也不足以应付这一点与游戏的画面。但现在显示卡负责了大量的绘图工作，而电脑的能力每18个月就可以提升一倍。至少，它可以开始避免使用象征性的捷径，来创造出一些［不会当机］的游戏。在案例研究8.3中，比较了非象征性与象征性的设计。

 

案例研究8.3　比较非象征性与象征性的设计

在原始的《魔兽争霸》中，农民只要进入一个金矿，并把袋子带回城镇中心就可以收集到金子。在游戏刚开始时生产农民是很重要的，因为你的农民越多，你的金钱收入速度就越快。不过，其中一个重点是农民开始挡住彼此要走的路，增加更多的农民，表示会造成［交通阻塞］，因为农民在市街上面碰到另一个农民时，就得后退让一条路给面前的人走。这种现象在较宽广的市街上问题较小；除此之外，让你的市镇中心离金矿远一点也是很好的点子――这样才有更多的空间，来避免交通阻塞。

现在，一个经济学家可以得出一个公式，来描述流入城镇中心的黄金数量。这些要素包括了农民的数量，城镇建筑的密度以及从城镇中心到金矿的距离。我们可以想象它是一个很复杂的公式，但是《魔兽争霸》的设计者从来不需要这样的数学式。他们只要在基本规则、行为以及经济模拟上面加以程式化，就可以把一切显示出来。

对照一下象《凱撒大帝2》（Caesar2）这样的游戏，它运用了隐藏在背后的公式，来创造一个古代罗马城市的模拟。这个作法比较难让人满意，因为玩者无法直接看到他们成功或是失败的原因。相反的，当你在玩一个象是《凱撒大帝2》（或是同类型的模拟游戏时，你正试着把你的建造过程观念，与游戏隐藏的公式相契合。这种模拟下的经济体系与游戏性较难观察出来，降低了玩者着迷的程度。

 

游戏的未来

电脑游戏大概持续了将近20年的时间；用在我们今日所知的外观来看，这种媒体事实上只有十岁左右。尽管如此，在这个章节中，我引用参考的范围回到了索罗门王与亚里斯多德，还有从莎士比亚到奥森·威尔斯。我在叙述电脑游戏上，不仅止于过去十年的技术跃进，还包括4000年的人类文明。

我之所以这样做，是因为我不把电脑游戏小看成是小孩子的玩意，它不只是个［益智游戏］。如果我这样觉得，我不会选择成为游戏设计者。我相信游戏――娱乐软体――是极具潜力，而且在制作方面可以看到惊奇不断的创意艺术，从一个人把野牛头掛在墙上开始，就可以开始讲故事。

但请注意我说的［潜力］。这种潜力是我们甚至还没有触及的一面，目前的一切只是在做基础的工作。未来必须利用这些基础，才能成长为一种娱乐媒体，与文艺、音乐和影剧并驾其驱。而这个未来，将从现在开始。

在过去的十年中，电脑以革命性的方式，让我们看到家中的新娱乐。不过，这种革命只是在实验阶段。举例来说，象是利用相片与戏剧来创造出电影这种新方向的媒体一样。

［没有人真的可以看到市场所要的，或是它真正的模样。就算我们找出答案，我们通常会在这堂课程中觉得丢脸。GTI制作的《猎鹿人》…只是一个幻灯片般的游戏，但是在美国的大众市场却把它狂吞猛喝，甚至加上《Big Game Hunter》到《Turkey Hunt》这些东西后还是不够。］

［《猎鹿人》揭露的是人民对游戏风格上的要求，是这个产业甚至没想到要制作的。这也表示人们想要去买个打猎的产品，而这只是其中学会的一课。］

――奥恩·班诺列克（Owain Bennallack），写于1999年7月份的MCV

 

后十年的设计者（可能包括许多正在读本书的读者）将会带着娱乐软体从兴趣的等级，到一个新的艺术层面。这也是我为什么要一直重复，你的作品是一个游戏并没有关系，如果你喜欢游戏，也没有什么不好。但是，只要你能创造出一些东西，是人们可以享受而且与之互动――而且这一点在其他的媒体方面，没有一个比软体做得更好――你就在做一个设计者的工作。

在电脑上的游戏更具吸引力、更让人兴奋、更方便而且比桌上游戏更为直接。多媒体的产品，证明了它可以比一本参考书提供更有趣、更好的表现方式。电脑玩具让你在无了奶的资源之下游玩，虽然这一些产品都有它的价值，但是其中没有任何一方可以利用软体本质所提供的机会，来创造出一个全新的媒体。如果我们现在站立的时代，如同当年电影院只播放火车快跑或是比赛的短片；那我们现在要做的事，就是找到新科技变形为新媒体的重点。

而且，一个娱乐软体真正令人兴奋之处在那里？它不只即将成为一个新的媒体；而且它的数量难以估计。

 

接下来的十年

随着娱乐软体工业的成熟，将会出现较定形的游戏，区别出不同的类型。为什么象是《古墓奇兵》、《阿尔发新文明》和《迷雾之岛2》这一类的产品都分类为［游戏］？资深玩者可能认为这些游戏在市场上有明显的重叠，但是更广大的购买大众会发现他们之间有很大的不同。

［另一个众所期待的游戏是《迷雾之岛2》，也就是《迷雾之岛》的续集。（它不是一个游戏！）我们大叫；但是更多的人回应：（那不要给我们游戏，给我们更多这类的东西。）］

――奥恩·班诺列克（Owain Bennallack），写于1999年7月份的MCV

 

我们会看到特定的娱乐软体杂志会不断的增加，为了商店中分门别类的展示它们，而定义出不同的类型。就象在书店中，大众市场的人们不会想浏览完所有惊悚小说、科幻小说和杀人小说，才找到他们想看的书一样。你会知道你有兴趣的东西是什么，而且将有专注于该方面的杂志或是网页，来找寻你所需的资讯。

那些类型又会是什么？我们可以预期它们将从现有的游戏类型改革而来，加上一些现在还没有人想到的东西。不断扩大的市场需求，对照现今的游戏，可能的改革包括了：

 

＊更容易接近――人们会想要可以马上玩的产品。

＊更有弹性――使用者在运用产品时，将有更多的选择。

＊更真实――更强化而广泛的人工智慧、物理与图象，将会转变这些产品的未来。

＊更好玩――不再因为游戏系统的不良而挫败；大众市场无法忍耐还在设计中，就拿出来卖的游戏。

＊完全的不同――只有死硬派才会保持我们目前看到的游戏现况。

 

软体的力量

让我们看看娱乐软体可以做得多好。如果我们曾经为媒体编译了一个独特卖点清单，我们可以说出它比其他的媒体强的地方，包括了：

 

＊深度――背景可以更鲜明，游戏世界中的居民会有他们独立的生活。

＊自由度――互动的真正结果，是使用者可以在这个产品中做出他想要的。

＊持久性――你可以在里面沉迷上数百小时，好好体验这种逃避现实的娱乐方式。

＊多人游戏――娱乐软体可以让人群拥有彼此陈述的能力。

 

上述都是一些我们可以看到真实进展的领域，因为娱乐软体（［游戏软体］？）的自我定义是有别于其他的软体。所以，我们可预期看到它会朝更多人、具有更好人工智慧与物理特性的倾向来发展。这个时候就会需要更多的互动性，让玩者可以选择如何来运用游戏（这个地方也可以靠更好的人工智慧来提供协助）。

即使是在今天，也有可能写出具有更深一层互动性的游戏，这正是我们一拿到游戏密技就马上会去试试看的原因。虽然游戏密技让我们有更广泛的自由度，缺点就是在没有适当支援的情况下，资深玩者才能好好发挥它的功能（而这些却是最不需要游戏密技的人）。在大部份的情况下，使用游戏密技不会提升游戏，相反的会破坏游戏。

所以，游戏应该试着提供玩者真正的选择。举例来说，我心目中的策略游戏，是一个可以让我在这个世界中选择扮演角色的游戏：一个部队的指挥官、一个文明的统治者，或是《上帝也抓狂》风格的天神。在这种方式下，一个同样的产品，可能同时具有战争游戏与模拟文明游戏的特色；我也想要决定我会面对的敌人，这都可以靠着选择电脑玩者的人工智慧，或是改变游戏世界的变数来决定（这种变动可以在饥荒之下，让一个电脑玩者从和平的农夫变成不顾死活的入侵者）。这是完全不同的互动层级，让玩者选择这个游戏要怎么玩，而不是靠着设计者用先入为主的方式，来强迫它们运作。在《地城守护者2》推出之后，你可以先自行设定游戏中的几个选项，我们终于看到了这种互动性，已经开始出现在游戏中了。

在十年之后的说故事或是冒险游戏中，你可能决定有天下午，来看看由Victor Virtual担纲的软体电影；之后，你可以决定要更换人物，或是要求出现更长的格斗场景。或者你决定要采取更直接的互动，为英雄提供一个线索。所以，你可以直接从英雄的眼中来体验奥德赛，或是改为海神（你的敌人）或是雅典娜（帮助英雄的女神）视角来看。

好吧，可能这些新媒体不会象我描述的结果，但是它的本质是很清楚的：互动会成为一定程度的选择，以及成为选择本身。

创意的十字路口

要了解一些电脑游戏的不同之处，看看他们提供的娱乐方式可以提供一些帮助。

 

游戏象故事

我最近听说数个研发公司雇用了心理学家，来为他们的游戏注入情感。在很多的状况下，这几家公司都把研发看成一种科学，而且现在他们连创意都当科学来看，而不是当做艺术来看！

如果你想要在你的游戏中加入感情，请雇用电影制作家、剧本家、小说家、诗人、导演或是演员，但是请不要雇用心理学家。这实在笨到很好笑。

在第6章中，我们看过一些持续性的说故事技术，可以用来强化游戏给人的感受。不过，我已经说过娱乐软体一定要成为一个新的艺术。只是把科技埋入其他的软体（象是电影），并无法完成这个目标。

最有名的，就是华德·迪士尼的目标是制作出可以感人热泪的卡通，而他最著名的一幕就是小鹿斑比母亲的死亡。在冒险游戏《时空英豪》中的结局虽然并不怎么引人热泪，至少在情感方面的表现十分成熟。不过，它所达成的效果全部都是透过电影手法。游戏的最后十分钟所提供的数段剧情中玩者虽然握有主动权，但是却无法影响最后的结局。在《时空英豪》中的故事虽然在流动，但却是由没有互动性的过场动画来交待。

要让娱乐软体立下标竿，我们需要采用一个新的互动说故事方法。这可以利用强化的人工智慧和完整的物理系统来达成，但是不要是故事，而是让玩者参与故事的创作。

我已经说过，娱乐软体必须从电影、小说般的旧模式中脱身，并在游戏中找出新的说故事方法。事实上，面对面的角色扮演游戏，可以提供有用的样板。

我在写角色扮演游戏方面已经是专家了，而且我也把它们当做一种嗜好。每一个星期，在准备一场好戏时，我会想出一个设定――举例来说，一个湖边的小镇受到瘟疫的感染而被隔离。我利用这个设定来分布主要的非玩者人物（NPC），来设定我的目标。所以，上面的告示可能写着：［匈奴之王：诡诈、小心、很有钱，想要时间之钥，但不准备为它付出生命］等文字。在我准备好所有的NPC之后，我可以推论出他们之间，在玩者还没到之前的故事。玩者的人物（PC）打乱了一些他们原先的行动，并协助一些NPC相互反抗。因为我知道这些NPC的动机、目标和能力，我就可能决定他们的反应，依此类推。

这边的重点在于，角色扮演的过程中，就是在创造故事。没有什么样的关系，可以先行决定计划的走向。相反的，它是从每个人采取的行动而浮现出来，表示在相同的场景中，以不同的二群人，可能会跑出完全不同的故事来（举个例，在一个游戏中，玩者可能杀死一个坏人并救出公主，然后获得国王大笔的赏赐；在另一个故事中，他们的行为极端邪恶，让坏人为他们工作，然后一块拿取赎金）。

这是一种说故事的过程，是可能在后十年的电脑角色扮演游戏中看到的。而且在稍做修改之后，也可以用在非电脑角色扮演的游戏中。

 

游戏象虚拟艺术

虽然娱乐软体本身具有丰富而独特的潜力，但就象其他的艺术，与他人分享是十分常见的事。特别是我们看到二个小组采用了不同的电影手法：舞台剧着重于空间印象的结构，而蒙太奇则在时间的结构上表现出特色。在案例研究8.4中，提供了一个舞台剧的例子。

要说明这些不同之处，你可以想象一个很有名的电影场景：［惊魂记］中的淋浴镜头。谋杀者用了差不多一分钟，而这一段差不多用了60种不同的镜头，这就是蒙太奇。在安排这些镜头时，希区考克创造出混乱而惊慌的效果。现在假设他在整个场景中固定使用一个镜头，你不再和受害者一样想看清谁是凶手，我们将成为一个杀人现场的目击者；感觉到的不是移情作用般的恐怖，我们会感觉到目标被捕杀的恐怖。

剧院用的是舞台剧而非蒙太奇。小说运用蒙太奇是理所当然的，这只是因为他们在同一个时间只能描述一个场景。不过，不引用蒙太奇将会很难运用舞台剧，因为同时要描述一个房间中的人与物，会变得太过显著；你需要利用蒙太奇把一个个图象分解开来。如同一个复杂物件的简单描述一样，我们可以说蒙太奇创造了强烈的情感与叙述方法，而舞台剧创造出的是设定、气氛与反身情绪（Reflexive Emotion）。

那电脑游戏呢？除了全萤幕动画（这就是小型的电影）以外，电脑游戏主要使用的只有舞台剧的技巧。这是因为蒙太奇手法需要观众成为一个旁观者，而无法控制任何行动。蒙太奇只有在互动性很低的游戏，象在一个神秘谋杀事件中，你只要选择跟随那一个人物。在一个互动性很强的游戏中，你可以暂时用蒙太奇带出不同的效果，象是效果惊人的《鬼屋魔影》早期场景，一个怪物跑过草坪并撞穿窗子。不过，这些用法一定要很朴素，否则不但效果尽失，而且还很烦人。你不会想要老是毁掉玩者沉浸的快乐，并强迫你的玩者坐正，看完零星的全萤幕动画。

娱乐软体的庞大优势已经超过了视觉艺术，跳到画面的框架之外。在一个冒险游戏中，我可以把一份文书交给一个人物，他就自行走开；过一会之后带着他主人的口讯回来。当然，这种事也可以发生在电影之中，但它将是一个跟着脚本走的事件。而在一个冒险游戏中，我可以利用这一点来创造出复杂的环境，让玩者可能受到埋伏、文书掉了，或是给错人（好吧，在过去这样做会吃掉太多的系统资源，所以不太可能，但是我们讲的是十年之后的事）。你在《世纪帝国》中也会看到同样的效果：你追着一个消失在墙壁后面的牧师，而你把部队赶到墙壁的另一边――你知道牧师走到［画面之外］，但是他一定还在。

娱乐软体独具的力量之一，是在玩者身边瞬间造出一个持续的世界。这个状态超越了电影中令人信服的科幻世界，不只让人信服，而且感觉上更为真实。

 

案例研究8.4　一个舞台剧范例

在Appeal公司的《时空英豪》游戏途中，有一个全萤幕动画描述了我们的英雄凱特·史雷德（Cutter Slade），在他女朋友死前回答：［我们等一下再来谈这些，］在自言自语时，他又说，［我想现在的我真是明显。］

突然间，他觉得受到监视。他回头看着城市中央的坚固堡垒。在一个连续的镜头中，摄影机飞向堡垒的墙壁，并继续不断的上升直到出现一个站在阳台上的恶棍，看着城市并盯着主角直到他藏起来为止。

虽然全萤幕动画并不能代表娱乐软体，但还是很难否认这一段是十分杰出的舞台剧手法。在一个连续不断的镜头中，同时把英雄与恶棍同时带入我们的眼中，在电影上面也不是一件容易的事。而且，如果这种现象出现在电影上，它也不会象冒险游戏中一样，让我们觉得如此的［真实］，因为在我们的虚幻感觉中，无法感受到这些人物平时一直都在吵吵闹闹。

 

游戏象运动

可以让多人同时参与的能力，让娱乐软体十分适用于运动；而这并不一定要是真实世界中的运动。运动可以透过软体这种媒体，轻易做到一些致命危险（战斗高尔夫、与猛狮搏斗）、庞大规模与花费（橄榄球一边派上百人）的游戏。

软体运动明星可能象真实生活中的棒球与橄榄球明星一样，而且并不需要每个人都参与。老式的游戏中，会坚持虚拟运动中要有玩者参加，但是我当个观众又有何不可？或许在十年之后，我们可能在家中工作，出去买个披萨和零食，然后连上最后一场全球《雷神之鎚》大赛奖杯中。

 

游戏象玩具

我们之所以玩一个玩具，是因为想找点乐子；这正是为什么［娱乐软体］和［游戏软体］要比［电脑游戏］这个词好用的关系。所有的游戏都是玩具，但并不是所有玩具都是游戏；而且我们的目标，应该是创造一些具有互动性而好玩的东西，并不一定非得是游戏不可。

我并不是在预测游戏的末日，因为它们在有趣这方面的价值很高。举例来说，游戏性在策略类型的作品中，仍然占有领先的地位；策略游戏的玩者将得不断的挑战游戏，并证明这才是让他们觉得游戏最有趣的方法。这正是为什么很棒的策略游戏（象《星海争霸》和《世纪帝国》）可以卖出上百万套佳绩的原因。在找到了一个令人满意的游戏之后，看来策略游戏的玩者会一头钻进去，直到一个更好的游戏出现为止（这种情况下，最好用游戏性是否站在有趣的基础上来评断）。所以，策略游戏玩者是忠实的顾客群，因为他们在期望的更好的产品，通常是一个游戏的续作。要把他们引开，你必须利用所有的技术与游戏性，才能让他们停下来（很凑巧的，这是我设计《Warrior Kings》的理念。时间会证明我是不是对的）。

但是其他类型中需要的游戏性呢？在这个时候，产品中的游戏性是以次要的方式出现，象是在《魔城迷踪》中如何选择你的武器与战略一样，但是这边的游戏性只是整体的一部分：它有助于加强整个游戏，但它并不是中心。我们可以预期这种公然的游戏性元素，只有在与历史事件有关的产品中，才有强化的效果：早期象是［哈比族（The Hobbit）］的文字冒险游戏，就是在模拟这一类的游戏，而非故事内容。

真正的革新是随着《模拟城市》而来到。这是个娱乐软体的革命重点，可以让人们说，［这很明显是一个大人玩的玩具，但是很受欢迎。］不管它是一个游戏，或是它与游戏无法划上等号（模拟游戏中会包含游戏性，只是因为真实生活亦如此；而这些［有趣的选择］是模拟游戏中提供的奖励之一。但模拟游戏并不受内涵的游戏性所定义。）

每个人都接受小孩很适合软体玩具（举例来说，象是《口袋怪兽》）的现实：

 

［鼓励探索，让你的环境自由而舒适到小孩子愿意并想要去尝试，而不用督促他们去做。在他们明白之后，他们就会得到乐趣。］

――兹费·佛理曼（Tzvi Freeman），写于游戏研发者［孩子的力量］，1997年8月

 

如果你在玩象《地城守护者》或《世纪帝国》的游戏，而有小孩子在旁边观看时，你会知道小孩子真的很喜欢游戏中带来的乐趣。他们会说：［让狮子去追农夫，］或是［抓起小妖精并让他吱吱叫！］

但不仅只有小孩子才会有这种反应。成年人也可以用相同的方式来享受娱乐软体的乐趣。我的一个朋友并不欣赏《世纪帝国》游戏的原因，是因为他喜欢命令他的小人去建造城市；所以在一群敌军冲过来的时候，他的游戏乐趣就被打碎了。

我想我们成年人喜欢的游戏性，如同我们想做一些让人尊重的事一样。我们不太确定这是不是只为了好玩，但好玩与愚蠢的动作并不是同一件事。游戏可以教育心智、刺激想象、磨练机智、让人滿心欢喜，并丰富灵魂。在未来，我们会看到很多更有自觉的娱乐软体象一个新玩具一样，而产品的种类会越来越多，也越来越好。

 

前进之路

一个小说家曾经对我说过，［我痛恨电脑游戏，它们不算艺术。］

嗯，艺术在几个菁英级的游戏中，并不是稀薄的概念。各种不同的娱乐中都有艺术的空间，他们可能不是正式的艺术，但仍然是艺术的一种。电脑游戏可能还没到那个程度，但这个倾向是免不了的。

目前为止，娱乐软体的科技会让艺术蒙上一层阴影。现在，在拥有了越来越强大的画面、物理系统和人工智慧后，我们可以迈步找寻新媒体在艺术方面的潜力。它会脱离影剧的比喻，并以我们开始期待的方式，重新定义本身。

设计将会决定前进的方向，因这设计者就是这个新媒体中的艺术家，如果中古世纪的建筑师是石块建筑的艺术家一样。身为设计者，我们必须坚持我们在电脑游戏上的成就还不够好。我们必须想出新的概念，让我们有站在这个角色上的价值，也是人类娱乐史上最令人兴奋的一刻。

我想引用二句话来做结尾。第一句是来自萧伯纳：［有理性的人调整自己来符合世界；不理性的人试着调整世界来符合自己。所以，所有的进展都是靠不理性的人完成的。］

第二句是引自克理斯多夫·卡克艾尔爵士（Sir Christopher Cockerell）,气垫船的发明者：［要不是这些小笨蛋，我们还在石器时代。］

对这本书的读者而言，或许这些［不理性］的男性或是女性将会成为开拓者，把娱乐软体从小小的乐趣转型为一个全新的媒体。

达达尼昂 | 游戏开发[资料] |

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

电脑游戏结构与设计  

第七章　包装起来

 

＊与专家谈谈

＊概念与执行

＊妥善应付变更

＊让小组运作

＊技术的正反二面

＊什幺造成伟大的游戏？

＊未来

 

在为这个部分做摘要时，我问过游戏产业的不少名人，谈谈他们在设计与研发方面的心得。不过，在看看他们的评语之前，我应该先警告一下。

在几年之前研究空手道时，我听说了一个英国人前往日本接受训练的真实故事。他的老师在纠正他对东方武术传奇的认知上吃尽了苦头。［武术并没有魔法，］他们告诉他，［你的成果来自于技巧与力量；只有不断的练习才能达到这个目标。］

之后没多久，这个英国人待在日本的乡村旅店，与数字老师和一位来自中国少林寺的年老僧人同处一室。这家旅店是一个巨大的木头建筑，中央有一根大柱子支撑着屋顶。在谈论之中他们展示了集中气（能量）的方式，少林寺的僧人站了起来，一掌击向坚固的木柱。他似乎没有用什幺力气，但是旅店的屋顶隆隆作响，反弹的震动持续了好几秒。

在这位老僧人就寝之后，英国人请教他的老师们：［我以为您说武术没有魔法。那我们刚刚看到的是什幺？］

日本的老师微笑着：［一般人所做的武术并没有什幺神秘，没错，］他的资深导师说，［但是这个老人是从少林寺来的！］

这个故事意味着，我们必须提醒您即将听到的交谈内容，是由一群主要任职于制作娱乐软件的人。听听他们创作以及获得成功的方式相当具有教育性，但别以为您能一步登天，用同样的方式作事一夜成名。

用上面的比喻来说，这些就是来自少林寺的人。

 

专业

本书提倡的［软件工厂］模型，它无法适应不断大幅变动的设计过程；所以我们在此假设，您会从一份十分详细的企划书开始着手，并在设计过程中尽可能减少内容的变化，因为这种行为最容易耗费研发效能。如果您只能确保50%的内容定案，在把所有的东西完成之前，您还有一长串的路要走。还有，一份详细的设计文件，是让大型制作小组专注于同一个目标的唯一方式。

为了应付没有预料到的状况，我们建议在设计过程中，使用一个研发测试台。不过，我们并不建议利用不断进化的方式，把测试台转换成真正的游戏。相反的，我们建议在反复的研发过程（称之为螺旋型研发）之前，使用测试台来创造整份企划的游戏设计以及技术结构，再另行完成游戏。

所以，看看一些经典游戏是如何制作出来的，将会很有趣而且也极富教育意义。因此，我们设计了一份问卷，请这些产业界的名人回答：

 

这些发言的人分别为：

＊　艾恩·贝尔（Lan Bell），《银河飞鹰》的协助制作者。

＊　迈克·迪斯克（Mike Diskett），［MuckyFoot］公司的共同创始者

＊　彼德·摩利纽斯（Peter Molyneux），《上帝也抓狂》、《地城守护者》以及其它许多游戏的共同创造者，目前是［Lionhead］的创始人之一。

＊　葛伦·克培斯（Glenn Corpes），《上帝也抓狂》的共同创造者，Lost Toys公司的创始者之一。

＊　布莱恩·雷诺（Brian Reynolds），Firaxis员工，《阿尔发新文明》的设计者。

＊　克理斯·克劳福（Chris Crawford），《帝国生死门之帝国圣战》的创造者，也是1980年代许多经典游戏的设计者。

＊　大卫·培瑞（Dave Perry），［Shiny Entertainment］创始者，最有名的作品是《蚯蚓超人》和《亡命暗杀令》。

＊        比尔·罗普（Bill Roper），Blizzard的设计指导者。

 

游戏概念

在本书的第一部，我们以一些粗糙的概念为前提。我在第3章说过，您应该努力的目标，是让游戏的说明以特色为基础。这个明确的规则有可能改变，但是这些特色就是您在游戏完成后想要看到的东西。所以，得知被人公认为经典级游戏的制作理念，以及制作人员的想法是十分有趣的。

 

您最喜欢的是哪一个游戏？您觉得它在商场上面的成功，主要的原因是什幺？

彼德·摩利纽斯：这是个很难回答的问题，我对任何游戏从来没有完全满意过。它们都有瑕疵――除了《善与恶》这个我最近在制作的游戏以外。如果我非选一个不可的话，应该是我第一个完成的游戏，《上帝也抓狂》。

在那个时候，我以为《上帝也抓狂》会被人视为反复无常而诡异的游戏。我没有想到它会卖到350万套。我开始觉得这个游戏有卖象、很特殊，是在我碰到一个玩过这个游戏的记者时，他的热情让我觉得他一定是发疯了。

 

葛伦·克培斯：《上帝也抓狂》。刚开始我们完全不知道它会这幺成功，但是当我们可以开始联机玩的时候，其它人也会喜欢就变得十分明显了――这是彼德的意见，让我们另进了可以感化计算机对手的点子。

 

迈克·迪斯克：我目前正在制作，也刚刚完成的游戏――《刀锋边缘》。它是个集平台、动作、格斗、驾车于一身的冒险游戏，场景设定在一个塌实的城市之中，让玩者成为城市中的警察。

它在商品上的成功之处，并不是一些单靠规划或是设计就办得到的。最主要的，我设计这个游戏时，是以我想要玩、我要制作的方向的出发，并希望它可以捕捉大众的想象空间。

 

比尔·罗普：我在这方面有点幸运，因为我对每一个Blizzard所发行的游戏都十分的自豪。如果我非得选择不可，我想《星海争霸之怒火燎原》是其中超出制作小组与我们预期的作品。虽然它只是一个资料片，但是它在增加的新内容与游戏性方面，是以续集的精神来制作的。这个企划的目标，以及小组的努力方向是［我们需要在各方面都凌驾《星海争霸》］而我觉得它在完工之后，就是这样的东西。

 

克理斯·克劳福：《Trust & Betrayal》。在商品上的成功――这不是它的荣耀。但它失败得十分光荣！

 

大卫·培瑞：《蚯蚓超人》可能是我们最具挑战性而且在研发过程中最有趣的东西。那时我刚刚创办Shiny，所以我是睡在地板上把游戏做完的。当我不写程序时，我正在学习如何支付员工薪水或是写保险单，也可能在修补建筑。那真是疯了，但是很值得。

我们把它带到亚特兰大的E3展，而大家的反应是十分惊人的――正是我们在努力工作之后所需要的肯定。它也很有趣，而且我觉得吉姆（Jim）教会我们这个游戏是混合式的娱乐，而幽默是其中最强的武器。

 

威尔·怀特：这个时候我想说的是《模拟市民》，但是这个游戏还没完工所以不算数；那我想我会选《模拟城市2000》。我想我们在这个作品中所做的一切都是正确的，结果就是它在架上的寿命极长。

 

艾恩·贝尔：《银河飞鹰》。它完成了其它游戏从没做到的目标。

 

为变更做准备

我在第5章曾经说过，要变更规划内容时，增加要比减少更为合理。不过，由于我们经常会低估了研发的时程，看来在没有时间为每一个特色撰写程序时，拿掉特色变成很容易碰上的事情。

回忆一下这些观点，下一个问题将会问问他们有哪些点子是他们刚开始想做的，却没有出现在正式的游戏中。

 

如果把刚开始的概念与游戏完成的结果相比较，会是什幺样子？

 

艾恩·贝尔：没有那幺圆滑。

 

迈克·迪斯克：完全不一样。我很相信我在一开始会写出一份简要的设计概念，一份只有一段段文字的概要，然后让游戏在研发过程中不断的进化。它很没有效率，而且会不断的丢掉东西――像是走错路或是走回头路――但我觉得它可以提供最佳的游戏性。

 

威尔·怀特（Will Wright）：我们在开始设计《模拟城市2000》时的特色之一，是采用动态的水文模型。这可以让玩者创造出一道河流，而且会在地面上真正的流动，并随着玩者变更地形（挖湖泊、淹水等等）而做出正确的变化。这是一个很棒的特质，让玩者在游戏中看着水流并安排它的动向。我们最后只在地形编辑器中完成了一半（将河流放上去，并看着它流下山丘），但是要让它动态变化实在太耗资源（CPU时间），所以在最后的设计中拿掉了。

在真正的模拟系统中，我一直对我们在《模拟地球》中建造出来的模型感到自豪。虽然它很粗糙，我还没有看到其它作品（在计算机系统中），尝试把所有的全球动态结合在一个模型之中：轴心的倾侧、核心温度、熔岩对流、板块位移、地面岩层、全球气候、生物群分布、生命进化以变动，以及全球文明的效应。

 

葛伦·克培斯：在《上帝也抓狂》中，并没有一开始的概念，只有外观及感觉，但是没有游戏。利用碎形产生的关卡从第一天就出现了，第二天有基本的草原、斜面和水。利用鼠标塑造地形的独特能力出现在第三天；但是游戏性的部分却严重的拉到很后面，有一部分是从这个地形的展示以及天才般的彼德·摩利纽斯所提供，再加上小组成员在酒馆中聊天得来。

 

彼德·摩利纽斯：《上帝也抓狂》刚开始时是一个实时战争游戏，但最后却被媒体认为是一个［天神游戏］。最好的游戏应该是可以让玩者从协调的策略中，发展出新方式。

 

比尔·罗普：第一个《怒火燎原》的概念是要创造一个［传统］的资料片――增加一个或是二个新部队，多些多人联机的地图，以及新的战役；另外，我们想要在《星海争霸》推出的三到五个月内就发行。当我们在这个企划上面努力了二个月的时间之后，很明显我们并不满意于人们只要我们做个资料片的想法，所以我们把目标提高了不少。这表示我们不只要回到我们的设计人员身边、重新构建我们的点子、在我们的新企图中把发行时程向后延展，还包括增加新的内部组件，是我们先前没有想要放进游戏之中的。我们最后多花了八个月的时间来完成《怒火燎原》，在我们推出游戏的时候，我们相信不但达到目标，也为玩游戏的兴奋群众尽了最大的努力。

 

克理斯·克劳福：根本上的不同。原始的概念中有玩者和一个小生物遇到船难，一块成为荒岛落难者。他们之间的唯一沟通工具是族间的图标语言，就是把特定的图标，以机场般的标志一样使用。族间的表示语言是完成游戏之后，唯一存留下来的部份，我把它叫做［eeyal］。

 

大卫·培瑞：《蚯蚓超人》是在我们独自走来的情况下完成的。并没有原始的设计文件，只有一群热情而且知道自己在做什幺的家伙。这表示我们可以照我们的工作方向来研发游戏。我喜欢用这种方式，因为它代表我们可以在任何时间加上任何的东西。现在，我们一想到这种情况就会全身发抖，他们称之为［恐怖的特色］。

 

有没有什幺东西，是你们当初期望但是最后没能加入游戏中的？

 

艾恩·贝尔：戏剧性的奖励动画，却因为内存的不足而省略。

 

迈克·迪斯克：能够进入每一栋建筑物中――这个特色最后觉得玩者会因为内部摆设与游戏主旨无关，只是因为想探索而分了心。另外，通往下水道的快捷方式也因为在PlayStation和Jellymather上面会用掉太多的内存省略，也没做到一个可以让对象变形、压挤或是弹跳的系统。这些都要靠浮点数运算，但是在PlayStation上面运作得很慢。

 

葛伦·克培斯：从《诸神纪事2》（Populous 2）中的点子一直没有用在《上帝也抓狂》（Populous：The Beginning）――像是法力系统的延伸以及更多的地形变动效果，类似旋涡和龙卷风。我也想要看到更多可变曲线塑造出来的精致地形，但这一点就算到《上帝也抓狂3》（Populous 3）中也没有做到。我还想看到更具弹性而且更具智能的城镇建筑，可以自动在平坦的地形上面兴建：这可以让游戏中的城镇看起来更棒，却无损于游戏性。

 

大卫·培瑞：我们想要拥更多、更多、更多的小游戏，但是卡匣的空间一下子就满了。这表示［母牛海绵关］永远都不会出现在玩者面前了。

 

游戏在进行中，是如何应付变动的？

　　

艾恩·贝尔：在玩者可以扮演更多的角色时，这种情况就越常出现。

 

迈克·迪斯克：主要的人物是一位警察，已经为背景资料提供一些线索，但她不断的获得进展，却成为游戏性的重点。

 

葛伦·克培斯：在早期的阶段中，《上帝也抓狂》是一个让玩者倒入大量战斗、手忙脚乱的热门游戏。这造成了不少问题（不只是速度和内存），而且要打完一场只有二位玩者的游戏，几乎都要点选几个小时才能打完。我得把它变成另一种情况，让玩者觉得他们可以全面控制这个关卡。

 

彼德·摩利纽斯：《地城守护者》的原始概念是［您扮演坏蛋］。我想，这应该是我想过最好的点子。事后证明这个点子的方向，实在不应该做成这幺复杂的游戏，而大部分的原因在于游戏的接口。在我的许多游戏中，我至少会对我的接口感到满意。这也是在我们最新的游戏《善与恶》中，主要目标放在改革游戏接口设计的原因。

 

比尔·罗普：虽然在我们原始规格（在《怒火燎原》游戏中）是要为每一个种族设计二个新的部队，但这些部队真的把游戏翻了过来。我们刚开始只是想制作一些看起来很酷的东西，但是我们却停了下来，看看我们从玩者那边取得的游戏平衡相关资料。虽然我们努力让《星海争霸》成为难以置信的平衡游戏，我们还是迫切期望能尽善尽美。我们把《怒火燎原》视为一个机会，让我们藉由增加部队的方式，让游戏在初期、中期、后期都得以平衡，而且还可以重新设计我们的空中作战变化表。

另外，我们想要完成的单人战役也改头换面，加入了更多的游戏过场动画以及数百场事件，来述说更多的故事。这表示我们可以对地图编辑器做一些正式的修改，而这并不是我们原先的点子。小组全力奉献于资料片，并不只是要加强原先的东西，而是在所有方面取而代之。我们所做的每一个决定都在改变游戏――不管是在图像、运作、平衡、技术、音效、音乐或是故事――都做到了我们心目中的目标。

大卫·培瑞：每一天都有反复无常的变化（指《蚯蚓超人》），但通常是朝向大家努力的目标。在运用一个具有无限可能性的人物时――他可以前往任何星球，拿起所有东西――这表示所有的活动都是自由的。问题是许多设计者今天面对的，是他们要制作出［真实］。真实的东西真的很纯。

 

克理斯·克劳福：噢，您是说变化！这个游戏在基础上已经背离了任何之前出现的东西。我发现我自己每一次碰到墙壁时，就要重新设计一次――这实在太寻常了。我不要做二个人与多位人物的互动之旅，因为我想要的是让玩者有更多、更具变化的互动设定。基础上就已经冲突不断：先是一个人在对抗大自然，然后是一个人对抗一个人再对抗大自然。我终于解决了人对抗人的问题。

为了做到这一点，我需要先把基础的冲突解决掉。我那时候的运作理论引导我完成这个循环，而非可递性的战斗关系提供了更有趣的可能性，所以我利用这层关系设计出一个冲突系统。我对这个系统感到很自豪，而且我要很难过的写出：这个产业界的其它人似乎不重视这种关系巨大的潜在能力。是的，他们需要一些人造的东西――我想不出真实世界中有很多循环式的非可递性关系，但是以前的游戏设计者从来没有被这个问题难倒过。我猜大部分的设计者都不了解这个概念。

还有更多的变动，但是我写到此为止。

 

布莱恩·雷诺：最重要的事是游戏进行时，让一些东西保持运作才会有玩的价值，就算玩得不彻底也一样。利用这种方式，您可以真的试出游戏强弱之处在哪边。然后您就可以修正您的原型，加强您的优点并去掉您的缺点，然后再玩，再修正、再玩，再修正等等。如果您连自己的游戏都不玩，您不会期待其它人来玩您的游戏。

 

每一次的变动会影响或是导致什幺？

　　

艾恩·贝尔：把零件放对位置。

 

迈克·迪斯克：有些变动是必备的――这些工作内容可以让游戏大幅的提升。其它时间的变更结果是十分平缓的，每一小步都可以导向更大、未预期的整体变动。

 

葛伦·克培斯：在第一代《讲神纪世》（Populous）中的效果是地震、火山和洪水。早期的游戏包括一个供玩者建造的平地，他的动作必须越快越好，才有可能在其它人以火山或是地震轰炸他之前，存到足够的食物。其它的效果是从游戏中激发出来，加速游戏关卡的结束来设计的。举例来说，骑士是设计用来带领玩者，集中人民和法力，才能扫荡大区域中的敌人，而玩者只要提供少量的协助。

 

布莱恩·雷诺：在我玩我的游戏时，我会记下我觉得生气的地方，以及我想要加强的部份。在我玩完之后，我就会做这些变更。

 

大卫·培瑞：我们使用了一个系统，让每一个小组中的人员都利用图稿来提供一些点子，不管他们有没有绘图能力。这会让整个会议变得很有趣，尤其在我们看程序设计师［充满架子］的手稿时。但是，还是可以让我们看到具有创意的点子。我们在游戏中用的点子以外，还有很多、很多、很多没用上的。

 

从事后看来，您会做什幺方面的变更？

　　

艾恩·贝尔：一些编码的手法太没效率，但是对游戏性比较好，所以还过得去。

 

葛伦·克培斯：我们得限制游戏中的人物和建筑物的数量，因为我们活动或是重绘的速度不够快。在数年之后，《诸神纪世2》可以在当年执行《诸神纪世》的阳春机上面画出更多的图素，并让人物活动得快一点，这都得感谢我们的程序越来越高明。我很喜欢看到没有限制、更［活生生］的《诸神纪世》一代；而不是看到更纷乱、更让人迷惑而且功能更多的《诸神纪世2》。所以从事后来看，我想说我们错失了写出《诸神纪世》的时间，而那时我们正在制作续集。

 

克理斯·克劳福：我想让人物具有更复杂的互动。目前的设计没有太多的活动空间：他们只会讲话，交易和背叛。我想建造另一个交谈互动的语气模式。

 

威尔·怀特：我有一个在《模拟城市》之前制作的游戏（而这是我的第二个游戏），称之为《Probot》。它是在Commodore64平台的游戏，而且在我转头制作《模拟城市》之前，它已经完成了90%。我一直在想它对市场会有什幺影响力。

 

大卫·培瑞：我会试着找到更大的卡匣！

 

技术面

创新的概念经常需要创新的技术。不过，研发的商业面是十分现实的，尤其是对小公司而言，养一群R＆D（研究及发展）人员是很昂贵的。在一个完美的世界中，您在开始进行尖端领先的游戏时，免不了也要拥有能够证明概念的同等科技。事实上，全面尝试及测试过的技术，才是最理想的。

在本书的其它部分，我们以下列的研发方针为主：除非一个游戏已经拥有所需的科技，否则不应该对它亮起绿灯（不过，这可能包括替代性的技术）：这就该是R＆D要负责的工作，而且他们不该从游戏预算中拿一分钱。

 

有什幺科技会让您大吃一惊？再以正面的角度来看的话，它们如何协助您完成您未预期的效果？

　　

艾恩·贝尔：最让我吃惊的是我们可以用人物为主的表现方式，而不是真正的位映像显示；现在的绘图速度在许多方面已经有很大的成长，而且要清除的内存也少得多。

 

葛伦·克培斯：《上帝也抓狂》这个游戏能完成，是因为有了地形变更（我可以说，这是我的点子）。它的结果是让您在养育人口、等待法力上升的同时，还觉得游戏很有效率而且好玩。这是一个在有限科技下，很好运的附带产品。

 

克理斯·克劳福：我对于我的逆向组译器的速度吓了一跳。这是另一个漂亮而被忽视的敏锐技术。我曾经害怕它会卡住，但就算是复杂的组译器，跑起来还是比显示的快。

 

大卫·培瑞：我们把Sega Genesis推到极限。每年做出来的技巧都在这个产品中。

 

布莱恩·雷诺：虽然我们每隔数年，都预期看到中央处理器的执行速度、硬盘空间与内存出现戏剧性的成长，但每次看到我们做一个游戏的时间，可以让机器成长到这种程度，还是让我十分的惊讶。对我而言，更多的内存与更快的处理器，通常代表更好的人工智能。

但是我在这个工作数年以来，我想最大的惊奇是Windows操作系统对产业界的革命，而且这个方向是好的。在技术性的观点中，它让游戏的研发更为简单，而且同时也可以让我们碰上更多有潜力的玩者。任何还记得DOS中［config.sys］地狱的人，一定知道我在说些什幺。

 

那科技的负面看法呢？它有没有阻止过您？它的出现带来什幺困难？

 

葛伦·克培斯：在我知道只有一种斜面，而且只有八层的高度可用时，感到限制很多。在这个时候，这些东西看来是系统最大的问题，但是从事后来看，这些限制可能是游戏成功的最大功臣。

 

彼德·摩利纽斯：技术可能同时是研发的恩惠与祸根。它前进的太快，当您刚刚设计出一个游戏，您觉得这个设计可以做到X的能力，但是在一年之后您就可以把X乘以2。这个诱惑将让您尝试运用新的技术来设计，而这就是整个企划延后的主因。

 

艾恩·贝尔：最主要的不同在于没有程序代码运作的空间。

 

布莱恩·雷诺：提升科技等级也表示增加了顾客的要求。在我们从软盘片进展到光盘片，而且很快光盘片就会提升到DVD，让游戏可以用的［磁盘空间］不断的增加，但也必须用良好品质的游戏性来填满这些空间。要做出一个高品质的游戏，代价将变得越来越昂贵。

 

大卫·培瑞：游戏可以使用更多的声音取样，但是他们将耗掉上吨的卡匣内存，所以我们限制在［Groovy］和［Whoa Nellie］的身上。

 

研发

本书传达的一个讯息是，游戏程序设计曾经是一个卧房工业――研发小组可能只有二个人――或是更少！与其它的娱乐产业比较起来（像是音乐或是影剧），这是个很少见的情况。

我们曾经争论过，正统程序中最有效的模式，是由中等到大型的小组（10个人以上）负责。软件工厂模型就是正统程序的样板，它的主要优点在于具有规划、预测以及追踪的能力――当研发费用象炸弹一样越来越高时，是很重要的一点。

 

您能把原来的计划时程维持多久的时间？

　　

彼德·摩利纽斯：任何说过在他看过原始概念后，就可以预测真正上市日期的人不是天才就是笨蛋；而我打赌这种人是笨蛋。就算您手上拿到了每一个游戏特点的详细描述，以及每个人工作的小时数，也不可能做出预测。您能做的事只有设立一个目标，让游戏可以尽早开始玩起来，才能开始进入［它看起来真漂亮，但游戏是什幺］征候群，而这个阶段最花时间。

 

葛伦·克培斯：我们没有时程表，游戏从开始到结束花了七个月的时间。如果我们花了一年的时间，牛蛙公司可能活不了这幺久。

 

克理斯·克劳福：我对时程表盯得很紧。我记不起正确的日期，但是我知道它在圣诞节之前要包装好。我现在猜测，如果我把时间表向后延三个月，游戏可能会更好；但是我一向在接近期限之前，保住我的自尊心。

 

布莱恩·雷诺：不管是什幺理由，我在时程表了的运气一向比其它方面都好。我前五个产品都在预定日期的二星期以内交件，但是最近的游戏《阿尔发新文明》，晚得实在不象话（差数个月）。

 

大卫·培瑞：我们一向及时把游戏完成，但是现在，在我们试着提升技术时，我猜时间实在是很难控制。我在最近几年已经学到不少东西，而且我现在真的很尊重科技与创意的平衡性。

 

艾恩·贝尔：没有时程表。

 

你们的进度追踪多有效率？您知道您在整个企划中，目前的进度百分比是多少？如果不知道的话，您下一次追踪时，会用什幺不同的方式来取得更精确的数字？

 

葛伦·克培斯：如果您现在问我，我可能会请您再讲一次，而且用我听得懂的语言讲。我想在十年之后，我会有比较好的答案。

 

克理斯·克劳福：这一切都在我的脑袋中简化了。这是一个疯狂的蓝天计划，需要不只一个从来没有研发出来的科技，以及我们之前从来没有完成的基础。不管怎幺说，我可以时间的信道中调整内部时程，以确保我能在期限中完工。

 

彼德·摩利纽斯：我们用来查验进度的方式是每星期的会议，每个人报告他在上星期完成的工作，以及他们下个星期的目标，接下来是研发的策略。这必须让小组的其中一人为核心，而这个人要十分清楚游戏完成的样子。

 

大卫·培瑞：我们想要更正确的朝游戏结束的方向前进。我们的游戏走了很久，而且在路上不断的加强，尝试新的点子。然后，在信道尽头的光线笼罩之下，它就会马上跳出来。

 

艾恩·贝尔：进度是造出来的，不是追踪出来的。

 

您会把游戏的设计比喻成从一个海港航向另一个海港，或是树木成长这样的有机过程？或者您有更好的类似说明方式？

 

克理斯·克劳福：呃，不是我自夸，我可以把一些设计用第三种更好方式来说明：堆积如山。设计者一直把特色铲在一块，直到它变得巨大无比，再一路通过发行商、行销公司和零售商这些人，看到这个庞大的东西，才知道里面的某处有他们想的小东西。

对我而言，这个过程像是拿破伦战争：先对部队来一场雄壮的演说，里面放满像是［为了荣耀！］和［法国万岁］这种词藻，然后来一场残酷的战斗，也就是用我的才能对着面前的问题宣战，除了胜利之外什幺都不看在眼中。如果我的运气够好，我可以冲破敌人的防御，把我的军旗插在山丘上；如果失败的话，就是一场漫长而痛苦的撤退。我二种都经历过。

 

葛伦·克培斯：许多年来，我一直确信它是树木的生长模型，新的类型杂乱不堪，似乎要再花一年的时间才会有条理。这些日子我们很接近航行的情况，却不见得完全相同。［Lost Toys］的哲学是小心选择我们前往的方向（希望是个不要有太多竞争者的地方），并以快速、互动的原型朝大众化的方向狂奔。

 

迈克·迪斯克：研发像是一个登山家，正在攀登一座云雾复顶，看不到山尖的高山。他会经常滑落、在山上改变路线，但是在看到山顶的时候――他就知道他的方向了。

 

比尔·罗普：我们在Blizzard通常是以有机体的方式来看待游戏的研发，但是它们比较像是某种受到控制之下的混沌。身为研发人员，我们得愿意经常变更游戏，让它在研发与设计的过程变得更好。我们在游戏发行到市面之前，已经确信我们做到了更好的游戏性、更好的平衡和――这可能是最重要的――最有趣的游戏内容。在游戏不断进化的同时，从各地而来的点子并不是某一位设计者坐得高高在上，在石板上写下变更的内容，并试着把一堆东西整合起来。我们会在过程中修补一些结构，而且我们在创造游戏方面，一直是不断成长的公司。

 

大卫·培瑞：这像是个恶梦。您去睡觉时期望可以有一段良好而轻松的睡眠，但是恶梦开始了――庞大的压力。最后，当一切结束时，您醒过来而且需要咖啡因才能让您的身体再动起来。不同的地方，在于游戏的制作时间长达18个月！

不，它真的比较像是有机体：一个游戏成长到有人想要为止，而且之后您把它包装起来，最后让它们从货架上面拔掉。

 

布莱恩·雷诺：比较象后者。新的点子会在旧点子上面成长，而您在早期和中期的阶段，无法确定它在最后是什幺样子。

艾恩·贝尔：它像是生态系统的演进。

 

您觉得正统程序中的应用组件如何？举例来说，像是以组件为主的设计，重复使用的规划，变更控制、回顾先期程序代码等等？

　　

艾恩·贝尔：这个点子可能不错。

 

克理斯·克劳福：只要在一个企划中的工作人员超过一个，预算超过，呃，十万美元左右，就是绝对必要的。不过，我们必须了解这个工作是在做创意，一脚踩进水中并不表示您可以越野穿过一个国家。

 

葛伦·克培斯：用十分严肃的方式，来看待游戏研发中的程序部分是一件很好的事。标准化、模块化以及对资源控制技术的兴趣，对程序设计师而言都是很好的。在一个较缺乏正统程序的设计过程，与有节制的程序练习结合，并不会让我觉得有什幺不好。

 

迈克·迪斯克：我痛恨软件工程爬进游戏的设计之中。正统程序只有在一开始就知道这个游戏是什幺样才会有效，但是如果您探索不同的方向，并让游戏分枝在研发中期保持自由化，那这些正统程序不过是您的绊脚石。

 

大卫·培瑞：这在未来将会十分重要，但是一个小组中的程序设计师的自由度不能太高，要设计出一个让他们同意的［合作］程序，将是一项大挑战。

 

布莱恩·雷诺：噢。

 

制作小组

这个主题的第一个问题，将在于整个制作游戏的小组――这不只包括美术设计师与程序设计师，还有管理以及市场人员。

 

您如何确定整个小组的网状结构？

　　

艾恩·贝尔：让小组越小越好。

 

克理斯·克劳福：这在游戏初期会容易的多，因为基本上就没有小组！我完全靠自己，这通常是发挥长处并隐藏缺点的好方式。我知道一些好的设计者不打算出现在群众之间――我就是其中之一。但是我很难告诉您哪个好的设计者，也是一个好的管理者。

 

布莱恩·雷诺：我们的运气很好，与一群彼此熟识喜欢相互合作的老手与菁英共同创立这个公司。在我们成长之后，我们已经为这个环境做了最佳的努力。

 

葛伦·克培斯：目前这并不是我的工作，小组可以维持这个结构，是因为它很小而且每个人都相互关心。在我的看法下，这是游戏设计的关键――这也是我们宁愿自组Lost Toys而不是待在牛蛙公司中，后者的员工人数超过160位。

 

彼德·摩利纽斯：如果一个成功的游戏有秘密的话，它一定是由一个小组全力合作找出来的。如果和您一块工作的每一个人都相信这个企划，而且如果他们了解您并信任您，获得成功之后他们也会同时获得奖励，那这个游戏的研发过程可能是最美妙的时光。在这个时刻，在《善与恶》中，每一天都有一件惊喜的事出现在游戏中，而人们也十分高兴能参与这个企划。

 

大卫·培瑞：小组的表现好极了，只有在选择音乐上才是我们的问题。我们曾为音乐打了一仗，然后当无礼的行为消失后，我再次让二个家伙在我的办公室拥抱言和。

如果一个小组不需要变动，有可能以狂热的小组伦理来运作。用这种方式运作的小组通常是很好的，但是如果新的组员必须整合进来，正统程序是一个让整合平顺的好方法。

 

您需要在研发开始之后，加入任何新的人员吗？

 

葛伦·克培斯：这是几年前的事，那时我和彼德·摩利纽斯在程序与美术方面已经完成了95%。在不同的时间，还有其它的程序设计师与美术人员。

 

大卫·培瑞：我们在游戏中需要大量的动画，所以我们雇用了人员来做数字绘图的工作。这表示我们的动画师只要画出铅笔稿，然后雇员就会把线条清干净，另一个则负责上色。这种方式完成了上千张的图像――比我们预期的要快得多。

 

克理斯·克劳福：不会。

 

艾恩·贝尔：不会。

 

费用及时程

计算机游戏在不断延展的期限，以及节节高涨的费用简直是恶名昭彰。一个游戏的发行日期定在一年之后（或是更久）并不是什幺少见的事，而且有很多这一类的游戏到最后都极为成功，但是他们让发行公司心力交瘁，不断取消先前的发行计划。

［游戏好了，但是还没做好］是种很让人生气而且奢侈的说法，小型的研发团队可能根本担不起。试着坐在您的投资者面前，告诉他们您还要100万美元，但是您无法把您的生意计划展现给他们看，因为游戏产业并不是一个可以预期的工业。您只会看到一片漠不关心的面孔！

本书的方法学是利用互动的方式来承担研发过程，也可以称之为［阶段］。在每一个阶段中，您的第一个计划是找出您想要完成的目标，然后您开始建造，然后测试，而且最后回顾您完成了多少计划，以及如何配合下一个阶段的计划。每一个建造物加挂物品或是调整特色的阶段，都在一个模块化的结构之下完成，让程序代码的元素可以独立进行查核。这个过程的最后目标是达到［完成］――我们这边的定义不只是游戏还可以在各方面加强，还有正在进行的程序；而且在任何阶段，都有可能因为特色方面的考量而中止，但最后还是有一个可以出售的产品。

 

如果是一个AAA级的产品，标准的研发时程是怎幺样子？

 

葛伦·克培斯：要二或三年的时间，要一年或二年太赶了。

 

迈克·迪斯克：一个原创性的游戏要二年。

 

布莱恩·雷诺：这些日子对我们而言要一到一年半，也可能是二年；而且我想这是这个产业的标准。

 

大卫·培瑞：现在差不多18个月――很快就要24个月。

 

彼德·摩利纽斯：至少要二年，从概念到包好的产品可能要花上三年。

 

比尔·罗普：在电影、显示卡、声卡与扬声系统越来越强而且价格越来越低，就会越期望游戏的品质更高。要增加这些东西，要提升的还有网际网络联机速度的频宽（至少在美国是如此），而且玩者不只期待神幻的单机版内容，还包括了流畅的多人联机设定，让游戏可以再玩数个月，而不只是几个星期。预期在效能以及内容方面的提升，表示制作小组得花更多的人力才能做出AAA级的产品，而且冒的险也会越来越大，直逼最好的电影。

这一切都在烧钱，所以可以接受的游戏设计周期差不多在二年的时间。这对研发人员而言极具挑战性的，因为在科技不断的进展之下，预测上会越来越困难，而且我认为我们已经看到在科技快速成长的现在，游戏已经有点跟不上的现象；在一个游戏花一到二年的时间来设计，很有可能因为研发小组试着追上新的标准时，不得不把游戏延期或是整个取消。

 

游戏性

在有机会询问研发人同的情况下，我很明显的感受到，知道他们是用什幺方式找到创意的火花是十分重要的。虽然我们之前提到的警告仍然有效（您可能无法用相同的方式，造出同样的成功产品），但是钻研高品质游戏性、外观及感觉的由来，仍然是很有趣的。

 

您自己的游戏中，有什幺特色是您特别讨厌，而且觉得无法接受的？

 

大卫·培瑞：我讨厌游戏要先看完说明书才能玩。我想要坐下来玩，而且当我卡住时才去拿说明书。我猜我的耐性不太够。

 

葛伦·克培斯：太过于强调故事线或是全屏幕动画。游戏应该具有互动性，所以故事线与全屏幕动画只会把您从事件中拉开，不管它们是否品质超高。我很喜欢的世界是每个人都有同样的想法，而且我们可以同时抛开这二样东西。

 

布莱恩·雷诺：不能用键盘控制整个游戏的接口。鼠标接口是学习游戏的主要工具，但是强迫玩者一道使用鼠标，会让已经学会游戏的玩者的手兖。

 

威尔·怀特：我真的不喜欢重复使用全萤幕动画。从另一个角度来说，我试着不要在任何方面太武断，如果我很强烈的考虑想要一些新特色，那我会用开放式的心态来进行研发工作。

 

克理斯·克劳福：至少，慎重取用人类灵魂的高洁之处。

 

艾恩·贝尔：免费的暴力、控制很差劲的设计、幼稚的规划。

 

这个业界最大的改革者（如果有的话）是谁？

 

葛伦·克培斯：《俄罗斯方块》是一个令人难以置信的游戏：世界上的每一个程式设计师，都在自责为什么想不出这个点子，只要一个下午就可以把程式写完。

另外还有《地下城主》，第一个不用被骰子整得团团转的游戏。《地下创世纪》更提供了一个［真实］的世界，而所有id公司制作的游戏，都一直站在科技的尖端，而且他们仍有勇气维持最基本的游戏性。

 

威尔·怀特：《FS-1 Flight Simulator》，这是我买下的第一个电脑游戏，我惊讶的是我可以开着这个世界中的小玩具到处飞行。这是第一个PC上的飞行模拟（由布鲁斯·亚特维克――Bruce Artwick制作）。它是用线条图来表现，而且以今天的标准看来是十分原始的。不过，它还是有一个自给自足的时空，以及我可以玩得很高兴的物理规则。

《Pinball Construction Set》（作者比尔·拜吉――Bill Budge）：这是我第一个可以建造一些东西的游戏，我真的很欣赏它的界面（拖曳式）以及开放式的本质。PC游戏则在《模拟城市》的设计之中受到了不少的影响。

《M.U.L.E.》是一个可以提供经济观念（以及多人连线游戏）而且很好玩的游戏。另外，对于一个想要设计挑战与合作的游戏（换言之就是游戏平衡）的人而言，它也是一个很好的范例。

大部份的人再也无法玩到这些游戏，实在是太可惜了。

 

彼德·摩利纽斯：如果要找一个最近，让整个产业界有惊人的变革的，我会选《雷神之鎚》与《毁灭战士》。它很简单、让人难以自拔、让人肾上腺素激增，都是一个游戏应该有的特色。

 

大卫·培瑞：《大金刚》、《终极动员令》和《快打旋风》。

 

艾恩·贝尔：《Colossal Cave》、《银河飞鹰》和《俄罗斯方块》。

 

您觉得续集的制作是如何？

　　

艾恩·贝尔：简单。

葛伦·克培斯：如果有这个理由制作续集的话，十之八九都是好理由――包括我曾经参举过的几个案子。

 

迈克·迪斯克：续集在研发的角度而言是很棒的。您知道这个游戏长得是什么模样――里面做了什么东西。群众很清楚他们会买到什么游戏，但是制作续集也表示这个游戏不会走入一个全新的方向，更表示这个游戏已经不会有太夸张的未来。

 

大卫·培瑞：如果第一个游戏很棒，那就会更好。我痛恨、痛恨、痛恨笨拙游戏的笨拙续集。

 

克理斯·克劳福：我做过一个，但是对它没有多高兴。续集应该延后五年再推出，否则它们只是在顾客基础上再压榨一次市场。我正在考虑设计一个新的《帝国生死门》，它离上一个游戏的推出时间已经有十年之久，我想我应该是对的。

 

比尔·罗普：续集可能好，也可能不好。没有续集，我们可能再也看不到［异形］；但是反过来说，我们也可能看不到［时空英豪2］。基本上，一个续集是再次给您一个您曾经热衷的东西，如果您只想要骑上前一个作品的荣耀，您可以去试试。在Blizzard，我们爱上我们所建造的时空，而续集给我们一个机会，在这个世界中更积极的探索并制作相关东西。我们也很努力去追求，让玩者可以在续集中拥有更多的东西，并在续集中延续前作的成功之处，找出一个方式解决掉我们或是玩者讨厌的东西。

我想我们在《魔兽争霸：半兽人与人类》跳到《魔兽争霸2：黑暗浪潮》再跳入《星海争霸》（本质上的续作）是很好的例子。如果您好好看看这些游戏，您会看到基本的游戏主义仍然保留了下来，但是加入了游戏性、界面、图象、连锁关系以及更多的东西。如果设计人员可以利用原始的基础，靠着经验来制作更伟大的游戏，那他们就在创造一个我所想象的续集。

 

您会和您的下一个设计妥协，以得到较好的发行合约头款吗？

 

克理斯·克劳福：当然不会。我已经花了至少八年的时间试着成为一个饿死的艺术家，我为什么要打破这么单纯的特色？

 

迈克·迪斯克：如果您需要头款才能创造一个游戏，那设计就是一路被市场认知牵着鼻子走，出卖的就是设计人员的梦。

 

葛伦·克培斯：这不是妥协的方式。如果您觉得您真的想出一个很酷的点子，但是发行公司就是［看不懂］，很有可能是您没有良好的游戏设计，而只是过度的概念化。在设计的过程中，确定这是一个发行公司想要推上市场的游戏（也可以视为玩者想玩的标准）。

 

大卫·培瑞：Shiny的运气很好，我们会尝试各种不同的点子。我们的游戏是由自己人来设计的，您永远不会看到我们在做芭比娃娃的游戏。看看我们的《Stunt Helicopter》游戏(www.stuntcopter.com)，或是我们的《Baby Angel》(www.messiah.com)，也可以看看我们的多人连线生物游戏《活祭》(www.sacrifice.net)。

 

彼德·摩利纽斯：在平常的状况下，市场人员与发行人员在签下合约时，都有他们选定的观点。我想研发人员――包括Lionhead――应该都具有合理的弹性，只要发行公司能支援他们的需求来制作好点子就行。

 

布莱恩·雷诺：如果我知道我想要做的是什么产品，我有时会同意在一个产品或是类型上面更进一步；但在这之前，我们必须站在我们的角度中，一直维持游戏中的创意控制与游戏性。

 

艾恩·贝尔：这得看个人的财务状况。

 

未来

在一家网际网路公司（不是游戏公司）的创立酒会中，其中一个投资者问我，［为什么你们这些人不能做象《迷雾之岛》那样的游戏？我真的是很喜欢那个。但是其他的――《毁灭战士》、《雷神这鎚》、《古墓奇兵》都让我提不起劲来。］

当然，这只是一个人的观点。如果这个人并非恰巧是随手就挥动上百万美元的冒险投资家，如果没有强烈的商业证据证明这样的游戏与市场百分之百契合，这个问题很容易被人所忽略。

这个问题到最后就变成了［人们想要多少的互动性？］这并不象是电脑年代版本的维多利亚式家庭：把孩子放上床，插上Playstation就开始玩游戏。如果人们想要某种东西，他们会玩角色扮演，他们会加入戏剧团体，他们会去玩桌上游戏，而且每个周末都有神秘杀人案餐会。

当然了，忠实的玩者一向都存在。很多研发人员利用下面这句话来鄙视大众市场：［叫他们去看电视。］但是电脑可以提供的互动性，可以同时取悦于大众市场以及游戏为主的市场。这些将可以视使用者所需是，来决定他们要玩的游戏。简而言之，互动性不应该强迫玩者做出选择；它应该让玩者去控制他的选择。

我们会在第8章看看游戏何去何从。首先，我们看看这些导师级的人物在想什么。

 

游戏能停留在目前的局势，但能吸引不玩游戏的人？还是游戏得为他们另行调整？

 

彼德·摩利纽斯：游戏产业的未来大门甚至还没敲开。曾经有些象是《古墓奇兵》和运动游戏这样的东西，表现出为大型市场设计的游戏，一样可以为游戏老手所接受。这并不表示它们是［笨透了］的，而且把它们做得更容易让人接近。当这件事真正出现时，游戏客层将会很庞大。

 

葛伦·克培斯：我想游戏正在一点点的渗入主要的文化中。它无法阻止，但它也可能无法加速。除非您做的是一个运动游戏，否则游戏是无法马上成为主流产品的。

 

迈克·迪斯克：游戏的牙观太难看、过度复杂，而且需要太多的功夫才能进入市场。适合大量市场的游戏，不是超级简单，能够马上被人所了解；就是有一定程度的复杂度，而微妙之处超过目前硬体的能力。

 

威尔·怀特：我在想，它们一定在中间有交会之处。想象一些人某天走入Wal-Mart（译注：美国大型连锁超商）买了一套《猎鹿人》，因为他的朋友叫他买回家看看。他把它带回家，然后享受了一段不错的时光；这一切都简单而容易。现在他可能会在游戏方面更有自信，下次去买一些更行进的游戏。现在，如果回到商店中买下《悍卫雄鹰》这样，专为高等级玩者设计的游戏。

所以，我可以想象的是，在大众市场中的顾客越来越有电脑基础后，我们的产业将会朝这个方向迈进。除了最专业的游戏以外（其中散布一些象是《猎鹿人》这一类的游戏），我们最后会得到一个象钓钟般的曲线，而中央的高点就是中等级的游戏，可以让游戏初学者和高级玩者同时满意的东西。

 

艾恩·贝尔：游戏必须为非玩者的人做一番调整。

 

布莱恩·雷诺：我想这个问题是一个不实的进退二难，所以我猜我的答案是［不经常］以及［不准备］。在游戏市场中的玩者是十分明显的团体，而且工作人员可以藉由他们写游戏，而换得体面的生活；要把您的头一路轰进［大型市场］的高墙并非必要。在Firaxis,我们倾向避开［市场研发］，并以专注于我们想要玩的游戏来取而代之。我们可以假定，如果我们写出一些想要玩的东西，就会有和我们一样的人们，会来买我们的游戏。

 

比尔·罗普：答案是［双方都有，但是不多］。我们在Blizzard做出来的游戏，一向可以让游戏老手感到满意，而且不会孤立任何坐在电脑前面，想要了解［电脑游戏这种东西］的人。我们负担不起的是，把游戏设计成只为游戏高手才能玩的目标，目前以电脑娱乐为主的群众数量越来越多，而他们需要获得满足。不过，在这同时，我们并不需要在游戏中，以没有挑战性与不适合老手的方面进行妥协。

对我们而言，制作游戏是一门容易学习却很难专精的崇高目标；但是如果您能走对路，您不只可以看到玩了游戏一辈子的玩者在享受您的游戏，而且也会看到一些从没玩过的玩者。这一切都只因为二个字：［好玩］。如果游戏容易接近而且好玩，您会发现拥有电脑而想要找一些与科技奇迹相关娱乐的群众，数量将会不断的扩增。

 

大卫·培瑞：游戏需要为不玩游戏的人做一番调整。这就象PC上的游戏需要取得IRQ编号与DMA设定一样。您得让它变得很简单；然后您才会有机会为人们带来好时光。

 

克理斯·克劳福：游戏永远不会打破它们的常规。上帝知道我试着协助产业打破这个常规，但是我全面失败，而且产业界在这个方面十分坚固，我不会考虑再试一次。

在之后的十年，将会出现以说故事为主的互动式娱乐，但是我想它会在游戏中独立出来。您可以拿书店与漫画店来做比较。

对您而言，如果您可以选择任一个游戏的话，其中什么方面是您最喜欢的？

 

葛伦·克培斯：象《雷神之鎚》那样的火箭跳。

 

迈克·迪斯克：在《地下城主》中，当您的火炬烧光时那种深深植在您心中的恐惧，而且您在黑暗中被遗忘，只有怪物的声音在您和同伴身边环绕。

 

艾恩·贝尔：让人玩起来觉得活力十足的游戏。在这方面，我指的是一个游戏在玩的时候，附带了不必要的炫目效果――而在登上巅峰的风格之后，就是执行效率的问题。《Chuckie Egg》就是一个这样的游戏。

 

大卫·培瑞：在弹子台游戏中一次丢出多枚的球。在五枚球同时出现在台子上面时，您走开时一定混身大汗。