|
|
楼主 |
发表于 2004-3-8 17:19:00
|
显示全部楼层
Re: 电脑游戏结构与设计——第十二章
以下是一些建议的东西（以及例子）：
＊编辑器（微软Visual C++）
＊自动侦测错误的软体（Numega BoundsChecker）
＊侧写程式（Numega TrueTime）
＊资源控制软体（微软Visual SourceSafe）
＊时程管理软体（微软Developer）
＊文书处理软体（微软Word）
＊3D模组建构程式（Kinetix 3DS Max）
＊2D绘图软体（Adobe Photoshop）
＊格式翻译软体（Okino Polytrans）
（这个列表中的东西，只是以我最熟悉的软体来进行建议，也是目前的研发公司最常使用的东西。这些软体中有些可能很贵，尤其是在预算有限的状况下。幸好仍有其他的选择，而且在本书附上的光碟中，也提供了一系列的免费或是共享软体，或是您可以在哪边搜寻的建议。您可以在附录B找到与软体相关的详细内容。）
血腥的尖端科技
您想要一些有用的建议，或是从痛苦中学到的一点点经验吗？那就是绝对不要用最新版的软体，直到它已经推出一段时间为止。如果您在一个企划半途转换版本，它也会造成延期。另外，如果事情进行的不顺利，把软体版本［倒转］回去将是一个很花时间而且很昂贵的工作。他们叫做［血腥的尖端科技］，自然有其道理。
查核点2.0 一般可行性研究
这个查核点中必须回应下列的问题：
这是一个有价值的企划？
您应该开始探讨游戏性与故事，并把它打磨光亮。很明显的，这并不会马上定案，而是倾向在研发过程不断的调整与变革；这是把旧点子挥去，并加入新发现、好点子的时刻。
在这边要提出一个警告：小心特色四处蔓延。很多游戏之所以延期或是取消，是因为低估了加入的特色。特色的潜行，以及它的预防方式，将在第三部中讨论。
这个市场准备接受这个游戏了吗？
这个游戏是否适合目前的市场？这并不表示游戏应该毫无新意，只是模仿市面上已经有的游戏（如果真的这样，那您就要重新考虑这个企划。有太多的公司生产出没有新意而且毫无生机的游戏，用不着您再加上一笔。回到第一步，直到您有更具启发性的点子！）
好，假定您还在这边，那您的游戏设计也通过第一道酸碱测试。下一个问题，是这个游戏设计到底是个全新的类型，还是目前类型的延伸。如果是一个全新的游戏，那我会建议您研究一下市场是否能够接受它。在刚开始时，试着询问一群中立、对游戏设计有不少批评的人们。问问他们这种游戏会不会想玩，并询问他们喜欢与不喜欢的部份。这边最重要的是得到诚实（虽然一向都很唐突）的答案，然后排除掉家庭、朋友与同事的意见。一个最常见的建议是，设计一个您会想玩的游戏；这本身并没有什么问题，但是您冒的最大风险是把游戏做成只有您要玩的东西。当然了，您必须设计一个您也想玩的游戏，但这绝对不能成为您的指导方针。
如果游戏是以现有的游戏做延伸，那上述的建议仍然有效。除此之外，试着去定义您的游戏如何加强这个类型。一个最传统的范例是Valve的《战??笨铡罚?桓龅谝蝗顺粕浠饔蜗罚?且浴独咨裰?m2》的引擎来建构的。不过，它在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章所示）。
［将二个图象系统整合，所以我们可以同时在画面上看到二者的存在…］
这个问题与上二个十分类似：并没有提供足够的的资记讯。不过，这个里程碑中包括了二个复杂模组的原始码整合（表示在二个引擎之间有标准化之后的资讯在流通），所以必须先定义出二者之间的界面。这个里程碑以自己的角度描述了整个企划，而不是一个庞大企划的一部份工作。
想想您要执行这个工作时，要做什么样的步骤。首先，您必须分析出每一个引擎输出的资讯，才能让二个引擎同时作用。哪个引擎是主要的？要把其中一个当做另一个的次程式吗？他们之间要如何互动？他们要共享萤幕的暂存区吗？什么样的变更，才能让引擎使用萤幕暂存区？如果在另一个模组中使用，会产生什么样的冲突？这在未来与其他模组整合时，又会有什么样的影响？
利用这个章节中的指导方针，您已经能够想象如何列出里程碑和查核点。藉由把问题分解成原子的厚度，我们可以增加可见度与企划进展正确性的指标。这个点子是以足够的问号去攻击现有的问题，让软体规划师的意图清晰可见。
［做一个可玩的关卡并执行看看…］
这实在太模糊，事实上完全没有用。究竟什么东西叫做［可玩的关卡？］
我甚至无法想象这个里程碑有什么用处。这并不是以任何技术或结构为基础的查核点；它反而象是一个用肉眼来查看的图表进度，象是一台自动机械，以精密的观察车身来检查您的车子。要真的知道里面的东西如何运作，他需要打开车壳，看看引擎的运转才对。
象这样的里程碑就会鼓励人们走近路，以取得可见的结果。需要肉眼来查看的里程碑（象这个例子）就是一个倾向挖墙角的作风。还有，您又如何预测这样的一个里程碑，要花多少时间来完成？
这方面的明显解答，是完全不要使用这一类的里程碑。让视觉效果做为一个里程碑的结果，并不是里程碑的作用。
从这个例子中，可以得知的结果是：里程碑是以结构为目标。完成里程碑的复合效果，将是一个可玩的关卡。
在这种情况下，下列的里程碑可能随着这一点而达成：
＊如果完成了关卡编辑的软体，开始载入并转换关卡的档案，成为内部的资料格式（包括所有待续的参考物件资料档载入，以及任何未知物件的控制）。
＊以载入的资料档案，正确显示出关卡，包括任何未知物件的控制。
＊完成以摇?U或是键盘来进行的使用者界面控制，包括以设计文件与基本玩者控制的简单选单，其中包括了结构文件中的物理系统。
这当然不见得每一个都要达到，但是它应该可以给您一些粗糙的点子，让您知道创造一个里程碑时，二者间的不同之处。
［做好五个可玩的关卡…］
这个里程碑是沿着上一个而来。这个点子是要确保软体可以载入一般定义的关卡（而不是锁死在上一个里程碑的单一测试关卡中）。
不幸的是，结果是比前一个里程碑，包括了一般假设情况下更多的硬性规定；主要是因为程式设计师可以看到他们必须在有限的时间中，把他们与下一个里程碑之间的东西清掉。所以他们会运用他们眼中的所有捷径，来冲向原来的里程碑。不用说，这样做以后有许多程式码得重写，而这些程式明明在第一次就可以写好。
这个里程碑应该是结合之前的目标，然后以技术上的目标分成数个较小的查核点，让最后的结果可以载入游戏的关卡。
［进入最初的测试阶段…］
这个里程碑讲的不够详细。什么叫做［最初的测试阶段］？我们如何在进行整企划、标准的研发与整合测试中，分辨［最初测试阶段］？
在这个阶段我会把［最初测试阶段］定义成所有的元件都处于［界面完成］（所有在这个企划中使用的模组，都完成了界面的设计）。这不只是个明确的进展，而且至少所有的元件都可以进行编辑，不会出现链结错误的状况。很明显的，在这个阶段中有特定等级的功能列表，但是??看到研发以一个方式不断的进展，如同本书所述一样??它也很可能会有一个很有用的核心功能。
为何这些里程碑有瑕疵
这些范例中举出的里程碑，最基础的问题在于它们的模糊性。大部份都没有清楚的指明，而且它们可以用许多不同的方式来达成。捷径可以采用、所以在企划附近会不断的繁殖错误与误解，并越来越庞大。
如同之前声明一样，这些范例中的里程碑用来当做企划的导航点并不会有问题，但是它们留下了大量有待详细说明、又可以完成的里程碑。它们需要分散成几个较小的里程碑，每一个都只有二进位基准：开启与关闭。
下一个部份包括了如何定义出较好里程碑的方法。
良好里程碑
在看过差劲的里程碑之后，我们现在把注意力转向如何让里程碑变好。很多这方面的成果，可以靠之前讨论的差劲里程碑加以推演（如果不是坏的，就一定是好的）来获得，所以我们只要把良好里程碑做一个总结就行了。
一般来说，一个良好里程碑不会留下产生怀疑的空间。它会很清楚、合理、以技术与结构的角度来说明，而且它是二进制：要不是全面完成，就是全面未完成。
良好里程碑应该详细的进行说明。每一个应该说明的极具深度，尤其是目前进展的是企划的哪一个部份。预测不应该以充满期望的想法为基础（很严酷），真正的研发时间上的预期是以经验为底子，而不是市场上的需求。要在圣诞节之前生出一些东西并不重要，您无法变更物理定律，而且您也无法变更写出良好、严密程式码所无原则的时间。不过，您可以试着进行预测并排好时程。这样做要比在程式码硬冲或是设定独断期限的赌局，来得更容易成功。
良好的预测是从创造一份阶层时的图示，来追踪整个企划以及它所有从属东西开始，然后从头到尾去追踪一条平面的路线，将路上相互影响所造成的延迟最小化。良好里程碑中必须指明技术等级，而每一个里程碑或查核点都要说明结构模组与次模组的完成阶段。这可以让里程碑更加鲜明而且定义清楚，也可以提升企划的可见度。为了正确的预测一个里程碑所需的时间，您必须把里程碑分散成数个次要工作的列表，小到您可以合理而正确的估算出完成它们所需的时间。这通常表示把工作打散之后可以在一或二天的时间完成，提供良好的次级里程碑与查核点（如果需要的话）。这是一个很需要技巧的过程，当您在预估的过程中获得经验之后，您就会发现它成为较容易分散的里程碑，并可以让您做出精确的预估。
一个良好里程碑可以强化企划的可见度，而且在完成之后，可以让一个人拥有完成这种工作的微妙感觉。
案例研究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%的结构无法得知或是猜测）。如您所见，这并不象一般常见的企划里程碑，因为它是以结构以及常用的英文，以减少技术方面的专用术语（如果这边用了专业术语，要解释起来就容易得多）。
由于一个示范企划中具有高度的模组化本质，这个里程碑通常以二个星期为一次，而查核点大约是二天一次。
研发与期限
在这个阶段，我们偏离一下主题快速讨论一下研究里程碑，是很有价值的。
让我们先把话说清楚：研究里程碑是一种矛盾的说法。
一个期限说明的是固定的日期与时间，由一个小心而充满考量的工作之下所假设出来。从另一个角度来看，研究是一个探索未知事物的举动。要如何正确的为不知道的事情，来正确的安排时间？如果不行的话，您可以试着向您身边大部份的企划管理者解释，然后看看您会得到什么样的反应。
在这个情况下的研究，不应该与必备物资的收集搞混了。研究是一个追寻新的科技与运算法则，以实现一个点子的过程。必备物资的收集是一个靠着设计文件来找寻您所需要的东西，用来建造产品的过程。
程式设计师的主要工作，如同前一章所提示的，就是把一组详细的技术规格转换成一个程式，或是程式模组。这并不是在职位上的研发工作，而且要在期限中完成。研究与期限通常具有独立性的本质，如果在一个企划的目前阶段需要研究，那在初始的可行性研究中肯定出了一些大问题（这些可能性应该在事前就探讨过了）。所有的研究都有风险：您的风险就是没有结果。之后您在一个企划冒着研究的风险时，表示有更多无法接受的风险随之出现。简而言之，在一个企划中，避免所有不必要的研究。
里程碑的评定
当评定一个里程碑的时候，在完成之前要有数个人签名。至少，这些人包括发行公司、原公司以及企划管理者。正因为如此，里程碑倾向于以结果为基础，可以在视觉上展现成果的时刻。如同我们之前所讨论过的，这并不是好事。里程碑的基础如果架在视觉效果上，表示您通常会看到您想要的：一个有着美丽外观而败絮其中的程式。象是湖上的天鹅一样，它在水面上表现的流畅而优雅，但是脚掌在水下强烈的拍动。这就是里程碑在游戏产业中评定的方法（或许这可以解释一些现象，象是游戏现在把风格凌驾在内容之上）。
整个研发的生命周期是以外表的模样为基准，而不是以内在的结构。虽然这对绘图而言不错，但显然对复杂的技术工作??象是电脑程式??没有什么好处。如果这些标准用在盖桥上面，想象一下这会发生什么事：只要结构体上画好颜色之后，就马上宣布盖好了，那如果有人真的走过去，桥塌了怎么办？
对于那些评定里程碑的人而言，只有接受时程表必须以结构上的规格为基础，才能保有最大的利益。
里程碑应该尽可能以科技为主，而且它代表的是目前结构状况的整合。在游戏研发中，结构是单一最重要的本质；所以，里程碑应该是以它为基础。它可以用骨骼来比喻：它需要完整的发展，否则不管上面覆盖多美丽的组织，这个生物还是会变形（如果您看过电影的［变蝇人］一、二集，您就知道我这边讲的是什么意思。真的很不雅观）。
就算您无法在撰写里程碑时避免使用技术性的术语，也尽可能使用大家看得懂的语言。如果您很小心的撰写，就算是最没有技术能力的人，也可以了解并增加技术里程碑的好处与可见性，进而延伸到整个企划。一般来说创造者，游戏设计者，与发行公司是最重要的里程碑回顾者。不偏不倚是十分重要的，而且里程碑也应该直接从强烈的技术观点，来进行主要的评估。
要为里程碑负责的小组人员，应该以里程碑为何要完成来看待他们的案子，而内部回顾人员却是要以魔鬼代言人的举动，试着证明里程碑尚未完成。这方面要严格一点：一个没完成的里程碑，相当于被抛诸于脑后的无味东西，将在日后以最让人意想不到而且最麻烦的方式出现（未完成的里程碑适用于墨菲定律）。
组员必须全面了解，为什么一个科技里程碑，代表的不一定马上向前迈进一步，尤其是对不精通科技的人而言。小组的责任包括展示与说明里程碑，连办公室的猫都要能够了解其中的重要性，以及如何符合广大的计划。
==============第十二章完！~============================
[em21] [em21] [em21]
|
|
发表于 2004-3-8 17:18:00
