游戏策划 Design Inside

达达尼昂 | 资料收藏 |

什么是游戏关卡设计【转】

为了接下来几天的文章，先转帖一文。

来源：Gameres

 

游戏关卡设计

关卡设计这个名词和关卡设计师这个职业，是20世纪90年代中后期，随着三维射击游戏的流行应运而生的。因此严格地说，应该称之为三维关卡设计。在DOOM类型的三维射击游戏出现之前是没有这个称呼的，在游戏公司也没有专门的被称为关卡设计师的人。在8位、16位游戏机上的动作游戏（ACT）中也是有多重关卡的，而且当时的玩家被称为“闯关族”。但二维游戏的关卡总体来说还是比较简单的，因为是横卷轴或纵卷轴，场景固定，敌人也是事先地在一定时间从一定的地方出来的。而到了三维时代，关卡的复杂度极大地增加了，敌人（NPC）的智能也增强了。游戏时对玩家的要求也就提高了。对二维ACT游戏来说，玩家知道自己在什么地方，知道自己在向什么方向进发，知道下一个敌人将会在什么地方出现。而三维射击游戏，你可以向四面八方走，还有不同的高度层，玩家的方位感尽失。比之二维ACT游戏的单向卷轴（一维自由度），三维游戏，也难怪很多老一辈的闯关族找不着北了。既然三维游戏对玩家的要求提高了，当然对设计者的要求也提高了。当关卡设计的工作量和复杂度大到一定程度，关卡设计的工作就独立出来了，需要专人负责，关卡设计师这项职务也就诞生了。

什么是游戏关卡设计

　　简单的说，关卡设计就是设计好场景和物品，目标和任务，提供给玩家（游戏人物）一个活动的舞台。在这个舞台上，玩家表面上拥有有限的自由，而实际上关卡设计师通过精心布置，来把握玩家和游戏的节奏并给与引导，最终达到一定的目的。
　　[地形]
　　地形是关卡最重要的组成部分。地形是指室内或者室外的建筑和地貌，抽象出来就是多边行拼接在一起的一个中空的空间，玩家就在这个空间里面漫游。母空间之内又可以分为几个相互连接的子空间。

　　关卡设计的重要性在于它是游戏性的重要组成部分。游戏的节奏，难度阶梯等方面很大程度上要依靠关卡来控制。

游戏关卡设计要素

关卡由以下几个要素组成：

　　关卡设计实际上就是对空间的规划，特别是建筑物内部空间的规划。除了几何形体外、还要考虑内部装饰、灯光效果和人在一个三维空间内的感觉和行为模式，这些东西显然和建筑学的很多方面有重合之处。目前的关卡设计师们已经考虑有意识地借鉴和研究一些建筑学方面的经验和理论了。
在三维游戏刚刚兴起时没有对计算机处理能力的局限，大多数关卡都是在建筑物内部的狭窄空间内。随着计算机处理能力的增加和各种算法的优化，在新一代三维游戏中室外场景和自然环节变得更常见了。

　　[边界]
　　边界是一个关卡必须的组成部分。关卡不可能无限大，必然要有边界。关卡的大小和完成关卡所需要的时间有着直接关系。一般来说，关卡之间是不连通的，只有完成了限定的任务才能进入下一关。部分边界可以是关卡之间相连的纽带。

　　[物品]
　　各种物品，包括武器、加力、补血等作用。在关卡中，各种物品的安排和布置可以对游戏的桀纣和那怒视起很重要的平衡作用。这些物品的安置完全是靠经验通过不断调整才能获得最佳效果。

　　[敌人]
　　同物品一样，各种敌人在关卡中出现的位置、次序、频率、时间，决定了游戏的节奏和玩家的手感。早期动作类型的游戏中，敌人不具有智能，起行为被预先设定的死死的，每次在同样地点或者在样的时段出现。游戏设计师则具有完全的控制能力，通过细心调节，可以完全设定各种敌人出现的位置、次序、频率、时间，力求达到最优。那时候游戏性令人怀念，很大部分就是这种控制和调节的结果。

　　在三维射击游戏问世后，NPC的概念得到发展，人工智能越来越得到增强。敌人出现的时机和行为，不再是事先规定的死死的，而是在一个大的行为系统和人工智能的指导下，有一定的变化和灵活性。这给传统动作游戏的游戏性反而带来了一些麻烦。游戏设计师这时候已经失去了对关卡中敌人行为的完全的控制。如何利用有限的控制能力去实现最优效果，是摆在新一代游戏设计师——关卡设计师面前的难题。关卡设计师这时必须和人工智能程序员合作，使得游戏既富于惊奇变化，有具有一定的平衡性。

　　[目标]
　　一个关卡，要有一个目标，既希望玩家通过此关卡而达成的任务。目标也可以有一些子目标，子目标相互之间成为串联或者并联关系。目标应该明确简单，毫不含糊。

　　[情节]
　　情节和关卡之间的关系可以多种多样。两者之间可以没有什么太大的联系，比如说早期的工作游戏。也可以通过过场动画交代情节背景，特别是通过过场动画使玩家明确想一个关卡的任务。更可以在关卡进行中加入故事要素，使得玩家在游戏过程中得到某种惊喜或者意外。

　　[大小]
　　进到关卡的大小，不仅仅指在玩家眼中关卡的大小和复杂度，更重要的是实际文件大小，比如材质文件大小。噶设计师在设计关卡时对各种文件大小的问题主要得很多，因为这涉及到是否关卡哭被最终实现，特别是游戏的实时性能。

　　[视觉风格]
　　关卡的视觉风格，体现在地形设计、材质绘制、光影效果，色彩配置的组合。

　　[关卡设计流程]
　　正如一切设计活动一样，关卡设计需要一个流程（process）。设计流程的作用是保证每个关卡按时完成，使其质量具有连贯性，并且利于协作交流。

　　[目标确定]
　　关卡设计的第一步是确定目标。目标基于任务，也就是前面所介绍的一个关卡所要玩家达成的任务。目标是从设计者角度看问题，而任务是从玩家角度看问题。目标可以有对角度，多方面，比如“此关卡一般水平玩家将费时10分钟”，“此关卡将使得玩家得到XX报宝物。

　　除了确定目标外，还需要初步了解技术上的限制，比如材质文件的大小，多边形数量的限制等等，除了技术上的限制外，还有其他非技术的限制，比如进度要求。

　　目标和限制相互作用。设计者要动用一切手段达成设计目标，但各种技术上和非技术上的限制使得设计者必须做出判断和一定的牺牲。所有的设计活动都是两者牵制作用的结果。

　　[集体讨论]
　　在明确了关卡的总体目标和具体限制后，就进入集体讨论阶段。一般是由所有组员（包括关卡设计师、美工、和程序员）聚集在一切，就关卡的地貌、标志性建筑关卡中的各种物品、敌人的特性等进行讨论，在白板或者纸上迅速地进行勾画。在集体讨论阶段，鼓励各种奇形怪状的想法和点子，所有的想法都可以提出。对这些想法，要马上做出取舍和判断，而是记录在案，留到下一个阶段。

　　[设计概念]
　　在集体讨论后，关卡设计师得到很多好的想法和启发。他把那些想法进行初步的取舍和综合。概念设计既是把设计师头脑里的设想句土化、可视化。在纸上或者其他媒介上表达出来。如果关卡设计师自己就能具有很好的速写能力，他可以自己动手。如果设计师本身没有美术技能，他需要和美工紧密合作，相互交流，共同把设计师头脑中的想法推绘出来。

　　这阶段关卡设计师和美工可以使用概念速写、二维平面图、关键地段的不同角度的速整体效果渲染图等等老完成可视化（visualization）。

　　[观念评估]
　　在各种概念速写完成后。整个小组可以进行初步的评估。全体组员坐在一切，利用各种图片，在关卡设计师的讲解下，把关卡整个过一遍，看看起整体感觉对不对，发现一些明显的问题和疏漏。

　　[使用关卡编辑器]
　　经过反复几次概念设计和概念评估后，关卡设计师可以开始在计算机里使用关卡编辑器构建关卡了。一般来说每个公司都有自己的美工制作流程。取决于制作流程的规定，关卡设计师和三维美工（制作三维模型）和二维美工（绘制材质）必须搞好协调，前后衔接。流水作业。

　　[测试]
　　关卡设计出来后，必须经过不断的调节和测试，以求达到最好的效果。三维关卡基本成型后可以进行对人参与的共同评估（walkthrough），将关卡浏览一遍，看看基本感觉。关卡、怪物和其AI脚本（script）集成后更可以进行更复杂的可玩性测试（playtest）。

达达尼昂 | 资料收藏 | 2009-03-12

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

达达尼昂 | 资料收藏 |

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

电脑游戏结构与设计 

第十五章　疑难排解

 

＊风险

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

＊变更控制

＊突发规划――［B计划］

＊公制与资讯的收集

＊灾难重建

 

在这个章节中，我们打算看看您的企划中，究竟有什么事会――而且可能性极大――把您搞得难飞狗跳。一般的企划只是一个单纯、等候发生的错误列表：时程表的错误、程式码的错误、过时、个人的问题与疾病――只要您想象得出来，就有可能发生，而且不要惊讶！不经一番寒彻骨，哪得梅花扑鼻香。您可以把企划安排到无微不至，但是您无法安排未知的事情。

 

疑难排解（名词）。追踪并修正组织中的错误，等等。

这个章节是叫［疑难排解］没错，但是所佔的大部份都是在提供建议，来预防可能需要的疑难排解。最具有成本效益的企划，是以高水准软体开始着手，而不是先建一个低水准的软体，然后再来修正问题。

就算是在一个执行上十分完美的企划中，还是会跳出没有预料到的问题。而成功的小组与失败小组相比较，差异就在于他们对这些问题的掌握与规划的功夫。

好，我知道您想说什么：您怎么可能不知道的事情做规划？如果您不知道会发生什么事，您又怎能先做预防来修正它？呃，说实话，您的确办不到。如果我试着告诉您另一个答案，您就知道我在撒谎。

没有人可以看透未来，所以没有办法知道您的企划会碰上什么样的麻烦。不过，您知道有些事情必然会发生。只有最天真的企划管理者，才会假定一个企划会顺畅而没有任何麻烦的进行下去，一直到结束为止。不管您信或不信，我曾经碰到过这处管理者――我认识一位此一类型的管理者，还会去相信一个长达18个月企划，可以在9个月的时间中完成。他一直抱着这个想法度过了前面七个月，这时急得不得了的发行公司来重新审查合约，让这个问题重重的游戏，在二次续约以及一年之后才发行。

这一类难以接受的情况，发生的次数实在相当多――尤其是在游戏产业。为什么？我相信这是因为游戏产业缺乏普遍规划能力所造成的结果。

整个游戏产业都很不成熟。在主机的世界已经进展到进行庞大的企划，包括了广大的小组以及上百万条的程式码时，游戏产业还在拔乳牙的阶段。在今天仍然有人采用这些大型企划处于测试期时所产生出来的结果。当然，有些更会挖苦的人将把这一点，归功于把它们拔掉不如让它们继续运作来得省钱。在某些程度下可能是真的，但至少他们仍在运作！那些无法运作的呢？

不过，游戏不象其它有20年生命周期的产业（虽然我很确信有些设计者会喜欢这种状况），所以规划与安排时程的时候，不需要象其他方面有完整的学问。事实上，由于一般游戏的生命周期很短，象这一类有组织的施行细则并非必要。

但是，随着戏曲开唱，在时间中产生了变化。游戏企划的规模越来越大，再也不是一个小型的工作，可以用少数的平台让单一的设计者制作出一些可以迎合大孩子口味的东西。今天，到处都是动作捕捉、全萤幕动画、电影品质的音轨、电影水准的美术，以及更多的多边形。

有些人把游戏产业拿来与当代的电影工业相比较。它可能只是少数人无法接受他们只是软体工程师时，所发展的罗曼蒂克谈话内容：这二种产业的相似之处，在仔细的观察与分析之下不攻自破。

平心而论，我可以看出相似之处。不过，与大部份的软体企划不同之处，在于他们比起游戏研发有更大量的艺术元素。这些特别的元素最适合的部署地点是在电影工业，而且电影与游戏之间仍然有很大的差距。电影主要是艺术――它们的确有很多技术方面的要素，但是在有所需要的时候，是靠着外来的力量来进行有效而顺畅的控制。除此之外，并不需要大量的科技研究，与游戏研发是不同的。

不过，一个游戏企划对这些制作艺术、全萤幕动画与音乐的需求，就和电影工业不一样了，而在这方面就是模仿电影工业的重点：电影的制片通常会从外面的其他公司找寻他们的需求，而不是把规模限制在昂贵的编制内小组。

如果游戏研发可以真的与电影工业相比，那是不是可以象电影制片一样，雇用新的工程人员、在每一个企划中安置新的摄影机、重新研发赛璐璐，并修正所有的软体？不是，今天的电影工业并不是一个好的比喻（虽然过去的电影工业，也就是技术仍然很简单的时候，勉强可以拿来做比较）。

今天的电影工业已经渡过了这一连串的磨牙问题。它十分成熟，而且再也没有什么需要进行的基础研究。它已经完工、平稳而且撰写出相关的文件。电影工业已经达到一个平坦的区域，所需的科技稳定，而且电影画面中的［目标平台］一般而言已经很调和并不会变动。想想看：除了（应该不会错）微小程度的改善之外，电影在数十年来并没有太大的变化。

游戏产业并无法达到这种类似的地步。科技不断的演进，所以游戏的科技从来没有稳定下来，连游乐器也不例外。看来每过个几年，就会在技术方面出现巨大的进展；这种由摩尔（Moore）预定的著名［定律］（指电脑的能力每18个月左右就会提升一倍）并没有慢下来的迹象。我并不期望目标平台会趋于稳定，虽然在一个隔离的层面下，象是DirectX，可以提供一些轻微的缓冲；阻挡研发人员马上采用新出现的科技。不过，DirectX也是年年更新，才能跟得上科技。

我猜，如果这一切都在继续的前进，有一天就会出现一个产业标准的游戏研发工具，包括了所有需要的元件（象是图象引擎、人工智慧引擎、描述引擎），可以让完全没有技术能力的游戏设计者，直接产生出一个游戏，象是电影导演在拍电影一样。游戏设计者可以从外面取用图象、音乐，而且甚至可以购买人工智慧模组，来扩增目前正在进行的游戏设计［描述］。在那个时候，很可能有不同的包装，适用于不同类型的游戏，而不是目前任何类型演进而来的（举例来说，第一人称的3D视角，并不是一个多单位策略游戏的理想平台）。

不过，目前的游戏研发仍然是以工程为基础，限制了艺术方面的看法。如果有任何现代的领域，可以有效的与游戏产业做比较的话，应该是建造桥樑。在建造一道桥梁时，设计图必须先画出来，工作必须按照时程表来完工，而且偶然的规划必须十分严肃的进行。当然了，盖桥与游戏研发的不同之处，在于桥梁的建造者如果不够小心，可能会影响到其他人的身家性命。

不管是盖桥或是游戏研发方面的学问，都是以［艺术工作］为最后的结果，而且二者都需要广泛的规划，才有希望在时间与预算的压力之下完成。

当然了，如果盖桥象研发一样，可以让负责的人员突然丢下他们的工具，成为桥梁的设计者，那什么桥都盖不成。您可以想象一道桥梁在建造时集合一百个工程师，每个人给几百吨的金属和一些工具，然后在完全不规划的情况下叫他们开工，只让他们知道这座桥盖好时长得象什么样子，然后含糊的告诉他们桥梁要延伸到河流另一边的什么地点吗？这是［地狱建筑］学校中的盖桥法吗？我不这么认为。这种方式从黑暗时代之后就没人用了！或许，如果游戏研发中的一项要素是人的生命，那就会比较注意一点！

不管怎么样，您可以用二种常见的方式来面对问题：在它发生之前，或在它发生之后。现在，哪一种比较好？

虽然我真的很想在这方面撒谎，我必须承认要预测并事先看出所有可能出现的问题是不可能的；老实说，这种方式也不值得建议。要面对着资助者解释［为什么偶尔落下的流星刚好把他的钱砸得一干二净］这件事，对一般的企划规划人员而言可能有点困难。

管理者有时候可以了解您为什么想要在一些可能永远不会发生的事情上面花钱的原因。他们可能会称呼您为扫把星或是末日杀手。不过，您应该坚定立场。这些突发性规划行动所耗费的额外工作，将成为您企划中的［保险］。

您应该向负责的人解释，几乎每一个企划中都有一定程度的风险，不管是过去或是今日，而且忽视掉这些教训，将是您手中企划成功的最大风险。在花费一些小量的努力，为这些问题建造可以回复的保证，您就可以彻底的增加企划成功的机会。

在找寻潜在问题方面，最好用各个不同的观点来查看整个企划，并尝试分辨出哪边可能会发生问题。它可能是一个实验性的结构，一个有风险或是未经证实的技术、人员的短缺、资金的问题，或是其他类似的困难（这将在本章后文中详细描述）。

这些情况不可能先行规划，必须靠着理性的方式来解决。

有些事情实在是太奇特而超出预想，而这种现象必须纳入考量。技巧是找到这些问题的主要基础，象童子军一样，先行准备。

到目前为止，我们已经确立了二种疑难排解的方式：主动与反应。主动式疑难排解自然比较受人青睐，但却不一定可行。反应式疑难排解通常不是最好的方法，但却不一定躲得开。

反应式疑难排解比较常被人称之为［救火队］，或是任何表示［问题在已经浮现作乱时才被发现］的词句。在这个时候，当然了，这个问题已经影响到企划。疑难排解的有效程度视您的侦测问题能力而定，必须在它的效力太大之前把它解决。

不幸的是，侦测这些问题通常都不单纯，而且有几个理由。第一个是因为太过熟悉而变得盲目；当您在同一个企划中日复一日的工作，重复相同的事情，眼光变得狭隘是很正常的事；有时您只是没有注意到问题在您身边爬来爬去。除非您可以在一切都太迟之前把问题找出来，在您发现的时候它可能已经大到您无法忽视的程度了。

第二个理由与担任管理者人员的名声有很大的关系。人们愿意告诉他（或她）问题所在吗？管理者会砍杀来使吗（译注：二国相争，不斩［来使］）？这是为什么管理者的行为特质要很容易亲近的主因。

如果这听起来象是一个您认识的管理者，那么他（或她）不知道早期发生的问题是很正常的。明显的，这是一个缺点，这不会让小组尽快把裂缝补起来，并把问题先拿出来解决。有时一个不具名的回报管道可以避开这个现象，但是这样的系统，必须看提供者的可信程度而定，因为所有人的名字都不会列出来。

很悲哀的事情是，企划管理者在突发性的规划中并不够认真：而且证据到处都是。游戏不断的遭到取消或是延期，而且在它们发行时，通常只具有次等水准而且充满了臭虫，需要数次的更新档才能把游戏带到一个可以接受的标准，这些都是没有好好进行突发性规划的征兆。游戏之所以延期，通常是在被动式疑难排解下的牺牲品。没有办法预见问题并进行处理，而且这些问题在出现之后，就急着把它解决掉（一个比较容易了解的比喻，就是在马匹狂奔时把马廄的门关起来）。

还有更糟的，许多管理者没有能够好好进行突发性规划，让一个企划在这方面没做多少事。事实上，突发性规划的目标在于拯救时间与金钱。藉由为另一个可能浮现的问题，准备另一个解决方式，就可以评估并准备好这个对企划的冲击。所以，这个企划才能获得回复的能力。

这个章节的重点在于把这个悲惨的状况好好整顿一下。如果在您那众所皆知的［制作小组］真的伤害了爱好者时，这些指引方针与建议可能救不了您的企划；但至少它可以让您先蹲下来，并在事发之后沿着准备好的路线飞快逃走。

 

风险

当您在处理企划的时候，最重要的事情就是考虑免不了的风险。在您进行企划的每一天，您都会碰上新的风险，需要小心的监看并查核。这个部份将会给您一些提示，告诉您如何实施一些合理而实际的风险管理计划，才能尽可能的避开这些风险；并在避无可避的情况下，控制整个局面。

在现今的软体研发企划中，风险管理（如果有的话）并没有发挥实质上的功效。这并不是说没人在考虑这件事，在不同的方法之下，普天下每一个企划都考虑过风险的问题。不过，他们通常被认为是另一个过程，而且没有指明它们的地位；通常不会有人直接去面对风险，而是采取次要的行动来处理它。

这种方式对企划管理者与他的小组而言，风险仍然是附骨之蛆；一直到风险大到足以妨碍正常的工作时，才会直接去面对它。因为没有人去正视它，风险都是在危及另一个范围中的工作才去面对。举例来说，当一个企划管理者在安排一个时程表时，他也会查看这个时程表延期的风险，以及一定程度之下的人事问题。当一个研发者在撰写程式码时，他也在查看程式码资料库中出现臭虫的风险，并检查任何已经存在的问题。风险只有扩大到另一个区域时，才会被处理到。

不过，从这些丰富的例子中可以看出：由于在一个工作范围中风险从来不会被指出来，到目前为止已经不知道有多少没考虑到的，掉落而穿入裂缝之中。这就是为什么风险管理的范围是如此重要，每个人都应该谇为它该拥有自己的地位。

在您试着把一部份的企划劳力纳入风险管理时，您在这个过程中会进行得比什么都顺利。在一个不假设会出现风险的企划中，企划（以及小组）通常是以外来观察者（有时也会成为内部的观察者，然后您就知道这个企划真的碰上了大麻烦）的地位，看着一个个危机把它弄得东倒西歪，一直到所有的动力耗尽；接下来可能是跑不到终点线，或是在不幸之下懒懒散散，从此销声匿迹。

风险管理的目标是让整个企划的路线平顺，就算是行经汹涌的海域也尽可能的愉快。在图14.2中说明了这个要点。

风险管理是一个具有特定地位的学问，需要格外的重视；但是如我之前所说，它通常被人们所忽视。所以，您要如何在您的企划中，教导人们使用一个风险管理的程式？

第一件事是想出在哪边――以及如何――看待风险。这是一个实际上的工作，所以您应该严格考虑指派一个人成为［风险审查员］，让这件事成为他（或她）工作的一部份。这个职位可以每隔一个星期、二个星期或是每月，由不同的组员来担任。

风险审查员的工作就是对任何可能威协到企划的东西保持警觉。风险审查员应该紧密的监看每一个企划的［正面］，而做这件事的好方式是不断的更新［前十大风险排行榜］，这至少应该每星期更新一次。在这个列表上应该排定风险的优先顺序，并以它们的困难程度来分级。

在一开始由于心理效果的影响，这方面通常是正向的。这种持续找寻风险并在风险出现时面对它的现象，将会鼓舞一个小组的士气。任何可以鼓舞小组士气的事都是好事，不管这个方式是否直接。

对每一个列表上面具有高度优先权的项目，应该决定出一个决议；而且在这个小组有可能处理并消除风险时，列为最优先的事项。在一些情况下，在面对一些更没有预期以及更极端的风险时，就有必要从雇员中组织［攻击小组］，把他们从原有的工作拉下来，处理这个问题。

这将会是一个很吓人的提议，而且它需要以十分小心的方式来控制，才能避免让人们惊慌失措。有时候，在很不幸的情况下，这种形式的正向行动可能被视为负面的征兆。人们将不会以［有效反应企划中所需的变更］来看待这件事，可能在资讯贫乏的情况下被视为［无头苍蝇］。任何有这种反应的人，都需要再度进行教育，告诉他们您想达到的是什么目标。

说得公平点，如果风险管理计划没有小心想清楚再实施，那它可能退化成为没有目标的攻击。如果只用琐碎而不必要的行动来处理表列的风险，它可能会让人们从企划中所需的真正工作中分神。在任何行动实施之前，提议的风险控制计划必须由相关的团队来进行批准，而影响的范围将视风险的本质而变化。举例来说，如果风险包括了改变部份的系统，那么它就会指向全面变更控制。

风险审查员的工作可以总和成一句话：他（或她）是那个在企划每一个地方嗅出问题的人。他（或她）的效率是以挖出这些麻烦，来节省未来耗费时间、效率和（最重要的）金钱来计算的。

下列的列表，是此类事情的范例；也是您很可能在您的前十大列表中出现的内容。

 

企划X：前十大风险列表

1．目前实施的资料封包编码演绎法在即时的网路上面太慢。如果我们要把它拿掉，这将导致我们的点对点网路游戏，暴露在被人入侵的情况下。

2．主要人物的美术工作要花太久的时间。动画程式设计师被贴图数量不足，以及这些贴图的相关资讯卡住。

3．小组被地图设计工具的延期卡在半路上。我们需要尽快开始设计新的关卡，否则我们会落后时程表。

4．一个新版本的C++编译器刚刚出现，这需要进行分析，看看是否修正了任何我们企划中会出现问题的部份。

5．在图象绘制模组中有一只臭虫，会导致画面在每几格之后碎裂。这并不是致命性的错误，但是已经引人注目而且很烦人。

6．没有足够的人员来完成目前的工作量。我们开始出现工作时数不够的问题，而这对士气有不利的影响。

7．我们目前得使用的压缩模组都是臭虫而且很难维护。在测试中已经显示出它的压缩错误率很高，会毁掉上百位元组的资料。

8．3D绘图模组刚刚被核心小组更新，而且我们需要修改一些程式才能使用它。这方面的好处在于画面的更新更快更平顺，而且支援了最新的硬体功能。

9．我们需要一个新的组员――这件事越快越好，才能让他开始上工。这应该可以减轻第6贴图的问题。

10．人工智慧模组所需的测试，得在新的功能中加以更新。我们想要使用里面提供的全新的模糊概念逻辑，因为它可能有助于加强敌人面对玩者的人工智慧。

 

并不是表上的所有要点都有价值或是值得尝试，而且它们的顺序也有争议之处。有些风险可能是风险审查员的个人意见（这就是这个职位有轮替必要的好理由之一，或者至少先在一些人身上试试看，是否能够公平不倚）。

问题演变成哪些有必要处理，而哪些并不是主观的意见，与企划目前的状况有很大的关系：不同的优先权将会视目前的状况而一一浮现出来。举例来说，最优先的事可能是先把游戏做好；在这方面，企划管理者可能不想在这个阶段，冒险引进新的技术（象是新的3D引擎，如同3D　Realms所做的事情一样，将《Quke Nukem Forever》这个冒险的程式引擎从《雷神之鎚2》引擎换到《魔域幻境》的引擎）。某些管理者会考虑平行研发方式，其中一边使用老式的引擎而另一边用新的引擎，来预防他们下错赌注。如果新的引擎成功了，而且这二个程式库并没在过渡时期差得太远，就可以继续做下去。如果程式码资料加全面分离，那这个整合步骤就成为一个很大的风险。在这个理由下，我不会建议任何人冒这种危险。这种要保住二边努力成果的事情，只有最勇敢（或是最愚笨）的人才会做。

不过，如果企划还没到最后的阶段，那一个新的3D引擎可能就是第一优先。在游戏的发行日期，技术已经更为行进，所以它在最新技术的支援下，将会在商场上面更具优势。推出用老式引擎所撰写的游戏，可能会让游戏看起来与其他货架上的东西差不多。任何在3D引擎方面的问题，都必须在发行之前解决掉，所以在列出这些要点时，很可能已经得到最高的优先权。

在前一个列表中的项目，可以分组成数个类别，以他们影响的区域来分类。这些区域并非包括一切，而是包括了问题的主要部份，影响到每天的企划进行。其中有些是风险审查员找不出来的，因为他们影响的是比较高层的管理。有些人必须在公司的层面看着所有事情，但是这部份通常对管理而言不致于太困难，只是请他们把这些事情看清楚一点而已。危险的区域比较倾向企划层级，这个地方人人都在忙着手中的树苗长成森林，或甚至是挥舞着炼锯的伐木工在他们之间来去。

下列的几个章节，将会讨论一些此类的风险，并提出他们如何证明自己能够掌控的范例。

 

设计与结构问题

一个企划中的程式与设计问题，可以说是最诡诈而且最难以处理的。这在每一个企划的根源与基础都是难题，而且应该在可行的时候尽快把它处理掉。

这一类的问题具有的潜在能力，极有可能会导致企划全面修正。很明显的，这会十分的花钱，所以这将是您要极力避免的问题之一。

变更基准的要求

变更他们已经签定的正式需求，可以导致一个企划中的功能，在整合与契合方面出现问题。

这些变动可以靠着数种不同的方式显露出来。有时候它们会因为小组中的人员提出了［好点子］（通常是由个性最强的人所提出，而且这些人会采用强而有力的个性，试图强迫他们的点子获得所有人的认同）。使用变更控制的会议有助于降低强势个性，但偶尔在强迫取消这些点子时，也会导致这些人不满。

当然了，有时候有其他的理由：发行公司或是外来的组织（象是一个评议会议或是主要的发行公司）会要求变更（举例来说，要求游戏中出现的血腥场面少一点）。这一类的要求通常与财务的问题有关，象是通路商拒绝发行这个游戏，或是发行公司（也可能是评议会）会阻止发行。不管是哪一种，通常只有一个选择，就是跟着路线完成他们的要求，不管设计者与小组有多么不喜欢他们的大作被人稀释！

 

定义拙劣的需求

如果需求被定义得很拙劣，它们很可能完全不符合这个企划。如果是这个状况，很容易确信的一点就是未来需要重新定义一次，才能弥补这些缺乏的东西。

对于缺乏需求的定义与再定义，很可能增加企划的范围；如果范围真的扩大了，那它就很可能（事实上通常都会）得修正已经在进行的工作，才能符合这些新的需求。当然了，您永远不可能在进行结构设计之前定义出所有的需求，因为有些事情在您插入真正的工作之前，永远都不会知道。

重点是至少要先定义出80%的需求，而且在任何人真正进行结构方面的工作之前，是越详细越好。最好的情况是真正进行建造的工作之前，至少要完成80%的结构与定义得很详细的内容。

不过，有时候设计与结构已经做了最好的定义，一直到突然出现额外需求。这种情况下有几个可能，而且我很确定您可以想出更多。某些理由可能是发行公司要求额外的特色，或是一个类似的游戏已经出现在市面上，导致您［必须］有些别人没有的特色――象是让您的产品拥有一些最先进的特色（如果之前没有规划的话）。一个例子就是要加上多人连线的功能，不过现在的游戏应该都支援了。

在这一类的情况下，通常埋头苦干来完成这个变更以外，没有其他的选择。有时候不把程式码与模组全面修正，是不可能达成这些要求的。如果这一类的修正在财务、合约或是时间的压力之下变得不可行，那这种情况的出现，通常会导致企划全面取消。不过，有时候这个状况可以利用保证推出更新档案，来修正其中一部份问题来抢救。照我的看法，这并不是真正的解决方式；它只是一个紧急应变的海市蜃楼，先把产品推出来再发行第一波的更新档，在社会大众的眼中会产生负面的效果，进而伤害您公司的名声。不过，如果二个选择分别为［先找出游戏再推出更新档］与［完全不发行游戏］，那么在100个案例中，99个（我不是在强调那个例外）会选择先丢出去再挨骂！

真正能够预防这类混乱的方式，就是先尝试收集您会面对的大部份详细需求，然后再开始进行结构设计，才能佔有领先地位。当您这样做的时候，其中一个用来计算不断增加需求的最好方式，是在后期指派一个工作，强迫去查看这些需求中有些什么东西，然后试着去预期往后的什么方向可能会继续延伸。这并非表示您要在这个阶段，就把这些可能性建造在您的需求之中；但您至少要好好考虑一下，让真正的规格需求有可能纳入这些特色，并将这一点转入结构的规格中。

每一个扩张的潜在性，都应该认为有三种可能的结果。第一种是这个潜在性的需求可能十分重要，所以必须纳入实际的需求之中。第二种结果是，虽然这些需求并不重要，但它应该有一席之地，而且结构应该以可以容纳它的方式来定义。第三种结果是这个潜在性的需求，在努力完成之后也不会增加真正的价值；这种东西就是大家熟知的［润饰特色］，一个有了很好、足以加强产品的东西，但是它的成本效率太高，让您完全不会去考虑它。

其他的问题可能发生在设计与结构的阶段，由于对80/20规则的误解（这边是指某些人宣称一定要完成80%的工作，才能进入下一个阶段）。您不可能完成整个设计与结构背后的理由，只是因为您需要的一些详细状况只有在动手之后才会知道。尝试着去完成所有的纸上工作是个愚笨的决定，因为您没有办法预期元件之间会造成的相互关系（其他的章节将会说明相关的理由）。

如果误解了80/20规则，下一个阶段有可能太早开始。在产品说明中的模糊部份，可以预期它会耗费更多的时间来进行。

模糊的说明会产生几种冲击，第一个而且是最重要的效果，就是行程表会受到相对的影响。如果企划目前处于很紧的时程表之下，没有空间可以进行这些事情，那就会成为严重的问题。第二个模糊需求说明的负面效果，在于可行的解决方案不一定能和系统的其他部份相容，或者甚至无法运作！在这种情况下，就有可能修正部份区域中的工作。

在一些理由之下，研发者的天性会倾向低估他们在未来的工作时间；这些理由的数量很多。来自同伴的压力也不容忽视：可以在很短的时间完成复杂的工作，也是让人觉得很酷的特色之一。第二个考量，是管理者不愿意经常听到研发者老是在讲他做的是一个［公平的估算］。在案例研究14.1中，说明了［对牛弹琴］的情况。

 

案例研究14.1　听不到的管理者

［这真是有趣的情况，］福尔摩斯（Holmes）说，［我是指听不到的管理者。］

［那真奇怪，］华生（Watson）一边说，脸上一边浮出了疑云，［我怎么一样也想不起来。］

华生坐回他的椅子，这时福尔摩斯详述了他与佛瑟基尔（Fothergill），一个资深研发人员的故事。

［佛瑟基尔正在为欧洲的客户，在一个复杂的应用程式中做一些修改的工作，］福尔摩斯继续讲下去。

［继续，］华生一边说，一边在迅速的在记事簿上面挥毫。

［这个顾客指派了一位管理者，史纳德斯（Snodgrass）；没有人知道他的技术能力，但是他最出名的就是没有耐性，而且最有名的能力是靠着脸色变紫与爆裂般的言语，让其他人不得不同意他的话，以免他炸成碎片。］

［在这个应用程式中的一部份需要加以扩展，而且整个新的模组得重新研究、设计并重头撰写，当然了，这个工作落到了佛瑟基尔的头上，因为他是研发者之中最资深的人员。］

［这个工作是由史纳德斯指派给佛瑟基尔。佛瑟基尔拿到了备忘录，简要的看了一下，然后把它放在桌子的另一边；那个时候他正在进行一些非做不可的繁忙修改工作。］

［真有趣，福尔摩斯，］华生说，［那史纳德斯对这件事的反应是什么？］

［嗯，很正常的反应，华生。史纳德斯在这个案子中充份表现了他的性格，］福尔摩斯回答，［他想要知道，要完成这个工作要花费多少时间。］

［而回复是？］华生问道。

［佛瑟基尔说他不知道，因为他还没有好好看过文件。他请史纳德斯在第二天的下午再来问他，这样他才有时间以怀疑的眼光，好好找出文件中的问题。］

［一个很合理的答案，福尔摩斯，］华生表示，［这个佛瑟基尔一定是位很有原则的人。］

［嗯，的确如此，］福尔摩斯回复，［不过你听听下面的。在第二天下午，史纳德斯的确去找佛瑟基尔，并问了同样的问题。而且――如同你刚刚的问题一样――他的回答是，在看过相关的文件之后，他相信他应该可以在三个月左右的时间完工，而其中预估的错误解决时间差不多要一个半月；换之，他说应该最少花一个半月，最多四个半月，而最有可能的时间将是三个月。］

［很有趣，福尔摩斯。那史纳德斯如何回复这一点？］华生询问。

［他这样回复，］福尔摩斯回答，［史纳德斯微笑，并说他十分高兴佛瑟基尔可以在一个半月的时间把它完成。佛瑟基尔被吓呆了。这时史纳德斯已经离开了犯罪现场，向他的老板回报好消息。］

［这个结果真的太让人不满意了，福尔摩斯，］华生惊愕的表示，［在这种鄙俗的手段之后，有进行任何方面的研发吗？］

［只不过是史纳德斯在花了三个月再加上一个星期的时间把工作完成后，在他的老板面前看起来笨拙无比，］福尔摩斯微笑着。

在这个有点想象性质的真实事件中，指出了一个重点：一个很危险的人，只会听到他们想要听的东西，而且他们会在他们规划时去责怪其他人的错误，但这却是以他们听进去的东西为基础。

 

在案例研究14.1中，虽然它的表现方式并不那么真实，但却是塌实而不幸的事件，而且经常发生。

除了缺乏详细规格相关资料与实行时的需求，不可能正确预估出时间长短以外，参与的研发者仍然给了最有可能的评估。管理者选择接受较低的范围，主要是因为它更适合他的目标，然后忽视掉最精准的预估值，除非在一连串的好运重叠之下，几乎不可能达成目标。

这些现象不只会降临到一个企划，让结构与设计的阶段中出现困难。在上一个状况中，很明显的是在设计与结构的领域有模糊的现象，而且没有人遵循80/20规则。

不幸的，当设计者或是结构师在制作出一个过度简单的设计时，运用80/20规则并无法侦测出来。一个太过简单的设计无法充份处理主要问题，必然会导向一个有企划必须加以修正与重新施行，以更为强大的型式来符合需求。这是一个很难查出来的问题，在设计太简单时会很不明显，尤其是在游戏设计的状况下，一个过度简单的游戏却在过程中花费很长的时间，而这部份通常是由于延长的游戏测试。

唯一可以避免白白努力二年的方式，就是多做一些努力，采用原型的方式把问题找出来。做一个模型对游戏性通常都有正面的帮助，它不需要十分奢侈、快速或是详细。在我的许多个企划中，我甚至没有想过要利用电脑来制作初始的游戏原型，而是采用手中的材料：铅笔、纸、积木、玩具车等等。

这个技巧在其他的案例中也很成功。您的脑中并不会马上弹出合适的名称，但是一些在PlayStation或是PC上成功的俯视赛车游戏，就是用玩具车以及很庞大的地板设计出来的。

有时可以采用桌上游戏来做为游戏的原型，或是用纸笔来设计角色扮演游戏，才能想出正确的运作方式，加入其他的选择。最近有些更为先进的原型解决方案出现在市场上面，这些都是应用程式，可以提供一个虚拟的测试台看出相互关系以及行为方式。一个特别好用的工具（而且，事实上，是我目前使用的是Virtools制作的NemoDev，可以在他们的网站中找到详细的内容（www.nemosoftware.com）。这个套装可以提供一个完整的3D世界，并把角色放在其中，在有必要的时候也可以利用C++的界面，来扩展原有的行为积木。

我并没有机会尽量的运用这个套装程式，但这似乎是另一个制作原型的好方向，而且它也可以为最后完成的产品提供相关的资讯。这并不是唯一可用的产品：其他类似的产品也有在市面上出现，但是不管它们的技术能力多好，在市场上面并不出名。

我在这方面的个人理论是以游戏研发者的本质为基础。研发者――尤其是游戏研发者――都具有很高的竞争性。我记得之前对一家软体公司示范一个以Voxel为基础的图象技术（这是全新而且之前从来没有人做过的）。这家公司的总企划派了他的一位程式设计师，来看看这个展示程式。在没有错误之下，当时的展示让人留下深刻的印象――3D加速卡这种东西只是地平线上的一个远方小点，我的技术史无前例的，在同一个画面中显示了数个高品质的3D物件。程式设计师在看到展示时的反应十分震惊，然后下一个评语是这种效果很容易做出来，而且他的言下之间是他一个人就能办到。我对这件事的回应是马上问他，为什么他现在却做不到。

我稍后从总企划那边得知，有一个特别的研发者想要靠自己组成一个研发小组，并以自由作家的方式来工作。而他对于任何有那种想法的人表示出极度的憎恶。

这个重点在于游戏研发者一向想要［自个来］。他们宁愿不相信外面研发者所完成的程式码与元件，这一点现今很难判定，因为所有游戏研发（掌上型游乐器，象Gameboy是一个例外）都是透过软体界面，象是PC上的DirectX。

不过，虽然这些软体界面看来避无可避，游戏研发者仍有特定的毛病。对这些研发者而言，这些软体界面已经成为新的［金属］，也就是他们能够接触到的最下层系统。他们之中，没有人想让任何人插手于他们与系统最低层级（也就是系统应用程式，API）之间。

真希望这种态度会随着时间而不断软化，尤其是当程式设计师了解到外来的程式模组，远比他们在任何时段中写出来的东西都要好之后。

这已经开始发生了。在看到了《雷神之鎚》与《雷神之鎚2》引擎的成功之后，他们授权给许多的研发者，并用来设计出很成功的游戏，象是《战慄时空》。不过，《雷神之鎚》引擎是这个规则中的例外。在ID　Software中的程式设计师，都被人认为是产业界中制作3D引擎的高手，而这正是《雷神之鎚》与《雷神之鎚2》的成功所带来的名声，这导致这些引擎能够散布得这么广（译注：这也与ID Software公司惯于利用所有法律途径保护他们的程式码，再全面对外公开的做法有关，这会让很多人去研究他们的程式库与3D技术，并以此为基础来制作游戏）。

希望这一类摆架子的行为会在研发方面的技术更为纯熟之后慢慢降低；而且游戏产业的进展将朝向更愿意使用模组，如同电影工业会从外面找寻常用的元件一样。在这个时候，我们已经离这一点有一段距离了，但游戏研发将会越来越复杂。很快的，它在财务上面再也不会容许您重写核心元件，从外面取材将成为必要的方式；这对所有的研发公司而言已经不再是一个选择（只有资金雄厚的公司除外）。即使如此，大型的公司也可能遵循这一套作法，因为成本效益十分明显。

新的公司诞生仍是有可能的，尤其是专门设计让游戏研发者使用的元件，Virtools可能就是其中的一家公司。还有，CyberLife（这是Creatures系列产品的发行公司）也有可能参与这个角色。在撰写本书的同时，他们目前正在研发Gaia,一个人工生命的研发工具，设计用来研发有智慧的虚拟生物，很可能可以在游戏中运用，或是用在其他的应用程式中。

如果结构与设计相反，太过于简单，那出现的问题将会完全不同。一个过度简单的结构在基础上已经碎裂，并需要尽快的加以矫正。如果这个结构无法提供所需的功能，那就没有快速的解决方案。通常都无法靠着把破损的部份修好，然后继续进行那么单纯。一个过度简单的结构甚至不应该通过回顾的阶段！

唯一真正的解答就是重复评估结构，并把次水准的部份挑出来修正。视错误的本质，它可能有必要增加所需要的界面才能继续工作。一个该方面的琐碎范例，就是一个光碟播放模组无法容许一条音轨进乱数存取。这个功能要加上去可能十分简单，而且不需要打破目前使用的任何模组。

不过，如果过度简单的部份太接近基础，象是想要设计一个从平面地图上面抓取资讯，并延伸到3D环境中运用的界面，那么问题就更为困难了。在这个情况下，加上一个简单的额外功能可能还不够。整个模组的结构以及它潜在的资料，将需要修正才能符合新的规格。

当然了，相对的状况就是设计与（或）结构上太过复杂。一个过度复杂的设计在游戏市场上面似乎很常见，但是单纯认为一个游戏设计过度复杂，就是十分主观的事了。

水能载舟、亦能覆舟。《星海争霸》对一般的玩者而言可能太过复杂（那简直象怪物），但是对战争游戏的高手而言，它可能还太过简单。

不同类型的游戏可以接受一定的复杂度，这方面看来象是由全体性的意见所设定。这种复杂度会在每一个同类型的新游戏推出时增加，而且也会有越来越多的研发者赶这个流行。这种现象在近几年变得十分明显，一旦出现一个大卖的游戏类型，其他公司的类似产品马上跟进，而且大部份在设计方面只会更差。我只能假定（而且我有明显的证据）这个设计过程是环绕着一些成功游戏的外型，然后讲一些象是［如果有更多的部队，不是会变得更酷吗？］或是［如果你能更精确的控制这些部队，不就更酷了吗？］

不变的情况是，这些变化并不会让它更酷。有时候加入了太过复杂的东西，游戏就会变成使用者与界面为敌。为什么这些设计师无法了解界面就是要故意做得简单，因为游戏可以在电脑负责一定程度的控制之下，进行的更为流畅。这种点子对玩者而言，不过是种冗长的感受。在《模拟城市2000》中恶名昭彰的输水管供水就是这方面的例子。对那些没有玩过游戏的人而言，这个游戏要您切到下水道的地图，然后安置水管把所有的建筑区连接到供水站去。这个特色受到不少媒体以及网际网路的批评，因为它真的不必要，而且减少游戏中的乐趣。既然供水管是必要的，为什么不让它自动安置？为什么会有人把一块地区的供水管拿掉？这完全没道理（译注：补充一下，在这个游戏中有铺供水管的地区，可以加速繁荣）。

扩展与重新定义一个类型，并不是光靠增加复杂性就可以办到的。如果真的是如此，那么，当即时战争游戏《Warwind》在《魔兽争霸2》之后没多久发行，一定会成为热卖产品。没错，《Warwind》有一些很好的特点，但问题是它容许玩者控制游戏中各单位的种种研发角度，而且在使用者界面上面十分模糊。对一个普通的玩者而言，要掌握的事情实在太多了。媒体在评析中的看法都让人不得不同意。

我个人在玩《魔兽争霸2》的前一天就玩到了《Warwind》但我依然同意媒体的观点。虽然《星海争霸》游戏的运作、使用者界面，以及部队的控制方式仍然与《魔兽争霸2》雷同；这显然是Blizzard Software蓄意造成的结果，而且是好结果。比较一下《魔兽争霸2》与《星海争霸》的销售表，与其他即时策略游戏的成果，都可以支持这个论点。

这并不表示您必须把您的游戏设计弄得过度简单，才能让它容易上手。这只是表示您应该小心的考虑一下您的［酷点子］列表，然后决定您这些点子之所以很酷，究竟是因为它们执行时很好玩，还是它们玩起来很好玩？如果您很客观的做这件事，那您可能很惊訝的发现表上没剩几个东西。

您游戏的任何复杂性都需要加以管理。您可以用很多不同的方法来做这件事，象是隐藏在使用者界面下，或是把复杂性降低到可接受的范围内。

最好的一块复杂性是互动式的复杂性，它是靠着简单的规则组合，来产生复杂的结果；象是分子或原子堆在一块，形成水晶一样。这方面的最典型例子就是康威（Conway）的生命游戏（Game of Life）。这部份可能没有介绍的必要，不过对刚刚进入这一行的人而言，我还是简单的说一下。游戏的玩者是在一块平坦的格子中，每一格有八个邻居；格子可能是活的或是死去。游戏的每一回合都代表了一个世代，而每一格的世代都是以下列的规则，源自于上一代：

 

1．如果一个活着的格子有二个或是三个活着的邻居，这个格子就得以活到下一代（延续）。

2．如果一个死去的格子有三个活着的邻居，它就会活过来（诞生）。

3．活着的格子除了上述的规则以外，都活不到下一代（死亡，表示人数太少或是太多）。

　　

如果您很熟悉这个游戏，那您就知道从这三条简单的规则中，会出现多少复杂的建造方式，象是［shooters］和［trackers］。这就是互动之下产生的复杂性。

在生命游戏中的规则十分简单。不过，从所有可能的过程中进行排列并选择这些规则，是经过深思熟虑的。规则是十分易碎的，任何变更都会导致他们中止运行。有些人尝试将这些规则加以变化（象是生存与否视颜色而定，或是延伸到3D），但这些规则没有一个象原作那么成功。

这边的重点是告诉您，在游戏中表露出没有必要的复杂性，并非什么好事。游戏设计的过程是复杂的，但是游戏设计本身的结果不应该如此。如果这种情况真的出现，那我建议您重写。任何让游戏性复杂的部份，都应该是源自一组简单、持续运作的规则，在互动之下产生。您在把一个本质复杂的系统藏到一个简单的界面之下，要想什么都保留下来是不可能的。在这个地方我会强烈怀疑，［规则基础的复杂性］是否与［游戏中所需的使用者界面］有关；而这一点应该在游戏的设计过程，不断的提醒自己。

一个过度复杂的结构是完全不同的状况，直接导致的结果，就是错误的增加。

一个过度复杂的结构，会产生出不必要而且没有生产力的实行方式。结构是企划的骨架，而程式码就是它的血肉。如果骨架的形状不正，那您培育出来的小孩就会很难看。

如果坚持保留过度复杂的结构，设计者就是在降低整个小组的效率：要达到一个层级中的工作，要花费更多的努力。在这些努力过程中，将会有更多的错误出现，并导致企划在程式码的复杂性上，更难加以维护。这也表示企划中将有更多［知识相关］的东西，而它相当于让任一研发者更难了解全局。

 

不熟悉或是困难的方法、工具与程式库

使用不熟悉的方法，随后而来的就是额外的训练时间，以及修正第一次尝试这种方法的错误结果。

本书中说明的技术，也需要花一些时间才能适应；您不能期望在您采用了一套全新的程序与技术之后，还能要整个小组马上而且完美无缺的执行它。

当这些方式第一次导入时很可能让生产力下跌25%，这会让人心烦意乱，而且在这些实施后的结果上，很可能会爆发出研发者与管理者之间的惊慌。对于那些反抗这些作法的人而言，这通常会被他们用来做为争吵的主题。研发者最经常做的事，就是对抗那些设计用来追踪他们进度的方法；而游戏研发者似乎对这一点特别感冒，如同他们喜欢保持他们的［自由心灵］与不用负责的心态，而且把［对权威的不尊重］视为心理健全的一部份。

可能有更多不满的研发者从头就开始反抗，所以任何危及生产力的现象，都会被用来当做回到温暖的［老式］制作方法的好理由。这应该极力尽免。

您可以让研发小组为这种事情先做准备，来绕过这一类的反应。对新的方法、工具或是程式库，都有一定时间的学习曲线，这是免不了的，对不熟悉的知识都会如此。不要让多疑的人，在还没有足够长的理解时间之前，把任何新东西都敲倒。您所尝试的每一个东西都不一会有用，但是您从来就不知道，它会不会被一个很难处理的研发者打得混身是血。

举个例子来说，如果产品（或更可能的情况，企划的一部份）是在低级语言）下实施，那么它的生产力将会比预期的更低。不过，一般来说在威力强大的机器上，组合语言的需求程度就越低。一般的主机都已经有足够的能力，让它无英雄用武之地。如果以Pentium级的中央处理器来执行一个多工作业系统，您可能永远无法确定一段特别的程式码，要花多少时间来执行。

唯一可以让组合语言发挥长处的主机，是那些记忆体受限、速度不足，象是任天堂Gameboy或其他掌上型的游乐器。虽然任天堂（以及其他公司）试着限制研发资讯，让只有签约的研发者才能取得，但是地下的研究从来没有断过。甚至已经出现给Gameboy使用的免费C语言编辑器，以及许多可以用来除错的模拟器。

在这些机器上的研发时间，要比成熟的PC与游乐器企划短得多；除了规格受限的原因外，另一个主因在于程式也小得多。Gameboy似乎是唯一可以让单人进行游戏的设计与生产，并与一群大孩子做出来的游戏相较量的平台。

 

结构整合的问题

在分别进行元件研发的主要危险之一（如同我们在软体工厂模型中所建议的），就是如果这些程序没有在极度小心的情况下进行，在整合时可能会十分困难。如果分别研发的元件无法轻易的整合在一块，那就需要重新设计与修正元件，才能发挥它们的功能。

这个问题并不只影响到游戏产业；它影响的是整个软体工业，也是增加可接受的物件版本技术――象是COM（Component Object Model，元件物件模型）与CORBA（Common Object Request Broker Architecture，共通物件需求中介架构）――的主因。这些在理论上，是用来进行游戏研发的好模型，除非您的目标是跨足多平台的游戏。

在PC的研发方面，COM是很值得考虑采用的。您不用担心它在效率上有不当的表现，因为整个DirectX程式库就是以COM系统为基础。虽然这部份在本书第三部有更进一步的说明，不过COM可以遵照研发者的要求来进行物件改写，以保证一个物件界面的作用仍然保持原状。所有的物件在执行时都必须找齐，而且是透过标准功能，以保证在界面上每个物品的号码都是独一无二的。如果界面需要加以更新，那就会指派一个新的界面编号，而且如它的重要性一样，老的界面仍然不会有所更动。这可以更新一台机器上面的共享元件，而不用打碎用在早期版本上的界面。COM当然不是一个万灵丹，但是它可以解决一些整合元件上最常见的问题。

目前COM只能在视窗为主的作业系统上运作，但是微软已经保证会把COM带入其他的平台。先不管谈论独占主义的趋势，COM很可能在未来成为产业界的标准，而且甚至适合进行跨平台的研发工人和。

 

行程表的协迫

行程表的协迫是很令人厌恶而且通常是最诡诈的威协，也是最难去侦测与控制的问题。

通常，只要有机会，研发者会把他们延误的行程表藏起来免得丢脸。就算是要一个经验丰富或是很有责任感的研发者，承认他（或她）落后进度也是很困难的。就算这不是研发者直接造成的错误，也无助于改善这个现象，因为他（或她）通常都要为这个延缓的时程表负责。

行程表的延误并不一定是研发者的错。这个责任的连锁会一路延着命令的阶层向上跑，而且谴责可能会落在这个阶层的任何地方。下列的章节将会提出一些延误的例子，指出原因，并如何修正。主要问题是，延误有时是难以注意的。当所有东西都比期限慢了一点点，然后某一天全部加总起来，就会突然变成时程表延误了数星期，甚至是数个月。

 

过紧的时程表

由于财务与商业上面的束缚，大部份的时程表都是很紧密的。给一个小组太多而且没有必要的时间，可能会让您到达您想要的完美境界；就算是有足够的财源让一个小组可以放声说：［它在准备好之后就会发行］，一个严密的控制还是有其必要，来确保时间不会白白浪费掉。

期限并无法提供集中力。一个员工在得知他得在一定的时间之中，达成短期的目标并无法让他更为专注。不幸的是，在很多的理由之下有时是一种压榨，尤其是管理者采取极端措施，决定要把时程表变得紧到想勒死人，藉以刺激那些［懒惰］的研发者开始行动的情况下。这种方式一向都有负面效果，研发者很聪明，如果不够聪明，他们就不会在这边。

从一开始就排得过紧的时程表，有好几个理由。有时候，时程表可能是因为外表的理由而修正完工时间，象圣诞节就是一个常见的理由。我知道这应该是一个充满希望的神奇节日，但是就算如此，在年初就诞生数个完全没有希望的乐天派时程表，试着在圣诞节大卖仍然让我高兴不起来。

对于一个修改过的时程表，唯一解决方式就是减少产品的规格，增加可用的资源，或是增加可用的时间。这三个属性（需求、资源与时间）都是在平衡的状况下。您在变更其中一个时无法不影响其他二个。

这三个属性可以视为三角形的三个点；与图14.4所示十分类似。如果您打算让这个三角形与中心点保持平衡，那很明显您不能变更光靠改变一个角的［权重］，而不去变更其他二个角。为了保持三角形不致于崩毁，您必须让重心保持在中心点。所以，如果您的时程表变短，您可以增加资源或是简化规格；如果您减少了资源，规则就必须切掉一些，否则时程表就要拉长，依此类推。

这是一个不变的定律，没有什么其他替代方式。如果管理者不喜欢这个结果，那就是一场硬仗，一定要给一些东西；否则光是叫员工长时间工作，来达成不可能的时程表只会招致反效果。他们不只会蜡蠋二头煤，而且也对士气有负面的影响。他们可能离开公司，而结果就是挑战管理者的责任，一样会造成大量的金钱流失。

另一个原因是采用［有可能］的时程表。这部份在本章前文已经提示过（见案例研究14.1）而且产生出来的时程表很不精确，除非一切都是处于最佳状况的［完全状况］，但事实上的结果是［预期状况］中的时程表。

这些［有可能］的时程表通常在二种理由之下发生。第一种是遵循时程表的员工没有经验。在这种状况下，他（或她）通常都尝试做出一个管理部门很想看到的程式表，以博取较好的印象。这个时程表的设计都是假定研发过程一切都在没有问题的情况下。第二种更糟，就是［有可能］时程表出现的原因，在于管理者倍受压力下要求砍掉时刻表后段，最后就是一个［不可能］的时程表。

这种事不会有人喜欢，而且它通常导致研发小组在时程表延误上倍受责难。要解决这种问题没有简单的方法，唯一的方式就是在有效率的现实考量中，要负责人第一次就把真实的时程表做出来；然后在管理部门要求减少时间的时候坚定立场。这通常是假定所有研发者反正都会在时程表中灌水，所以他们可以切掉一些灌水的部份然后做出［真正］的时程表。这种让人迷惑的争论必须不计一切代价的加以反抗，您不可能光是削掉一部份的时程，然后期待制作时间加快，来完成等量的工作。这边一定要争取到一些东西，而且这些东西不是要能与企划相符，要不就是指派更多的资源。

当我被人要求减少不合理的时程表时，我试着让他人从我的角度来看事情。他们可以快点拿到东西，但是这会让他们花更多的钱与较少的功能，而且伴随而来的是更高的风险。这暗示着更多的金钱、减少的功能以及增加风险，可以让他们马上集中精神，最后通常可以达成其他方面的妥协。

 

不完整的时程表

在排定时程表的人经验不足时，另一个可能出现的问题就是他们会省略掉时程表的一部份。或许他们会忘掉的有的图档需要进一步的处理，也可能忘掉游戏需要有安装与解除安装的程序。不过，要预测二年时间中的工作列表，也不是一件简单的事。

事实是，如果一个工作没有出现在工作列表中，它就不会排入时程。这个结果就是让一个不完整的企划成为恶梦般的局面，因为照时程表来看，它应该完工了才对！唯一的解决方案就是埋头苦干把工作完成，让时程表过头，为额外的工作取得额外的资源；或是降低企划的标准。这将会视他们的花费与劣势来决定，如同我先前说明的一样。

 

缺乏的资源

如果时程表的安排是以特定的组员为基础，而且这些组员无法运作，那就是一个大问题了。

如果特定的组员拥有所需的技能，而且他（或她）正在忙其他东西，那除了等候以外并没有其他的选择。不过，更重要的一点是，这种情况根本就不应该发生。让一个人独占一种特定的技能是极度危险的事情，万一他（或她）决定要离职呢？您应该做的是鼓励技能在您的员工之间传递，全面预防碰上这种局面。

记住，一个企划在理论上都有最少量的需求。如果您变更了任何一点，那么另一点或是另外二点都需要以相反的方式进行修正。这也是一个不变的道理，所以尝试去违反它并没有什么意义。这样做只是导致另一个问题，例如研发者力竭、企划延期或是取消、甚至是一个次水准的产品。

 

高估省下的时程表时间

如果采用了特定的生产工具（象是行进的原型工具），他们通常被视为一种［新世界］风格的希望与敬畏。

通常，要不是因为没有场所可以让研发者操作一连串的旋钮与按钮，否则他们都会认为自己做到超人般的水准，从高楼上面弹跳而下，从倒塌中的建筑中救出孤儿，并能够在荒谬的短时间之中，单手做出完整又可以动作的游戏原型。好吧，我在高楼弹跳救援方面撒了谎，但是一个全新、美妙工具的能力通常被人高估，尤其是当它们完全不象小组用过的东西时。

有时候，工具会以［充满各种所需特色，让您可以做到各种想做的事情］面貌出现。问题就在当工具提供您更多的［解决］之道，它就更会催促您采用它的方法来做事。经常发生的是，除非您的运气超好，否则它并不完全是您想要的，而且您会把大量的时间花在有明显缺点的工具上。视工具的本质，做这件事的困难度可能从稍微费力到完全不可能。是的，大部份重量级的工具都可以让设计者制作出一个外掛的模组，但它会把设计卷入一个模组，去符合一个不熟悉的结构，学习新的API，并发现在一个不熟悉的设计程式中受限时，如何真正进行工作。这是一个吸引人的工作，因为它可能会［错误的］假定，因为它是采用了象C++这样的标准语言来创造外掛程式，一个很好的C++程式设计师应该可以很快的把它纳入使用的范围。问题是，要得知这个延伸系统的运作方式，所花的时间通常会被加成。

这个解答可能是重排时程容许学习时间，或是切掉使用这些有错的［强化生产］工具。当然了，您可以把这二种作法并用的想法丢掉。

 

预估不精确的时程表

在一些情况下（而且我很确定我们讨论过），一些时程表看起来可能很正确。它可能把每一个工作都标出来，考虑到每一个风险，而且每一个研发者都会保持忙碌，不会产生冲突。但是，在它进入实行过程时，一个或是更多的范围就与时程表脱节。举例来说，不熟悉的生产范围可能要花费比预期更多的时间来设计或是实行，或者一个工作中的延期可能会导致更多独立的工作同时向后延。

这可能是因为产品要比预期的更为庞大，或是需要的努力与工时要比预期的更高。这将假设这些困难单纯来自于解决方式的技术复杂性，而且与工作中进行的研究没有关系。如果是后者，那就没有解决方式。您只能坐下来然后静候研究结止，或是干脆把这个功能砍掉。不管哪一种解答通常都令人无法忍受，但这是您必须为排定时程的研发，所付出的代价。您无法把研发排定时程：这个行动完全无法预测。您难道不知道安排六个月的时间，附上精确的查核点与里程碑，来研究反地心引力的驱动器有多荒谬吗？您必须完全了解问题与解答的所有知识，您才有可能精确的预估要多久的时间才能完成。研究的本质，就是探索未知；安排未知的时程表？您一定是在开玩笑！

不过，如果这个问题是源自于未预期的复杂度，那这一类的问题通常只有三种解决方式。一个是切掉功能，这个解决方式能不能实施，看您的需求而定。第二个方式是重新安排企划时程表，把额外所需的时间排进去。第三种解答是以软体工厂的方法，从程式库找一个可以相容的元件替换掉（不过能力可能比较差），这种方式不一定会与整个游戏契合，但是如果其他的方法统统失败了，您还有一个可以运作的产品。

不过，这并不是重点；真正的重点在于就算您插入的元件无法提供全部您所需的功能，它至少也可以在新元件完成之前，做为应急的举动。其他部份的企划仍然可以进行。如果再多加小心，光是等候一个重要的元件完工，不用花费太多的时间。

说服人们拉长工作时间是另一个选择。如果一个企划中的努力只有稍微的延期，那短时间的加班可能是个赶回进度的好方法，只要研发者能够负担的起就行。

不幸的，这个系统在游戏产业中长期受到滥用。我听说过一些可怕的故事，研发者被迫每星期工作80小是地，长达一个月，而且没有额外的金钱方面奖励（除了每周末的匹萨，以及在企划完成后低劣的T恤）。这实在太荒唐了，我坚定的相信人们绝对不应该被强迫工作，一天甚至不该工作超过八个小时。这会招致反效果，而且您通常会得到的不过是次水准的游戏，一群不满的、烧焦了的研发人员。

管理部门对这种滥用事件的最大藉口（而且注意一下，管理者本身很少周末待在公司）就是写一个游戏与牺牲奉献有关，或者是一些相关的谎言。无聊！这是一个工作，单纯而简单，而且任何想要说服您的人，都是想骗您（或是要靠您的牺牲来赚大钱）。总归一句话，志愿加班在短时间不会有问题，只要研发者能从中得到合理的费用就好。

 

时程表调整的错误

为一些没有预期的延迟来调整一个时程表，通常会出现错误。有时候重新仨计来应付时程表的延误是过度乐观或是忽视企划历史，也可能是从其他企划中引用的缺席。

要确保这些错误不致于发生的最佳方法，就是使用过去的资讯与自然的制度，并用在员工的身上。

在案例研究14.2中说明了这些程序的真正状况。

 

案例研究14.2　重新调整一个已经实行的时程表

当我在一个误点的企划中担任了疑难排解人员的角色时，我被人指派分析目前的时程表，并以当时的企划状况为基础，把它重新调整成正做的预估值。

如果不从小组身上先取得他们的缺席，要做这件事是不可能的。为了做到这一点，我观察了每一个人指派的工作，以及他们分配到的工作时间。刚开始，我很确定他们不会因为企划中的问题而遭到责难，所以我再评估了时程表，并做了更精确的预测。其中一个理由是企划已经碰上了麻烦，随着加诸的压力他们放弃了程序，试图赶上期限（这部份在本章后再讨论）。而这样做的结果，当然了，加重了问题并导致更多的臭虫，最后是时程表延误。在这个阶段，我们中止了任何新的研发，只专心于把企划带回可以接受的程度。这个工作已经做了二个月之久，而且几乎完成了。

现在正是调整时程表的好时机，因为新的研发正准备开始。如果我试着预先准备，这个结果可能会没有用，因为需要先处理的，是老旧程式码资料库中的问题，而额外的工作势在必行。

小组的人员被指派了新的工作，每一个人（按照时程表）的预期工作时间是一到二天。小组被要求要紧密的维持程序。我强调这并不是一场比赛，而且他们也不是被评定为精通这方面的高手。每个人都有不同的工作量，而且程式员的速度快也不代表他真的很棒。我想要的资讯是他们个人的工作速度，因为我需要以他们的工作速度，来调整时程表。

在这些指示之下，我观察并收集小组中的制度，进行了差不多一个星期的时间。我发现在没有例外的情况下，所有的小组都无法在期限内完成时程表的工作；这个时程表太贪心。

对每一个组员来说，我找出他们做一些简单行动真正花费的时间，以及时程表安排的时间。在完成这一点后，我拿着工作列表走到每一个员工身边，然后把安排的时间乘上这个比率来算出更精确的预测时间。在小组的指导下，我把工作洗牌一次，并确保每一个人员都有平衡的工作列表。

整个过程又重复了一个星期，而且在每一周的末尾再度计算这个比率，并把工作重洗牌。

在第三个星期，我们发现研发者持续的符合期限要求，并紧密的维持程序。在这个阶段的士气已经很明显的提升，小组开始怀疑他们之前为什么这么慢而且没有效率，并了解到他们先前工作的时程表是达不到的。

下一个障碍就是对急迫的管理者解释，这个新的时程表预期的完成以及发行游戏时间，要比他们希望的晚二个月。我接到的要求是，看看我能不能把时程表切掉二个月，赶上发行的时间。

这一点让我有点惊愕，因为这种思考方式就是他们搞得一团糟的主因。我在白板上面画了一个三角形（如图14.4中所示十分类似），并开始解释完全的平衡行动必须靠着资源、规格与时程表来达成。我无法把时程表切掉，因为现在已经没有可以操控的空间。他们不是要增加资源，要不就是砍掉功能，并准备迎接在企划后期阶段所带来的抱怨。

对他们而言，增加资源或是砍掉功能都无法接受，因为他们已经将特色用来签定合约并取得预算；所以在最后，他们没有其他选择，只有按照我的建议来行事。

这个企划在我新安排的行程表中，提早了一个星期左右完工，而顾客也被安抚完毕。

 

一个无法达成的时程表所加诸的压力会降低生产力，主要是因为研发者的士气会不断下降，如同他们明明全力以赴，本身的进度还是不断落后。这种状况的唯一解决方式，就是考虑一下在案例研究14.2中采取的方法。

组织上的问题

组织性的问题是我的最爱，不过，它们在处理上也是最没效率的。它们之所以成为我的最爱主因，是因为这些问题通常源自于管理上的错误，而且把这些问题丢回给老板都是好事！它们之所以最难处理，是因为您要想办法告诉您的老板他犯了一个错误――这也是最快前往大门的路，如同图14.5所示。

这种状况要极端小心的处理，光是告诉您的上司并不一定有用，因为如果是个坏消息，他（或她）可能会觉得把这个消息告诉他的大老板将危及他（或她）的事业！每个人都喜欢［杀人灭口］。

不过，如果站在老板的立场想想，您想听到的是有可能要多花数个月制作初始的模型，还是在游戏已经延了数个月还没有上市，然后听到有人一年前就想要告诉您这个问题，但却被这个人的上司挡了下来？

这个特别情况的解答，就是透过不具名的管道。利用这种方法，任何人都可以把问题回报上去，而不用担心事业受到危害。

 

管理引发的困难

管理会导致组织方面的问题。这句声明不是想要打击管理阶段，它只是反应出管理对一个企划组织天生负有的责任。嘿，他们总该负一些责任吧！

举例来说，管理部门（甚至是市场部门）可能坚持一个技术上的决定，导致时程表延长。很不幸的是市场受到科技的驱使，但我们却无能为力。这可能是一个委托加工合约的一部份，要求一个产品能够全面支援一块特殊的显示卡，而不是单纯透过类似DirectX的常API等等，诸如此类。

在某些情况下，管理部门会坚持一些回顾性的决策，象是购买、预算的同意、合法的事情等等。这个状况通常在一个庞大的发行公司，出资提供一家较小的游戏公司时较容易出现。其中一个状况是这些发行公司会插手于［否决权］的运用。这表示每一个影响到产品的决定，必须受到母公司的批准。如果母公司有许多的附属公司，那造成严重延期的可能性就大为增加（当然了，您必须了解，发行公司在电话中对您的管理者大声咆哮，要求知道游戏为什么要比行程表晚三个月才会上市，一定会忘掉一些事情）。

这一类的事情会影响到您小组的士气，其他管理上的决策也可以让士气降低，象是这类长时间不断延伸的权力，或是在没有好理由之下的特权，以及没有效率的小组结构，都可能在未来降低生产力。

很惊人的是，就算是在良好的管理决策（至少暂时性）下也有降低士气的可能；象是负担程序并定义出实际上的研发。这方面源自于人们对于这些变更无法适应。这方面必须利用［慢慢来］的方式，而且不能妄用。如果您打算强制让他们负担加班的重任，并预期他们一天要工作十小时，进行程序让小组以更有效率的方式来进行，可以说是一点道理也没有。在研发过程的严格实行重点，在于让这个小组更有效率，并为个人省下漫长的工作小时。如果管理部门打算实施的作法，会导致小组的士气下降，那最好让您的小组有一个可见的好处，而且要出现得快一点。

有些早期的管理学校可能还不了解程序所带来的平稳作风。您应该记住游戏产业背后的坏习惯已经有数十年以上，没有办法一夕改观。有些管理者会对延误而稳定的步伐感到紧张，然后越来越沮丧。他们可能想要看到一些更尖端的勇者，带着漂亮的展示与明显可见的进度，而不是看着稳定的工作持续进行，但短期内只有一片漆黑的画面。如果要解决这个状况，整个小组必须把重心转移到企划的特定部份中，才能够让管理者满足；接下来研发过程的平衡会打破，导致未来的工作中出现捷径与不必要的妥协。这是一种破坏良好状态的研发，只专注于外表、从底部挖除小组侦测并修正问题的能力，而妨碍了精确的状况回报。

在企划尝试着做出一个结论，但是小组却发现重要的子系统可能还没完工不见了，很可能造成额外的压力。在这一类的状况下，在时间压力之下企划中的计划很可能被忽视掉，最后变成一团乱、没有效率的研发，如同案例研究14.2。

 

承包商的问题

很惊人的（或者不奇怪，只要看看其他产业平均薪水，就知道游戏产业薪水奇低），通常承包商都不熟悉游戏产业中的事物。在游戏产业之外，通常会听到一个组织，象是银行，按惯例雇用了一个签约的程式设计师，来进行一个企划；但这种事在游戏公司中却从来没听过。

通常承包商在游戏产业中使用的方法，是找一整群的单位来进行工作，象是全萤幕动画的制作、动作捕捉、游戏测试与设定测试；把一个已经做好的游戏转到另一个平台，或是设计一个3D的模型。

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

 

寄送延期

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

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

 

品质不良

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

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

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

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

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

 

个人的问题

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

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

 

关系

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

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

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

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

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

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

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

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

 

技巧的不足

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

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

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

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

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

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

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

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

 

研发的问题

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

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

 

办公室的设施

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

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

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

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

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

 

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

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

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

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

 

设计的误解

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

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

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

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

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

 

符合需求

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

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

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

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

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

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

 

研究：结果

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

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

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

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

 

过程问题

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

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

 

官僚作风与繁文褥节

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

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

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

 

误用与制度

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

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

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

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

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

 

拘于形式的问题

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

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

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

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