|
|
第四章 设计详述
＊一份经过详细设计的文件的重要性
＊与软体规划师沟通
＊准备接受变动
＊谁需要这些
截至目前为止，这个阶段所做的游戏设计内容都属于［象牙塔］中的企划过程；也就是说，到目前为止设计者可以单独一个人，把所有时间都投注在这个企划上。
在这个阶段的结尾，您应该写好两件文件了：游戏内容规格以及设计备忘录。游戏内容规格是一个［远景描述］的文件，用来说明最后完成的产品是什么模样，而且将成为每一个人所要努力的目标。在程式码与游戏内容规格集结于一点之后，这个产品就已经蓄势待发了。设计备忘录是用来与游戏内容规格同时对照查看的，上面解释了您的设计理念，并让其他人挑战您的假想内容，而不只是挑战您做的结论。
设计者的角色
您一定想说：［请先等一下］，我知道您想说什么，是的，设计师并不是单人乐团，难道他不应该听听其他成员对游戏上的建议？游戏设计上采用民主的过程，难道不会比较好吗？
在上述的最后一点，我抱持的看法是，只有一种东西值得让多人参与讨论（象委员会），那就是美国作法。不过一个设计师当然要请其他成员发挥意见，并接纳他人的想法。没有人可以想到所有的东西，而且在脑力激荡的过程中，光是二小时引发出来的点子，换成一个人来思考，只怕一辈子都未必想得出来。
所以，您一定要与所有参与研发的人员谈谈这个游戏。另外，行销人员有他们要扮演的角色，所以您也有和他们沟通的必要，看看什么样的游戏，在未来二年中最适合市场的需求。最重要的是，靠着您的游戏提案与概念性的手稿，找出客户看到这个游戏时的观感。
我先前说过，设计师到目前这个阶段的工作都是单独完成，也表示不应该有其他人参与其中。请先牢记这个差别，它对于观察现行企划的整体时程表十分有帮助，同案例研究4.1。
案例研究4.1 一个研发时程表
案例研究4.1显示出一个即时战争游戏《Plague》的研发时程表。
灵感：
时间：一个月
过程：初始的点子以及可行性的讨论，导向提案文件的完成。
人员：首席设计师，有时会接受结构与技术小组的建议。
结果：客户（发行公司）决定这个企划是不是可以亮绿灯。
概念化
时间：三个月
过程：写下详细的设计内容。
人员：首席设计师在第二到第四个月的工作。
结果：二份文件，游戏内容规格与设计备忘录。
蓝图
时间：二个月
过程：规划阶段性的迷你规格，也就是一连串的较短文件，详述每一阶段的研发过程。每一份文件描绘了各个阶段［最有可能］的解决方案，以及一个总结来说明这个阶段中要完成的事项。
人员：首席设计师以及一位软体规划师。
结果：数个（举例来说，可能有六份）迷你规格的文件。
技术性结构
时间：二个月
过程：以阶段性的迷你规格为基础，现在结构小组准备进行技术性的设计，这个时候得详细说明游戏中需要的工具和技术性元件。首席设计师一段段的说明游戏概念，并将主导权交给企划领导者。其中包括《Plague》的企划领导者，一个结构小组的人员，将会针对这个游戏做出一个结论。
人员：企划领导者、首席结构师，以及一位软体规划师。
结果：主要的技术规格与进一步的阶段性迷你规格，将针对游戏性与技术性层面问题进行辩论。这些结果与游戏规格将组成进一步的企划。阶段性迷你规格将对应成里程碑（在这个案例中以每季为区隔点），并完成与客户端签定的合约内容。
建造工具
时间：四个月
过程：建造游戏中所需要的每一个元件以及工具组。这个阶段要做到的认知是，在完成任何方面的游戏结构时，不能出现相互依赖的现象，否则需要再度进行校正。
人员：企划领导者以及四个工作及技术小组的成员。
结果：工具以及游戏中的元件，如果还无法完成所有的特色，至少功能要完整。在《Plague》中，这些包括了一个3D图象引擎、关卡设计工具，以及一个设定游戏的编辑器，来进行部队以及建筑物的创造。
组合
时间：二个月
过程：一个企划领导者以及一个工具程式设计师，现在负责管理整个小组（举例来说，四个程式设计师与四位美术人员），以六个星期为周期的时间，按照分阶段的系统把游戏组合起来。企划领导者以各种不同的手法，让游戏性有最佳的发挥空间，工具程式设计师提供工具，并在必要的时候可以将工作交付给工具和技术小组（理论上，首席设计师在这个测试与回顾的每一个分层阶段末尾，都要担任顾问的工作，但是并不需要天天参与这个小组的制作。他（或是她）已经有?的空间，来设计下一个游戏了。）
人员：企划领导者12个月，工具程式设计师9个月，四个程式设计师12个月，四个美术人员在最后的8~9个月。
结果：游戏与完整的工具出炉，之后的过程中再也不需要程式设计师了。
关卡
时间：四个月
过程：游戏关卡将在企划领导者的指挥之下开始制作。实际上，企划领导者现在应该在一连串的战斗下显出疲态，所以首席关卡设计师是不是具有创意，以及创作人员能否担得起这个重任才是最重要的。所以，企划领导者应该可以将他的部分主导权，在打造关卡时分担给关卡的设计人员。
人员：企划领导者以及关卡设计者。
结果：完成游戏中的所有关卡，以及游戏教学关的内容。这时应该写好说明书的文字，并完成所需的图稿。
回顾
时间：三个月（至少有一部份是与关卡设计时间重叠）。
过程：这部分的工作应该与关卡设计重叠，不过可能在资料来源上有所不足。一般来说（象是《Plague》这个例子），可以由发行公司的客服部门来负责。
人员：四位测试人员。
结果：找出游戏中的臭虫并加以修正。如果找到的是游戏性方面的基础问题（虽然在这个最后阶段中，不应该出现这种情况），可以把游戏交回制作人员手中调整，但这个阶段已经接近压片完工的时候。
在图4.1和4.2中，显示出在制作一个游戏时，从概念到压片所花的全部时间，在花费与结果的比率（投资报酬率）上有明显的差别。看看《Plague》这个范例是如何规划的，您可以看到如何让花费保持在一定的程度之下。在前6个月的时间，只需一小群人进行这个企划就行了，整个制作小组参与的时间差不多只有12个月。
图4.1中显示出现今常见的情况：整个小组从第一天开始就朝夕相处。设计的工作交由游戏设计师负责，而且在完成之后交给研发小组。发行前的准备工作通常是由设计师与游戏小组的部分成员，做最后一次的游戏性调整。在这样的流程之中，会浪费掉不少时间与金钱：因为流程中会出现人员无事可做的空间。
图4.2显示的是一个理想的状况。设计时只有游戏设计师和软体规划人员在进行研究，而且在完成之后就把结果交给研发小组，在设计与软体规划人员的监控之下，把特定的计划组合起来。发行前的准备工作，是由设计师与软体规划人员做最后的调整，让大量人员从事于同一个计划的时间缩到最短。
不过，游戏产业的文化，导致上述有效流程，在过去不太可能实现。从历史上来看，这个产业是从一个有热忱的小型团队组成，以集中每一个人的才华。现在，只有勇气十足而且拥有充分资金的研发工作室，才能负担起整个制作小组（可能有12个人）从头开始设计游戏的花费（谁知道？这种方式可能会做出较好的游戏）。不过，重点是，很少有游戏采用这种管理方式来制作，而是不断的设法取得足够的资金，直到游戏看到一线曙光为止。
在强调软体研发的方向（详见第11章）上，我将老式的研发过程命名为12毛瑟枪模型（Twelve Musketeers Model）：［人人为我，我为人人］（然后别管每个月烧掉多少钱）。不过，在这二种模型的转换过程之间，是不是有一些先期的准备工作？再来一次，我们来回顾一下电影工业：在创始的阶段中，工作小组带着摄影机来到好莱坞的山丘上（那些日子并没有那么多的建筑物）然后一次拍一个场景的把电影拍出来。脚本（如果有的话）可能是大家合作的成果，或是靠着知道怎么写的技术人员（或是演员）来提供。
用这种方式做事情，比经常在电影中被雇用的老枪手还早阵亡。电影工业开始严肃起来，这条赚钱的方式代表要拍出更壮观的影片，也表示更大的团队；很快的，社团似的拍摄体系不再适用。要更有效率，则需要更好的规划，而今天已经有了更精巧的程序。作者在他的文字处理机前面猛敲键盘，写出第一份脚本的草稿。然后导演和电影摄影师可能要完成一份分镜表和处理手法。幕前制作（选角、地点查看等等）只需要一个小组来负责，而且只有在这些过程之后，才会让整组人员（可能有上百人）加入。在幕后制作中，整个计划一样在导演、编剧、演艺人员、音乐、特效等等分层承包。
这个在关键路径分析下的实物教学，是游戏产业必须好好学习的科目。
设计文件
再重复一遍，您现在应该拥有的是游戏内容规格和设计备忘录。下列的章节中将会更详细的进行说明。
游戏内容规格
游戏内容规格是对游戏的详细描述，在研究并全面的了解之后，可以让阅读的人看到游戏完成之后的真正模样。在一开始的时候，您可以把游戏内容规格看成游戏本身的原型，或是把它看成来自未来的文件，内容就是您一年这后对这个作品的描述。游戏内容规格是可变动而且不断变化的文件，它在整个研发的过程中，都会结合不同的想法而改变。
现在，拿着您辛辛苦苦写好的游戏内容规格，把它放在程式设计师们的面前，然后告诉他这份文件已经完成了。您知道他们会说什么吗？［这怎么算完成？你甚至还没把超能力、蛮族战士、纵火狂放进去。］这一团突如其来的混乱，是因为人们误解了［完成］这个了的意义。在游戏研发中，它并不表示一份文件或是程式模组不会再变动；而代表的是它处于一个可以运作的状态下：它已经能动了，但可能还不够完美。如果文件或是程式码的作者掉到火车下面去，您也用不着把他的大作丢掉。既然它已经完成了，其他人就可以在必要时拿来使用，甚至是加以修改。
所以，完成并不代表结束。完成是一个正在进行的过程，而且在每一阶段都完成之后，游戏（理论上）才能发行。它目前的状况可能卖不到十套，但它已经可以发行了。在游戏制作结束后，它将会拥有您所想到的每一种特色，而且一切都搭配的完美无缺：这指的不只是程式码本身，还包括游戏性、界面以及其他的一切。
法国的著名诗人华莱理（以及之后的乔治·卢卡斯）说过：［工作永不结束，只有放弃。］如果他们曾经担任过游戏设计师，他们讲的话会变成：［没有什么游戏会做到结束，只有放弃。］接受这一点吧，您的目标是让您的游戏历经许多不同阶段的完成，才能把东西拿出去卖。
设计备忘录
设计备忘录真的只是一份文件，上面写的是您在考虑规格时，脑袋突然想到的一切事情。上面的涂鸦可能包括您在凌晨二点时随手在信封背后写下的东西，如果您喜欢的话，就把它定个标题然后解释它的作用。
设计备忘录在两方面十分有用。首先，所有的文件都有它的价值：如果您正在设计下一个游戏时，却在梦游中掉下悬崖，这个计划也不用就此中断。其次，它和程式码旁边的说明文字拥有相同的优点，在游戏内容规格中的一句话（嗯，象是一个两台坦克相对火力的决定，或是收集压碎甜瓜的奖励多寡）都可能是深思熟虑数小时之后的结果。您会记得您花多少时间才写出来，但不会记得为什么要用掉那么多时间。在案例研究4.2中，可以给您一个例子，看看写一份规格要什么东西。
案例研究4.2 规格文件所需的东西
正在进行研发的游戏叫《Metropolis》，是一个资源管理的模拟游戏。设计者约翰（John）已经写下了一条规则：资源必须在世界中加以控管，也就是说，显示在画面上方的铁块与黄金数量，其实是放在玩者的市民中心总数量。市民中心这栋建筑物可以存放各1000单位的铁块与黄金。如果市民中心放满了，玩得可以建造储存性的建筑，来创造更多的储存空间：象一个贮塔可以存放各250单位的黄金和铁块。
二个月之后，其中的一位程式设计师艾恩（lan）开始进行程式码的撰写，这方面是与资源管理有关的。他质问为什么一个储存性的建筑物可以存放二种不同的资源。［为什么不让市民中心可以存放总共2000单位的资源，而不用管它究竟是黄金或铁块？这样话，贮塔就可以放500单位。］
约翰从来没有准备好一份设计备忘录文件，而且想不出为什么他当时没想到艾恩的作法，所以他答应做这一项变更。
又过了二个月，进入测试阶段：这时一位关卡设计师史提夫（Steve）找到问题了。他的储存空间都用光了，而且需要建造新的贮塔，这得花掉他100单位的铁块。但是放在市民中心的资源存量却是1960单位的黄金以及40单位的铁块，这些铁块并不足以让他支付新贮塔的费用。他叫其他人过来，并把问题表演给大家看。
［我们可以把它改成这样：工人所携带的资源，可以直接用在现有的工作上，史提夫建议，［利用这个方式，只要派去盖贮塔的工人身上还带了60块铁块，他们还是可以把贮塔盖好。这样就不用经过玩者的储存区了。］
［我不喜欢这样，］艾恩反驳，［这会变更你在花用资源时，扣除资源的计算方式。在目前这个阶段要改变这一点已经太勉强了。当然，你可以用更简单的方式，派工人去做一些要花用黄金的事情，只要在市民中心清出60单位的空间，你就拿回存放100单位铁块的空间了。］
［这已经打破了第一条规则，］约翰力辨，并引用第一条规则的内容，［你的敌人应该是其他的玩者，而不是游戏系统本身。这表示要中止所有工人运送黄金的工作，直到有足够的铁块为止…］他猛拍了一下前额，［该死！］
［什么事？］艾恩与史提夫齐声发问。
［我早就想到这一点了，好几个月前就想到了！所以我原来的规格中，才会分别设计黄金和铁块的储存量。但是我却忘了为什么要这样做！］
使用设计文件
您必须考虑到二个事实：
＊程式设计师该看您的游戏内容规格。
＊程式设计师不会去看游戏内容规格。
他们真的不看。您可能告诉他们这东西为何这么重要，您可以和他们进行激辨，您甚至可以施展您的权威。但是您的程式设计师真的不会去看这一份规格。
您可能听说过，程式设计师无法分辨木头和树木有什么不同；而设计者无法分辨树木和木头有什么不同。这是真的，尤其是程式设计师，有时连树上有没有叶子都搞不清楚。这就是他们为何可以在程式方面无所不通：他们的主要能力是在面对一个过程时，按照细小的独立步骤，把东西打碎到量子的等级。所以他们无法（而且不能）看完游戏内容规格，吸收里面的所有资料之后，在他们的脑中建立出一个完整的游戏模型。
事实上，他们为何要这样做？这是设计与结构小组的工作内容。小组中的程式设计师，要看的只是详细说明。
但是在几个理由之下，他们手边还需要准备一份设计文件。首先，执行我们的工作却不知道目标，很容易导致士气低落而且招来反效果。其次，当一些工作的观点引发争论时，参考规格要比把设计师绑架过来回答有效率得多。第三，虽然基于财政的考虑，游戏规格只靠一个人或是一小群人写出来，但是，如果能聚集所有人最好的点子，让游戏臻致完美更好。最后，一个大家都可以想象的游戏完成远景，有助于凝聚整个小组以及提升士气。
这两个事实真的让人进退两难，所以很明显的，在设计工作中必须为程式设计师提供另一个解决之道。您可以永久性的安插一个设计小组人员，坐在由3D Studio Max（译注：一套常见的3D动画制作软体）所砌成的山顶上，回答任何浮现出来的问题。不过这个方式不能保证每一分钱都花得有价值，所以另一个效果近似的好方式，就是把您的设计文件放在内部网路的一个网站上。
图4.3中告诉您这个网站可能的组成方式。在这个例子中，它的结构是以一个［内容概要］的小型文件为中心，并对应到另一份较大的文件［游戏内容规格］上，从这边可以对应到旁边另一份较大的文件［设计备忘录］，以及数个小型的单页文件，标示着［进行中］。
会按照设计文件中最大的标题，将文件切成好几个部分，可以在进行内容变更时供所有人参考。而它详细的程度如下：
＊7.3军事单位（物件类型）军事单位是由共享行为协定加以个性化。将非军事单位是由共享行为协定加以个性化。将非军事单位认定为军事。
＊7.3.1部队部队是人类的军事单位，继承人类的物件类型。
部队的类型如下：
＊7.3.1.1步兵
＊7.3.1.2弓箭手
＊7.3.1.3斥候
＊7.3.1.4骑兵
除此之外，每一行都可以加上注解，提供进一步的说明。举例来说，写在［骑兵］旁边的注解可能是：［在进入弓箭射程之后，一对一的情况下可以打败弓箭手；但是会被步兵打败。］
内容概要可以让浏览器指向完整游戏内容规格的相关部分，然后再指向设计备忘录。当然了超链结可以直接对应游戏内容规格的不同地方，让观看的人自由探索，从概念中得知游戏设计的内容。
如同图4.3所示，您也可以对应到目前正在进行的部分。所以，在不久之后，您就可以看到一个骑士的人物动画，出现在新的页面中，并加上一段人物在游戏中的功能详述、目前的装甲数值、移动速度以及攻击伤害值。另一个页面可能会显示出使用者介面的实体模型。
利用这种形式，可以鼓励程式设计师与美术小组来探索游戏的设计内容，并提出他认为该修改的地方和新功能，来参与游戏的设计工作。您只要小心一件事，他们的工作是让游戏尽善尽美，而不是负责网站的内容！
将设计套入研发
好了，现在您已经把游戏内容规格和设计备忘录，完整的呈现在内部网路的网站上面了。在这个阶段，我想应该至少要开一次会议，把您的点子表现出来并表达给整个小组。您得先完成概念性的图稿，讨论过的音乐和音效内容，并记得链结到您的网页中；让每一个参与游戏的人，可以了解游戏的外观和努力的目标。那现在该是每个人都拚命点头，然后开始程式的时候了，对吗？不尽然。
您现在所做的事情只是大笔一挥把概念写出来而已。回到我们之前的推论，您可以想象您目前完成的是一部电影的脚本草稿，连一部拍摄脚本都谈不上。它仍然缺少运镜、分镜、打光、以及设定的详细内容。这还不是一份计划书，它只是个目标。
目前的想法是，游戏最好在互动的过程之下建造。在某些螺旋型的最佳研发过程中，研发会变得十分模糊，而且危险性变得很高，因为在它的容许范围中，会出现一些您完全无法预期的东西。（详见下册）同样的，它会让您十分精细的控制研发过程，让您看出哪些才是可爱的［润饰］特色，并在游戏后期时间不足的状况下，先把它砍掉以免吃掉您的荷包。
螺旋型的研发中包括了软体工厂的模型，我们将在第11章说明。不过，这并不是唯一可以运用的模型（瀑布概念就是另一个）。我会解释在这二者之间，为什么要独厚这一个。
阶段与测试台
很多游戏性都是靠互动来展现，所以在真正进行实验之前，您不会知道这些规则实际运作起来是什么样子。在下一个阶段开始之前，每一个程序都已经完成，而且内容坚若盘石，本身已经构成象是瀑布般的模型。之所以叫这个名字，是因为每一个阶段都会以正确的顺序流入另一个阶段，很象飞落的瀑布。
更有用（而且在现今的游戏工业中十分盛行）的模型是进化原型或是测试台，而养护它将是最优先的事项??在将近数星期的前置作业以后，就可以做出一个能够运作的测试台游戏。早期的图象可能只是粗糙的点阵或是方块，但您可以和这个代表性的模型互动，然后将完成的图象置换上去，并骄傲的看着这个粗糙的东西一步步成形！
这个测试台模型的制作方式，可以让您单独一个人设计您的游戏。而一个具有创意的游戏设计师，当然可以利用这个模型完成一个好游戏，不过它也不是没有缺点。您的研发过程无法轻易的排成时程表，您只知道您［哪一天］要把游戏做完。另外，整个过程无法进行关键路径分析、没有事前工作可以同步进行、整组人马必须在进行修改时原地踏步。只有在您看到一个有顺序的工作在最佳化的情况下完成时，才会觉得恍然大悟，看出这种方式的缺点。看到经验的丰富小组在争吵哪一件事应该先做，我一点也不觉得奇怪；就算我在为这个计划出资，一样觉得司空见惯。
藉由连续性、分成数个时段的过程来研发游戏，是一个十争稳固的解决方式，这就是我称之为［阶段］的东西。在每一个阶段中，会加入游戏中的新元件，加以调整并测试。早期阶段中的现存元件，可以加以推敲或是扩张。阶段性模式的好处在于可让小组将目光集中在最靠近的期限中。每六个星期就可以完成一个新的阶段，而游戏就在您的眼前步步成长。
现在，一个纯粹的进化性模型出现，而它正急着想要进入编写程式码的过程，在结构上则与游戏元件相互连结。您可以把它搬开并调整它的人工智慧。但如果制作了六个月的时间后，您却看到结构上出现裂缝时，您能做些什么事？除非您的客户很能谅解，否则全面重建已经来不及了。
所以，我建议把编写程式码的时间向后拉一点。制作一个测试台，用各种角度来评估您刚刚完成的点子，使用现有的工具来组合测试台，并在它功成身退之后把它给丢掉。
要从事一个周期性的研发工作，首先您需要把游戏内容规格转成一组迷你规格。每一个迷你规格都处理一个阶段??就是单一周期的建造工作，让它以测试台的方式逐步完成，除非您的第一个测试台只是纯粹靠想象。您会对自己说，你可以先从只有线条的环境开始着手，然后取得第一称的视角，就可以利用研发人员的介面在这个空间中自由移动（X、Y和Z轴）。接下来，您可以开始加入墙壁和物件等会碰撞的东西，下一步就是一个物理运动系统，来控制游戏世界中的动态物件，接着您可以加入武器和敌人。找一个很容易在网路程式码中分割开来，可以让您进行一对一战斗测试的地方；您这时也应该注意到，网路程式码的骨架可以已经和第一阶段的不一样了。接下来您可以安排敌人的人工智慧，然后是游戏编辑器，最后是关卡本身。
每一个阶段的迷你规格，应该以下列的要点来说明：
＊目标 设计者对这个阶段中，希望看到的特色列表。
＊哲学 这个阶段要测试的是什么。
＊预期的结果 在测试和修正之后，这个阶段要达到什么成果。
＊变通方法 如果概念或是点子需要变更，最有可能的猜测。
假设您把一大捆的迷你规格交给您的软体规划师和首席结构师。他们第一件要说的是，就是您只专注在游戏性方面的主题，而其他需要建造的元件却还没写。这件事本身很好，所以现在工具和元件小组就可着手开始撰写东西。
除此之外，在您认知的阶段中，还需要加入其他的过程：在各个阶段中需要测试的不只是游戏性，还有技术方面的问题。这也是一件好事，它可以协助您向程式设计师洽寻，以解决这些初始阶段的文件，而不是单单告诉他们，您身为设计者觉得最好的建构方式。由于技术性阶段是需要相互结合的，您的目标会随着团队合作而不断的达成。
您可许认为建造一个游戏就和盖一座桥一样。阶段性文件的作用就是告诉您去哪边找寻支援。如果能在小组开始编写程式之前，就画出全部一连串的阶段会是很好的做法，因为您接下来就可以靠它来规划游戏的结构，如案例研究4.3。
案例研究4.3 规划迷你规格以符合结构所需
《Warbots》是一个即时战争游戏。设计师彼得（Peter）在早期阶段规划的概要中，设立的目标是机械人在地形上面四处移动，并相互作战。［基本上，我想要的是点选一个我方的机械人，叫它去攻击敌方的机械人，就可以把对方打成垃圾，］彼得解释着，［我们将在下一个阶段来处理近战时的规则，伤害以及其他相关的东西。］
［好，］首席设计师尼克（Nick）说，［我们已经有寻找路径的模组了，目前我们还没有战争迷雾??这是在后期阶段中的??但是我先假定你会让它派上用场。所以机械人会问自己，他是不是近到足以攻击对方，如果没有的话，他会问他是不是知道目标在哪边。如果是的话，他就会利用寻找路径的模组，并向目标移动。］
［这个好，］彼得同意，［另外，如果他不知道目标在那边，我想在他的头上打一个问号或其他东西并留在原地。现在我们先记下这一点??这个机器人在完成的游戏中也不会自动移动。］
其中一位关卡设计师查尔斯（Charles）插嘴：［如果机械人找不到他的目标，会不会有其他我们的未决定的行为？］
［原则上是如此。事实上，智商较弱的机械人可能会绕个圈圈一直跑，或是前往目标最后出现的地方；而较聪明的机械人会开始进行某种程度的搜索路线。是这样的吗？］彼得对人工智慧程式设计师维多利亚（Victoria）微笑着说。
［如果有足够的时间，他们就可以象你想要的那么聪明，］维多利亚说，［但我们先倒回一点点，让机械人自问他的目标是不是在可见范围中。机械人之间可以相互交谈吗？］
［你是指同一阵营，但是不同的机械人是否看得到目标？当然。玩者可以看到所有去除战争迷雾的区域，他当然希望他的机械人也有相同的视野。］
［好，］维多利亚说，［容我建议几个处理方式。我们可以让准备猎杀目标的机械人得到目标的座标，并把这个数值与所有友方部队看得到的范围做一次比对，这是第一种方式。另一种方法是玩者这边有人工智慧的协助，不断更新目前进入视野的敌方部队。然后你的机械人只要查对这个表格，就可以得知它的目标在哪。］
［我不觉得有什么不一样。］彼得说。
［在这个阶段是没有什么不同。但是在数个阶段之后，视野的问题会突然冒出来，所以我想我们应该现在把它定下来。］
尼克一直在看这个阶段的迷你规格，关于处理视野与战争迷雾的主题。［你是不是打算让战争迷雾用其它的方式突显出来？所以部队看不到的地方，会隐藏起来或是变灰？］彼得点头。［而且很明显的，在可见范围中的敌方部队会出现在玩者的画面上，而其他在战争迷雾中的敌人就不会。］尼克继续说下去，［所以，这表示我们将得建造一个可见范围的所有座标资料区块，而且另一个资料区域，可能是从上一个资料区块参照而来的，就是所有看得到的敌人部队。］
［记得把隐形部队拿掉。］查尔斯说。
在一个苦笑之中，尼克在战争迷雾的迷你规格中写下摘记。［如果有隐形的部队，也提醒我一件事：你一定会放一些感测用的部队。所以我们可能要有二个可见范围的资料区块，分别给感测部队与非感测部队使用。］
［我看不出这是做什么用的。］彼得提出抗议。
［这不会影响到你的阶段计划，］维多利亚向他保证，［但是设计的道路是架在结构上面的。我现在知道哪边会有一组可见范围的资料区块，而且我知道它们之间是如何运作的，所以现在我可以在人工智慧中放入一个程序，告诉机械人如何去找其他的机械人。在预设的条件中，如果这些区域中没有写下过滤后的资料，就代表机械人随时都知道他的目标在什么地方，所以现在使用的原型会让机械人在地图上面，彼此猎杀其他的敌人；不过，在我们写好可见范围的程式码之后，他们只会找到他们应该知道的敌人。］
到底为什么要使用文件？
在使用文件的过程中，很容易招人批评的一点是，为什么要在一份文件上面将整个游戏展现出来，并不断的强调事前的准备工作？游戏难道不能在测试台上面设计，并以这种形态表达给整个制作小组吗？
就算现在已经到了21世纪，但是要为写好的东西辩护，感觉还是很奇怪。当然了，已经写好的文件并不足以将设计师对游戏的全部概念表达无遗（因此，您才需要利用概念图稿、具启发性的音乐、参考文件、图表和其他任何东西，来帮助您传递概念），但是一份写好的游戏设计书却是不可或缺的，这就是原因。
在棋盘游戏以及玩者面对面的角色扮演游戏中，游戏的运作是完全透明的，您可以很清楚的看到您为什么会得到这样的结果。轻装步兵被逼下山丘？那您就不应该让它们在没有骑兵队的支援下行动。在北方的州郡中出现暴动？在下一个秋季时记得准备更多的房屋津贴。
您在电脑游戏中看不到这些，因为游戏的运作藏在画面背后，或者用更精确的方式来说，藏在电脑的基板上面。从玩者的角度来看，这个结果相当好（他可以在数小时中就打完滑铁卢战役，而不是一玩就耗掉数个星期），但如果您是运用测试台向您的制作小组解释您的游戏，看不到过程的好处就完全无用武之地。而这就是您为什么要运用各种可能的手法，让您的设计文件具有吸引力、受到欢迎、而且容易阅读，而在研发的过程中，您也必须持续的站在核心地位。
======================第四章完！！！====================
[em17] [em17] [em17] |
|
发表于 2004-3-8 15:21:00
