小论游戏开发的几个主要阶段.txt

小论游戏开发的几个主要阶段

在得到了一份详细的需求分析文档后，下面要完成的就是各方面的具体工作计划。主策划开始分配具体的脚本编写工作，当然主要的游戏脚本还是要主策划自己来写，或者这时脚本已经全部完成了。程序员开始技术攻关，如果有现成的游戏引擎最好，没有的话就开始有针对性的开发引擎。美术人员可以进入素材搜集阶段，也可以在策划的协助下开始进行建筑或人物形象设计。
这时的工作是最繁杂的，也是矛盾最容易激化的时候。如果在可行性分析阶段和需求分析阶段没有把思路理清，或者管理人员没有把任务分清，在计划的制定过程中就会全面爆发出来。因为项目开发中一旦涉及到细节问题就会暴露出很多在初期阶段设计上的不足，为了尽可能减少管理和设计上的难度，加强总体设计时的文档管理是一个较好的解决办法。游戏脚本在保持大思路不变的情况下，对单个体系进行局部修整是保持文档完整的必要条件，而且每一次对文档的修改都要开项目小组会议进行讨论，并对讨论结果进行意见整理获得新的文档版本。否则随着文档的不断增多，很多相关人员不知道游戏到底什么地方做出了修改，最终结构就是产品最后驴头不对马嘴，各个模块根本无法结合在一起。文档的修改会贯穿游戏开发的始终，甚至在游戏开发的后期这种事情还可能发生。认为一开始就能得到最终版本，今后再也不会对脚本进行修改的想法是极其幼稚的。这种问题只有靠大量的经验和开发人员之间的默契来弥补，在保持文档完整性的基础上尽可能避免关键性模块的修改。项目组内的核心成员应该经常碰头，直到拿出最终的游戏总体设计报告。
总体设计报告应当包括以下几个主要部分：
1、 游戏的详细脚本，包括所有体系的详细设计；
2、 程序开发的进度计划；
3、 美术工作的详细分工，以及工作量审核标准；
4、 阶段性验收规划
在上述报告都已经完成后，项目设计与规划就告一段落，下面就进入具体的实施阶段。
第四阶段 代码编写与图形绘制阶段
进入到该阶段，主要的工作量都集中在程序和美工部分。该阶段和具体游戏关联太多，而且会涉及到很多技术问题，难以一下阐述清楚。从程序员角度来讲，现在才真正进入到了实战阶段；而对美术来说，工作才刚刚开始。
如果有了一整套合适的开发工具，会大大加快游戏的开发速度，这一点没有任何人会怀疑。我们平时所说的游戏开发引擎，实际上就是这样一套可以大大加快游戏开发速度的工具。不同类型的游戏所需要的引擎都不相同，而游戏引擎的获得方式也有很多种。可以是公司自行开发，也可以直接去购买商业引擎，但是否适合该产品就要看开发人员自己的功底了。一般来讲，地图编辑器和任务编辑器等工具是开发RPG类游戏所必须的，凡是研究过星际争霸地图编辑器的人就可以明白一个好的工具可以给开发人员带来多大的方便！
对于美术人员来讲也是如此。有了好的开发工具，可以大大减少美术人员的工作量。还是以星际争霸的地图编辑器为例，美术人员只要制作好一部分地图元素和建筑物样本，然后根据需要命名放在规定目录中，就可以在地图编辑器中直接绘制新地图了。开发引擎的好坏对开发进度影响很大，所以多花些时间制作一些对游戏制作有帮助的工具是最好节省开发周期的办法。但是这对开发人员要求很高，不仅需要极强的编程能力，还要对游戏开发有很深入的研究，开发经验在这时会起到关键性作用。一个熟练的游戏开发程序员和美工做东西要比一个新手快好几倍，所以只有人本身才能决定着开发产品的速度和质量。那些不重视开发人员自身素质的观点都是错误的，这也是国产游戏开发周期长但质量不理想的主要原因。
该阶段几乎占据了整个开发时间的2/3，漫长的重复性工作很容易把人的意志消磨光。为了避免长时间工作所带来的战斗力减弱，必须在总体设计阶段制定好阶段性验收规划。这样可以定期检查工程进度是否正常，并给予开发人员里程碑式的成就感。在微软的项目开发中就非常重视这一点，但实际工作中人们往往忽视了成就感的重要性。抱怨和问题导致矛盾不断累积，最终的结果就是无限期的跳票，这也和项目管理者的组织协调有关。
美术人员在开发过程中任务是最艰巨的，大量的绘图和建模工作导致程序与美术进度难以做到同步。主程序员应当及时和美术、策划沟通，定期进行工作总结达到思想上的统一。如果有项目经理，那么整体的规划工作就由他来完成，根据已经制订好的工作计划进行监督和调整。策划人员发现脚本问题或者游戏逻辑上的错误应及时汇报，主策划提出修改意见在工作会议上讨论修正，最后对文档进行更新。这些都是理想化的情况，在实际操作中远不止这些工作要做，就要看项目组成员修为如何了。
开发期间，还需要定期向部门负责人汇报工程进度。这份工作汇报既要把已完成的工作情况及进度进行总结，还要对项目进行展望。如果有产品经理，则对工作汇报进行汇总，和其他部门进行协调规划。就开发而言，定期的工作总结就是对上级的唯一接口。另外，阶段性演示也会对巩固上级的信任度有很大帮助，同时也可以给开发人员自己加油。
总之，编写代码和美术设计阶段是整个游戏开发中历时最长、耗费人力物力最大的阶段，该阶段各部分的关系协调由项目经理或小组长来进行，如果在需求分析和总体设计阶段进行了周密的安排，该阶段的进行就只是一个时间的问题。但实际情况却是由于项目匆忙立项，还没有得到充分的准备就开始了编码美术工作，再加上开发人员自身条件的限制，往往产品的开发过程成了一场噩梦。国内游戏不近人意主要问题也出在这个方面。

第五阶段 内部测试与后期合成
在程序和美术工作基本完成后，就进入了后期合成与测试阶段。这时游戏的各个部分都基本上通过了编程调试，整个游戏世界可以在局部模块内跑起来了。这时工作的重心又转移到了策划身上，如何把各个体系连接在一起，将游戏的整体效果发挥出来，达到预期的设计目的是该阶段的主要任务。
这里还是要强调开发人员自身素质的问题。一个有经验的程序员能够很快根据策划的要求更正游戏中的问题，因为在写代码的过程中他就应该注意到了有关方面的联结，所以改起来知道从什么地方下手。对美术人员来说，好的美工可以达到的境界根本不是一般新手所能够在短期内能够领悟的，尤其在开发后期这个现象就更加明显。所以进入该阶段后，主程、主美术和主策划之间的配合再次成为核心。测试期间会出现很多模块接口上的问题，而且游戏逻辑进入调整期，策划文档和程序都要做好大动干戈的准备。因为设计初期策划不可能看到游戏的效果，在这时就可以知道那些地方不合理，并开始进行调整。
这时音乐和音效制作应该开始进行了。由于音效制作比较特殊，而且和游戏本身结合非常紧密，如果需要游戏配音的话就更复杂。包括游戏的片头动画、过关动画以及各种情节动画都要加入到游戏过程中进行调试，策划人员对效果进行最后的审定，如果有问题可能会返工或者另外设计。
内部测试也是需要很长时间来进行的，而且在该阶段发生的问题往往是致命的。因为整个开发时间已经快到期了，一旦出现大的错误或者开始没有发现的结构性逻辑问题，就只有进行大规模调整，从而延误工期。实际上几乎没有一个游戏是按照进度完工的，诸如那些知名的游戏公司也是如此。而国内的游戏大部分都为了赶时间上市而放弃了对产品本身的高要求，加上低劣的内部管理，势必会造成时间花了不少，结果不是很好的现有局面。这时就能够体现出早期设计时需求分析和总体设计的重要性了，因为如果在那时就通过一些测试模型发现了这些策划上的问题，无论从时间上还是经济上都会把损失减少到最低，或者在可行性分析时就把这些问题给解决了。
测试和合成阶段耗时很长，大约可以占到整个开发周期的1/4时间，如果发生重大问题该阶段的时间还会更长。而且不同的游戏类型测试期也不相同，测试的重点也不相同。这时应当有专职的测试人员集中一段时间，根据开发人员给出的测试方案有针对性的疯狂玩游戏，并按照一定格式给予测试反馈，就是测试报告。在这里仍然要强调游戏版本的文档管理，如果要做一个大项目，完成一次测试、修改、再测试的过程就要对文档进行一次更新，尤其是游戏脚本的文档，否则最后策划本身都弄不清某个关卡是如何设计的就糟糕透了。
在经过了项目组内部的测试和后期合成处理，游戏就基本上成型了。这时的游戏是不是策划人员当初想象的那样，就要看是否完全按照即定的游戏设计文档来进行。一般情况下很多东西没有能够实现或者实现出的效果和当初设想的不同，这是很正常的。但最后整体效果如何，游戏是否好玩，体系是否均衡，界面是否友好，这些东西都是应当在设计初期就要预计到的，否则这个主策划就太不称职了。接下来，就进入和用户接触的阶段：游戏的BETA版测试。
第六阶段 BETA版测试
进入到该阶段，游戏就应该没有什么大问题了。丑媳妇就要见公婆，是好是坏就要看玩家的评价。这时市场方面就要开始宣传工作，并开始进行测试版游戏的发放，然后取得玩家的反馈信息对细节问题进行修改。正常情况下，美术人员应当完成了全部广告宣传品的设计，程序人员也忙着做游戏的DEMO，策划继续检测游戏逻辑，对游戏中的数值进行微调。经过了一段时间用户意见的反馈之后，进行一次最终的内容修改，就可以出成品了。
理论上讲，这个阶段开发人员应当是最清闲的。但实际上正好相反，由于国内开发商把内部测试和BETA测试混在一起进行，导致进入该阶段时仍然是BUG漫天飞，放在测试光盘中的程序往往是未经过完整测试的版本。因工期紧迫而草草结束的项目势必会造成测试期工作大量积压，原本应当进行充分测试的时间被程序的调试所吞噬了。
这里就不再评价那些游戏的制作问题，只集中讨论一下如何能够较好的完成游戏的测试过程。这里将整个测试过程结合在一起来描述，既涉及到了内部测试，还有用户测试的部分。测试前期完成测试方案是一种有效的管理手段，如何测试、怎样测试、怎么把测试结果反馈给程序人员都是非常重要的环节，缺一不可。一般情况下测试报告由程序人员和策划共同制订，然后交给测试人员执行。测试报告包括几个主要部分：分类模块测试、模块接口测试以及综合测试等。根据不同的设计测试方法也不同，大部分情况下是在通过了内部程序的逻辑测试后，由非开发人员狂玩游戏，反复进行各种可能发生的操作来检测BUG。这里需要强调的一点就是一定要找非开发人员来进行测试，在寻找BUG的同时还可以收集足够的玩家反馈，知道哪些地方存在不足。虽然这时已经不可能进行大的修改，但对未来可能发生的问题进行预测并想好解决办法是一种积极的态度。对于发现的小BUG，一定要及时处理，否则堆积起来无论是对策划人员还是对程序开发本身都是一种危险。万一发现设计中的漏洞，或者是短时间内无法修正的大BUG，就需要另外寻找解决的办法了。一种方法是马上召集开发小组找出解决办法，然后确定最后的完成日期，而这种结果一般会带来产品的“跳票”，对市场推广会带来很大的影响；另外一种方法是不管BUG，按期推出，等待问题解决后再出PATCH来弥补。但国内大部分公司都采用另一种方法，按期推出游戏，可是并没有对游戏中的问题进行修正。这样就造成了玩家的意见得不到反馈，一个游戏做完就拉倒的局面。
测试是一个很漫长的过程，也是最痛苦的一个阶段。不存在没有BUG的程序，也没有不出问题的测试。在测试中发现问题，最害怕的就是相互埋怨，程序怪策划没有设计好，策划怪美术水平不到，美术怪时间太少……诸如此类的问题太多了，而且这会导致内部出现情绪上的激化，尤其在最后的关键阶段。这时由于长时间的艰苦努力，开发人员的精神已经非常疲劳了，如果给一个火，谁都可能立刻爆炸的。为了保持好良好的开发心态，项目经理要起到协调作用，快速解决开发人员的心理问题，并制订好测试计划。另外可能出现的一个心理问题是开发人员只想快速了解，所以自己对产品质量放宽。这种思想也是普遍存在的，因为他们已经达到了崩溃的边缘，如果快点结束测试，既能早拿奖金又可以去休假，和开发相比谁都愿意选择前者。这时就要管理者给大家调整心态，适当的情况下给点甜头也是可以的，实在不行就拿制度来限制一下。否则产品质量从开发人员自身就无法重视的话，就更不用说用户最终拿到的产品如何了。上面说的两种心态贯穿了整个开发过程，并不只是在开发结束的时候才会出现，只不过这时矛盾全部集中起来，表现的更明显罢了。
在完成了BETA版的测试，这时就可以进行最终的上市前准备，压盘、做招贴画、开经销商大会，开卖！