青龙，亦作“苍龙”，古代神话中的东方之神。龙是中华民族的图腾，自黄帝授命于天，威泽四方，龙就成为中华民族乃至整个中国的象征，而比较明确的定形是在汉代，从大汉朝开始，龙就被确定为皇帝的象征与代表。在东方传说中，青龙身似长蛇、麒麟首、鲤鱼尾、面有长须、犄角似鹿、有五爪、相貌威武，而在西方神话里，龙更像是长翅膀的蜥蜴。 　　 　　白虎，古代神话中的西方之神。形体似虎，白色，凶猛无比，因此成为尊贵的象征。同时白虎也象征着威武和军队，所以古代很多以白虎冠名的地方都与兵家之事有关，例如古代军队里的白虎旗和兵符上的白虎像 　　 　　朱雀，亦称“朱鸟”，形体似凤凰，古代神话中的南方之神。因其形似鸟状，位在南方，火属性，所以在游戏中经常以凤凰的形状出现。但其实朱雀和凤凰是两种不同的生物，凤凰是百鸟之王，而朱雀却是天之灵兽，比凤凰更稀有尊贵，破坏力也更强。在**的漫画和游戏里，朱雀都是作为强力召唤兽或者妖兽出现的，比如漫画《幽游白书》和根据漫画改编的同名游戏。 　　 　　玄武，也叫“真武”，俗称“真武大帝”，是道教所奉的神。相传古净乐国王的太子，生而神猛，越东海来游，遇天神授以宝剑，入湖北武当山修炼，经四十二年而功成，白日飞升，威镇北方，号玄武君。但宋朝忌讳玄字，因而改称真武。玄武又相传本身是北海一只大龟，此龟曾经被当作柱子支撑整个蓬莱仙山，因其灵性深觉，历经多年的听道闻道，终于修得正果。所以帝王陵寝多有驮碑之龟，正是以此暗寓玄武。另外玄武又叫玄冥，故又称北冥，听到这个名字估计不少读者又联想起北冥归海，还有金庸老先生笔下人物逍遥子的《北冥神功》。

测试方案属于软件工程的范畴，对于策划人员来讲是测试游戏的主力军。好象没听说过哪个策划将测试过程描绘的很愉快，因为测试本身是一个非常枯燥和痛苦的事情。一套合理的测试方案可以尽可能减少测试人员的工作量，也能够让测试出的问题能够尽快解决，这就需要测试方案的制订人员对游戏开发有全面的了解，并能够掌握好测试的进度，其中的难度可想而知了。

　　测试是游戏开发一个极为重要的组成部分，其所需要的时间一般要占去整个开发周期的1/3左右。测试贯穿于整个开发进程，小规模的模块测试是由程序人员自行完成的，对策划来讲，如何完成最终的产品测试才是真正需要关心的。按照软件工程的理论，测试方法主要有两种：黑盒测试与白盒测试。所谓黑盒测试就是把要测试的对象当作一个黑盒子，不需要知道里面是怎么处理的，只要对输入和输出数据进行测试就可以了；而白盒测试正好相反，测试者必须对测试对象的内部处理过程非常了解，对里面所有的分支和循环进行实验从而达到测试的目的。黑盒测试与白盒测试都是最基本的测试方法，属于低层的测试理论，实际的测试方案都是在这两种测试方法基础上产生出来的。

　　对于游戏的测试，也不外乎这两种测试方法。基于黑盒测试所产生的测试方案属于高端测试，主要是在操作层面上对游戏进行测试；基于白盒测试所产生的测试方案属于低端测试，是对各种设计细节方面的测试。黑盒测试中不需要知道里面是如何运行的，也不用知道内部算法如何设计，只要看游戏中战斗或者情节发展是否是按照要求来进行的就可以了。这种测试可以找一些对游戏不是很了解的玩家来进行，只要写清楚要干什么，最后达到什么样的效果，并记录下游戏过程中所出现的问题。而白盒测试就需要知道内部的运算方法，比如A打B一下，按照A和B现在的状态应该掉多少血之类都应当属于这种测试。白盒测试需要策划人员自己来完成，因为内部的算法只有开发人员自己才清楚，而且发现问题策划是最容易知道如何解决该问题的人。由于测试的工作量巨大，合理安排好测试和修正BUG的时间比例非常关键，否则很容易出现发现了问题却没有时间改正或者问题堆在一起无法解决的矛盾。测试设计应当在开发的设计阶段就要完成，如果开发初期没有给安排出合理的时间，那么最后的结果肯定是不停的跳票！

　　在测试方案中，设计人员要根据需要把黑盒测试、白盒测试有效的结合在一起，并且按照步骤划分好测试的时间段。根据游戏开发过程，测试大致可以分成单元测试、模块测试、总体测试和产品测试几个部分。单元测试一般集中在细节部分，主要是在游戏引擎开发阶段对引擎的构造能力和完善性进行检测。该部分的工作要求细致严禁，因为任何一点小的纰漏都可能导致后期大量的BUG产生。这时要求程序开发人员与策划达到无隔阂的交流，策划人员要清楚该引擎任何一个功能单元的使用方法和效果，这样才能够保证测试中能即使发现问题并指出问题的所在。模块测试是在游戏开发进程中按照阶段进行的，每当一个模型产生后就需要对该部分进行一次集中测试，从而保证系统的坚固和完善。模块之间的接口测试也属于该部分的工作，就是说各个游戏模块之间如何实现过度，数据如何进行交换都要进行严格的测试。往往在模块内部测试时一切正常，把模块拼装在一起后反而问题百出，这就需要在阶段性模块测试中及时解决！总体测试属于比较高层的测试，在游戏的DEMO基本完成后，要从宏观上把整个游戏合成在一起，这时就要求有全面控制进度的能力。最终的产品测试是游戏质量保证的最后一道关卡，要求大量的非开发人员介入进行地毯式轰炸！产品测试往往也会伴随一些市场活动，这就不是我们现在要讨论的范畴了。

　　我们已经知道了测试过程分成几个阶段，下面就一起来看看具体要包括那些内容：

1、 测试的时间分配：测试时间如何分配会直接影响到开发的进度，它包含测试时间、测试结果汇总时间以及修改错误的时间等几个部分。一般来说，开发人员只认为测试时间才是需要分配的，其实合理的安排测试总结和修改BUG等工作占用的时间才是更多的！如果不进行测试情况汇总，项目管理者就无法弄清到底是哪些部分出了问题；不马上对发现的问题进行修改就会导致更多的问题发生。所以定期测试、发现问题、解决问题才是最合理的，把整个开发周期划分为几个阶段定期测试是对产品质量的根本保证！科学安排测试的时间能够用最少的代价解决最多的问题，否则把测试都堆积在最后结果只会是一团糟！

2、 测试人员的安排：测试人员的选择和调配对游戏质量来讲是非常关键的。测试人员尽量不要选择游戏的开发人员，只有对游戏没有任何了解的人才能真正的发现程序或设计中的问题，虽然他可能对程序和游戏设计一点都不懂。如果能有一支专门的测试队伍当然是最好的，在经费和人员实在紧张的情况下把其他非开发部门的人借调一下不失为一个好办法。

3、 测试内容清单：这部分要求测试方案设计人员精心的考虑计算，尽量把测试内容精确到操作级。意思就是说最好细化到某测试人员点击鼠标几百次这种程度，因为测试人员是对你的游戏内容一点都不了解的，只有你把任务全都明确后才可以收到预期的效果。只规定某人去玩这个游戏然后给予反馈是不负责任的做法，这种测试方案只能当作垃圾给丢到废纸桶里面去！要对每个测试人员的工作明确下去，用测试表格的形式进行填写测试报告并签字写清楚测试时间，才算是合格的测试方案。

4、 测试结果汇报：最终测试报告汇总上来，策划人员要对全部方案进行评估并进行分类，把测试中发现的问题确定解决优先级然后反馈给相关部门。问题特别严重的要敢于要求返工，任何一点小问题也不能放过，严格的测试才能带来高质量的游戏产品，这个法则适用于任何产业，游戏也不例外！

5、 调整开发进度：由于测试发现的问题所带来的进度影响要及时反馈给上级领导，然后马上更新项目进度表，并注明更改原因。因为开发进度的调整关系到很多部门的工作，所以最好在早期设计进度时就把测试时间预算进去，但实际上大多数情况下开发进度的变化是非常频繁的。如何休整进度还不影响到游戏完成的最终时间，对于任何项目管理人员来说都是一个挑战！

　　测试方案一旦确立，剩下的就是烦琐和枯燥的机械工作了。测试是最痛苦的，但没有测试游戏是不可能成为产品，这也是国内大多数赶工期的游戏BUG百出的问题所在。科学的制订测试方案并协调好各部门之间的进度，对任何一个项目来说都是至关重要的事情，对于刚入门的策划来讲，学会写测试方案是必修的课程之一。

　　测试工作的全面完工，标志着项目开发的结束。但对于策划来说，你的工作还没有完，接下来你就要开始教给玩家如何玩这个游戏，让我们来看看如何完成游戏手册吧！

对于游戏的熟悉程度，估计没有哪个开发人员会比游戏策划更清楚了。大到游戏框架，小到界面热键，一点一滴都需要策划人员进行详细的描述和设计，也只有策划才能对游戏的实现情况进行全面的把握。所以一旦策划和其他开发人员发生沟通上的障碍，整个项目的进展就会受到极大的影响；如果策划能够协调好各部分的工作，那么项目进展就只需要看个人能力了。而在现实开发中，策划人员由于自身的个性或者其他条件所限，往往在沟通这个环节上出现一些致命问题导致进度的延误。如何把握好自己的情绪，从大局观出发是成为一个成熟策划人员的关键所在。

　　文档不管写的多详细，对其他人来讲仍然会存在理解上的错误或漏洞。策划经常把注意力都放在了如何把游戏设计的更完善上，而忽视了别人的理解能力和感受。因为对任何一件作品来讲，每个人的看法都是不同的，策划应该知道如何去听别人的意见并吸收到自己的设计中来。这并不是说坚持自己的立场是错误的，而是在大多数情况下策划本身容易把自己的设计当作一个孤立的个体，对其他外来的思想用全部抛弃的态度来对待，这是极其危险的。就算是别人的意见是多么的滑稽可笑，你也应该认真的听完并加以分析，任何渠道的意见对你的设计来说都是有益的。

　　在前面讲过如何书写流程图和安排工作进度，在这些设计过程中和其他部门的沟通都是非常重要的。我不提倡大规模的定期会议，因为这样会影响其他人员的开发进度，而且会导致很多问题的扩大化。公众场合下不适宜对个人问题进行讨论，大量的沟通和谈话应该以私人或者小型会议的形式来进行。大部分开发人员不喜欢开会，尤其是这种针对性不是很强的例行会议。所以如果确定要召开会议，那么就一定要先确定这个会议要解决哪些问题，需要哪些人来参加，最后要达到什么样的效果。纯粹为了开会而开会，尤其是一些例行会议是没有必要的，这样只会增加别人对你的厌恶情绪，导致关系间的不协调。如何尽可能减少大规模会议，通过单独会谈来解决问题是沟通的一个有效手段。

　　如果你想知道其他人员对你的策划方案是否有意见，单纯的把文档发送给程序或美术不是一个好办法。无论你的文档多详细，别人都很难完整的理解你的意思，利用好黑板和纸笔通过讲课的方式进行沟通，可以一次性让大量的相关人员了解你的设计。在讲解完毕后让大家以发表见解的方式来发现并解决问题才是有效的解决手段，你所要做的只是把你的想法表述给大家，而不是争吵。在你的讲解过程中要以听为主，对于一些核心内容进行强调，认真做好笔记，在会议后对别人的意见进行总结，让别人知道他的看法你是很重视的。只有对别人尊重别人才会尊重你，想处理好与他人的关系首先就是让别人感觉到你对他的意见是重视的。

　　在完成了第一次讲解后，就不要再召集这种大规模的会议了。剩下的工作你就应当找对应的工作人员进行单独会面，只和他谈有关他这个方面的设计问题。对程序就是描述游戏流程以及一些需要确认的技术实现问题，而和美术则应该谈界面实现以及整体效果等问题。

　　给程序员交流要求你能跟的上他的逻辑思路，就是说你要对计算机的编程有个大概的了解。起码你应该知道程序流程是通过条件分支、循环以及函数等组成的，而且要对面向对象的C 语言有一些了解，否则他会认为你的思路太混乱而产生很多理解上的概念混淆。最好你是拿着一个游戏设计流程图来和他交流，这张图应该类似于程序设计的流程图，由几种基本的图形和线条来实现。这样一边描述你的思路一边给他指出需要完成的模块，发现问题进行记录并修正你的文档就能够让双方都保持清醒的头脑，而不是产生做出来产品后和你所想象的完全是两个东西。这时经验就会起到非常关键的作用，如果策划本身就是程序员或者做过程序员就完全不用考虑这个问题了，可如果你对程序一窍不通或者根本就不知道那些东西是怎么实现的，那你最好去找本介绍编程基础的书看一下。多和主程交流应该是最省事的办法，只要交代给他哪些工作需要在多长时间完成就可以了，但很多情况下是主程和策划一样固执，这时他会不经过考虑就告诉你很多想法都是不能实现的。你要拿出详细的解决方案才可以说服他，或者让他提出一种合适的解决方案。总之，用程序的思路来和程序员进行交流是最好的解决办法，给程序员一份详细的流程图要比给他一份几百几千页的文字说明要管用！

　　给美术人员交流更困难。因为每个人的美术风格都不相同，要求几十个美术人员画同样一副图你所获得的结果肯定千奇百怪！通过主美进行协调是一个好办法，这样可以减少你很多口舌的。在你写策划方案时，不要对美术做太多的要求，而应该先和主美术确定好游戏的整体美术风格。美术方面具体的人员安排和工作量限定等事情都交给主美术或者美术总监去处理，除非说你对美术非常精通能够把握住整体风格，否则你的工作只是描述你需要什么样的东西就可以了。当美术完成样品后，一起和主美术进行审查，风格一旦确定就不要再修改了，否则这对美术人员来说完全是种摧残！美术人员工作量往往是最大的，美术风格的改变可能会造成大部分工作的重做，从而严重影响工程进度。把交流的事情交给美术方面的负责人，这是最好的同美术人员的交流方法。

　　保持好自己的心态，用积极的态度来解决问题，不要抱怨多听别人的想法是一个策划人员需要掌握的基本方法。只有沟通顺畅才能够让项目按计划进行，扩大自己的知识面，多和主程与主美交流，少开大规模会议，用私人交谈的方式来解决问题。把握好上述几点，项目的完成就只是时间上的问题了。