达达尼昂 | 资料收藏 | 2009-03-12
《电脑游戏结构与设计:理论篇》第十四章 产业的未来【转】

  

第十四章　产业的未来

 

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

＊变动的管理技术

＊电影工业的模型

＊让小组运作

＊产业的成熟

＊线上的革命

＊调整的可能

 

这个章节包括了我们对游戏产业未来的最佳猜测，以及整个游戏市场中会发生的事。而如同这个世界没有照预言在1999年7月走进世界末日，没有人能够成功的预测未来――至少不是现在。

我会在这个章节中，以我相信未来产业会发生的事，试着为企划找出一些可行的方向。

我猜的每一步统统都错是很有可能的；但是，如果平均法则仍然有用，那至少我会猜中几件事。而且，不管怎么样，有些事情是无可避免的；象是线上游戏社群的发展。

游戏产业仍然很年轻。我们已经渡过了［长牙时期］与［可怕的两岁期］（译注：这是指二岁小孩老是把［不要］掛在嘴边的作乱时期）：我们已经越过了黄金年代，那个人人都可以设计并撰写热门游戏，而且什么都可以尝试的时期。我们甚至超越了在卧室工作的程式设计师以及辨称自己将成为百万级程式设计师（大部份都是没有失败过又想出风头的人）的年代。

现在，我们已经到达了这个产业的青年期。一切仍然又美又酷，但我们却不太愿意去尝试一些奇异的点子，而且我们开始把眼睛放在愚笨的商业主义上――这主要是源自于市场的统一与巩固，与电影工业的流行倾向十分类似。

 

产业的状况

如果我真的百分百诚实，我必须说我对目前的产业状况失望透顶。早期的独创性与热烈似乎已经烧得一干二净。

最近的科技似乎都聚集向同一点。在最新的游乐器中，所有的游戏都出现了类似的外观。三度空间的多边形似乎成为现今的体制，即使是在最谦虚的系统上亦然。

 

第一纪元

很多有才能的人建造了这个产业。在早先的日子中　，一个很有热忱的人可以在他的空闲时间策划一个游戏，然后用合适的金钱把它卖出去产。这些日子中可以规划出各种千奇百怪的点子：几乎什么点子都可以卖钱――只要是个好游戏。

不过，并非所有的公司都产出好的产品。有些公司想要推出冒充的产品，在新的家电电脑游戏上面换取现金。随着家中电脑市场的成长，其中相互竞争的公司增加，导致一些较没有效率的组织被挤出了市场。

首先，这是一件好事。会买游戏的人大多很清楚内容或是电脑方面的专家，而且知道他们在买些什么。任何只会生产出低品质游戏的公司，很快就会发现他们的产品不在购买的风潮中，并把他们逼到破产。落到这个局面的公司并不多。

剩下最合适生存与最强而有力的公司，开始在眼光敏锐的市场上展开竞争。这些公司必须找出一个方式，让他们的产品与对手不一样――才能如他们想要的一样，在货架上面一支独秀。

最恶名昭彰的方式就是取得搭售的授权：源自电影的游戏，以及源自小说的电影。没多久，几乎每一个产品都获得其他行业的授权；而且几乎没有例外的是，这些东西都可以用一名［平庸］来形容，产品在冲刺之中完成，以搭上电影销售的列车。在高耸入云的疯狂授权下，各种产品象是洋竽片、榖片或是汽水一样的出现。如果只看独创性，这时的业界水准可以说是最差的时期。

不过，这仍然有一个好处，就是替未来把差劲的公司除掉，只留下最菁华的部份，足以制作出技术精湛（如果他们的游戏亦非原创）的作品。

这就是家用电脑第一纪元的结束。靠着即将来临、威力强大的主机与大型市场的游乐器，事情已经开始变化…变糟。

 

第二纪元

在大众市场中游乐器的进展，象是Sega Master System与任天堂红白机提供了广大的平台，也增加了销售的潜力。强大的16位元主机――象是Amiga和Atari ST，在大众的心中提升了游戏的名声。

除了区域性的授权以外，在新的游乐器上真的有不错的表现。一波全新原创以及惊人的软体在市场上出现――更多冷眼旁观公司发现，只有几种游戏特别适合出现在游乐器上。然后一波又一波的平庸游戏不断出笼，几乎要把这个市场毁掉。

同样的情况也出现在次世代主机，象是超级任天堂与Sega Genesis（译注：在台湾、欧洲及日本称为Megadrive）。很重要的一点是，不象最近的游乐器朝向3D加速的方向发展，这些较早期的游乐器在硬体上面并没有太大的特色。

不过，持续不断的平台游戏（一向如此）证明了在这些系统上面，可以用最简单的方式来进行游戏研发，所以市场再度掀起大洪水。或许在未来可以预测平台的死亡预兆。以一个塞尔特传说中的女妖精来做比喻，平台之死将会在大量的平台游戏推出之后上演（或者是不管那一种游戏，在该主机上面特别容易设计）。

大约在同一个时间，授权的金矿挖得差不多了。在时间上的增加，会导致游戏的研发越发困难，很难确保游戏能与电影同时上市。如果把电影造势的优点从游戏上面拿掉，游戏就得靠它自己的长处生存下来。很少有这一类的产品成功，而且大部份负责的公司，对这种徒劳无功的表现也很失望。

 

第三纪元

第三纪元（现今）的游戏产业似乎无法改变增加多边形的现象。3D技术已经占据了社会大众的心智与大脑，而大众市场对游戏的要求，几乎就在我们的身上。

在PlayStation（以及一些PC）上的成功，已经让游戏更容易在主流中撑竿缓行。

亲眼看到《猎鹿人》游戏成为很热门的产品后，这个东西的成功可能会打破所有人的眼镜：所有的权威很高兴的对它大力批评，准备将它打入冷宫；但是再看到它达到的销售数量，游戏世界对它的地位不得不另眼相看。

看来大众市场的玩者――也就是游戏产业一直在追踪的神秘巨兽――对过度科技所搭建的光荣产品没什么兴趣，反而钟情于一个简单、普通的打猎游戏。结论是，这是一个可以取悦完全不同市场人们的产品，而这些人甚至不一定算得上玩者――而且它很便宜。这是一个适合在圣诞节或是父亲节，送给爸爸的好礼物。

有人说，如果您目前产业的状况，要把一个游戏卖出去，能做的游戏类型就没几项。基本上，如果您想要确保您在美国市场的成功，理论上您就该去做一个打猎游戏或运动游戏。事实可能是您该写一个可以被大众市场所接受――象是《猎鹿人》――而不要期待大众市场突然之间对古神或是电浆砲有兴趣。

在英国和欧洲，打猎并不是那么盛行，您唯一可以获得绝对保证的游戏类型就是足球。美商艺电在每年大赛前都会推出一系列的足球游戏，而且行之有年。一些毒舌派的评析人员会暗示今年的游戏不过是去年的装修版本，但这个特定的足球系列，仍然会受到平时不买游戏的玩者青睐，而且它卖得好的另一个原因，在于他们与足球协会签下了许多的运动名星。

同样的事情也出现在美国人的运动中，约翰·乔丹（John Madden）的橄榄球游戏也会在每季热赛时有惊人的销量，但是它的评语和英国的足球游戏也是一样的。

当然了，运动与打猎游戏并不是目前市场上唯一的成功者。产业的一部份越来越清楚，另一个卖游戏的方式在于争论。这是一个吸引全球一般人注意的方法。不过，它就象是大众市场的圣环一样，并不是直接靠着争论来达成的――大部份的人并不想要残暴的谋杀、拟态的人类或是外星人――这只是一个让游戏穿入意识的方法。在这个领域中有二个成功的物件课程，分别为《快乐天堂》和《模拟城市》系列。今天，《快乐天堂》销量超过了400万套，而《模拟城市3000》就有超过200万套的销量，更不用提先前的《模拟城市》与《模拟城市2000》。

 

名声的挑战

在电脑游戏上的一个新趋势，在于利用名声来推销游戏。这些名声可能是真实或是虚拟的。

在虚拟的名声上，我们有很多方面的选择：玛琍欧、音速小子、罗拉、《萨尔达传说》中的林克、《太空战士》中的克劳德以及一堆东西。玛琍欧和音速小子是分别在任天堂与Sega上面的知名人物。

在《古墓奇兵》中，我们看到的主流人物是萝拉。如果《古墓奇兵》系列没有萝拉·卡芙特与她那庞大的产业，这个游戏会成为文化上面的表征吗？如果萝拉换成另象是印北安那·瓊斯的人物，那电视广告还会把这个人换成世俗中的萝拉吗？我想不会。

Eidos已经利用萝拉的商品来赚取了不少金钱，并在他们制作其他游戏时，同时推销他们的人物。一般媒体对《古墓奇兵》的看法骒，这个游戏已经在光芒中迷失了自我；但是还有很多潜在性的商机。在撰写本书时候，已经准备拍摄一部萝拉·卡芙特的电影（译注：电影已经在台湾下档了），提供了一个不单单把游戏搬到电影的模式（玛俐欧、快打旋风、真人快打），而是把Eidos的金鹅送进去。

但是，随着每一个成功的虚拟名声出现，就把前一个打下去。还有人记得Zool或是Bubsy吗？只要其他公司看到了玛俐欧与音速小子的成功，他们就会想要参一脚。太多可爱但是自大的人物出现，而且――幸好――大部份都在路上死气沉沉，死绝湮灭。

最近，这个倾向让Rare公司设计出Banjo熊、Kazooie鸟以及其他东西。这表示我们会看到另一波可爱的人物？

嗯，有可能，虽然这必须看Rare在产品中如何运用这些人物。可爱而容易一眼看出来的人物（像玛俐欧）可以抓住年轻人的心。不过，游戏的品质与这方面完全无关。玛俐欧与音速小子是定义明确又讨喜的人物，不过如果游戏不够出色，这些人物也不会这么成功。

［这个点子是看你能不能耗掉每一个玛俐欧的物品，如果你可以穿着一件玛俐欧兄弟的运动衫，围巾上面是玛俐欧兄弟的零食，透过一些神秘的方式你可以变形成玛俐欧，或者至少拥有他的部份能力。这有点象是逆向动作的小木偶――有上百万的真正小孩，每天都想要成为数位化的玛俐欧。］

――J.C Hertz,写于1997年Joystick Nation

是的，这就是虚拟的名声。那么真实的名声呢？如果不算那些出现在运动游戏中的明星运动员（这太明显了！），我们可以想到的，只是一些打进游戏市场的人物。

英国的重金属乐团Iron Maiden，目前正推出一张光碟，上面包括了一段以他们吉祥物Eddie为主角的第一人称射击游戏试听音乐。当然了，英国的专业媒体嘲笑这个普通游戏的每一点，最简单的理由在于Iron Maiden不再是流行的尖端。

我一直对英国的专业媒体人员抱持着意见（其中只有象Edge这本负责的媒体除外），他们并不象他们的美国近亲那么成熟。为了这本研究性的书藉，我旅行经过了欧洲与美国，一路上阅读专业媒体的文章。我发现美国人的媒体很具有成人导向，内容倾向平衡而合理的文章；而英国媒体似乎是针对青春期以前的年轻人，写的都是不敬的类似言语。这种角度是美国人产业环节中极力避免的，所以大众市场当然不会乐接受英国的游戏角度。

道格拉斯·亚当（Douglas Adams）是［银河顺风车旅行指南］小说的作者，最近跨足于电脑游戏协助创办了The Digital Village。这个研发者的第一个产品是潦草的冒险游戏《Starship Titanic》，由亚当斯所设计，设定在一个前往一场灾难的星舰上。

汤姆·克兰西（Tom Clancy）是许多政治悬念小说的作者，也在游戏产业中有一片天。相关的成功作品是《虹彩六号》，一个以小说的跨国性秘密行动组织为背景的游戏。

并不只是作者打算来试试身手：著名的［侏罗纪公园］创造者迈克·凱基顿（Michael Crichton），也与游戏界中的Timeline Studios结盟，来设计一个尚未公布的游戏。您可以打赌这个游戏在制作中会不断传出恐龙的叫声。

甚至是老牌明星大卫·鲍伊（David Bowie）与皇后合唱团（Queen）也在《恶灵都市》中小试身手（现在被人冠上了游戏的绰号）。

这些方式都有用吗？大卫，鲍伊真的有办法吸引下赌注的人吗？呃，时间会告诉我们答案。我的观点是娱乐软体现在很新而且具有不同的媒介，可以创造出它自己的明星。如同范伦铁诺（Valentino）与齐柏林（Chaplin）在无声电影的时代都是明星，但是都不会转型到有声电影一样。迪士尼的确在［玩具总动员］中立起了名声，而且其他电影也是，但这都是好玩的，真的。举例来说，他们不会把汤姆·汉克扮演伍迪的声音拿出来当做大卖点。一个名声响亮的动画特色只是有助于提升他们在市场上的形象；它不会变更任何人对它的观感。用好莱坞的说法，可以打开真人拍摄影片市场的明星，没必要去碰动画市场的大门。

在电脑游戏时空中的明星，通常都是虚拟的明星，象是萝拉·卡芙特，而不是真正生活中的名字。凱特·史雷德（来自《时空英豪》）是一个拥有自己意识的人，而且游戏就算找来象布鲁斯·威利（Bruce Willis）这样的大明星来为他配音，也不会让游戏更出色。如果说要有什么，可能一份不调和的备忘录，上面提醒我们［这只是个游戏］，因为布鲁斯·威利的声音实在太好认了：我们知道他不是游戏中的人物。而为史雷德配音的演员大卫·加斯曼（David Gasman）表现的很好，而且事实上正因为他没有那么响亮的名声，协助我们相信这个人物的真实性。这方面的软体媒体需求，可能要避免的是远离象相片般真实的人物，而转向比较有个人风格，象是在好卡通或是漫画中的表现一样。想想蝙蝠侠的电影与卡通的区别，或是看看Rhame这个别具风格的英雄人物，由托比·加德（Toby Gard，也就是萝拉·卡芙特的设计者）所设计的另一个《Galleon》新游戏。这应该可以创造出一个别具特色的人物，并具有特定的声音来搭配，而不是光把一个明星从电影银幕上面搬下来。

 

游戏中的暴力

近期游戏中的暴力问题越来越严重，主要是因为技术的提升，真实的暴力将会透过图象先表现出来。

《真人快打》是一个恶名昭彰的游戏，主要是玩者可以用各种组合的招式，用残暴的方式让对手以各种不同的方式死亡。其中一个最血腥的画面就是把对手的头骨与脊椎骨拔出来，然后高高的举在空中。如同画面真实的本质，让这个画面在道德方面倍受争议。

在英国，第一个因为有内容而受到评断的游戏，是ZX　Spectrum电脑上面的《科学怪人》。一部份的发行者为游戏宣传完全是出于自愿，这个（而不是冷嘲热讽）方式在之后的几年，也套用在数个不同的游戏上。象是《侠盗猎车手》（一个从高空俯视的游戏，可以让您杀伤任何人）因为它的丑名而在法院以［限18岁］以上才能玩，反而声名大噪；甚至英国的公关专家麦克·克里福（Max Cllifford）也被叫来为这个游戏宣传。他靠着在报纸上大幅刊登的冷酷文章，以及［禁止这个下流东西，现在！（Ban this fith,now!）］的标题，让销售竄升到屋顶去。

为了宣传他们的盗匪游戏《流氓大亨》，Eidos雇用了［疯子］法兰基·福拉瑟（“Mad”Frankie Frazer，在［Kray Gang］中一个恶名昭彰的成员，曾经在1960年入狱）出现在欧洲电脑贸易表（ECTS）。这个作法受到媒体的唾弃，被视为下流的大众宣传手段。为了回应这一点，福拉瑟马上减少出现在大众面前的次数。不管这种出风头所产生的效果，强迫《流氓大亨》映入大众的眼中有可能妨碍或是帮助游戏的销售。

《终结狂飙》虽然是受到Paul Bartel的电影《2000年死亡大赛》（Death Race 2000）的激发，不过该电影以讽刺社会的手法，让观众从暴力之中引出娱乐效果，这个讽刺手法在游戏中却看不出来。刚开始，发行公司不得不把徒步的行人换成喷绿血的僵尸，因为审查员认为红血太过真实了。他们指出您车辆在地面留下的红色轮胎纹太具攻击性，而且在游戏完成修正之前拒绝推出。

专业媒体对这个作法发出嘘声不满，要求他们的游戏要有鲜血与内脏。以怀旧的眼光来看，这并不是好点子，因为它只会对整个产业造成负面的影响。如果产业界无法自我约束，那就必须接受外来的审查，这不只让发行公司高兴不起来，而且也无法为顾客提供良好的产品。

《终结狂飙》的发行公司显然是要对抗审查小组的决定，而且他们真的把对方打翻，让他们推出了完整的血腥版本。但是，在看到一些业界的人员已经［非官方］的推出了鲜血更新档，这还是有点过头。我个人还是比较倾向僵尸版本的气氛。

很有趣的，当微软在近期推出了一个赶时间的赛车游戏《疯狂城市赛车》之后，英国方面的专业媒体中，有一些较不负责的人员居然抱怨他们不能开上人行道去压人。他们老是打算在最后一刻跳出正轨，采用70年代的车辆电影观，象是［Cannonball Run］。

这还真的在数篇评析中被列为缺点，而玩者不能开上人行道去压人成为最大的缺点。这真的有点病态：让玩者去压死路人并无法让游戏变得更好，而且也不影响游戏中驾车的感觉。如果杂志的评析人员觉得他们的评语有正确的理由，那他们可能看电脑萤幕太久了。我会建议他们出去吸点新鲜空气，感觉真正的世界，直到心情好一点为止。在对照之下，美国的媒体觉得游戏中不致命的本质，是可以加分的特点。

《喋血街头》这个游戏是以一个真实的导陋事件来命名的。这个事件中邮局工人回到他之前的工作场所，然后用枪枝攻击任何视线中的人，并不是为了现金而是为了暴力。

这个游戏的广告中包括了所有媒体加诸的责难，并用来当做大家该买游戏的理由。不管如何，媒体并没有让《喋血街头》符合任何大众市场的喜好――在刚开始的兴趣以后，销售很快的跌落。

一个祖父级的真实暴力游戏《毁灭战士》，被人批评导致美国许多学校枪击事件。这让道德权威人士大声疾呼，必须把电脑游戏中的所有暴力连根拔除，而数个集体诉讼的法律案件，也对着数家发行公司展开。

一个电脑游戏不可能把一个理性的人转变成一具杀人机械。唯一的可能是这个人本身就有问题。

不过，在发生了让人悔恨的悲剧之后，这些回应只是合理的反应了。在发生了让我们忿怒而且惊惧的悲剧时，四处找寻目标来加以责难，是人类的正常本性。

据我所知，大部份在地球上的人都玩过《毁灭战士》。这是一个发行最广、玩者最多的游戏：我当然也在空闲时玩这个游戏，但是我不会觉得十分暴燥，想要拿出散弹枪或是链锯来攻击别人。

再说一次：游戏并不会导致暴力。它们可能让一个有问题的人，具有较强的暴力倾向，但是一本书、一份报纸上的文章，或是电视影集、一部电影以及我们每天可以看到的上百种酒精饮料一样可以达到相同的效果。事实上，如果是个人的问题，什么东西都有可能成为引暴点。

在1999年7月的日本，一个年轻人手持小刀劫了一台飞机，并以割喉的手法杀死了机长。为什么？因为他要象微软《模拟飞行98》一样，从下面穿过东京的彩虹大桥，而驾驶员拒绝这样做。

 

这是否表示模拟飞行游戏应该禁止？微软应该被市场控告，因为他们写出危险的产品？

 

不。这实在太荒谬了。一个民主社会的基石，在于人们对他们的行为具有理性的判断。光是靠着［是恶魔要我这样做的］做为答辩，应该是在耶路撒冷女巫审判时讲的话，如果目前还在那个年代，这句话或许还有用。这基本上每次都会出现一些新东西。在17世纪的英格兰，奥立佛·克伦威尔（Oliver Cromwell）的政府关闭了剧院，因为他们认为戏剧是一种颠覆的技术，会导致人们坠落。在早期的戏剧中，黑帮的电影倍受攻击，是因为他们相信美其名的暴力会导致社会上的问题。哈沃·霍克（Howard Hawks）的电影［Scarface］被延后了二年，以加入一些反抗暴力的场景来取悦道德权威；它最后在1932年以［Scarface:Shame of a Nation］推出，还是受到各方面的责难――但这在今天却以经典看待。电视与漫画书也受到相同的待遇，被骂成社会的疾病（早期的1950年评论家把电视看为［一个吓人的潘朵拉之盒］），现在轮到电脑游戏了。

图15.1显示出目前市场的结构。游戏高手的市场只会购买到顶尖的好游戏。接下来是一个庞大浮动玩者的基础，只有在他们透过任何管道看到有兴趣的游戏时，才会买一个游戏，象是相关产品一样。最庞大的区域，大众市场，是哪些在普通情况下不买游戏的人。这些人是游戏产业视为金牛的人们――而暴力游戏并非打入这个市场的路线。同样的，超级暴力的日本动漫画电影也不受大众市场的青睐，在游戏中的暴力行动是一种特别的品味，只有狂热者才会欣赏。它只是刚好成为大部份玩者，在这个时候成为同一个狂热的党派。如果您想要人们把您请入他们的家中（这与他们购买您的游戏一样的），您很明显的需要承诺可以用合理的方式来取悦他们。大众市场绝对不想把会冒犯并吓到他们的游戏带回家。

产业在未来描写真实性的暴力时，采取的态度应该越严肃越好。电脑游戏在生活中占的成份越来越重，而且有更多的家庭会参与；游戏也不再只是15到20岁年轻人的专利品。事实上，传统非电脑基础的公司，在进入这个市场之后也有很成功的产品（象是乐高与芭比产品）。虽然它们受到高手级的研发人员所嫌恶，但的确表现出业界在这几年来的变化。

适合家庭的内容需求与日俱增，而且这表示暴力的内容最好经常受限，才能保护年轻人，并让父母安心。

推出象是《黑街太保》的游戏，显示出游戏在描述暴力上比以前更为主动，而且也更为真实。不管这种方向会不会增加游戏性，我个人宁愿让它在游戏性上有销售的价值，而不是比较里面的尸体数量。

如果一个游戏中有适度的暴力，我并不觉得有任何不妥，只要它处理得很好。举例来说，在《时空英豪》中的英雄对抗的是军事议会，采用暴力的高压手段来控制和平的人们。这个英雄是海豹部队的成员，而且对武器十分专精，而且从背景故事来看，他很明显没有任何暴力倾向，而是一个负责任的士兵，只有在没有任何选择的情况下才会运用暴力。在目前，电脑游戏中的暴力都是不平衡的――与道德有关的暴力很少拿来使用，只是让免费的暴力四处散布。把这一点与戏剧或是文学相对照之下，暴力最后也会落在猎杀者，甚至是受害者身上。暴力的出现一定与道德有关，而这一点应该是任何游戏运用暴力的一部份（另外提一下，要表达出道德与暴力之间的关系，并不是指您一定要在游戏中处罚任何使用暴力的人，那是游乐场中的道德。一个成熟的艺术，可以利用各种方式来呈现一个困难的主题，并在不说教的情况下探索每一个主题）。

 

［游戏在历史上十分依赖暴力，有二个理由。首先，游戏玩者大部份都是青少年（至少第一代是如此）；第二，技术限制了游戏的环境，让太复杂的互动难以实现…所以Sony的下一代PlayStation2处理晶片，叫做情感引擎（Emotion Engine）不是没有道理的］。

――引用自1999年9月Edge，丹米斯·哈撒比斯（Demis Hassabis）文章

 

每天的生活中都有暴力。您会在电视上、报纸上看到。身为一个顾客，我在这方面不觉得有问题，但是我觉得会有问题――而且我认为在未来是件大事的是――对于暴力的美化与赞扬。如果您的目标市场只是一小群的青少年还好，但那不再是我们的市场了。我们的市场现在包括了很关心的父母与祖父母，而且您可以确定的是他们不会欣赏过度的暴力。当他们知道游戏的内容可能会引发麻烦，当然不会在孙子的生日去买一套《黑街太保》当礼物。

 

［刚开始在画面还十分基础时，您能做的就是给人物一把枪，然后看看他可以打倒多少人。随着科技越来越进步，游戏将拥有更多的想象，将有更多的有趣剧本，而不是更普遍的暴力。］

――丹米斯·哈撒比斯（Demis Hassabis），《快乐天堂》的创造者，也是Elixir的创始人之一

 

我已经指出百事达中的电影并不一定要避开暴力，不过在一个电脑游戏中，玩者参与的感觉要比电影来得强烈。但是，电脑游戏有可能更有严格管理的必要，因它和电视一样都是家中的东西，所以成人会很困扰的就是他们的小孩也会暴露其中。还有，电脑游戏是互动的――当我们看到电影中的暴力时，那只是导演把我们卷入的手法与技巧；但是在一个电脑游戏中（如同现实生活一样），除了自己以外，没有人会尊重我们的行动。

 

孩童产品

一个目前被大家所忽略的市场是孩童市场。只有少数几家公司，试着扭转这个可能性。

这是我认为具有最大成长潜力的区域。并不是因为这些［育教于乐］的产品――他们尝试的教育方式乏味至极――而是二个分离的孩童教育产品与娱乐产品。

我在这边可能有错。很多人看来象［育教于乐］型，但是我个人认为这对孩子而言并不公平。最近，我有一个机会在这方面做了一些研究，我把一个二岁大的孩子放在PC前面，提供一些芝麻街方面的教育软体，让他的母亲玩几个星期。当我回来查看他在二星期之后的测试进度时，我很惊讶的看到这个二岁大的小孩很有自信的在使用者介面中四处游走，点选游乐街的地点并全面沉浸在其中。不过，我并没有她的母亲来得惊讶，她告诉我他已经可以分辨出画面上的数字0到9。

这个广大的市场仍然没有人把门给敲开，而且我很确定的预测，孩童的市场在接下来的几年应该是具有最大幅度成长的区域。不管您给成年人的东西有多酷，这都是您没看到的珍珠。

就算是类似Cyberlife的公司（《Creatures》与《Creatures2》）也正在尝试利用简单版的《Creatures》游戏打开这道门，称之为《Creatures Adventures》。

［《Creatures Adventures》设计在哲学中到处游走，您的目标是教导并指引您的生物，来应付这个世界的其他东西。这个产品提供了积木般的方块，可以让你建造他们的经验，而不用强迫他们按照你的模式来走动。］

――摘自于Edge杂志1999年9月号，设计者班·辛普森（Ben Simpson）所言

 

不管他们采用了正确的方式，或是掉到［帮助Roger Raccoon拯救他的礼物，只要用数字木头来算出总和就行了］的老掉牙方式，我对这方面的特定产品抱着很大的希望。这个人工生命为基础的《Creatures Adventures》表示小孩可以自由的探索并实验自己的步调，避免过去孩童软体中，老是用同样的架构加诸于孩子的身上。

 

研发者的新模型

目前正是困难的局面。如果一个研发公司光想靠着他们的游戏来赚钱是十分困难的。关键在于成功是要靠影响力。这可能靠着技术本身来达成（象是把引擎授权给其他的游戏公司，或是非游戏界的公司），也可以靠着创意的IP（智慧财产权）――《黑街太保》出售相关的服装，萝拉·寇芙特出现在漫画与商业行为，依此类推。

在这个时候，以现有授权为基础的游戏（象007黄金眼）要比用人物为基础的自制游戏（象是《神通鬼大》）卖得好，有三个理由（摘自：研发者杂志）。不过，您必须记得您的授权是花钱买的，而您可以期望利用自己自制的智慧财产权来生钱。

一个对照是流行产业，在巴黎服装秀中的设计永远都不是给大众市场大师消费用的；不过它们会获取注意力，展现出才华，而且描述了这一季的主要流行驱向。如果服装秀成功会有加分的效果，但这并不是主要的；凡赛斯（Versace）可以在一场展示之后把所有的服装秀服装统统丢开，还是可以赚进上百万。

我在看到象是Valve的《战慄时空》这种游戏时，真是感到十分的自豪。他们是在我们的基础上面建造，而且做了十分壮丽的表现。我并不是光坐在这边然后想：［我们也做的到这一点］；相反的，我们想［嘿，我们有从里面抽授权金。］

――摘自于Edge杂志1999年4月，约翰·卡麦克（John Carmack）

 

影响力也可能来自内部。对一个小型的研发公司而言，重复使用是唯一可行的方法――您完成了一个游戏的时候，您目前使用的技术可能已经很旧了。所以连续使用之下的价值就会很差，但是同样进行（也就是把相同的科技、设计理念，甚至是图案在数个企划上面并行）就是不只是优势，在经济看来也是必要的。

很明显的，一个单独的研发公司，里面只有20位员工很难达到内部同时运行的目标。所以，在接下来的几年中，我们将会开始看到产业间的统合。少数的［超强发行公司］将会出现（我们现在已经看到第一家了），而且将会进展为一个很接近拍摄电影的系统。这包括了一个中央集中或是资源收集的中心。

有二个更具启发性的方式是Gathering of Developers（以下简称GoD）联合系统以及由彼德·摩利纽斯的公司Lionhead Studios，所采用的卫星结构。这二家公司采用的方式，是集结一些佔优势的研发人员，并对着附属的研发小组社群，提供支援与协助。

案例研究15.1Gathering of Developers的宣言

下列的内容是摘自Gathering Of Developers(www.godgames.com)的网站。

Gathering of Developers，一个位于德州的电脑与游乐器发行公司，创始于1998年1月，基于产业需要一个能够了解并尊重独立的游戏研发者，而设立的发行公司。在得到他们过去的发行经验与坐挫折的协助之下，数个经验丰富的热门游戏研发公司结合在一块，形成了The Gathering，一相关的发行公司，以［专业娱乐艺术家］的眼光，来看待研发者。

 

目标签名

The Gathering的任务并不是建立自己的品牌，而是建立公司与合作公司的价值，以推广研发者及其游戏。我们的主旨很简单…把研发者与它的创造建立品牌，让顾客可以轻易的辨认出有品质的产品。

 

独立特色

在专注于品质而非数量之下，The Gathering可以提供研发者全面性的AAA级市场高手，以及在他们产品的销售上面，提供一个有利的折算率。

因为The Gathering的根源，从创始开始就源自于游戏研发，公司在产品的领域与研发部份提供了非平行的专家意见，并以决定合适的研发与里程碑周期来进行认可。

在选择过程的部份以其优点、追踪记录和技术与商业上的可行性来决定。公司也尊重研发者的权利，并鼓励他们保留他们本身的智慧财产，而不要以金钱为优先。游戏研发者应该拥有不可剥夺的权力。

 

要把这个模型想成一个没有希望的乌托邦并不难，很象1919年是United Artists对公开的艺术的看法：

 

（电影）Mary Pickford,Douglas Fairbanks与Charlie Chaplin和D W Griffith导演，创始了UnitedArtists，成为一个合作组织以发行他们独立完成的产品。United Artists绝对不会拥有制片工作室；相反的，它所发行的特色影片是由制片家在他们本身或是租用工厂中完成。

――接自Cinemania中的［United Artists］（微软，1997）

 

如果您把United Artists原来创始者的出发点，视为创意远景方面的失败，就表示您没有看到重点所在。这种联盟的优点很多，最重要的一点是，从商业上的观点来看，可以分享技术性资源与管理，所以任何的参与者可以在经济上的销售获利（举例为说，有多少小型的独资研发公司，可以担得起一个动作捕捉系统的费用？）其次，这个建立出来的中央工作室太傘，将可以在下面培育新人：就算是个最优秀的研发小组，在刚开始时仍然得面对许多问题（确保投资、说服房东给他们办公室的空间，安排银行中的贷款），小组这部份的问题得以缓解。第三，中央工作定可以把有才华的结果保留下来，所以在这个系统中的个体绝对不会被闲置。第四，在把研发财务问题与发行公司脱鉤之后，研发小组可以确保得到更多更高的权利金（详见案例研究15.2），而且至少工作室可以保护他们的品质控制，这一点对发行商或是顾客而都是好事（所以GoD强调的重点在于竖立品牌）。

 

案例研究15.2　研发者难为

一年之前，我被拉入了一个小组之中，并为商业计划之下的初生研发公司，设计结构上面的规则。他们从一个发行公司手中获得了开创时的初步资金，所以看看他们谈好的发行合约，来推算销售与收入预估是很有趣的。

他们的权利金从20%起跳，在卖到35万套时升到25%。这让他们大约在卖到37万5千套时才开始获益。在把这一点与发行公司谈过之后，他们设定了一个补偿，让游戏在20万套之后可以回本。

发行公司不这样安排实在没道理。不管怎么说，这个风险应该由他们来担――这可是他们的二百万元！结果是，他们只是建立了自我保护的措施，象是银行的投资必须象放款一样有利息收入，或是冒险资本中的风险一样。

公司的创办人有一些对自己事业的创意。在确保了发行公司的稳定利益之后，他们可以安排自己的投资（从生意上的后台老板）以取得稳健而公平的股权。这甚至可以让他们把完成的产品与其他顶尖的产品竟标，可以把授权金飙到将近45%。顺便提一下，这个后台老板也可能为一个游戏而设立一个特定的公司，就象好莱坞的模式一样，每一部电影都有可能成立一个新的公司。这表示研发小组也可以成长到担下另一个企划，而不用在一开始就对一个游戏［出卖灵魂］。

 

为了在卫星结构中取得全面的优势，独立的小组会全面运用分享出来的资源，如同我们在软体工厂所建议的方法一样。找数个独立的小组在技术分享的合作结构下，并无法达成它原先的希望：唯一的方式就是正统程序。

这种方式类似电影工业的研发模型，拥有一个中心的创意核心，然后被踢除的设计与研发，将雇用独立的人员或是承包商的小组，来进行程式上的筹备工作。不过，您不会想要在您的产品中，采用没有足够资料或是非您所要的元件。这表示：

 

＊创意核心必须监督企划。某个从创意核心而来的人，必须保留全面控制权。传统上，我们可能期望这个人是本产品的制作人，但更可能的方式是转由设计导向的控制方式，所以我们或许可以预期是由企划来领导，比较接近一部电影中的导演角色。我会预期这种工作方式（每个人都可以扮好自己的角色），在您与一些先前合作过而且可以信任的独立小组时有最好的效果，或者您可以把承包商带入您的位置，以取得各种资源。

＊必须有一个标准化的设计方式、程式库与相关东西。如果我在拍电影，我可以和我手下的导演看到分镜，并讨论光线的安排，这样我才能确定他会照我想要的方式来拍。我们需要在研发中有同等的普遍标准。还有（最特别的），有些研发者会慎重的选择，以定义出他们的独特标准――您把只有出现在Navajo字典中的东西拿出来，去怀疑福尔摩斯电视网为什么不这样讲，是没有办法帮您找到工作的！

 

GoD与Lionhead的模型似乎是设计用来创造一种我们正在讨论的［超级研发者］模型。Lionhead的卫星构造会学习做事的基本方法（无论如何，他们的确有这种潜能）：他们分享资源，而且他们相互信任执行时的标准。还有，象是彼德·摩利纽斯这样的超级研发者，可以使用这种结构在一年展开几个企划，而不是每二年只做出一个。假设这个明星的品质（也就是做出AAA级产品的能力）让发行公司愿意付钱，那么让指导的天才不会绑在一个企划，去注意每一个细节是很合理的做法（当然了，这会让研发公司更容易了解全面的设计是少不了的。尤其是他们必须认识测试台是设计阶段用的东西，而不是研发阶段的产品）。

［超级研发者］之所以成为领导方针，是因为发行者（或是他们的股东）已经要求：［为什么我们要在研发中绑这么多的钱？我们是从发行来赚钱的！我们不是在开银行！］在几年以前，很多发行公司直接在内部研发上投资。这表示要养大量的研发人员，任何时候都在烧钱，对一个中型的发行公司而言，相当于上百万美元。少数倾向部份资助独立的研发工作室，或是（从一个发行公司的角度来看）只是购买一个完成的游戏，然后在没有风险的情况下送入市场。

所以，我们会看到一种类似电影工业财务结构的倾向，由发行公司或是主要的工作室来提供自信。Sony公司的总裁最近举例，在世界上面只有五个研发者。这些超级研发者将会与环球或是派拉蒙齐名。这些研发者会构成才能的创意核心，象是软体工厂的在大规模时的设计与结构模式一样。当然了，并非所有的人员都必须是长期员工，就象作者可以从一本书的发行公司换到另一家一样。如果您刚好是投资的银行家，这方面的课题已经很清楚了：您可以在一个超级研发者身上丢个二千五百万，但是不要在一个小的研发小组中浪费掉二万块，因为在这么高的风险下，您永远都不会有回收的。

有些企划是源自于超级研发者的［工作室］。这方面的优势如同我们在案例研究15.2中看到的一样，就是您不用找投资者（后台老板或是其他人）来直接购买您公司的股份。他们想要投资《Shudder》这个游戏时，就直接把钱丢进［Shudder公司］；在这种基础上面，并不会稀释掉您的核心部份（如果《Shudder》卖得很好，他们可以从续集以及人物的授权上面持续获利，从投资的观点来看十分理想）。

其他的游戏将会以较小而初生的小组带入公司。举例来说，一个设计者、规划师以及首席程式设计师，可能对一个工作室的老板们做一个概念与技术上的展示，象是导演、剧作家与明星在好莱坞签定合约一样。在接受了一封来自工作室的信函（［我们很有兴趣制作这个游戏…］）后，他们接下来可以从一个银行得到资助并组织一整个小组（象是拍片的人员）。这是共同合作的好例子，也是经济学上面我们称之为［合作优势定理］的东西：投资者有钱但是没有专业的知识，告诉他们这是一个好游戏。工作室有专业的知识但是不想投资比所需要数字更多的金钱，因为他们要守住优先购买权。研发者只是想要开始完成他们的游戏。

但是超级研发者如何赚钱？就算是50%的权利金，在全面的销售价格下滑之下，您将需要卖到30万套，才能吸引投资者的眼光。嗯，首先，销售游戏的收入并不是超级研发者建立出来的唯一资产；它们会拥有很多的IP。除此之外，研发对他们而言十分低廉（这边又是规模经济），而且他们可以负担起多重的企划研究工作，而这一点对小的研发者而言是不可能的。最后，如我们所见，创意上的巨星可以利用这种模式生产出更多的企划。假设席德·梅尔个人每二、三年可能会想出一个游戏，还是他可以每六个月就策划出一个，然后把一部份的工作委托他信任的亲信。您可能认为游戏的品质会受损（如果采用合理的研发程序，我就不这样认为），但是就算真的受损，象这样的名声仍然可以让市场的力量维持健康的状况。

那承包商呢（这些承包商是由超级研发者所雇用的，他们不只负责程式工作，经常也是包括12到20人的小型研发公司）？他们如何赚钱？最简短的答案是他们不赚钱（至少不象权利金那么可观）！他们只是拿薪水的，好处在于这些薪水将要可以与资讯科技产业的主流等值。我们可以举一个类似的情况，在于作曲家用他们的作品换钱；或是在电影方面：导演和制片与明星可以获得丰厚的权利镏金，但是如果您是一个摄影机的操作师，您必须拿薪水才会工作。

那发行公司呢？他们的优势在于买了一个产品，而且这个大家都知道这个名称代表的是具有创意的力量（我可能就是那种人，象是威尔·怀特，或是其他众人皆知的品牌，象是Blizzard）。他们知道这将遵循品质上的标准交准时交件，而且在新的模型中提供的额外信任与减少风险，将值得把权利金加倍。发行公司会继续以很低的风险赚进大笔的钞票，不管零售商尖叫着他们办不到。不过，如同保证会上线或是在网页上面的购买行为一样，发行公司的损失将会越来越小。最后，就逻辑来看，我们只会看到一家大型（以网路为基础）的游戏发行公司。

 

线上的革命

在十年之后，我看不到人们从商店中购买游戏。如果您有一台电脑（如果您要买游戏的话，应该早就有这个东西），那您为什么不从网页上面直接购买？这不只更为容易，而且您还可以利用观看动画或是试玩的方式，过滤出您想要买的游戏。

 

线上买游戏

目前的科技趋势，在于让游戏执行的速度加快，而下载游戏的速度仍然不足，产生了一个科技上的空隙。不过，在二、三年之后，它有可能在玩者越来越倾向于网上购买游戏，而让零售业慢慢的消失。

 

由BT、ICE、电子邮件订购单所看准的Wireplay,正是新创立公司Gameplay.com的着眼点，目前已经出现在AIM市场下面数个月的时间了。Gameplay计划升到310万。Gamplay.com将会提供客户一个完整的线上游戏环境。在与Futuregamer.com合作后，将会为Gameplay网站宣传并提供链结让玩者互相较劲，并透过线上机制与Wireplay的技术来购买游戏，并由ICE来运送。

――摘自1999年7月16日的MCV

 

Gameplay.com在1999年8月份开始在Alternative investment Market之下营运，成长到460万；要比预期的多出了150万。这个新公司的价值为790万，而且据一些预测看来，应该很快就会让它的资本结构加倍。它在财务方面的部份似乎是信心十足，而这也是未来产业的走向。

在线上订购您的游戏，并不表示您可以从线上获得――不管怎么说，没有人想要把小说下载回来并在家中印出来看，但这并不会影响到Amazon的生意。不过，直接从发行公司的网站下载回来当然是最好的方式。未来的线上发行公司，象Gameplay一样，将需要找一个方式来让下载的速度更快、更简单而且没有麻烦。一个方式是提供一些牟取预览的资料，让这些资料的传输更为快速。我猜，这并不需要是完整可玩的试玩版，象是您现在从杂志附赠的光碟上所拿到的游戏一样。发行公司有很多产品，而且他们要您尽可能的看看他们的动画。所以，我们可以看到游戏试玩的出现，将和电影的广告试映一样会越来越多――将形成一些较小却更完美，足以说明整个游戏是否合您胃口的片断。有兴趣的顾客会在完整近艺术的评析、全面的试玩以及其他任何东西带领下，被一步步卷入游戏中。

要解决下载时间的问题（也就是鼓励使用者直接从他们手中购买游戏的方式），线上发行公司须要建立一个基本的程式库封包，只要下载一次就可以用在所有的游戏上面。然后，在理想的状况下，只有主要的游戏逻辑与图案需要从《雷神之鎚》中传送过来，就可以用在《战慄时空》这种相同基础的游戏中。在这方面，必须结合研发公司与超级研发者，来进行［一次解决］的游戏结构，让他们的游戏可以适应这个架构。在目前，只有微软有可能执行这种规模的企划。

 

线上玩游戏

最近，一些专门提供线上内容的公司兴起，象是在恐龙群中出现的哺乳动物一样。或许他们相信，其他人会和恐龙一样，在无法适应之下死亡。

或许这一点解释了象是Origin公司，逐渐走入线上游戏，提供了《网路创世纪》的原因，塑造出一个神幻的Britannia世界，让玩者加入其中的社群。不过，这真的只能锁定资深玩者。

 

资深的网路创世纪玩者一天大约会玩上六到八小时。您可能花个八小时睡觉，然后一些时间用在工作与学校上，剩下的时间就是在上网。

――理查·盖瑞特，在PC　Gamer杂志1999年9月的访谈

 

线上游戏在欧洲会有一段阵痛期，这边的当地电话每分钟都要收取固定的费用。不过，电话公司会达成协议：如果他们把价格降低，大家都做得到生意――如果他们太贪心，就抢不到这块大饼。

另一个线上游戏的主要缺点，在于它们很难有大幅的成长。大众市场对每天都要花时间上网才能玩的游戏没兴趣，他们要的是能够自由选择娱乐时间，而且就算他们没有花时间去养，也不会有什么关系的游戏。线上游戏会变得很大，但是在这个限制下，它不会象权威人士想象的那么广。

 

最适者生存

唯一可以让游戏研发占用经济优势的方法，就是采用本书描述的过程。我们知道的原因，在于这个方法已经有一个公司在得到发行公司赞助之后，创立采用延续到今日。唯一可以让研发公司在未来还能生存――在合理化过程上仍有压力――就是采用这本书的技术。这些方式都经过尝试与测试，而且已经可以看到它们的优点，要比任何其他的方式更多。

公司现在必须开始实施这些标准与相关的用语，或是直接被丢到路边去。虽然有人会反抗这个说法，但是整体上再不做一点事，结果就是经济效益不足，让研发公司无法营运下去。

如果您取得一个明星的大名或是授权，您就可以卖出上百万套的佳绩。如果没有的话，您顶多能卖到25万套。您的经营计划必须让您能靠着这个成果存活。如果您计算一下的话，您会看到达到这个目标的合理化过程，让您同时省下金钱并减少上市时间的损失，而且可以增加内容的充实性。

、、、
没有评论

达达尼昂 | 资料收藏 |
《电脑游戏结构与设计:理论篇》第十三章 程序与［过程］【转】

  

第十三章　程序与［过程］

 

＊程序

＊［过程］

＊原始码控制与程式码回顾

＊资讯传递的重要性

＊主动与反应的资讯

 

在这个章节中，我们将会讨论运用软体工厂的概念之后，若想要在成本效率上有良好的成绩，必须进行的程序与实行事项。

不过，这些程序与实行事项并非受限于软体工厂的范畴，它们可以在所有非琐碎的研发中占有优势。大部份在研发中的软体（尤其是游戏软体）在研发方式上面并没有真的程序化，一般的游戏企划在成长时，只是从［稍有系统］到［很有组织］而已。

这个章节中提及从管理观点来看研发过程，而管理的部份则是藉由状况报告以进行控制。满足管理部门的兴趣，是程序与实践的主要理由。

管理者想要取得精确的资讯以及状况的报告，然后以这些资讯来判断未来的行动国，不用打扰研发方面的工作。同样的，研发者不想让管理者不分青红皂白的介入，并在一连串没有重点、浪费时间的问题下，打断了研发的过程。

这些程序与实践将会包括互动的介面与区域，让资讯可以在随时不断更新的方式之下传送，并定义出控制流程，用来引导研发的方向。

这个［过程］并不见得象您想象的那么糟糕，它大部份都是与常识有关的。不过，最好的［常识］，就是把它写下来让每一个人都很清楚这边所指的［常识］究竟是什么。如果每一个人对常识的概念都不同时，它就会碎裂成不同的看法。

这些过程的执行是否要延伸，端看企划的需求而定。一个很重要的企划，就需要用严格的方式来进行：而较不重要的，可以用比较轻松的方式来看待。

 

程序

在这个章节中讨论的程序类别，都是减少劳力浪费的基本控制与方法，并在低品质的成果污染整企划之前，将不良的部份拔除。

　　

下列的程序列表，是在企划的进行时程中，维持精确企划资讯以及控制的建议事项。每一个程序都在后面的章节中进一步的说明。

 

＊设计回顾

＊文件回顾

＊技术回顾

＊程式码回顾

＊单元测试

＊整合测试

＊系统测试

＊设定测试

＊后退测试

整体来说，［回顾］行为在找寻与侦测上面，要比单纯的测试来得好；先决条件是把回顾力量集中在找出问题，而不是修正问题。另一个附加的好处，在于回顾也倾向于找出不同类型的错误。

 

回顾

回顾的格式大体是相同的，只不过回顾的东西不一样。

二种类型的回顾有［正式］与［非正式］。要进行哪一种类型的回顾，端看工作的本质来决定。这个工作与内容有密切的关系，而且正式与非正式的比率，也是由情况来决定（这一切通常是由企划管理者在分派工作时决定的，但是个体的贡献也有可能影响这个决定）。不管怎么说，企划管理者知道工作究竟有多复杂，所以他（或她）应该可以说明哪些东西需要回顾一下比较好，重点是没有什么工作可以不经过查核的手续。回顾通常是在一个企划受到时间压力时，第一件半途而废的事情；这通常是一件大错误。省下这一点时间，通常会造成长期有痛苦。

只是把没经过查验的工作插入企划中，然后发现没有倒塌就认为一切OK，算不上什么好事。这种［方式］并没有在企划时程表中，指出会出现的任何难题，更没有告诉您这些工作是怎么完成的。回顾可以让您在早期的阶段中，拔除任何明显的错误――在他们进入企划之前――而且对于预防低于标准以及虚有其表的工作而言，这是最好的方式。

在一个不进行回顾过程的企划中，低水准的工作会变得难以侦测并存在很长的时间。这种类型的问题会等到很久之后才显现出来，通常是在某些人修护或是更新受影响的地区时才会发现。在这个时候，又有谁知道这个毒害扩散的范围？后期的工作可能是以这个反复无常的原始工作为基础，导致邪恶长存。

回顾还有其他的好处：它可以让所有的员工共享并散布相关的知识。由于这个工作会在一个小组中进行讨论与回顾，这些知识会传播到所有人之间，大量的降低了风险。

 

非正式的回顾

非正式回顾很简单，完全没有真实的纸上作业，也没有复杂而耗费时间的会议。

一个非正式的回顾包括了把数个小组成员集合在您的萤幕旁边，然后与他们讨论您的工作，如果能进行一段排演会更好。

这些回顾可以用数个不同的方式来完成。举例来说，在一个非正式的程式码或是设计的回顾中，您可以选择几种不同的方式，象是简单的排演与视察，虽然这些作法一样可以在正式的回顾中运用。

排演是由这个工作的作者来指挥，主要的作用在于可以用很简单而且容易了解的方式进行回顾工作。排演的优点在于快速而简单，而且它可以忽略掉工作中的科技品质。这并不是一个真正的评估，比较象是一个评议请求（request for comments,RFC）。这也是一个分享技术与经验的好机会。如果一个回顾原有更好的点子以及更佳的工作实施方法，也可以在这边传达给作者。这种交谈也是很正当的；有时候回顾员工会学到一些新的技巧。

讯息的传递协助了分散大量知识到所有的人身上，所以会降低小组对单一人物的依赖。在理论上，每一个员工都应该努力淡化本身的地位，没有一个人是绝对重要的。很明显的，以这种方式来工作，管理阶段不应该在任何人身上加诸压力与紧张；要让一个人做出更多的事，就在他身上加诸更大的压力，这种观念是错误的。要让人们全力表现出他们的能耐，他们必须尽可能的放轻松并有安全感，而且还要了解他们在做的事情，需要在期限之前完成的重要性。这已经造成足够的压力，而不用靠着管理阶层来做额外调整。

不过，排演并不一定都是乐观的，因为在一个回顾过程中，大多是以最没效率的方式来进行。在统计学上来看，排演的有效程度有很大的变动，能打到的错误比率可能在30%到70%之间。

其中的一位回顾员通常是您的技术管理者，而他（或她）可以让您的工作有保证。在这方面完成之后，只要有任何主题（或是问题）在讨论并解决之后，就可以插入企划的主要贮藏室之中。这边很重要的一件事是，技术主管不应该在这边以管理的权威施压，否则在作者觉得有必要让他的作品发扬光大、证明他自己的同时，会让结果变成其他的东西。这件事并没有发展到这个程度的必要，它的目的只是讨论工作并侦查出任何明显的错误。

从另一方面来看，视察几乎是排演的相反。这并不是与作者谈论并一路看完工作内容，而是要技术管理人员拿着韁绳并看着排演进行。这边需要以全新眼光来看工作内容，可能有助于发现作者遗漏掉的问题，这是因为作者［太熟悉］作品所导致的。不过，缺点就是这一类的视察要花漫长的时间来进行，不过至少它有很大的机会找出错误。

如果在回顾的过程中，有人找到了问题并靠着一些动作或是变更修正，那工作内容就需要原来的回顾员再回顾一次，包括那个第一次提出要求修正事项的人员。这个随后而来的回顾是否正式，必须靠着它的本质来决定。庞大的变更需要正式的回顾，但是较小的调整以及改善只要非正式的回顾就行了。至于变更控制，它本身就是一个庞大的主题，将在第14章中讨论。

非正式回顾的危险在于它们有可能变得太不正式。所以，在一次回顾中经常指派出负责人员，是一个较好的方式。这个非正式回顾也是正式回顾的一部份。一个没有效率的非正式回顾可能比完全不回顾还糟糕，它会逐步把错误的安全感小组之中，导致最后出现大麻烦。

 

正式回顾

通常在一次回顾中会包括四到五个人。这一个回顾小组的人员，是从合适的群组领导者中遴选出来，而且先前的负责人员也应该包括在内。只要有任何没效率的东西，就会让所有东西都没效率。

作者的责任就是确保所有的回顾员都充份了解他们要看的东西，才能展开这场回顾；这可能包括影印好的工作内容，并回答任何回顾员在进行之前的所有问题。

回顾员的责任就是确保他们十分熟悉要回顾的东西。回顾会议真正的目标并不在这个成品上面，这会花掉太多的时间。回顾会议的目标是让回顾员在会议之前，详加讨论要回顾的内容。

所以，在会议之前回顾员应该完成一份回顾表，列出他们想要在这个会议中提出的重点。视回顾的规模大小，他们应该要花一到二小时的时间，看完相关的资料。一个简单的回顾将在第15章中提出，其中包括的RTF（Rich Text Format）文件已经附在本书的光碟片上面。

基本上，回顾表是用来提醒回顾员，让他们不致于忘掉任何要观察的东西。结论将写在列表中，并以不同程度的严厉眼光来看待，象A是最严重的错误，而E是最小的问题（当然了，您也可以选择适合您自己的分级方案，但这种方式最为常见，而且最容易了解。这简直象是回到学校一样！）

工作的内容应该以数个标准来回顾，其中的［符合需求］是最重要的一点。这才是我们应该要求的东西。能够与企划和公司标准相符也是十分重要的，但是功能很明显是第一优先事项。

在会议中，回顾表上的每一个要点都要提出来讨论。这个会议将从负责人员的展示开始进行，这一场展示将会概略性的说明工作内容，并开始讨论其中包涵的东西。

很多人遗漏的一点是，在一个回顾中的批评并不是针对任何人，或是对完成工作的员工进行人身攻击。回顾的目标是取得第二种意见，把工作中出现的问题拔除。让一群人专注于一个想法，可能会更容易找出问题所在。这个回顾应该集中力量于找出问题；这个会议并不是用来讨论解决方案的。这样做只会让所有人分神，目前并没有必要把所有的问题都解决掉。

回顾会议的真正本质，事实上就是钜细靡遗的找寻错误。它只是在一场独立的回顾会议中，利用讨论来进行资讯分享的时刻。在回顾的过程中，其中有90%的错误是在会议之前找到的。

一旦在回顾表上面的所有重点都讨论完之后，他们就可以进入［行动状态］。基本上，这些要点不是被接受，要不然就是遭到拒绝。如果它们被接受了，那么作者就必须进行校正的工作，来满足提出这些要求的人。如果有超过一位回顾员提出相同的缺点，只有其中一个会取得问题的［所有权］。他们考虑到的所有重点都必须合并成一个电子回顾表，将与工作一块储存起来，以待日后查验。如果这些变更会显著的影响功能（例如它牵涉到其他的区域），那就有必要召开一个变更控制的会议，讨论任何逆向效果中的控制与限制。

视需要变更内容的本质，可能必须进行另一次正式的回顾。在这种情况下，应该运用同一组回顾人员。如果所需要的变更级小，那一场非正式回顾就应该足够了。作者需要让每一位回顾员在他们指出的要点上签名。一旦这一步完成之后，工作就可以插入企划的主体中。

这一切听起来象是一场冗长的过程，而且――说实话好了――的确如此。不过，我已经发现只要能预防次水准的工作进入企划，那就可以大幅节省您花在回顾上的时间。

我也发现了一点，如果有人知道他的工作会被人拿来回顾，他们在工作时就会更加小心并注意各个细节，而且对他们所做出来的东西更为自豪。这可以增加注意力，对士气有正面的好处。人们知道他的工作在检查之后即将纳入企划，所以企划代表了更高的标准（而且风险也会大大的下降）。在这些理由下，回顾大约可以增加20%的生产力。绝对不要低估提升员工士气对输出结果的正面效果。

由于游戏研发的本质，执行回顾的工作会受到一般性的抵抗。要压制这种抵抗的最有效方式，就是收集回顾中找到的错误，然后算出找到每个问题的平均时间。把这个统计数字，与研发后期修正这些错误所要花费的时间（与金钱）相比较，就没有人说得过您了。

 

一般测试

如同我看过的很多企划都没有回顾系统一样，我从来没有看过一个没有测试系统的企划。

我看过很没有测试效率的企划，而且这些通常很容易发现。当游戏推出后处处都是臭虫时，它通常有一到二个理由：这个测试就是够不上水准；或是研发小组的时间用光光，发行公司已经受够了，所以一定要把它丢上市面，不管里面有多少臭虫。在这边，我们先来考虑第一种剧本：次水准的测试。

测试是找寻错误的过程，您在程式码中预期可以找到多少错误？就算是陪审团也无法得到一个正确的数字，但是在业界中粗估的平均数字，是每一千行的程式码，会出现15到50个错误。在游戏产业方面我会稍微高估一点，虽然这方面可能会视游戏是小型或是中型企划，而有所不同。

测试是在找寻研发任何阶段中，可能发生的数种错误：但是，一般来说，测试可以侦测出来的错误，只限于原型与程式设计的阶段中。请牢记这一点，只要一个错误没有被抓出来，时间越久要修正它的费用就越高。如果在设计阶段出现一个错误，在实施到一半时才要修正它很显然要比在设计阶段中，把它抓掉更费时费钱。

事实上，这是实施这个过程的主要理由。它可以让您试图去［相位牵制］；不是，这不是与［星舰迷航记］有关的东西（虽然它应该也是）；这边的相位牵制，表示您要在创造的阶段去侦测并修正其中的错误。一个标准的统计指出，在创造时发生的错误如果没有抓出来，事后的修正要花费将近200倍的时间。很明显的，侦测并修正错误的动作越早做越好。

同时，也要记住测试本身并无法影响软体的品质。尝试藉由测试来加强软体的品质是没有用的；它的作用只不过是品质的指标。它后面必须附带着决定性的方式，才能加强品质；让这些额外的效果反应在下一个测试过程中。

在这部份提及的测试，指的是针对程式码；所以下列的章节中，指的就是程式码的测试。

 

非正式的测试

［非正式的测试］与［非正式回顾］指的并非同一件事。这边并没有必要把一群人聚集在萤光幕前面，因为非正式测试只是任何研发者，在进行程式码模组研发时做的测试。

每一个研发者在撰写一个程式时，都会周期性的将程式码编辑并进行测试（至少我希望如此！）这是一个很好的出发点，但是这并不足以预防爬进程式中的臭虫――尤其是在模组整合的阶段。

大部份我看过的游戏研发企划中，只有运用到这种类型的测试，再来就是让一个有活力的人进行游戏测试，一直延续到企划结束为止。这通常只能勉强合格。

为了加强非正式的测试，有为数不少的自动错误侦测应用程式（象是Numega Boundschecker）以及程式设计的技巧，可以用来找出明显的错误。

它真的有用，但是如果能再加上一些基本的测试程序，这个风险可以明显的降低。虽然是否要进行正式测试，必须看工作的本质来决定，所有在这边讨论的测试阶段，都应该以一种或是其他的形态来实施。

 

正式测试

正式测试十分类似非正式测试，只不过它们比较具有结构性。

一个特殊模组所提供的测试描述，将用来对这个模组的所有功能与特色，进行耗损性测试。这段描述通常是由该模组研发人员中的软体规划师所撰写。

测试描述是以一种特别的方式来撰写的（一个简单的测试描述将在第15章介绍，而且以RTF格式的文件放在本书的光碟中）。这个测试应该是设计用来执行这个模组中的每一条程式路径。因为要完成这个工作并不是简单的事，所以测试描述本身也是回顾的重点之一。

三种主要的测试可以用这种方式完成：正向、负向与特别。

正向的测试是在检查预期的行为，所以这些测试是写来让模组产生预期结果的。一个正向测试的例子，是对一个专门用来画三角形的模组传递一连串的方位，并预期在画面上看到正确的三角形。

负向的测试是在检查预期的行为，所以这些测试是写来让模组产生预期结果的。一个正向测试的例子，是对一个专门用来画三角形的模组传递一连串的方位，并预期在画面上看到正确的三角形。

负向测试则是查看没有预期到的行为，而且这些测试是针对产生例外而且还能控制的错误状况。一个负向测试的例子是对一个专门用来画三角形的模组传递三个相同的数值，或是排成一线的三个点。这时应该可以测试临界的状况，在您送出三个很大的数值（正值或是负值）时会出现什么情况？那一串很小的数值呢？或是送三个零进去？

在规划测试时，试着考虑各种不同的输入值丢入系统，不管是有效或是无效的数值。这些物件将以各种可能压迫系统；把您找到的任何东西统统丢进去。您可能发现并非所有东西都会出错，但是您可以除掉其中最麻烦的问题。

特别测试是乱数的效果。测试者要玩弄模组，并查看他（或她）是否得到预期的结果。这些测试只是把一些测试者想要的东西丢入模组，举例来说，他可能把一组乱数产生的点丢入绘制三角形的模组中，并查看输出的三角形是否正确。

很多组织只会使用这三种模组的其中之一，但是要进行真正有效的测试，这三种方式都该使用。如果一个测试模组已经写好，可以把这三种测试隔离测验，那就应该让测试者可以任选进行的测试项目。

当您在执行一个测试描述时，结果应该以电子档的方式记录下来。这些测试应该以文字说明，让结果可以表达出［真］或［假］的回应。在一些例子中，需要进一步的描述才能得到正确的结果（尤其是在测试失败时）。

如果一项测试失败，那么就要进行下一步的行动。一项测试的失败理由不外乎二项：问题在于程式码，或是在于测试。这二者所采取的行动都是一样的，测试者站起来回报问题，并展开修正问题的工作。

 

单元测试

单位测试是研发者进行的第一波测试行动，而且它是一种开箱测试，表示测试者完全了解要测试对象的从里到外。从统计学中显示，在平均的情况下，单元测试可以在程式模组中，找到将近一半的错误。

单元测试通常是以严格的方式来进行，它会设计一个简单的程式，该模组中的每一种功能动作。这可能简单而且没有互动性，或是它会更为先进并容许设定输入的参数。

单元测试的用途如字面所示：它是在隔离的状况下测试。这可以预防其他方面的互动，象是容易出错的模组。这就是为何要限制测试环境的原因，而且也是为何这个限制的测试环境要越简单越好。有好几次我在测试结果中找到错误，最后发现它居然是源自于我所使用的资料！如果您在程式码中找一个虚幻的问题，最后发现是您输入的测试资料出错一定会让人心灰意冷（我试着将它看为提升经验的练习，我真的这样做了，但是我不会建议把这种过程，做为判断您神智清楚的举动）。

单元测试可以在数个不同的层级中施行。如果我们拿C++做为例子，那单元测试可以在模组的层级或是物件层级中进行。对那些不熟悉物件导向科技（您之前看的是什么？）的人而言，一个物件是一个逻辑性的资料与程式码封包，可以用来处理资料。这个程式可以分为许多方法，类似于程序化程式设计的功能。物件等级的测试是一个黑箱测试，而方法层级测试是一个开箱测试。

当然了，测试无法保证模组中不会有任何错误。一个测试只能证明模组中有错误，但这就是要牢牢记住的重要规则。如果一项测试显示出模组中没有错误，那比较可能的情况，是这个测试本身不适用。或许它没有包括了足够的状况，也可能测试本身有问题。

要让研发者的想法倾向完成的东西非测试不可，实在有困难。一个成功的测试可以找出破碎的程式；您所认识的人，又有几个人愿意主动把自己的程式打破？

事实上，这是一个别有含意的问题，而答案应该是所有人。如果不是的话，那这些研发者还不够彻底。不幸的是，我注意到一些研发者在写好程式之后马上宣布他写完了。他们似乎很厌恶在自己的程式码中找出错误，就象这个举动会指出他们的弱点一样。

这一点在游戏产业中特别盛行，让软体之狼四处横行。在某些公司中，指出任何迹象的弱点，象是取得把东西撕碎的特权一样，只留下您被四分五裂的尸体，被兀鹰吃得一干二净。

每个人都会犯错，这是很自然的事，但是它代表的不只是一个错误：您是要在自己的程式码中找寻并修正一个错误（承认您自己的失败），还是要拒绝接受您会犯错的事实，甚至不想全面检查？

研发者应该主动查看并打破自己的程式码。他们需要进行测试，假定程式码是一个有臭虫的謎题；事实上，他们应该真的想要找出错误。用这个角度来看吧：您宁愿让谁找出您程式中的错误？您，还是其他人？

如果您先假定不会找到任何问题，那就有可能找不到任何问题。这并不是因为真的没有错误；这是因为研发者不愿意仔细而且努力，去注意该注意的地方。

 

整合测试

整合测试是研发者会进行的下一阶段测试，虽然它也可以由其他的组合来执行。如果由一个测试小组的成员来做这件事，那这就是一个黑箱测试；如果是由研发者来进行测试，就是一个开箱测试（在进行整合测试时如果能由研发者与小组中测试者同时进行更好。不过，整合测试是介于单元测试与系统测试的中途站，所以这并不是一个严格的规则）。

整合测试是测试新的程式模组，与现有程式基础是否能够整合的测试动作。它会造成组译上的问题吗？名称领域是否出现碰撞？它真的有作用吗？

这个程工测试――在必要性上面――并不需要单元测试那么详细，因为在这个测试中，要看的就是模组在程式环境下的运作情况。您几乎可以把它形容为模组的［实战演练］。

整合测试的焦点在于解决一个新模组整合进来的技术问题。在理论上，模组本身应该在单元测试之后已经没有错误。在整合之中，一些在单元测试中没看到的问题，通常会以十分明显的方式出现。这些可能会让人倍感挫折并很难查出来，提供您一个正确的动机，在这个阶段之前把所有的问题尽可能摘掉，而且您绝对不会把这些问题留到系统测试的阶段。如果您觉得在整合阶段进行错误诊断十分困难，那您应该试试到系统测试中找出一些小小的臭虫再来说这句话！

这个测试应该与单元测试差不多，应该写好一个描述，来执行每一条程式路径。

在整合测试中的一个严格的规则是，一次只能整合一个模组。这是一个简单而明显的规则：如果您把二个以上未经测试的模组同时整合进来，在找出问题的来源时，其困难程度将会以指数曲线上升。它们可以到处都是错误，或者它们可能在相互作用之后，以未预期的方式来运作。不管是哪一种，都是您绝对不想踏入的领域。

好消息是，利用物件导向结构的系统整合，并不会比早期的古老日子中，采用程序化的程式设计难到什么地方去。物件导向技术可以让所有的东西都简单点。游戏研发在采用这些技术上已经慢了一步，主要是因为物件导向应用程式被认为是慢火炖煮的软体，而且在编辑时大家都认为产生出来的程式码很没效率。

这些在早期的恶劣日子中或许没错，但是因于现在这个时代已经可以与作业系统合作；如果一直抱着把系统每一分效率都逼出来的想法，会越来越困难。除此之外，靠着物件导向API（象是DirectX）扮演将游戏与基础硬体加以隔离的角色，运用程式语言让研发更为容易，是比较合理的作法。

一旦整合测试完毕，这个模组就可以签名了，它已经是基础程式的一部分了。

 

系统测试

系统测试是一种至少要每天做一次的事；如果这不可行的放在，最少也要每星期进行一次。如果比这个频率更长，系统测试就会失去它的效用。程式码在每星期的变动量实在不小，如果要修复破损的程式码，却有其他的程式已经改变或是其他程式码以它为基础时，就是一件大工程了。系统测试的频率指的就是这种事情，在某些状况下，并不是所有系统都可以进行测试。这通常只有在最大的企划中才有执行的需要，而且大部份的游戏应该可以每日进行系统的测试工作。

为了方便起见，这个软体需要每天都处于可以扩建的状况。事实上，这是最主要的需求，不论系统测试是不是每天都要进行。这个软体应该在可以扩建的状态下，并不是指它要发挥所有功能；子系统可能还没写好，在这种情况下应该把它关掉。在这边指的［关掉］应该是由界面所定义的，但是目前还没有这个功能，所以它必须转换成［关掉功能］并输出一个除错的讯息，或是出现一个预期的错误，视这个界面的重要性而定。这个结构已经大部份都完成全面定义，让研发者可以轻易的取用。

扩建刚开始时，会由测试小组来一个烟雾测试，看看它是不是够稳定。这边的烟雾测试是从电子工程方式中引用而来的，用来测试刚建好的装备，看看它是不是会运作：他们把开关打开，如果它开始冒烟，就表示没有用。

如果没有通过烟雾测试，这个成果就会被退回。研发者在修整这个扩建的东西时，具有最高的优先权。这个东西损毁的时间越久，表示测试小组浪费的时间越多。这并不是一个好状况。

一旦这个成果开始运作，它就可以在资源控制系统中贴上一个标签。所有好的资源控制软体，都可以让您什对内容做一次［快照］，就算它有更新的档案在后期加入也能重新创造。每天制作一个快照是十分重要的，因为它可以确保测试小组在这个成果上面再多花一天的时间。

为这部份安排一个合理的每日行动系统，可以保证所有研发者在下午三点都签好名字。完成的程式码与模组就可以从资源控制系统进行查验，然后进行全面的系统建造工作。

同一个下午就可以进行烟雾测试，而且系统测试也可以在接下来的几天由测试者施行。扩建一个游戏的时间要受到限制，才能让系统测试者有时间进行所有的测试。

系统测试应该在二种层级中运作。第一个层级是执行测试描述，来检查是不是所有完成的功能都如同宣传般运作（这是系统测试中，有效的正向与反向测试）。这些测试的描述写法，很象是按照软体结构撰写的：在这个层级的测试中，主要在于结构设计的错误，而不是低级程式码的错误。当然了，有些在整合测试中没出现的问题会在这个地方冒出来。

第二阶段的系统测试，相当于特别测试。测试者应该玩这个游戏并测试所有的程式功能，看看是不是如预期的表现一样。他们应该看完手册来安装并设定游戏，而且遵循游戏的说明，看看他们能不能进入游戏中。

这样做有二个目的：把可能在程式码中到处乱爬的错误抓住，并提供初步的游戏测试资讯。很明显的，如果游戏仍在很早期的阶段，这一点可能帮不上什么忙；但是随着企划的进展，它会越来越有用。

在系统测试中的结果应该以电子档记录下来，而且任何的错误都要回报给企划管理者，来指派相关的人员去解决。

 

设定测试

设定测试是系统测试中的延伸。它是不同硬体设定之下的测试行动。

这对游戏而言特别重要，因为它们通常比较依赖硬体，而不是标准的应用。测试用的主机范围应该要包括市场上面的常见机种：从尖端的高速怪物，虚弱、年老只有少量资源的Pentiums，还有中间的所有东西。

还有，没错，我知道DirectX与其他的API应该可以解决所有硬体相容的问题。但是，如果您真的相信这一点，您真是有罪到什么东西都会信（如果您真的是这种人，给作者一封电子邮件。我们为您准备了一个投资的好机会！）

老实说，这个等级的设定测试对一个普通的研发工作室而言，通常超出了它能负担的范围。不过，一些独立的测试公司也可以帮助您解决这些问题。

如果这些资源无法在公司内取得，那么一些独立的测试公司可能是您最佳的选择（而且要比推出一个只有靠您研发用的机器来测试的游戏，要好得多）。

 

后退测试

后退测试本身并不是一种测试，相反的，它与这边讨论的所有测试都不一样。

后退测试是把目前相同的测试数据重新执行的动作，不同的地方只有动作的模组是前一个还没修正过的版本。

后退测试的用意是确保模组不会从早期的形态逆转。其中最常见的一种错误，就是再导入之前出现的错误。这个后退测试可以检查出是否有任何老旧的错误出现，而且它可以用在所有先前的测试类型中。

 

［过程］

在开始之前，我们会看看研发的概论。在每一个阶段的研发中，都需要产生出正确的状况讯息。所以，我们这边需要一套程序，也就是之前说明的东西，才能做到这一点。

图13.1　什么是一个［过程］？

在图13.1中，显示出一种目前流行的模糊研发阶段。在现实中，在数个不同的要素相互交织之下，组成的主要研发要来得复杂得多。这个图表并不打算呈现这一点，而它的要点在于指出一个讯息传递界面――所以才需要［过程］这个东西。这个章节的其他部份，将致力于讨论如何实施这些方法，让这个方式不致于成为疯子的举动。

过程通常被大部份的研发社群鄙视为一种高高在上的方法。在研发社群中的游戏撰写部份，更是受到一致的嘲笑。过程被看成全面浪费时间（Waste Of Time,WOT），并会减少真正有用的内容（Really Useful Work,RUW）的完成时间。

一个WOT的例子包括重写一个老旧的程式码，以期与新的程式码相容；重写一个结构；以及无法控制的修正与变更。

这些研发者相信过程是完全没有必要的上层。他们并不把过程可以预防的额外工作，纳入他们的考量之中。

图13.2中显示出他们怎么认为这个工作会干扰到一个标准的企划。企划的工作中只包括了撰写新程式码以及修正旧程式码（RUW），而上层有一小部份的时间，是在处理小组中的动态：会议、重复其他人的工作，以及其他的WOT。

在图13.3中，显示出这些研发者在相信一个企划中要有过程时的表现。他们相信过程可以在一对一的情况下，直接减少RUW。在每一小时的过程下，企划就会损失一小时的RUW。如果这个过程很不适合目前的企划，这是有可能的；但是如果在十分切合的情况下，这个图表中的状况一样是错的。

在图13.4中，显示出一个没有过程的企划中，真正的工作分配状况。在企划变得越来越大，而且越接近完成的时候，WOT的数量会随之增加。增加的比率视在企划中工作的员工能力，以及好运的程度。

在图13.4中显示的是一个普通的企划。WOT的数量会随着加入企划研发者的数量而增加。在小组成员之间越有互动潜力，就更有造成混乱的潜力。

这个过程的效果（图13.5）――如果目前使用的程序是为这个企划精挑细选――就可以增加有效的工作执行并降低WOT。很明显的，这些是无法完全消灭的――没有生产力的工作会一直存在――但是这种良好的程序将足以提供双向检查（以及可见度），把这些降到最低。

这些过程必须随着企划的人员数量而缩减。如果这方面很有效率，那么这个过程的WOT与RUW比率，应该会维持固定的数值。

过程的麻烦之处，在于它真的很难在［过程数量］与［工作数量］之间达到平衡。在许多情况下，严格的制式化程序会在无视［企划的类型］以及［研发者的需要］之下，硬性的发挥作用。在这一类的状况下，这个过程会比不用更糟，因为它对研发者会造成示范的作用。这个过程在这边应该为企划小组所用；企划小组不应该去奴役过程。

 

案例研究13.1　疯狂的过程

在制作一个规模庞大的银行企划时，我发现太多的过程，要比太少的过程更具毁灭性。

这个特别成套的研发过程已经完整的写好相关文件，而且要遵循一个极端复杂的规则，放在一本300页的文件之中。

这实在太荒唐了！三百张纸？哪一种过程需要用300页，来告诉一个研发者如何在一个特定的企划中撰写程式？还有更糟的，这个过程追踪系统是以公司中自制的Word Basic写成的（这是与微软Word软体同时推出的程式语言），完全无法用在这个工作中。

维护一个程式模组，有时候需要超过20页的文件，有时只是一份简短的文章。表格可能需要二页或是三页才印得完。接下来这些东西都要影印出来，分配给至少五个人，然后把电子档案放在不同的目录中，部份文件中的名称还是用神秘的规则来创造，并在300页文件的某处加以定义。

这一切只是为了在核心模组中做一个小小的变动。您可以想象为了要创造一个新的模组，要用掉多少红色的标签，而且我甚至不想把这些标着红色标签的文件，送到测试小组手中。

这些过程真的是太复杂了。这些规则是这么的奥妙而复杂，没有人能够全面理解整个程序。错误发生，捷径横行，而且程序遭到忽视。

这个情况不断的重复，好象完全没有程序一样，因为整个企划的状况没有人猜得出来。由于复杂度的关系，说明文件的撰写状况延期，晚了程式码三个月的时间。模组是变更了，但是相关文件没能来得及赶上，导致下一个可怜虫出现问题。这些问题不断的复合，让整个局面完全无法控制。

这个企划的历史显示出先前发生的情况差不了多少。在刚开始只有一个小型的核心小组，以及最少（如果有的话）的过程。随着企划的复杂程度增加，更多的员工加入，但是用来支援他们的结构与程序严重落后。在这之后，有数个新的员工碰上了严重的麻烦，并出现臭早数量多达200只的危机。一位直觉反应的人体育焦燥的回应：［都是这些严苛的过程造成的］。

可以确信的是这些程序可以保证没有新的臭虫，在步步拔除一些臭虫的时候陆续出现（这可能是真的，但不是好理由！这个程序实在太过复杂，让研发过程慢得象乌龟，几乎无法撰写程式码）。

不幸的，一直到新的管理方式介入，整个情况才有改善。过程的数量被砍掉，而且每一个不必要而且过度庞大的程序被削到最小，以能够保持控制为原则。

在这之后，这个企划开始回到常轨上，而且我们才有可能在程序之间，做一些有用的工作。

 

在案例研究13.1中，这个［直觉反应］者提出来的问题十分常见。一个刚开始没有进行处理的企划，然后再尝试进行抑制，以确保问题不会在后期的日子中增加，就是这种失调现象的主旨。

这个情况如同图13.6。

整个过程的导入，是在结合了一大堆没完成的工作之后，将整个企划磨到全面停止。这个企划通常会在这个时候取消掉，但是在案例研究13.1中是不可能的，因为这个企划实在太重要了。游戏研发企划不会经常性的碰上这么重要的事，所以这样的一个企划很可能在这个阶段取消。

注意到在图13.6中，显示出企划事实上是在过程与WOT耗到100%的劳力时，才会抵达它的发行日期。用简单的一句话来说，就是这一点可以在企划预设的日期之前就抵达，导致取消的可能性大幅提升，除非采取一些矫正的措施。这一类激烈的行动，将在第14章中说明。

不过，在一般的状况下，如果把过程导入一个［处女小组］，很可能会出现问题。主要的问题，在于他们不了解这个过程是什么东西，以及它的作用是什么，而升起全面抵制的念头（这种精神上的惯性，要花一些时间才能克服）。在强迫他们接受这些看似［没有必要］的程序时，很可能会招致他们的恼怒。过程将在他们的头上监看，这一点，在刚开始是必要的。正式程序的好处，会在这个企划执行了一段时间之后，才会让他们有所感觉。

所以，这些抵抗问题的解决方式，就是要求他们给您一点点的信任。采用其他的系统，并无法真正的控制或是程序化，导致没有效率的工作环境以及差劲的企划可见度。研发者不可能扮演法律的角色，他们为公司工作，而且这个公司的管理部门（相当于您的［顾客］）有十分充份的权利，知道整个企划的进展。

同样的，研发小组也有一样的权利，象管理部门一样知道这个企划是如何进行的。在这个方式下，如果有问题出现，就可以进行预防的工作。如果没有可见度，唯一可以采取的步骤通常是改善发生的问题，而这将会更为激烈、范围更广、风险更高、花费更大。

经验告诉我，在为一个新的企划引入过程的观念时，一般都会导致暂时性的生产力降低。这方面的认知是十分重要的，要不然，它可能迫不及待的成为争吵中所用的弹药，主题就是过程为什么不是好东西。

暂时性生产力下降的原因有二个主要的理由。第一个是不管新东西是什么，都会影响到学习曲线。这个小组必须熟悉程序，才能让它具有效率；换言之程序必须成为整个小组的第二天性。这一点则暗示了程序必须十分简单而明确，可以让所有人轻易的牢记。每一个程序的作用应该让所有人能够了解。就算小组刚开始对程序不太热衷，他们至少应该能够明确的看到潜在的好处。

第二个暂时性生产力下降的理由，是源自于一个企划初始阶段的本质：一切都是新的，所以没有什么空间可以犯错。在刚开始的程序只是纯粹的顶端监看。程序存在的主要理由，是在企划进入一定程度的复杂度以后预防错误发生，而这一点不会在早期阶段出现（参阅图13.5，看看相关的图形）。

 

程序：在哪边使用它们？

在图13.7中，显示出模组研发（左侧）的主要阶段，以及每一个阶段的相关动作（右侧）。注意到表格中二个方框中的举动都是在阶段的转移点界线上。要插入一个程序来控制设计、研发、测试与发行阶段的每一点是有可能的，但很少有这个必要。

一个很好的定则是，在研发周期中所需的过程与要点的数量，必须视企划的大小来加以调整。下列的章节，将讨论要在哪边进行何种程序。

 

设计阶段

设计阶段包括的企划部份是从游戏设计者将游戏设计形式化开始，转化为整体设计的要点来撰写模组。

对一个单一的企划，这是种一对多的关系。这边只有一个游戏设计，但是这会导致放多模组设计在整体性的结构下，拥有一贯的特质。在图13.8中说明了这个概念。

 

初始概念

这个地方并没有太多的程序要施行。初始概念离可控制的领域还太远，这还在一个想象空间。游戏的初始概念（除非市场部门干涉得很深）是纯粹的创意。

在管理上的幸运之处，在于初始的概念倾向一个企划的起跑点，所以最不欠缺的就是好点子（嗯，事实上在游戏产业中好点子有短缺的现象，但是只有少数的游戏设计者真正注意到这个情况！）

输出：描述游戏用的点子与备忘录。基本的概念图稿与表格。

建议程序：将这个点子展现给保管赌金的团体（管理部门、研发小组、发行公司，或甚至是您的同事）。

 

提案

提案是一份用来定义游戏性的原始宣言，一份文件定义出游戏中的特色，并尝试画出一个游戏的图象，设定小组所要遵循的样式。

输出：一份正式、用来描述游戏的文件（故事、外观及感觉以及基本的运作）。

建议程序：由相关的团体（也就是看过初始概念的同一个团体）来回顾文件。游戏设计应该彻底的检讨，如同一个回顾程序该做的事情一样；而且它应该在下一个阶段之前完成。

 

整体设计

整体设计是第一份详细游戏设计的草稿。这通常都会在制作中另行发展，但是，在进行任何热心的企划相关技术工作前，需要定出这份文件的基准线。整体的设计文件是半科技性的，而且它将说明游戏的运作方式、外观、玩起来的样子，游戏的所有规则以及单位的运作方式。

输出：一份所有单位的人物、策划、物理外观、样式与设定、控制、所有与游戏相关的详细说明。这份文件也可以用来做为游戏说明书的基础。

建议程序：由整个小组来回顾文件，或者至少看过代表用的范例。

 

结构

结构文件是技术文件的初始。这份文件中描述了企划如何建造成模组层级的东西。这应该包括这份企划是如何与公司的结构方针相呼应，包括了重复使用已经完成元件的计划，让元件的使用达到最佳化。

输出：一份说明组成游戏模组，以及模组之间是如何连接的元件。

建议程序：文件由程式设计小组来回顾，或者至少看过代表的范例。

 

模组设计

这个文件是一份要从设计交到研发人员手中的东西，也就是一份写给每一个模组的文件。初始的草稿是由软体规划师或是游戏设计者所撰写的，接下来后续的修正通常是交给研发者来掌控。这个文件是一个高层的技术规格，描述了特定模组的功能，也具有说明书的作用。这个模组设计文件，主要是针对模组所需程式库的相关资讯，而且它另一个重要之处在于重复使用的计划。请注意，一个模组可能有许多种形态，每一个都可以变更它的重要性与重复使用性。举例来说，程式模组可以重复使用，但是美术模组或是游戏的资料档模组，在重复使用上就没有那么方便了。

输出：一份包括了详细指令的文件，说明一个特定的模组功能以及用途，包括了使用上的范例。它必须与模组同时进行维护。

建议程序：由首席程式设计师（如果可能的话）或是设计者来回顾这份技术文件和软体结构（如果文件已经由程式设计师完成的话），而且至少有二位程式设计师随同作业。在合适的情况下，其中一个回顾员应该指派为重复使用元件的负责人，以确保可以尽可能的重复使用所有写好的东西。

 

研发阶段

研发阶段并不只包括撰写程式码的时间，虽然有许多游戏产业中的程式设计师（甚至在游戏产业之外）都是这以觉得。甚至有更多开明的程式设计师觉得，一个附带了说明文件的程式档，就应该足够了。

研发阶段在整个周期之中是最重要的一环，但是撰写程式码只是其中的一小部份。

请注意，这一段讨论只针对了程式码的研发。我并非在谈论美术或是其他游戏所需的模组，虽然它们的原理与程式模组差不多。

 

详细的技术设计

每一个模组都是以纵的方式，写出详细的技术文件上。这可以视为模组设计文件的延伸，但是更为详细。这份文件是用来针对每一个研发人员解释模组运作功能，包括了设计背后的理由以及其他特征的详细说明。

这份文件的效用，在它对模组的重要性影响下，将会变成研发模组的一份日记。这个模组与技术设计文件必须先保持在纵排的方式下。

输出：一份包括了特定模组的详细技术规则文件，象是界面、演绎法、设计上的选择、测试描述、以及测试上的管理等等。

建议程序：设计上的回顾，是由研发者以及软体设计师引导。

 

研发

这个模组通常是从某些型式之下的设计文件研发而来。在美术的情况下，这通常是在风格指引结合了游戏设计的成果；而在程式上，是由详细的技术设计文件而来的。

输出：一个在企划中使用的模组。这可能是一个程式码、一个3D模组、2D图案、一个文字设定档或是其他与企划有关的东西。

建议程序：由研发者来进行程式码的回顾。

 

单元测试

单元测试是在测试研发者写出来的程式码，而且通常是同一个研发者来进行。这个单元测试必须以一个研发者写好的描述为主，也应该是技术设计文件的一部份。

输出：说明单元测试的结果。

建议程序：在单元测试中找到的错误要回报给企划管理者做进一步的指派。视这个错误的本质，指派原先负责的研发者加以修正。

 

整合测试

整合测试通常是研发过程中的最后一次测试。研发者测试完成的模组，看看它是不是建构得相当完整。整合测试应该认为是单元测试的延伸，而且，这个测试本身采用的描述，也是单元测试技术设计文件的其中一部份。

输出：说明整合测试的结果。

建议程序：与单元测试相同。

 

签名

最后阶段要让所有在这个模组上面工作的研发者签名；只在有所有的测试都通过的时候才能做这件事。如果测试没有成功的过关，这个行动就没有任何意义。

输出：一个通过测试、没有错误的企划模组。

建议程序：进入资源控制。

 

测试阶段

测试阶段包括了三个主要的测试层级：系统测试、品质保管测试以及游戏测试。

 

系统测试

系统测试通常是越多越好，由于它采取的是黑箱测试，所以生产出的一般性资讯要比单元测试和整合测试更多。

输出：一个系统测试记录。

建议程序：错误将回报给企划管理者，来进一步的指派工作。

 

品质保证

品质保证是一个高等级的测试，这可以确保程式在美术上面有满意的表现。这并不表示它会找到程式上的错误，因为这一类的错误在这个阶段之前，早就该统统拔除了。

品质保证的目的是确保艺术水准（游戏的气氛、选单画面、说明书等等）是对使用者很友善、有条理，并遵循着游戏设计文件中的游戏内格说明。

输出：品质保证报告。

建议程序：结果将回报给企划管理者与游戏设计者，来进行评估。

 

游戏测试

这应该是最后阶段的测试，要测试的是整个游戏玩起来的感觉。它怎么玩？说明书写得好吗？学习上手要多久？有没有什么其他的游戏性？

输出：游戏性报告

建议程序：提出的问题将由游戏设计者与企划管理者做进一步的指派。

 

资源控制与程式码回头：协同合作

对那些不太喜欢查字典的人来说，协同合作的意思就是所有人合力的成果，要比一个人来得庞大。

资源控制与程式码回顾方面，就是协同合作的一个完美案例。

如果您不熟悉资源控制的话，请把它看成一个管理用的应用软体，控制了集中化以后的修正档案资料库。它可以在一个合理的程度下，控制正在受到维护修整的原始程式档，并让完成修正层级的程式码进入测试。如果一个研发者正在处理原始程式档，其他人就不应该插手同一个项目。这可以预防那些我们在采用资源控制之前，所出现的可怕设计错误，也就是二个人在编辑同一个档案，最后产生互要影响的问题。

资源控制在研发过程中成为不可或缺的一部份，可以提供自动化企划历史记录以及在回顾周期中的一般系统追踪控制。让我惊讶的是，游戏产业在采用资源控制时，步调已经很慢了。

 

案例研究13.2　资源控制？我们不需要臭气冲天的资源控制！

朱利安（Julian）是一个老练的技术领导者，有几次换工作的经验，并在他开始进入一个新鲜人所组成的研发团体之前，看到了游戏产业界以外采用的研发技术的成熟度，所以被众人视为保守派的产业界老手。

在他到任之后，他被指派控管二个研发小组的其中一个，进行一个团体合作的运动游戏。这个企划已经进行了几个月的时间，而且没有经过设计的阶段，只有在撰写程式码，所以已经陷入蛛网之中，写出来的程式码在结构上面都很差劲。

［好吧，］朱利安对小组说，［我们来谈谈资源控制吧。］

整个小组半信半疑的看待这件事。他们从来没有听过这个东西，它看来象是穿西装打领带的人，在撰写资料库或是其他无聊东西时，才会用到的。资源控制怎么可能符合不断成长、酷毙了的画面程式编写。

［但是我们不需要资源控制，］其中一个人员大叫，［我们做得很好，而且我们不需要额外的工作。它只是慢了一点！］

［或是，你们应该可以看到好处吧？我们可以不断的在主程式码中持续加上注解。我们会知道这个工作的进展程度，而且是谁、为什么、什么时候要完成。］朱利安回答。

现在轮到另一个组员，约翰（John）发言了。约翰对他程式码的品质觉得有点不安全，而且他不喜欢这个可［查清楚］的点子。

［所以，管理方面想要利用这个软体来监控我们，并查看我们做了多少事，是这样的吗？］他发问之后，整个小组同时附和。

讨论的内容很快恶化到程式设计小组绝对拒绝与任何资源控制牵扯在一块。

由于在交涉上面的利益考量，朱利安决定先放过这个话题。相反的，他去找高层人员，看看这件事要如何推动。

一般人的意见与研发小组十分接近。［为什么我们要买一个软体，是研发小组觉得没有必要的？他们当然知道他们在做什么事，而且如果他们认为这会让他们的创意窒息，那我们就用这一点来决定就好了。］

在这个时候，朱利安了解到他面对的是一个必输的战争，并决定这个时候不要施压。他的推测是：［没有管理部门的支援，我就没有立足点来强迫小组使用资源控制。］

研发象平常一样持续进行，直到有一天，一个年轻的程式设计师安迪（Andy），笨拙的拖着脚步去找朱利安。

［朱利安，我们可能在我们的程式码中碰上一个小问题，］他低声的说。

朱利安坐正，［哪一类的问题？］他抱着不断涨大的怀疑发问。

［嗯，我正在检查其中一个核心的人工智慧档案，而且我发现它有必要整理一下。所以，在过去的几天，我一直在做这件事，］安迪开始解释。

［继续说，］朱利安觉得一道不详的感觉从他的脊椎骨爬上来，坏消息来了，他可以感觉得到。

安迪吞下口水，［呃，嗯…看来好象是约翰也在同样的区域中作事，他在我之后进行工作，但是在我请所有人别碰那个档案时，他好象不在座位上面。］

朱利安好象被打了一记，脑袋一片空白。但是他什么都没说。

安迪继续下去，［结果就是他也在把核心最佳化。现在它的执行速度达到了我们的目标，但是仍然有些演绎法的小问题。他大约花了一个星期的时间来做这件事，但是我把我的档案复制上去，把他的成果盖掉了。

朱利安扁了扁中嘴，安迪很不舒服的改了一下坐姿。［他之前的努力都白废了，而且他对我很生气。他最新的备份差不多是一个星期以前。］

朱利安坐回去并叹了一口气。［所以我才想要进行资源控制。如果我们进行了资源控制的程序，这一切都不会发生。］

 

缺乏程式码回顾的程度，在游戏产业并不是什么罕见的现象。就算一直到最近，甚至连资源控制都是不怎么熟悉的概念。当我在游戏产业中开始工作时，资源控制被视为无法信任的东西。它被人认为是限制良多而且没有必要的。一个对程式人员的隐私权侵犯者。错误会被指出，而且――最可怕的――就是会有人开始责骂。这是一个坏东西，我猜这个态度仍然渗透到游戏产业的黑暗地带，但是我希望未来的作法更具启发性。

程式码回顾已经在这个章节前面讨论过了，所以这个部份将专注于资源控制以及如何正确的运用，尤其在与程式码回顾结合之后。

与任何工具一样，资源控制只有在正确使用之下才会有效率。如果在没有效率的状况下运用，那还不如不用：您可能会失去程式码、文件可能会一团乱，而且没有人可以确定，企划的最新版本究竟在哪边。

 

资源控制应该用来做什么？

最简单的答案是：一切！

研发如同一个模组一样，应该视为一个封包。所有与这个模组相关的电子档案材料――象是设计文件、问题回报、回顾报告――都应该保存起来。所有的资源控制封包可以让您加上说明来加以修正。这些应该可以对目前的变更以及其他的相关区域，提供一个概要的解释。每一个程式码的回顾，应该以一个独特的编号来标示，以便日后在数个档案之中进行追踪。如果采用了这个方式，一个简单的保存区域搜寻，就可以把单一工作的相关资料，统统整理出来。

虽然，并不是所有组织都需要这种精细的检查方式，一些少量的额外工作可以在后期得到效果，也就是在回头查看资料的时候。

在游戏产业中一个很重要的个性是，很少有公司会从错误之中学习。这可能是由于前一个企划的相关资讯，已经找不到的原因。

事实上，在我参与过的大部份企划中，这方面并没有极为耗时的步骤。没有人真的会在收集企划资讯方面花费太多精神，才能在下一个企划中增加成功的机会。

这可能有好几个理由。游戏产业在研发的本质上面，有些很难听的名声。举例来说，重复使用的概念对大部份的研发者而言相当于诅咒。所有的游戏都得看成不同的怪物，所以前一个版本中，没有真正有用的程式码可以重复运用。使用在一个游戏的程式，如果用在新的版本中都会被认为太慢或是太老旧；而不管这是不是事实。

在游戏产业中的研发工作，也象是一个奇怪的生物。最常见的游戏研发者是彆扭的天才，会使性子而且保护自己的程式码。他们的弱点不存在，而且没有人敢去质疑研发者的程式能力。简单的说，每一个研发者认为他是小组中最强的人，而且每一个小组都认为他们是产业界中最棒的；只要有人能够给他们一个机会，让他们做出真正想要的游戏就行了。

以下是一个程式设计师的常见笑话。我无法保证它会很好笑，但是它却有效的表达了一些重点。

Q：要多少个程式设计师才能换一个灯泡？

A：所有人，一个人真的去换，而其他的人围着看他做得有多烂，然后讨论如何做得更好。

事实上，这个笑话如果不是真的，保证会更好笑。在案例研究13.3中，描绘了一个很令人惋惜的故事，正是游戏产业经常发生的。

 

案例研究13.3　虚幻的伟大

一个研发小组正在为一家很大的发行公司进行一个新的企划。他们讨论了他们很有希望的游戏，并以市面上已经推出的类似游戏相互比较。

《世纪帝国》是一个特别挑选出来批评的游戏，主要是因为他们认为在人工智慧演绎法上在过于简单。

唐（Don）是游戏设计者，正在与企划管理者杰瑞（Jerry）进行讨论，这二人刚刚从一群研发者的会议中，出来透口气。

［我们可以做得比那个好，］杰瑞说，［他们的人工智慧程式设计师一定是个笨蛋！我们的人说，他可以轻轻松松的就超越他们！］

唐可没有杰瑞那么容易说服。［好，我们把他和其他的人聚集起来。我要知道他为什么认为他可以做得更好。］他之前就已经听过他们讲这件事了。

他们老是在谈论企划，每次主题都在其他已经发行的游戏中有哪些错误上打转。他们说在《星海争霸》那个爆炸不够好，这个程式中的人工智慧很差，在这个程式中的使用者介面不够友善，以及其他程式中出现的问题。他们假定在他们的企划中，一切都是完美无缺。

一场会议召开，而唐询问了克理斯（Chris）这位人工智慧程式设计师，为什么他认为他可以做得更好。

［这实在太明显了，不是吗？］克理斯反问，［我就算闭着眼睛，也可以做得比它更好。我们有很多的时间来做一个企划，而且我可以轻易想出如何做的比它更好。］

［在你说（轻易想出）的时候，你是指研究，对吗？］唐再度发问，［你现在并不是真的了解策略人工智慧的整体运作概念，但是你认为可以想出来。你知道这要花上多少时间吗？］

克理斯想了大约一分钟，然后回答，［嗯嗯，我猜这么该要花上六个星期左右的时间。］

［你是以什么方式来假设的？］唐反问。

［我只是有这个感觉，］克理斯露出狡黠的微笑回答。

［好，］唐说下去，［但是比较可能的情况是什么？他们之所以这样做，只是因为他们不能做得更好：还是他们这样做的原因，是因为这种作法是一个复杂问题的最简单答案，才能让游戏有足够的贴图张数？］

这个问题是针对整个小组发问的。在经过一阵子的思考之后，克理斯说话了［呃，我想这是因为他们无法做得更好。］

小组的其他人点头同意。

 

在案例研究13.3中出现的现象，更不幸之处在于随处可见。就算我也不得不屈服在这个恐怖的摩手这下。

有好几次在我觉得必须更新我数个月以前写的程式码时，我的第一个直觉通常是它应该要比我重写来得容易。这通常是因为我想要花费额外的工作，让我自己重新熟悉老的程式码；而让我转变态度的就是成本/效率比。如果我曾经在以前的程式码中加上说明，并确定相关的文字随着程式码来撰写，那要修改我的程式就不用花费太多的工作时间，比从头再写一次省时。我这时才知道，在程式码中加上说明与文件，对我在修改程式的时候有多在的帮助。

在案例研究13.3中的例子，最主要的错误在于另一种观念之下的游戏简单的要命，而这种现象必须要制作小组来负责，因为他们没有足够的技能做得更好。

这个小组觉得他们可以做一些事情，因为他们之前从来没有做过，所以一定十分简单；但是他们对整个程序只有模糊的认知。当然了，只在您听到一个点子，一切都会变得十分明显。

这是一个明显的［那很简单，我也想得到］症侯群案例。如果全世界程式设计师都有一个共通的特征，那就是高估他们本身的能力。我所知最好的程式设计师是那些会说：［我不知道如何做到这一点］的人。

在一个类似的局面下，看看这个：您可能有办法分辨出解剖刀与骨锯的不同，您甚至也知道它们是用在什么样的情况下，但是只有外科医生才知道它们的正确使用方式。您要一些只会宣称他们知道怎么进行手术的人，在您身上动手术吗？

所有的研发小组都假定他们的企划朝着完美无缺的情况进展。没有人认为有必要妥协这一点，他们一向假设他们会在时间之内完成他们的工作，而且不会有任何问题。在这边得到的教训是天下没有［完美］，所以只要有［够好］就行了。

 

资讯传递的重要性

在研发中，资讯的传递通常是被忽略的悲伤部份，而且它从来不会单独地受人注意。如果您真的考虑过的话，这种假定代表资讯传递很容易发生。

不过，现实上并非如此。如果资讯可以从一个脑袋送入另一个脑袋，那事情就简单得多了。或许目前有人正在研究这方面的科技，但是我在商店的架子上还没看到这种东西。

一直到现在，我们都得依靠一些良好的老旧方式象交谈、撰写、以及利用电子邮件与网页来传递资讯。

事实上，上面这一行列出的沟通顺序并不是巧合；它列出来的是有效的顺序。这边有一些重叠之处，例如电子邮件与打好的文件在顺序上是可以对调的。

大部份的小组都有一些资讯传递的方式，但是它缺乏了应有的效能。大部份的资讯是以口头的方式进行传递，而且它是与每天进行的企划有关。企划的状况说明仍然以口头来进行，而且每一个人都对企划状况有自己的看法。这个资讯的误差可能会导致问题。

在一些情况下，会做出一些象征性的努力让企划仍然上轨道，并进行常态性的状况会议。这些作法在效率上面可能有很大的变动，视执行这些作法的企划管理者经验等级而定。这边主要的问题是要吸引这一类的高手进入游戏产业，在薪水不足的前提下将会十分的困难。

大部份的人在晋级为企划管理人员之前，一般都是程式设计师。一个常见的管理理论在这边出现了：一个在组织中的员工被晋升到他无法胜任的等级中。这很明显是人类天性的副作用。

如果一个员工在他（或是她）的职位上表现出色，他（或她）很可能得到晋升。没过多久，他（或她）就会在一个不是刚好符合他（或她）的技巧能力，就是超过负荷范围的职位上。

象这样的员工接下来可能会留在他的职位上搞得一团乱，直到他们在厌烦之下离开，或是被迫［放逐］到别处碰碰运气。

在这些理由下，您在管理位置上面找到的人，通常都不是最适任的人选。如果他们曾经担任过程式设计师，这可能表示他们的沟通技巧不够完善。

重点在于一个小组的组员，必须看着他们的领导者才知道如何控制自己的言行，而且小组的领导者必须为小组内的沟通设定一套风格。

在管得最好的小组中，沟通的工作在不同的层级上面有效的运作。不只是每天的事件都详细的散播到整个小组，而且技巧与经验也会同时分享。最后的效率净值，就是随着企划的进展，整个小组升到了一个全新的技能等级。一个比较公平的说法是，只有在企划指定的范围才会升级，但是升级的部份十分显著，可以从每个人的身上看出来。

这是最有效的资讯传递方式――知识的分散――靠着数个不同的要素。首先，而且也是最重要的，在这边要用上之前提过的所有沟通方式；第二个是在小组中维持开放性。

如果在心胸狭窄的游戏产业之外，这部份不会成为太大的问题，顶多是研发者猜疑的保护着他们自己的［下一个大东西］。但是在游戏产业中，这可能会由于小组之间的提议冲突而引发战争。

在我们详细讨论到任何特定的建议之前，我们以沟通有效程度的顺序，偏离一下主题。

在图13.9与13.10中，说明了二个小组成员之间，在沟通线上面的因数关系。

当这边有三个成员在一个小组中时，就有三条可以用来进行沟通的线。A可以与B交谈，B可以与C交谈，而C可以与A交谈；这可以轻易的管理。每个研发者只需要与二个其他的人员交谈，这一点不会花掉他（或她）太多时间。

不过，在有四、五甚至是六个组员（如图13.10所示），这个情况将变得极为复杂。

在图13.10中显示出十五条这样的沟通线。这在实质上比原先只有三个人要来得多，所以会花费每一个研发者更多的时间。

当然了，这是一个最恶劣环境下的范例，而且这一类的沟通是不可能发生的，就算是在最松散的组织中，也比这个来得有结构。

图13.11显示出通常会出现的状况。

要把一个大型的群组打散，成为功能上的小型群组，其中一个理由就是把沟通最佳化。在小组之间，将会有n(n-1)/2条的沟通线。

在图13.11中，一个有24位员工的小组分散成四个小群组，每一个小组都有6个员工与小组领导者（如同图13.10所示）。在小组之间的通讯可以由每一个小组的领导人来控管，而且这将有助于降低其他状况下出现的沟通恶梦。在这种设计之下，将有6条小组内部的沟通连结，以及4组每组15条的小组内连结，总菜有66条。

将这个结果与还没分组的24位员工比较，后者将有276条沟通线。您可以很清楚的看出来，这将是每个人花上最多时间的部份，会完成的事情很少，而且很快的就会全部崩溃，成为无政府的状况。

这个系统也可以让资讯的传递变得很有效率，但是这边的效率有不同的意义。这一类的口头沟通在一对一的情况下是必要的，而且这边有许多案例，可以指出一对多的沟通方式更具效率：会议、文件以及内部的网页。当然了，其中的每一项也有它的正反面。

举例来说，会议并不是经常都很有效率。某些管理者似乎对开会有特别的热爱，这几乎很象他们的生活如果没有一天开一次会议，就会出现缺陷一样，所以会是开得越多越好。

我的意见是，会议应该在特别的情况下经常性召开，而且甚至没有必要把每个人都叫进来。在普通的状况下，在一个管理者召唤一次会议时大家都得到，连倒茶的小弟也不能例外。

会议倾向于浪费大量的时间，而且虽然它要比一个个分别讲述来得有效率，在简单的状况报告下很好用，但是采用公司内部网站或是每星期寄发的电子信件，一样可以达到相同的效果。

如果每一件事都进行的十分顺利，会议就没有什么召开的必要。如果出现了问题，或者必须进行变更――举例来说，主动性的新消息必须大范围的分散出去――那一场会议就势在必行。

 

主动与反应的资讯传递

一直到这一步，我们都还没有考虑到资讯是以主动还是反应的方式来进行传递的。这到底指的是什么？

嗯，主动的新知识会直接影响到未来企划。这方面的一个范例是大量的变更。这会影响所有人的潜力，而且可能需要收集一些意见，才能决定未来的走向如何。

主动的资讯通常最好在会议中传递。事实上，在一个执行得很好的软体企划中，我最期待看到的会议就是回顾会议，以及变更控制的会议。除了一些特定的实例之外，其他所有东西都可以在更有效的方式下进行传递。

被动的新消息比什么都有效。一些例子象是回顾者完成的企划状况报千，对手企划中的资讯，或是在企划任何部份发生的101条单调东西。

在我的经验中，我已经发现二个最好方式，来传递这一类的资讯：用电子邮件传送的新闻，或是一个在公司内部网页中的连结文件（或者，更好的状况是二者都用）。最让人困扰的，就是明明这种组合的电子邮件与内部网路，可以提供足够的资讯来取代耗时冗长的会议，却还是得去开会。

每一个企划应该都有自己的网页，如同图13.12所示。

网页的真正结构，与个人的品有很大的关系。示范用的网页显示在图13.3中，采用的方式与第11章中的软体工厂模型是相同的。请注意，从主要企划网页中，只留下相关的连结以保持清晰度。

在最理想的系统下，一个每星期寄发的新闻信件系统，将每星期更新的相关资讯寄给公司的每一个人。当然了，查看这些资讯是每个人的义务。

其中一个缺点在于，在一个大型的组织中，他们可能得顾用一个专门负责网页更新的设计师，来进行相关的工作。不过，幸运的是大部份的公司中，都已经雇用了负责网页的人员。

将所有公司中的文件与过程搬到内部网站上面，并不是一项轻松的工作。它需要小心的设计，而且还要提供搜寻的功能。如果这方面处理得很好，那公司中的每一个人都可以看到企划的进行状况。

我曾经在一个我参与的研发企划中实施这个系统，而且将它延伸到加入时程表系统，所以可以利用单纯的网页界面，指派员工黄鹂不同的工作。员工可以进入特定的网页中，查看他们工作相关的详细资讯，以及安排个人回顾、会议的相关时程表。

假定这个网页经过谨慎的设计与编排，它应该可以去除每一个研发人员在试图不去查看相关文件时，最常采用的藉口（包括我自己）：［可是我到处都找不到］！

、、
没有评论

达达尼昂 | 资料收藏 |
《电脑游戏结构与设计:理论篇》第十二章 里程碑及期限【转】

 

第十二章　里程碑及期限

 

＊企划的时程安排

＊避免独断的期限

＊破除模糊的里程碑

＊企划的开始

 

不管我们多喜欢在自由而且没有压力的情况下撰写软体，一些里程碑与期限这是有必要的。是的，它们是所有［不琐碎软体企划］的常见要素，而且也是许多研发者生命中的祸根。

在看看所有的里程碑和期限后，很令人惊讶的是，大部分的里程碑规格都是设定在一个独断的风格之中：而且在大部份的情况下，期限则是定义在一个［期限］的基础上，而非实际的预估。这个特点来自不同要素的作用，包括市场的影响、没有经验的软体管理者，而且在某些情况下，包括了极为固执的人。当然了，大部份的人们只是不知道如何针对软体的研发来预估时程。想要维持公平是一个困难的过程，而且它包括了许多的分析与计算，才能产生有用的结果。

在游戏产业之外，软体公司使用一个比较严密的方式，而不是［选一天并期望那天做完］。即使如此，贵重的训练以及指导方针，还是有助于在合理的态度下，定义出里程碑。

里程碑的作用是把企划分解成可以管理的厚块。最不应该采用的作法，就是列出一长串想用的功能列表，让研发者一个个查看是不是统统完成：当然了，事实上也不应该建议这种方式。您可以想象到，在一个企划持续了18个月的时间后，每个星期只能在几个要件上面打勾，会让士气低落到什么样子？这种做事的方式有可能成功吗？小组要怎样去集中精神并保持热忱？如同它的荒谬之处，有些企划仍然使用这样的系统来进研发，而它们的过程可能是软体研发中最无趣的。

在这边呈现的方式可以运用在各种类型的软体上，不管是试算表、资料库或是大型电玩中的射击游戏。这个章节将告诉您一组以［良好经验］为基础的指导方针，以更实际的方法来定义里程碑和期限。在本书的后面，我们会解释这些预测是如何进展，并随着企划的延续而越来越精确。这个越来越精确的现象，可以视为集中性的规则。在讨论企划的全面结构时，这个章节也可以做为本书未来章节的地图。所以，如果您正在寻找研发过程的相关资讯，这个章节可以说是您的第一站。

 

里程碑如何运作

您有多少次，非要用一个［模糊］的里程碑当做目标来工作？对没有经验的人而言（而且数量不能太多！），一个模糊里程碑是一个有很多解释且具备X种可能完成它的方式，而这个X代表您想要的任何数字，只要比1大就行。

而且您要怎么样才知道您抵达了一个模糊里程碑？如果这个里程碑的目标十分模糊，在预想的情况下，它们就是开放性的解释。那谁的解释才算数？当然了，这通常要靠您的老板才能做出［正确］的解释，而且很可能出现的情况是，他与您的看法完全不同。

试试这个简单的测试。想象您的老板给您一张纸，上面画了五角形的五个点，标示出A、B、C、D和E，如同图12.1所示。

现在，想象您的老板说：［我今天很忙，而且我需要在一个小时中完成这个工作。我有很多人要见，所以我只能简要的告诉你我需要你做些什么事。我要你在A和B之间画一条线，在我从生意上的午餐回来之前做好。

三个小时之后，您的老板蹒跚的回到办公室，并向您要完成的文件。

如果您直接在A与B之间画一条线（如同图12.2），我很抱歉，但您输了。不过，如果您先在A与E之间画一条线，然后确定这条线延伸绕着五角形穿过D、E和B，（如同图12.3），而且在A与B之间留下空白，那您就成功的达民了里程碑。

好吧，您的老板不会叫您做这些琐碎的事，这边的重点是：含糊的里程碑是没用的。

要走到您的解答，它可能代表您作了太多或是太少的事情；而大部份的情况下，程式设计师的基本心理一定会倾向后者。这并不表示良好的程式设计师都是懒虫；这只是表示在普通的原则下，二点之间的最短距离是直线（大部份的良好程式设计师，喜欢以最小的工作量，产生出规定的结果）。

不过，在前者的情况下（作了太多事）也通常代表错误的工作方式，这表示程式设计师在解答方面太过热心，提供了不需要或是没有必要的复杂功能。

在完美的情况下，里程碑不应该有这些大的活动空间，但很不幸的是，这一类状况正是大部分安排时程的问题核心所在。在一个比率公平的企划中，里程碑之间的距离放得太远，它们之间就可以容许一定程度的偏移；象是进行不必要的工作，或是缺乏集中注意力的焦点。

一个里程碑应该十分明确而简洁。它应该也很明显，足以一眼就看出这个里程碑是否已经到达：黑与白、失败与成功。它不应该迎合或是鼓励任何野心的结果或是灰暗的阴影。没有人可以说一个里程碑完成了90%；一个完成90%的里程碑给人的感觉，好象是一个灯泡的亮度为90%；这个灯泡只有亮与不亮，里程碑也是如此。

这个要点十分重要。模糊里程碑是在企划中最常见的单一问题。

 

您老板的五角形工作，应该以下列的方式来说明。

1．必备工具：尺以及一只黑笔，可以划出连续的细线。

2．在点A到点E之间，以粗细均匀的黑线相连。

3．在点E到点D之间，以粗细均匀的黑线相连。

4．在点D到点C之间，以粗细均匀的黑线相连。

5．在点C到点B之间，以粗细均匀的黑线相连。

注意：不要连接点A到点B之间。

 

这个列表是一份更详细的分析文件。这个分析应该详细到没有产生怀疑或是问题的空间。告诉您如何去解决问题。在这个例子中，还有一个更好的解决方式，而且产生出来的解答刚好可以想连的点连起来（一语双关）。您可能觉得这样的作法会将程式的创意抹杀，对这一点，我的回答是［程式并不是发挥创意的空间］，换句话说［有创意性的程式设计］叫做胡闹。适合发挥创意的地方叫做设计与结构，在我们开始进行系统的程式撰写时，游戏与结果设计者已经完成了所有创意的部份。这一点可能会削弱自尊，但是一个程式设计师的工作就是很简单的翻译：拿到详细的设计，把它转换成可以在电脑上面执行的东西。

我可能已经听到程式设计师的坚决声明，说他们是创意上的天才，我怎么有这种胆子把他们贬低成只会写程式码的猴子？嗯，只写程式的程式设计师是程式码猴子。一个真正设计工作中的程式设计，在一个漫长而复杂的过程中，真的只是一个小小的阶段。它是一个结束的修正，一个微小但重要的详细过程。不过，程式设计师通常有更大的责任，而不只是写程式码。在大部份的状况下，他们也要为详细的模组设计以及相关的执行工作负责。这可以让他们把创意移到该去的地方，把创意放入附有详细说明的程式码设计文件，而不只是在写程式码。

对那些还看不懂上述争论的人，请回头看看第11章，将更详细的讨论了上述的重点，并提供了我的看法。

我曾经参与过的每一个良好企划，都有意把程式设计的等级降到简单的翻译。这些企划都平顺的进行，也统统在时间与预算的要求下完工。

相反的，所有我曾经参与的不良企划，都直接从整体的结构设计进入程式码的编写。在没有例外的情况下，这些企划都超出了原先的预算，而且完成时间向后拉长――如果他们真的完成的话。

如同在案例研究12.1所示，模糊里程碑会导致企划的延期，而且结果是让那些守着里程碑的利益团体，出现迷惑以及大量的猜疑。如果没有指出一个明确的中止点与进度，您就降低了企划的可见度，这表示没有人真正知道这个企划的进度在哪里。所以，延期与问题成为疾病，在没有人想出一套解决这种问题的方案下，它就这样发生、不受注意，一天又一天直到它大到无法忽略为止。在统计学上，大部份的企划损失时间导致没能及时完工：就是因为延期又造成了延期。这样的问题必须及早解决，而且这个状况明明可以及早矫正。

 

案例研究12.1　为何模糊里程碑可以做一个企划

在我很早以专业身份担任第一个游戏的企划时，我刚刚从学校出来，被指派一个看来很简单的任务：为我们正在进行的游戏，以微软的Visual Basic4写一个关卡编辑器。

这对一个企划的标题或是任务说明都是好事，但不幸的是，它也成为我的企划里程碑。

再也没有更难让人看到里程碑的情况了。不过，在那个时候，我并没有什么经验，所以也看不到问题的所在。

我接到的期限是二个星期，来完成这个特别的企划。在基于上一版Visual Basic的良好知识下，我开始工作。

第一个障碍，在于我对问题领域没有足够的知识：我不知道它要的是什么，即使我的老板和我认为，我们二个脑子中的游戏完成产品想象图是一模一样的。

我在思考的企划（而且我知道我可以在二个星期内完工）是一个用方格为基础的地形编辑器，可以产生出棋盘式的方块，然后用这些方块拚出有高度的地图。

而在我的老板脑中的企划，需要的是一个地形编辑器，不但有拥有上述的能力，还要能够自动用乱数或是输入一张代表高度的地图，让从VistaPro（一种地形产生套装软体）载入的资料来产生出地形，并启动更换地形上面的游戏物件（包括让先前安置的部队自动产生阵形），自动输入并在输出给美术师时进行分类，而且产生一组完整的关卡档案，其中所用的色盘将视每个关卡来最佳化。

这二份上述的说明，都是关卡编辑器的描述，但只有一个有可能在二个星期中完成，而且只有一个（在我老板的意见中）才是对的。不幸的是，我们二个看到的并不是同一个。

结果，在二个星期后，我以每一个规格完成了地形编辑器，所以达到我的企划目标（这是我所见到的）。没有人告诉我其他的东西，而且只有一个时间很紧的期限，我在写程式时没有办法加入任何东西，当然我也不可能提供一个选择，让这些东西在日后再加进来（换句话说，我在进行软体创造时，用的是［地狱程式码］的方式）。

最后的结果，是要再花十个星期的时间，才能达到里程碑，而且这个程式最后执行起来慢得让人受不了，因为它用了Visual Basic4，去尝试做太多色盘有关的处理。

 

模糊里程碑

就象登山者会被人警告不要去吃黄色的雪，您得到的警告则是不要容忍模糊里程碑，这是一个常识。为什么要在规定的期限内，朝一个您甚至不清楚在哪边的目标前进，而且在您抵达目标之后，还有可能和别人争执这个目标立在什么地方？模糊正是软体时程安排上的敌人。

模糊里程碑也会导致在企划进行全面的规格定义之前，先完成里程碑与时程表。因于这个时候还不清楚问题的领域在那边，里程碑是以概略的通则来定义，而期限则是以独断的行为，将可用时间予以切割，以直觉般的本能来安置。通常在单一的里程碑中会包括太多的工作，这代表在到达这个里程碑之前，必须完成所有分散的工作。这就会形成一个模糊里程碑，而且可以合法的描述成一个（举例来说）半完成的东西（象是要完成这个东西要二股力量，但只完成了一项）。

在单一的里程碑中填入了太多的东西，会招致反效果。除了很明显让人迷惑的要素外，它也会导致其他的次要问题。小组会觉得他们要做的事情是达成一个里程碑，但是要到达这个里程碑之前所花的额外时间，将会影响到士气，而且整个小组的态度也会转换成一场壕沟战：我们每天都在对抗他们，并在不断的磨擦中降低了前进的速度。一个小组，应该知道要花掉多少时间，所造成的进展在整个企划中占了多少百分比。

这并不是一个不可能的工作，但是它的确需要更多的规划，通常也是一位游戏企划的工作。

 

里程碑与迷你里程碑

如同定理一样，要踏上一个里程碑所花的最好时间，应该是四到八周。这将提供有限的目标，可以让里程碑在合理的情况下受到所有人的重视。另一个问题是庞大的模糊里程碑很难让人专注于其中：有谁会在意四个月之后的期限？这个状况通常会造成前三个月的时间都没有人在写程式，而最后一个月大家都在地狱中工作。

要解决这种现象（除了把里程碑之间的距离缩短）可以把每一个里程碑分散成迷你里程碑，或是查核点，大约每星期一次。很明显的，想要做到这一点，您必须把结构规划的相当好。如果，您发现在目前的处境中，无法公平的定出里程碑和迷你里程碑，那么在结构的设计上就不够完整到足以开始写程式。在这种情况下，我们可以先确定企划开始之后的重要阶段中，是否进行着良好的运作，再来解决这些问题。如果一切进行的很好，要让它们保持运作就比一开始要先修理问题，并勉强运作来得容易得多。一个在里程碑和迷你里和碑之中良好的工作分配方式，是把迷你里程碑指定成完成特定模组，而把模组的整合当铸主要的里程碑（有时候把迷你里程碑再加以分割是必要的，但是这将视您小组以及手中的工作而定）。

在良好的小组之中，迷你里程碑不一定有存在的必要。举例来说，如果小组的经验丰富到知道解决问题的最好方式，而且成熟到时时留意期限的逼近时，就没有设立的必要。不过，对新的小组或是一个全新而不熟悉的企划来说，迷你里程碑就可以做为二种用途：

 

＊让小组专注于他们手中的工作。

＊在重要的时间，提供大家已经增加的企划可见度。

 

第一点中很重要的是不要把里程碑的间隔安置得太远，才能避免人员在企划中漫无目标的漂流。一个很类似的情况，是想象您手中有一份指示，叫您前往一个您从来没去过的地方，但是您对这个地区有个模糊的印象。现在有人请您沿途画出一张路线图，并在有限的时间中抵达。在您上路时，您最花时间的工作是画地图，从现在开始，您会不断的走走停停，四处看看您的前进方向。

在这个例子中，里程碑就是您走走停停的动作，而企划就是地图。您走走仿停停的次数越频繁，您在地图上面走错路的可能性就越低。很明显的，这个方式正是［报酬递减法则］：如果您每走二步就停下来，不只会花更久的时间到达，而且您无法专注于绘制地图。如何找出这方面的平衡就是关键，这个里程碑不应该如此频繁，导致有效的工作进行受到损失；但是也不能一次冲刺得太远，然后看到整个企划迷失方向。

一个良好的定则是把迷你里程碑的数量，以小组对这个主题的经验高低来调整；而这个迷你里程碑少要保持在一或二天。任何比这个数值更小的时段，将需要更频繁的管理，而且在可见度方面会让坏处多于益处。

 

何时要使用里程碑

在一般的情况下，每一个程式或模组都是一个独立的企划；而且对大部份的程式而言，这都该被视为本质相同，而且提供相关规格与说明文件。是什么东西导致程式琐碎并没有定论，但是在这边的建议，是只有在您能够断言没有其他用途之下，才考虑写一个要丢弃的程式（即原型程式），这可以减少程式琐碎化的机率。如果您用这个程式继续研发下去，只会产生一个荒废谬的庞大企划。

一个可以做为例子，并符合上述标准的程式，是那些生产出对照表的程式。它会产生出预先计算的数值档案，以减少执行时所需的计算（在处理器越来越快的现在，对照表已经不再受到青睐，但是它们在速度有限的系统上面仍然十分有用）。要研发这一类的产生方式，将包括撰写常式分析器，可以读取使用者定义的公式来产生表格。在这个特定的状况下，很明显的要比把计算公式写死在程式中的好。

 

让您的里程碑正确

为了增加时程表的正确性，我们需要尽可能的把不确定的东西移除掉。这并不表示您可以移除所有的东西，但是只要您能把不确定的数字降到最低，就等于避开了里程碑的模糊性。

在案例研究12.1中，问题源自于一个共通性的误解，以及对正确的需求缺乏深度的说明。之所以没有附上说明用文件的原因，是因为在这个问题领域中没有进行相关的研究。在给予了严格的期限后，很明显的并没有提供任何相关需求与想法。老板只是假设他想要的知识会［自动］的从他的脑袋传到我的脑袋中。在混合了这样的想法后，他假定其他的组员可以在数分钟之内，把他们所需的东西说得一清二楚。

这实在一点道理也没有，但是您会很惊讶而且吓一跳的，是有好几个企划的确就是以这样的基础来进行。大量的金钱都花在这种预期上，而不把所有可能影响到企划进度的要素列入计算之中。在一些案例中，期限的设定基础是由市场部门要求的，这可能只有最没品质的小组才能同意这样的要求。

发行日期很显然是源自市场方面的压力，但它绝对不应该成为时程主题的决定要素。尝试让小组去尊重市场部门设定的期限是不可能的，尤其是当这些期限设定在独断而不合理的前提之下，再加上完全不把研发方面的技术要素考虑在内。如果出现了一个市场决定的期限（象声名狼藉的圣诞佳节大冲突），那就得把功能加以调整，才能让企划符合规定的期限。这个减少的功能必须在各方面都十分的清楚，碰上这一类情况最有效的回答，就是要求修整时程表的时间，但是要完成的工作量还是一样（这边的假定是，反正所有的研发人员都在时程表上面填了一些空间，来让他们的生活轻松点。这是很荒唐的事，但如果您屈服在这种假定之下，您就是在自找麻烦）。在处理所需的工作量上面，这个时程表一定要经过最佳化并极为清楚。如果这个工作必须在短时间完成，那就非得砍掉一些功能不可。我已经看过太多的状况，是企划领导者同意这样的状况，并假定他们可以在12个月中完成18个月的工作。不得不承认的是，只要足够的超量工作，这并不是不可能的。尝试让一个研发小组在紧密而且加班情况下工作12个月，处理上吨的工作并非容易的事（而且绝对不建议这样做）。这会伤害原本高昂的士气，而且这个企划结束之后，失去您所有技能高超的研发人员，也不是什么怪事。

在案例研究12.1中的程式期限很明确，但是对这种正式的工作而言太短了。在这个企划中光是收集资讯至少就要一个星期，而且如果先收集到足够的资料，就可以预测出这个企划需要再花六个星期来撰写。当然了，就算这个预测是靠着其他组员在这段期间的工作量来判定，您还是要把撰写说明文件的时间，以及说明这个编辑器中所需的功能考虑在内。这件事可能会得到老板的同意（或是拒绝），但至少这个结果可以让他采取其他的选择，象是指派更多的人加入这个企划、降低要求、延展时程表、给这个企划一些在相关领域中经验丰富的人，或是把您开除掉！

在您想要规划并为整个企划安排时程表之前，您有些动作是一定要先完成的。一个企划的前三个里程碑（如表12.1所示）一定要实行，这可以让您更详细而且更精确的分析出接下来的每个月，时间要如何运用。

 

表12.1　前三个里程碑

里程碑

查核点

工作

1

1.0

一般性必备物资收集

 

1.1

技术性必备物资收集

 

1.2

资源上必备物资收集

2

2.0

一般可行性研究

 

2.1

技术可行性研究

 

2.2

资源可用性研究

3

3.0

结构规格草案

 

3.1

企划开始

 

这些里程碑有效的包括早期规划以及可行性的研究。这些阶段的花费，是企划总成本中最小的一部份，而且它有助于提供良好的资讯，计算出整个企划的总成本、时间以及技术上的可行性。在第一个里程碑之后的每一步，都让做决策的人有一个很好的地位取消整个企划，或是让它朝下一个里程碑继续前进。在那三个里程碑完成时表示企划可以开始运行，那企划就应该可以朝完成的方向迈进（除非它掉入汪洋大海）。如果通过了可行性的研究再把企划取消掉，那应该视为可行性研发过程的失败，并进一步的调查。

一个企划的初始调查阶段的实行优点十分明显，毕竟接下来是为期15个月的研发过程，在所有人的身上投入大量的金钱与努力，并假定每个人都可以把这个企划完成（这个情况有没有让你们听到擂台上的钟敲响了？）取消一个企划对士气的影响，将会随着企划进行的时间而不断的增大。不过，如果组员有进行过可行性的研究来查看技术与可玩性方面的需求，那这个伤害就可以降到最低：每个人都可以了解他们做的是一个企划的研究，看看它是否值得尝试。如果最后的结果是可行，则所有人都会受到鼓舞。不过，如果所有人都做了各方面的可行性查核，但最后还是有机会被取消时，效果就没有那么好了。

人们的天性是在舒适安全的位置上时，工作表现会更好。当然了，一个企划早夭的风险还是无法全面消除，但是它至少可以藉由在进行时，早点解决任何主要的问题把可能性降到最低，而且要在大量的金钱与人力投注到这个企划前完成。否则，您不只会失去您的金钱与时间，您还会失去人们对您的尊重。

 

案例研究12.2　取消企划的代价

为了保护无辜与那些不见得如此无辜的人们，下列的人名、公司与产品都已经全面改写。

在一个与热门《Cryptlnvader》系列发行公司，也是Y公司的总裁――司诺先生的会面中，他声称Y公司最近大约中止了十个企划案，这些都是在做了六个月之后　，结果无法达到预期的东西，而这些企划案已经进行各种不同阶段的研发，而且都在上面砸了不少钱。

司诺先生说，这样的作法是为了保证他们推出的软体都具有高度的水准，听起来很有商场上的味道。据司诺先生表示，这些企划取消的费用（包括《Fatal prison ll》），每一个企划都将近在￥160000到￥720000之间，对他而言这并不算是大问题。有些人可能会说，如果您有手中这么多Y公司到处投注的钱财，那您也看不到什么东西叫做问题。不过，如果您考虑到这笔钱可能全部用在资助四个其他的企划（如果早期的原型阶段执行的很好），那这就是完全不同的光景。这种努力的浪费不只在金钱上面很可观，而且它也不利于研发小组的士气（可能有上百人）。

 

在案例研究12.2中，企划案中止于不同的研发时程。幸运的是，其中有些仍然在原型的阶段，所以不会花太多钱；就算如此，￥150000美元花在一系列的原型上面，仍然是一大笔金钱。在现实中，我在一个原型上面的金额不会超过￥75000，这只是看您如何定义（原型）这个字。在这些案例中，［原型］并不真的是指传统的字面意义，而是完整研发游戏的部份研发版本。在大部份的状况下，这个游戏将会以普通的方式开始研发，而且在主要的研发中，分离的原型并没有什么效果（的确如此）。在这些例子中，原型的程式码是真正游戏所用的程式码。

不过，一个［原型］的意义是这样的：快速而可丢弃。这是一个测试点子与概念的动作，所以不要与科技研发搞混了。原型阶段的用意在于研究出游戏概念的可行性。在这个阶段的结尾，需要的科技应该已经完工（或是找到可以取代的方式）。这并不象它听起来那么限制良多，因为这些元件将会在标准的介面中研发，如果（或是有时）一个新的科技在真正的企划过程中研发完成，这个新的元件也可以在后期把它插入正确的位置。

这个原型甚至不需要以编译式语言来撰写。通常一系列连续的原型――从纸笔进展到高等级、快速研发的语言（象是培基语言）――都足以测试这个粗糙的概念。不管怎么说，它是一个原型，又不是完成的产品，而且如果它与最后的产品是用不同的语言来撰写，那就可以断绝将［原型］当做［完成产品］的所有可能。

把原型的程式码放入正式产品等于在调制一场灾难，因为通常在定义上面，一个原型并不具有［产品等级程式码］（译注：真正成品所用的程式码，以下称为［产品程式码］）的特性。这不只是程式码写得很草率，还包括了写原型时编写程式码的优先程度。举例来说，游戏执行速度并不是在原型程式码中的第一条件，但是在一些产品程式码中却是最优先的事项。不要低估把原型程式码放入完整产品的诱惑，那种节省时间的期望相当于一个危险的陷阱，通常导致的结果是显著的时间延迟以及后期产生的大量问题。所以，把原型的程式码用在产品程式码是一个不值得尝试的举动，这不但是一个不可能完成的工作，而且甚至有可能阻碍原型的研发。

在表12.1中的里程碑时程表试图包括上述的所有要点，并包括企划的初始阶段，一直上溯到可行性的研究。

下列的部份，包括了这些初始里程碑的详细说明。

 

查核点1.0　一般性必须物资的收集

这个查核点中应该回复下列的问题：

 

企划是什么？

很明显的，它是一个游戏，游戏的元件，或是一个有助于游戏生产的工作。但是哪一类的游戏？目标的客层是什么？为什么会让他们满足？游戏的什么地方、以及这个游戏如何与公司的远景契合。这些问题的答案，有助于集中这个企划的焦点。

什么样的游戏要写出什么东西，应该不会有什么问题。举例来说，应该探索游戏的外观及感觉，还有在一般层级中，所有其他足以影响游戏的主题和考量。我个人很讨厌使用［任务说明］这个字眼，但如果我写的任何企划包括了这个字，那这就是需要定义的地方。

 

［顾客］期待的是什么样的功能？

在这个案例中，顾客可以定义成好几个不同的层级。第一种顾客是公司的管理部门，第二种是发行公司，第三种是媒体，而最后（希望不是最少的）一种是购买的大众。

每一个群组的顾客必须特别迎合他们的需求，而且很麻烦的是，他们的需求与想要的东西都不见得相同。每一边都可以证明他们具有同等的重要性，所以要让所有人高兴就很难平衡。举例来说，管理部门与发行公司可能要示一个正式的展示，以及间歇性的推出先睹为快或是展示。媒体会需要游戏的远景，而且购买大众要的是完成的产品！这些需求都要先行预期，并放入您的时程表中（至少最后一个少不了）。

 

需要的最小功能是什么？

很让人惊讶的是，最小的功能正是最重要的考量。虽然我不想去研究这种灰暗的想法，但是研发时还是要了解它；如同真爱一样，从来不会象预期般平顺。从企划的最早阶段，就必须定义数个功能上的阶段（这些将在第14章中介绍，并在第三部做进一步的讨论）。

最低的功能阶段定义了最小的需求：也就是软体已经［有足够的完成度］然后可以发行到市面。在这个时候的游戏可能不会特别好，但至少它的核心可以运作。达到这一点是时程表的主要目标，一旦这一点成功的抵达之后，进一步的功能就可以一阶段一阶段的逐步加入，直到理想中的功能出现，然后产品才能发行。当然了，如果企划碰上了任何延误，它可能需要的是在所有想要功能加入之前把游戏推出去。在这种情况下，您会很高兴您采用的是阶段性的方式。

在这个阶段中，您得收集所有与企划相关的必备物资，这可以让您在整个企划中，成为一般性的指导方针。

这个阶段必备的是游戏提案文件，如果第一部所定义的一样。它的要旨是一份小小的文件，描述了游戏给人的主要感觉，以及它背后的所有点子。

从这个初始的提案，您可以研发游戏设计文件，如同在第一部所示。一旦游戏设计全面规格化（80/20规则的发展主题！）那它已经提供了足够的力量，可以进入下一个阶段。

 

查核点1.1　技术性必须物资的收集

这个查核点中必须回应下列的问题：

 

需要的是什么技术与过程？

最理想的状况，是在您拥有所有元件的情况下进行研发。接下来这个问题就比较容易回答了，如果您没有需要的元件，他们是不是可以在一定的时间中轻易完成，还是需要进行研究，才能把定义出来的功能写好？

如果需要研究的话，那这个企划就不能跳过原型的阶段。很重要的一件事是，必须把它一直延期直到研究完成为止；只要您打破这个规则，您就在承受一个不能接受的风险。记住这个研发过程中的物件，已经尽其可能的把风险降低。不依靠研究而硬性认为可以在固定时间写好，相当于损坏所有已经在进行的方式。千万别做。

如果您确定要研发的技术是可行的（您现在有了应变之道），那您可能想要继续研发出一个原型。一个应变的例子是，在您想要运用所有硬体支援的3D画面之前，先写好一个以软体运算的3D程式。就算硬体支援失败了，您还是可以运用软体引擎，虽然有点麻烦，但至少不会让失败成定局。不过，您应该小心的步步为营。

 

查核点1.2　资源上必须物资的收集

这个查核点中必须回应下列的问题：

 

企划中所需的资源是什么？

针对这个企划，准备一个您目前尚缺的所有软体以及文献列表。

在这方面不要太热衷；否则您可能连厨房的流理台都列了出来。相反的，理性一点。您的预算可能很有限，而且根据墨菲定律，只要您用掉了您手中的预算，就会推出一个主要的软体，而您一定买不起。

 

以下是一些建议的东西（以及例子）：

＊编辑器（微软Visual C++）

＊自动侦测错误的软体（Numega BoundsChecker）

＊侧写程式（Numega TrueTime）

＊资源控制软体（微软Visual SourceSafe）

＊时程管理软体（微软Developer）

＊文书处理软体（微软Word）

＊3D模组建构程式（Kinetix 3DS Max）

＊2D绘图软体（Adobe Photoshop）

＊格式翻译软体（Okino Polytrans）

 

（这个列表中的东西，只是以我最熟悉的软体来进行建议，也是目前的研发公司最常使用的东西。这些软体中有些可能很贵，尤其是在预算有限的状况下。幸好仍有其他的选择，而且在本书附上的光碟中，也提供了一系列的免费或是共享软体，或是您可以在哪边搜寻的建议。您可以在附录B找到与软体相关的详细内容。）

 

血腥的尖端科技

您想要一些有用的建议，或是从痛苦中学到的一点点经验吗？那就是绝对不要用最新版的软体，直到它已经推出一段时间为止。如果您在一个企划半途转换版本，它也会造成延期。另外，如果事情进行的不顺利，把软体版本［倒转］回去将是一个很花时间而且很昂贵的工作。他们叫做［血腥的尖端科技］，自然有其道理。

 

查核点2.0　一般可行性研究

这个查核点中必须回应下列的问题：

 

这是一个有价值的企划？

您应该开始探讨游戏性与故事，并把它打磨光亮。很明显的，这并不会马上定案，而是倾向在研发过程不断的调整与变革；这是把旧点子挥去，并加入新发现、好点子的时刻。

在这边要提出一个警告：小心特色四处蔓延。很多游戏之所以延期或是取消，是因为低估了加入的特色。特色的潜行，以及它的预防方式，将在第三部中讨论。

 

这个市场准备接受这个游戏了吗？

这个游戏是否适合目前的市场？这并不表示游戏应该毫无新意，只是模仿市面上已经有的游戏（如果真的这样，那您就要重新考虑这个企划。有太多的公司生产出没有新意而且毫无生机的游戏，用不着您再加上一笔。回到第一步，直到您有更具启发性的点子！）

好，假定您还在这边，那您的游戏设计也通过第一道酸碱测试。下一个问题，是这个游戏设计到底是个全新的类型，还是目前类型的延伸。如果是一个全新的游戏，那我会建议您研究一下市场是否能够接受它。在刚开始时，试着询问一群中立、对游戏设计有不少批评的人们。问问他们这种游戏会不会想玩，并询问他们喜欢与不喜欢的部份。这边最重要的是得到诚实（虽然一向都很唐突）的答案，然后排除掉家庭、朋友与同事的意见。一个最常见的建议是，设计一个您会想玩的游戏；这本身并没有什么问题，但是您冒的最大风险是把游戏做成只有您要玩的东西。当然了，您必须设计一个您也想玩的游戏，但这绝对不能成为您的指导方针。

如果游戏是以现有的游戏做延伸，那上述的建议仍然有效。除此之外，试着去定义您的游戏如何加强这个类型。一个最传统的范例是Valve的《战慄时空》，一个第一人称射击游戏，是以《雷神之鎚2》的引擎来建构的。不过，它在1998年成为最佳游戏时，也有许多竞争者在同一时段上市（象是《原罪》与《魔域幻境》）。《战慄时空》慎思熟虑之后，在这个类型中加上了强而有力的故事、敌方不可思议的人工智慧，并十分小心的建造游戏中的环境。在《战慄时空》中，通常每个面前的问题都有二种解决方式：您可以用强大的火力轰进去，把眼前会动的东西统统杀光；或是您可以想想下一步怎么做。这是一个极佳游戏性的典范（不过，这个让人思考的元素在接近游戏尾声时似乎越来越小，要过关靠的是更为快速的反应与大量的弹药）。

当您考虑到推出一个既有的类型时，试着在现有的内容中加强，而不是遵循传统的［更多的武器、更多的敌人、更多的爆炸］途径。举个如何不去扩张既有类型的例子，看看即时战争的类型。在1998年12月，已经出现了停滞的现象，只有一些明珠（象是Blizzard的《星海争霸》）可以在这堆垃圾中增加一些新的东西。

运用您的想象力，试着开拓每一个可行性，来收集设计的点子与意见。一般可行性的研究是在一场研发过场中的最后重点，而重新建造主要的游戏设计，可以在便宜而有效率的情况下完成，所以在这方面要全力以赴。如果一个想法成不了气候，不要害怕丢掉一个研发内容中的争执。这可能会因为参与的人员与内部政策而更加的困难，但是最好在这个阶段承认个人的失败，而不要推出一个差劲的游戏，然后伤害到公司的形象（这会在大多面前承认您的失败，包括您让一个失败的游戏设计成为漏网之鱼）。

 

查核点2.1　技术可行性研究

　　这个查核点中必须回应下列的问题：

什么是效率方面的需求？

一般顾客的电脑设定与等级，是否该纳入游戏可行的技术需求范围？

游戏研发者的运气很好。他们通常使用最好的装备、最快的机器，以及最新的硬体；在这样的硬体上面，游戏跑得象在飞一样。而一般的使用者，当然了，就没有这么好运了，而且他们通常用的是普通的机器。研究显示出顾客大约每隔一年就会买一台新的电脑（这通常是因为领先的游戏，一向需要最新而且最好的硬体）。您的一般顾客可能会在二到三年的期间换一点PC，同时提升各方面的性能。这本书在我的许多电脑上面撰写，其中一台二年之久的Pentium 200 MHz MMX，我还觉得很好用。我觉得没必须升级到Pentium ll这种怪物级的电脑，在成为不可或缺的设备前，大部份的普通使用者也没有这个必要（译注：本书出版日期是1998年，以现在的电脑水准而言，想买台Pentium ll只有到古董去找了）。

当您选定了基础等级的机器后，您应该估算的是二到三年以后的技术，并用此来推算未来这个基础等级的主机成长到什么程度。如果您指的是更高等的基本配备，那您应该有一个很好的理由（举例来说，您是ID Software，正准备推出Trinity程式引擎），或是接受销售上面可能出现的损失。只有最尖端的游戏才能将基本的设定向前推到另一个新的标准。一般来说，在常见的研发时程（18个月）之后，今天尖端的机器可能只是产品发行时，只能称为中上等级的电脑。

 

查核点2.2　资源可用性研究

查核点1.2定义了企划所需的软体以及书藉。而查核点2.2的目标是合并早期几个查核点的结果，并选择企划群组中的初始人员（如同第11章中定义的）。如果可能的情况下，企划群组应该选择的人员，尽量以该企划内容范围技术最好的人为主。这个小组的大小视企划而定。一个小型企划中用二到三人的规模十分合适，但是更大的企划就需要更大的群组。虽然这一点似乎很明显，但要指派一个企划中的人员，一向比它外表看起来复杂得多：一个群组人数太多，您冒的就是效率不彰并有额外费用的危险：人数太少则冒的风险是小组人员工作过量，并会造成延误。主要的观念就是第一次就把状况平衡过来。在后期再来变更这一点，通常会更为困难，而且要花的钱也更可观（在第21章会更详细的讨论这一点）。

在查核点1.1中将会决定进行企划之前是否要先进行研究工作，然后这个时刻也是决定您要不要开始研发这个企划的相关内容。如果答案是否定，这就是这个企划的结束。难以下咽吗？您可以看看好的一面：很可能现在要做这个企划早了一点（您至少要等全相萤幕出现在市面上并人手一台，才能做一个用全相萤幕来玩的游戏吧？）所以它可能在往后才有一鸣惊人的时刻。不过，请记住这个游戏应该还是以游戏性为主，而不是以科技为优先。不然我们不会叫它为游戏。

如果最后决定要进行研究的话，那这个企划将衍生出更多的研究企划。查核点3.0与3.1（后述）仍然可以进行，但是从这边开始，我们就得等候企划研究的成果（这些已经在第11章中讨论过，本书后面会再提及）。

 

查核点3.0　结构规格草案

第一件要了解的事，就是结构是一个不断演进的怪物。除了一些研发产业中的人员持续的主张以外，在一个企划开始进行之前，把整个结构全部定出来是很重要的一件事。我们的老朋友――80/20规则，又再度昂首了。

在合理的预期之下，我们顶多只能在一个企划开始时，完成大约80%的结构；而这个结果可能会让大部份游戏产业的研发者大吃一惊。虽然在游戏产业以外比较容易看到一个企划定义到这种程度，但这些都是会成功的企划，而且很受欢迎。一旦结构的完成度觉得将近有80%，企划就可以开始了。剩下的20%会在企划过程中完成（剩下的20%通常包括了无法先行处理的东西，这部份在第三部将会进一步的说明）。

 

查核点3.1　企划开始

这个完成度80%的结构，已经足以安排初步的行程表了。工作将分为逻辑模组，并以合适的方法分给所有的群组。这个模组将会在小组之间打碎，成为更进一步的时程表。这个次级的时程表会再分散成一系列的独立工作，然后指派给独立的成员。

研发是一组复杂的独立工作，需要进行组织化才能缩短关键路径的问题。这些工作的分析以及企划管理时间相互依赖的主要部份，将影响到整个研发过程。与结构一样，时程表也会在研发过程中不断的更新（这可能包括调整每个人的时程表，并在组员之间交换个人的工作）。重点是不断持续的追踪过程，将会在企划中不断的进行；而不是在碰上问题时才来追踪。如同我们将在第14章解释的一样，解决疑难杂症的最佳方式是靠主动，而不是预防。

研发过程在这个阶段犯下的经常性错误，是把行程表当做刻在石头上的东西；而且这个概念在游戏产业中占了大多数。如果您好好思考一下这个问题，您就会了角这有多荒谬：怎么会有任何人可以预测接下来的18个月时间中，每一个人的工作内容？通常只有在紧急的情况下才会变更时程表：在整个企划陷入危机时的主要调整，也是［太少，太晚］的例子。

如同在导引一艘船一样，您可以在航行中不断的变更微小的角度，以更好的方式来导引这艘船，而不是靠近目标再做一次大调整。

 

下一步

在这个阶段，企划已经准备起跑了，所以您需要考虑下一步该怎么走。

下一个部份解释了如何在企划的剩下时间中，定义出里程碑与查核点。

 

定义里程碑

一个常见的游戏企划可以分割成数个不同的子企划，这每一个子企划将会逐步具有［企划间从属关系（interproject dependencies）］与（更精细的）［企划内从属关系（intraproject dependencies）］

对企划常见的错误是把它们想成等大同尺寸的东西，然后假定里程碑亦是如此：一个二次空间的列表，可以让您在里程碑A到里程碑B之间，把您目前的进展画出来，依此类推。您应该要了解的是，这个列表事实上是碎裂在多次元的网状从属关系中。当这个网折叠成一个直线的列表时，您就失去了所有从属关系方面的资讯，而且在所有的从属关系中，只有最后的结果还看得到。这会降低整体的弹性，所以能让这些复杂的从属关系处于可见的状态，而且不断的更新内容才是好的办法。

试着从少数列出来的里程碑，来看清这个复杂的网状资讯，可以比喻成尝试从一个投射出来的影子，来创造一个复杂的三度空间物件。在影子中已经失去了一些原物件的幅员；结果过程中将失去重要的资讯。所以您可以看得出来，在进行安置里程碑的工作时，取得企划从属关系的资讯是极为重要的一环。

第一步是发现并定义出这些从属关系，来为每一个子企划创造出里程碑的时程表。在这个方式下，一个多层阶级性结构的企划图表，可以从此研发出来。记住，一个企划是一个庞大而复杂的问题，而且处理这种问题最明显的方式，就是把它打散成数个较小――而且比较简单的问题。画出一个阶级性的企划（并包括子企划以及他们的相对元件）有助于您得到一个较好的整体画面，是您和您的小组可以参考的。

在图12.4中显示出一个我使用的全面阶层性图表。您可以轻易的自定这个表格，用于其他的结构上，但它基本上是用来快速了解一个企划在阶层结构中的位置以及状况。在公司的内部网站中放置一个这样的表格，如同第11章所说明　的一样，也可以在每部份的相关元件上面加上超链结。由于它是一个阶层性的图表，它也连结到较大的阶层，象是连接公司中所有企划后，有助于定义出未来研发的策略。在取得从属关系并创造出阶层性的图表后，您手中的知识可以轻易的看到整体的画面（指公司远景），然后决定如何取得已有的资源，并减少不必要的努力。

主管在这个图表公诸于大众后，得到的好处是有效的消除掉公司之间沟通的障碍。每一个小组中的任一位员工，都可以明确的知道其他小组人员在做什么事。这些资讯拥有高度的扩展能力，如果必要，可以再钻研得深一点，让整个企划的所有进展可以让所有人轻易看到。

在图12.5中，显示出《Balls!》企划的阶层性图表。

您现在知道庞大的企划需要打碎成里程碑。这通常在明确定义出功能之后变得十分困难，但是避免让里程碑成为鼓励大家走近路的诱因是十分重要的。相反的，里程碑应该定义在结构点的附近，才能让这些解决方案保持了结构上的完整。

要更了解什么原因造成了良好的里程碑，我们应该注意一个什么会造成差劲的里程碑。

 

差劲的里程碑

无法提供企划进展任何相关资讯的，就是差劲里程碑。这些里程碑可以用模糊来形容，也可以是指定了表面的层级，但什么内容都没提到。

 

徒具表面性的里程碑范例包括：

＊写一个Visual Basic关卡编辑器来设计世界。

＊将图象引擎转换为32位元。

＊将二个图象系统整合，所以我们可以同时在画面上看到二者的存在。

＊做一个可玩的关卡并执行看看。

＊做好了五个可玩的关卡。

＊进入最初的测试阶段。

 

这边列出的里程碑是出现在现实生活，从不同企划中取材的里程碑。有些一看就知道很差劲，但其他并不太明显。我会一个个拿出来解释，并说明其中的优点、缺点，以及这些里程碑应该如何指定。

 

［写一个Visual Basic关卡编辑器来设计世界…］

这个里程碑（与案例研究12.1中所示的一样）是为了一个飞行射击游戏所设，要求提供碎型几何产生的地形。这个里程碑太过于普遍；它并没有提供足够的资讯。这个普及的里程碑应该改成下面这样的东西：对Visual Basic的关卡编辑器，实行初步的物质收集以及可行性研究，来决定它是否符合我们游戏的世界设计。

从这个地方开始，一个行程表以及一组以结构为基础的未来里程碑，就可以逐步完成。

 

［将图象引擎转换为32位元…］

这一项真的是表中比较好的里程碑。完整的说明是要把所有的16位元的C语言与组合语言的模式，从16位元的结构进化，才能利用32位元处理器的全部优势。这没有什么大问题，事实上，它十分的清楚而简明。

不过，这个问题是涵盖了太大的工作区域，而且没有指明转换码的等级在那边。举例来说，16位元的程式码只要简单透过转址层的运用，就可以从32位元的程式码来呼叫16位元的功能，并控制所有需要的转换过程，这也是一种［转换］。另外，这个里程碑也可能代表从头开始撰写所有的程式码，让整个引擎都在32位元的架构下。所以我们有二种解决方案，每一种都有它的优点与缺点。利用转址层的好处在于可以快速而直接的实施，坏处在于额外而全面性的Layer是每一个功能呼叫都需要用它来转换变数与回傅值，而且事实上这些程式码仍然不是全面的32位元（所以很多可能使用慢速的记忆管理呼叫，在16位元的限制下面动作）。

第二个方法的优点在于，只要能达到这个目标，所有的效能都会提升。主要的缺点在于这种转换工作通常要花量的时间。

这个里程碑应该以不同的转换来做为说明。事实上，也有另一个可能是不要把所有的程式码统统加以转换（举例来说，只有最耗时的程式码才有转换的必要，而其他的程式码――象是载取资料的程式码――大可运用转址层的方式）。

这个里程碑应该分成数个较小的里程碑，以各个不同的模组来完成这个工作。这样做可以让您对于如何进行转换工作做出更合理的决定，而且也可以彻底的增加进展的可见度。在现实中，这个里程碑从雷达上面直接消失了将近四个月之久，才又被人找出来进行。这很明显是一个难以接受的风险，所以才会有查核点的设计来解决这方面的问题。不过，在这个案例中我们的运气很好。程式设计师在这方面的能力足以胜任，而且对引擎的了解极为透彻。不过，这种对单一组员的依赖，是一件很糟糕的事情（如同第11章所示）。

 

［将二个图象系统整合，所以我们可以同时在画面上看到二者的存在…］

这个问题与上二个十分类似：并没有提供足够的的资记讯。不过，这个里程碑中包括了二个复杂模组的原始码整合（表示在二个引擎之间有标准化之后的资讯在流通），所以必须先定义出二者之间的界面。这个里程碑以自己的角度描述了整个企划，而不是一个庞大企划的一部份工作。

想想您要执行这个工作时，要做什么样的步骤。首先，您必须分析出每一个引擎输出的资讯，才能让二个引擎同时作用。哪个引擎是主要的？要把其中一个当做另一个的次程式吗？他们之间要如何互动？他们要共享萤幕的暂存区吗？什么样的变更，才能让引擎使用萤幕暂存区？如果在另一个模组中使用，会产生什么样的冲突？这在未来与其他模组整合时，又会有什么样的影响？

利用这个章节中的指导方针，您已经能够想象如何列出里程碑和查核点。藉由把问题分解成原子的厚度，我们可以增加可见度与企划进展正确性的指标。这个点子是以足够的问号去攻击现有的问题，让软体规划师的意图清晰可见。

 

［做一个可玩的关卡并执行看看…］

这实在太模糊，事实上完全没有用。究竟什么东西叫做［可玩的关卡？］

我甚至无法想象这个里程碑有什么用处。这并不是以任何技术或结构为基础的查核点；它反而象是一个用肉眼来查看的图表进度，象是一台自动机械，以精密的观察车身来检查您的车子。要真的知道里面的东西如何运作，他需要打开车壳，看看引擎的运转才对。

象这样的里程碑就会鼓励人们走近路，以取得可见的结果。需要肉眼来查看的里程碑（象这个例子）就是一个倾向挖墙角的作风。还有，您又如何预测这样的一个里程碑，要花多少时间来完成？

这方面的明显解答，是完全不要使用这一类的里程碑。让视觉效果做为一个里程碑的结果，并不是里程碑的作用。

从这个例子中，可以得知的结果是：里程碑是以结构为目标。完成里程碑的复合效果，将是一个可玩的关卡。

 

在这种情况下，下列的里程碑可能随着这一点而达成：

＊如果完成了关卡编辑的软体，开始载入并转换关卡的档案，成为内部的资料格式（包括所有待续的参考物件资料档载入，以及任何未知物件的控制）。

＊以载入的资料档案，正确显示出关卡，包括任何未知物件的控制。

＊完成以摇桿或是键盘来进行的使用者界面控制，包括以设计文件与基本玩者控制的简单选单，其中包括了结构文件中的物理系统。

 

这当然不见得每一个都要达到，但是它应该可以给您一些粗糙的点子，让您知道创造一个里程碑时，二者间的不同之处。

 

［做好五个可玩的关卡…］

这个里程碑是沿着上一个而来。这个点子是要确保软体可以载入一般定义的关卡（而不是锁死在上一个里程碑的单一测试关卡中）。

不幸的是，结果是比前一个里程碑，包括了一般假设情况下更多的硬性规定；主要是因为程式设计师可以看到他们必须在有限的时间中，把他们与下一个里程碑之间的东西清掉。所以他们会运用他们眼中的所有捷径，来冲向原来的里程碑。不用说，这样做以后有许多程式码得重写，而这些程式明明在第一次就可以写好。

这个里程碑应该是结合之前的目标，然后以技术上的目标分成数个较小的查核点，让最后的结果可以载入游戏的关卡。

 

［进入最初的测试阶段…］

这个里程碑讲的不够详细。什么叫做［最初的测试阶段］？我们如何在进行整企划、标准的研发与整合测试中，分辨［最初测试阶段］？

在这个阶段我会把［最初测试阶段］定义成所有的元件都处于［界面完成］（所有在这个企划中使用的模组，都完成了界面的设计）。这不只是个明确的进展，而且至少所有的元件都可以进行编辑，不会出现链结错误的状况。很明显的，在这个阶段中有特定等级的功能列表，但是――看到研发以一个方式不断的进展，如同本书所述一样――它也很可能会有一个很有用的核心功能。

 

为何这些里程碑有瑕疵

这些范例中举出的里程碑，最基础的问题在于它们的模糊性。大部份都没有清楚的指明，而且它们可以用许多不同的方式来达成。捷径可以采用、所以在企划附近会不断的繁殖错误与误解，并越来越庞大。

如同之前声明一样，这些范例中的里程碑用来当做企划的导航点并不会有问题，但是它们留下了大量有待详细说明、又可以完成的里程碑。它们需要分散成几个较小的里程碑，每一个都只有二进位基准：开启与关闭。

下一个部份包括了如何定义出较好里程碑的方法。

 

良好里程碑

在看过差劲的里程碑之后，我们现在把注意力转向如何让里程碑变好。很多这方面的成果，可以靠之前讨论的差劲里程碑加以推演（如果不是坏的，就一定是好的）来获得，所以我们只要把良好里程碑做一个总结就行了。

一般来说，一个良好里程碑不会留下产生怀疑的空间。它会很清楚、合理、以技术与结构的角度来说明，而且它是二进制：要不是全面完成，就是全面未完成。

良好里程碑应该详细的进行说明。每一个应该说明的极具深度，尤其是目前进展的是企划的哪一个部份。预测不应该以充满期望的想法为基础（很严酷），真正的研发时间上的预期是以经验为底子，而不是市场上的需求。要在圣诞节之前生出一些东西并不重要，您无法变更物理定律，而且您也无法变更写出良好、严密程式码所无原则的时间。不过，您可以试着进行预测并排好时程。这样做要比在程式码硬冲或是设定独断期限的赌局，来得更容易成功。

良好的预测是从创造一份阶层时的图示，来追踪整个企划以及它所有从属东西开始，然后从头到尾去追踪一条平面的路线，将路上相互影响所造成的延迟最小化。良好里程碑中必须指明技术等级，而每一个里程碑或查核点都要说明结构模组与次模组的完成阶段。这可以让里程碑更加鲜明而且定义清楚，也可以提升企划的可见度。为了正确的预测一个里程碑所需的时间，您必须把里程碑分散成数个次要工作的列表，小到您可以合理而正确的估算出完成它们所需的时间。这通常表示把工作打散之后可以在一或二天的时间完成，提供良好的次级里程碑与查核点（如果需要的话）。这是一个很需要技巧的过程，当您在预估的过程中获得经验之后，您就会发现它成为较容易分散的里程碑，并可以让您做出精确的预估。

一个良好里程碑可以强化企划的可见度，而且在完成之后，可以让一个人拥有完成这种工作的微妙感觉。

 

案例研究12.3　一个真实的里程碑

《Balls！》是一个为本书撰写的展示用企划，主要是用来证明本书所有的研发方式与概念确实可行。

这个案例研究是检视企划中使用的一组真实里程碑，并详述它是如何分割为查核点。它本身会展示出如何实行技术上的里程碑。

里程碑：

概要：实行一个物件层级的Z暂存区，藉由减少不必要的画面贴图，来增加画面的更新速度。

备忘录：在朝这个里程碑迈进时，要容许退回标准的绘图运算法则，并考虑目前用来环绕所有Z－暂存区程式码的假定编译指令。当这此些指令都完成定义之后，Z－暂存区的程式码会启用，否则这个程式码会采用以前的方式来运作。

查核点1.0.采用标准的测试层级并启动计时的程式码，以计算每一个画面的绘制速度（0.5天）

查核点2.0.将物件分类成数量最少的组别。每一组应该包括这些物件，在平面画面的座标一样的时候，全面重绘其他的东西。旗标将成为这个规则的例外（举例来说，不应该让透明物件背后的东西看不到）。为每一组物件提供分别的Z－暂存区（1天）

查核点3.0.对每一个有效的种类进行Z－暂存区个体（Member）的［查核］与［设定］。每一个游戏物件必须拥有这个个体，所以在实行时可以将它们看为画面物件资料库中的纯粹真实个体。提供一个标准的运作，把一个点带入特定物件组的Z－暂存区中，设定一个阶层越高越好的参数，并在必要的时候让这个特殊的案例失效（象是透明的物体）（1天）

查核点4.0.在基础等级的［Prepare To Draw］与［Draw］个体中插入Z－暂存的检查与设定。在这个阶段中尽快针对失败的Z－暂存区进行测试，让不需要显示出来的物件，只要花最少的工作量。（1天）

查核点5.0.为测试关卡生产新的计时资讯，并与查核点1中的结果相比对。全面更新模组设计文件来反应这些变化，并插入新的计时资讯（1天）。

这是一份直接的里程碑与查核点副本（虽然编写得有点简单）。我已经变更了查核点1，如同它也考虑到回顾并整理这些程式码，来确保所有的说明都是最新撰写，而且所有的不良程式码统统移除（因为我有一段时间，没有参与特定模组的工作）。这边并不是我们要考虑的，但是它会让时程表再多花上一天。

在案例研究12.3中，这个特别的里程碑在结构定义之后，已经被插入了一个里程表。这是一个结构上的变更，才能在速度较慢的显示卡上面，增加系统画面更新的速度（在这个变更中，有20%的结构无法得知或是猜测）。如您所见，这并不象一般常见的企划里程碑，因为它是以结构以及常用的英文，以减少技术方面的专用术语（如果这边用了专业术语，要解释起来就容易得多）。

 

由于一个示范企划中具有高度的模组化本质，这个里程碑通常以二个星期为一次，而查核点大约是二天一次。

 

研发与期限

在这个阶段，我们偏离一下主题快速讨论一下研究里程碑，是很有价值的。

让我们先把话说清楚：研究里程碑是一种矛盾的说法。

一个期限说明的是固定的日期与时间，由一个小心而充满考量的工作之下所假设出来。从另一个角度来看，研究是一个探索未知事物的举动。要如何正确的为不知道的事情，来正确的安排时间？如果不行的话，您可以试着向您身边大部份的企划管理者解释，然后看看您会得到什么样的反应。

在这个情况下的研究，不应该与必备物资的收集搞混了。研究是一个追寻新的科技与运算法则，以实现一个点子的过程。必备物资的收集是一个靠着设计文件来找寻您所需要的东西，用来建造产品的过程。

程式设计师的主要工作，如同前一章所提示的，就是把一组详细的技术规格转换成一个程式，或是程式模组。这并不是在职位上的研发工作，而且要在期限中完成。研究与期限通常具有独立性的本质，如果在一个企划的目前阶段需要研究，那在初始的可行性研究中肯定出了一些大问题（这些可能性应该在事前就探讨过了）。所有的研究都有风险：您的风险就是没有结果。之后您在一个企划冒着研究的风险时，表示有更多无法接受的风险随之出现。简而言之，在一个企划中，避免所有不必要的研究。

 

里程碑的评定

当评定一个里程碑的时候，在完成之前要有数个人签名。至少，这些人包括发行公司、原公司以及企划管理者。正因为如此，里程碑倾向于以结果为基础，可以在视觉上展现成果的时刻。如同我们之前所讨论过的，这并不是好事。里程碑的基础如果架在视觉效果上，表示您通常会看到您想要的：一个有着美丽外观而败絮其中的程式。象是湖上的天鹅一样，它在水面上表现的流畅而优雅，但是脚掌在水下强烈的拍动。这就是里程碑在游戏产业中评定的方法（或许这可以解释一些现象，象是游戏现在把风格凌驾在内容之上）。

整个研发的生命周期是以外表的模样为基准，而不是以内在的结构。虽然这对绘图而言不错，但显然对复杂的技术工作――象是电脑程式――没有什么好处。如果这些标准用在盖桥上面，想象一下这会发生什么事：只要结构体上画好颜色之后，就马上宣布盖好了，那如果有人真的走过去，桥塌了怎么办？

对于那些评定里程碑的人而言，只有接受时程表必须以结构上的规格为基础，才能保有最大的利益。

里程碑应该尽可能以科技为主，而且它代表的是目前结构状况的整合。在游戏研发中，结构是单一最重要的本质；所以，里程碑应该是以它为基础。它可以用骨骼来比喻：它需要完整的发展，否则不管上面覆盖多美丽的组织，这个生物还是会变形（如果您看过电影的［变蝇人］一、二集，您就知道我这边讲的是什么意思。真的很不雅观）。

就算您无法在撰写里程碑时避免使用技术性的术语，也尽可能使用大家看得懂的语言。如果您很小心的撰写，就算是最没有技术能力的人，也可以了解并增加技术里程碑的好处与可见性，进而延伸到整个企划。一般来说创造者，游戏设计者，与发行公司是最重要的里程碑回顾者。不偏不倚是十分重要的，而且里程碑也应该直接从强烈的技术观点，来进行主要的评估。

要为里程碑负责的小组人员，应该以里程碑为何要完成来看待他们的案子，而内部回顾人员却是要以魔鬼代言人的举动，试着证明里程碑尚未完成。这方面要严格一点：一个没完成的里程碑，相当于被抛诸于脑后的无味东西，将在日后以最让人意想不到而且最麻烦的方式出现（未完成的里程碑适用于墨菲定律）。

组员必须全面了解，为什么一个科技里程碑，代表的不一定马上向前迈进一步，尤其是对不精通科技的人而言。小组的责任包括展示与说明里程碑，连办公室的猫都要能够了解其中的重要性，以及如何符合广大的计划。

、、、
没有评论

达达尼昂 | 资料收藏 |
《电脑游戏结构与设计:理论篇》第十一章 软体工厂【转】

  

第十一章　软体工厂

 

＊软体工厂所解决的问题

＊设定一个软体工厂

＊使用一个软体工厂

＊软体工厂的可适性

 

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

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

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

 

临时的工作环境

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

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

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

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

 

分散风险

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

、、
没有评论
« 更早的文章 较新的文章 »