|
|
楼主 |
发表于 2004-3-8 17:09:00
|
显示全部楼层
Re: 电脑游戏结构与设计——第十一章
抓虫
大家都知道一件事：如果能在研发周期中早点把臭虫抓出来（而且这种事可能会发生在企划的任一个阶段），就会省掉更多的时间与金钱。一个在结构阶段抓出来的臭虫，如果放着它不管等到游戏即将发行才去处理，可能要花费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++研发经验打下了基础；°这种状况下的研发速度与效能都十分出众。在可能的情况下，在各种规模的小组上建造出软体工厂结构，得到的结果也会让人满意；就算它会让部份的研发人员，在不习惯的情况下产生反抗心理，而且管理部份也必须等到较为后期才能看到游戏结果，臭虫的修正也有可能拖到游戏发行之后。
最后的讯息
在本章提供的方法并不是宇宙中的万灵丹，软体研发方面也没有捷径。如果您在研发小组之中找到了基础性的问题，象是技能不足或是经验太浅，那不管是什么方法都帮不了您，直到您把问题的根源解决掉为止。
另外，您没有必要把这个方法当做戒律。去试试看。看看什么方式有效，哪些无用。把有用的部份留下来，无用的碎块丢掉。靠着决断??以及大量的努力??就可以看到这个方法的结果。
很多其他的方法与技术一样适合于游戏设计，大部份（包括这一个）都是靠着传统程式设计上的努力而发迹。这是一个已经证实可以生产出高品质软体、可以不断的制作续集的系统，每一阶段的产品周期，就可以一点又一点的朝游戏发行迈进。
游戏研发者的特别之处，在于他们会把任何放在他们工作路线上面的限制，以最快的速度打掉。当然了，如果所有的企划都可以拥有水准以上的表现，并在规定的时间完成，这些措施根本就是不需要的。
在各种理由之下，真实世界并非如此，所以在这边传达的讯息应该是［没试过之前给我乖一点！］不管怎么说，结果可能会让您很高兴。
===================第十一章完！=========================
[em17] [em17] [em17] |
|
发表于 2004-3-8 17:06:00
