游戏策划 Design Inside

达达尼昂 | 游戏开发[资料] | 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万套。您的经营计划必须让您能靠着这个成果存活。如果您计算一下的话，您会看到达到这个目标的合理化过程，让您同时省下金钱并减少上市时间的损失，而且可以增加内容的充实性。

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

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

电脑游戏结构与设计 

第十二章　里程碑及期限

 

＊企划的时程安排

＊避免独断的期限

＊破除模糊的里程碑

＊企划的开始

 

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

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

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

里程碑的作用是把企划分解成可以管理的厚块。最不应该采用的作法，就是列出一长串想用的功能列表，让研发者一个个查看是不是统统完成：当然了，事实上也不应该建议这种方式。您可以想象到，在一个企划持续了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%的结构无法得知或是猜测）。如您所见，这并不象一般常见的企划里程碑，因为它是以结构以及常用的英文，以减少技术方面的专用术语（如果这边用了专业术语，要解释起来就容易得多）。

 

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

 

研发与期限

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

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

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

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

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

 

里程碑的评定

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

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

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

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

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

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

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