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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　作为项目管理的重要组成部分，工作进度表的设计是一种必要的项目监控手段。科学系统的进度安排可以达到提高开发积极性，监督工程按时完成的作用。但由于管理上的种种问题，项目负责人根本就没有经过周密的思考和规划就开始制订工作进度，甚至很多东西都是拍脑门就定了的。这样的任务进度设计是不负责任的，其结果只有不断的延期，相互推卸责任导致游戏跳票。那么如何能够保持一种良好的工作进度，并不断给予开发人员信心呢？

　　我对微软的里程碑式进度非常赞同，虽然我们还没有实力完全按照这种模式来进行项目开发。里程碑式的项目规划有以下几个好处：

1、 按照阶段对项目进度划分，可以清楚的看到游戏的真实进展情况。在进行阶段划分时，一定要能够让开发人员能够获得成就感。这是什么意思呢？就是说在设计初期，不能把项目阶段规划的太长，也不能让开发人员感到很轻易就完成了。这就需要项目管理人员对开发者的能力有清楚的把握，合理的对工作时间进行预测来达到阶段性成果。

2、 阶段划分要能够有可以演示的东西。对上层管理人员来讲，你给他说你做了多少文档，程序写了多少代码，美术画了多少图是没有用处的。必须用可以进行集中演示的样品拿出来，领导才会感兴趣。所以在写项目进度时，要有目的的定期拿出DEMO或者阶段性成果，能够把工作中的一些精华部分展示给大家看。不仅仅是领导需要成果的鼓励，这些DEMO对开发人员自身来讲也是一针有效的兴奋剂。

3、 将进度按照人和时间进行统筹。因为一个人在一定时间段内是无法做很多件事情的，把人的任务进行合理规划，在同一时间段内不要做超过2件的事情才可以保证项目的顺利进展。人的精力是有限的，再加班加点也是有个承受能力的极限的。合理的保证开发者能够把精力集中在一件事情上是最有效的开发手段。

4、 根据事件的前提和结果进行任务分配。一个任务要确定完成了才可以进入下一阶段，不能因为工期紧张而把必要的前提给丢掉。很多项目在没有完成前期准备的情况下就开始下一阶段工作，从而造成后期管理上的混乱，使得项目无法控制。一定要在必要条件完成后再开始后续工作，这一点一定要在项目进度规划上进行明确，即某项工作的开始时间一定要在前提工作完成后才可以进行。

5、 工作的延迟问题。再完善的工作进度表也会被一些意外情况所打断，比如生病和其他客观因素。这种情况下要对工作进度表进行修正，一般处理是将后续工作顺延，或者把休息时间计算进来当作加班。对于国内把加班当白饭的游戏公司来说，加班更是不需要给理由的最佳选择。其实良好的工作进度是会留出一些时间避免意外的发生，而且这些时间分散在各个阶段当中。不加班的项目才是最理想的开发！

　　那么，用什么工具来绘制进度表呢？

　　推荐使用微软的PROJECT2000，这是一套专门用来绘制进度表的工具软件。我们不用全面掌握该工具的使用，只要会一些最基本的功能就可以了。使用该工具，可以自动生成各种进度图表，并可以随时调整任务分配情况，非常方便直观。不是我帮微软吹牛，利用他的系列工具真的能够快速应用到工作中去，而且还很容易上手，PROJECT和VISIO就是两个非常典型的例子。

　　工作进度表在设计完成后也是需要多方一同讨论确定的。进度表可以由策划或项目经理来定月进度，直接确定程序方面和美术方面的工作任务。然后具体到任务模块内部则由主程和主美来具体设计，最后确定到周进度。每个参与开发人员都应当有一份自己的任务进度列表，如果没有问题就签字实施。在开发过程中，每达到开发阶段的终点就应该开一个演示会议，让领导和全部开发人员一起来看一下这段时间的开发成果。这就是所谓的里程碑式开发模式。每个开发人员都可以切实感受到自己艰苦工作所得到的成果，这样才可以保证他们一直感受到一种积极的工作态度，漫长的开发工作对每个人的意志所带来的折磨是很可怕的！对于一个刚开始学习做策划的人来讲，很难想象连续几个月集中开发所带来的压力。当你真正进入到开发中时，就知道建立起一个良好的进度计划是多么的重要了！

　　按照上述几个原则规划好你的开发进度，接下来应该做的就是正式的开发了！

　　游戏策划文档基本上由下面几个部分组成：游戏界面设计书、游戏任务详细设计、游戏AI算法设计、战斗系统设计书、游戏脚本设计书、游戏地图一览表以及游戏操作手册。这些文档相互渗透成为一个整体，根据游戏的不同有所变化。在第四部分中，我们已经介绍了如何建立起游戏的框架，现在就要根据游戏流程来进一步的细化。

1、 游戏界面设计书：游戏对于玩家来说，第一印象就是界面所给予的。界面设计包括的范围很广，片头片尾以及过场动画也可以算界面设计的一部分。这里要对游戏的安装、注册、进入游戏等主界面进行详细的规划，另外游戏中所有可能出现的场景以及操作界面都要考虑到。界面设计和操作体系设计是一体的，在界面设计中要对全部的鼠标、键盘等输入设备的操作进行详细的功能描述，最后用表格或者其他方式表述出来。一般的界面设计是按照层次来划分的，比如主界面、一级界面、二级界面等，这样设计比较系统，也容易让使用者快速掌握。每个下级界面都要有返回菜单或按钮，主界面要有退出和帮助菜单或按钮。这都是一些基本要求，具体情况视游戏类型而定。RPG类游戏界面比较固定，现有的几种常见界面就囊括了大部分RPG游戏的情况。一些主流游戏设计也都是参照现有的游戏界面设计来做，除非自己想弄一些新颖的界面来吸引玩家，但也要考虑到新界面的风险。毕竟现有的成熟界面已经有了大量的用户群，也不存在太多的操作上的缺陷，在现有界面体系上进行改良是一种比较稳妥的界面设计办法。

2、 游戏任务详细设计书和脚本设计：这两部分是一个整体，但往往由不同的人员来负责。任务设计是由主策划来完成，游戏脚本是由专门的脚本策划或执行策划来处理，最后由主策划来统一整合。任务设计可以用流程图的方法来设计，先划分好阶段和模块，先构成整体任务框架然后再进入到任务里面来具体设计，这些设计工作大部分是由执行策划来完成的。任务设计牵扯的方面很多，如何让各个分支既独立又相互联系，既有趣味又让用户能够接受，算法设计是否平衡，升级体系是否完善等许多问题都要考虑到。无论是PRG游戏、AVG游戏还是SLG，都需要有完整的任务体系作为支撑，根据游戏背景故事设计出符合游戏规则的各种任务是对策划个人创造力和想象力的考验。游戏的脚本是对任务的具体描述，什么人物做什么事情说什么话就是对脚本的一个概要描述。冗长的烦琐台词是谁都不愿意见到的，但是紧张的设计周期让脚本策划着实没有办法。多分支和多线索的流程，决定了任务体系和脚本设计的工作量成倍增长，调整好作息时间与工作状态是激发灵感的好办法，一味的加班是很难有好的创意的。

3、 游戏AI及算法设计：每个任务如何执行，怎样让玩家根据你的设计思路来完成任务，并感觉到趣味是整个游戏设计的关键。这就要求策划人员对人工智能和游戏的玩法进行深入的研究和演算。很多高效的AI系统并不是很复杂，一些简单的分支与循环就可以完成很多智能化的处理。但玩家的要求是极高的，在设计之初就要对一些可能发生的非程序BUG进行预防，比如寻路算法中的死角以及NPC的运动轨迹等。升级算法和各个属性的关联是要反复演算的，专门设计一些小的平台来演算数值的相互关系是最方便有效的方法之一，利用程序自动进行数值测试能够快速检验出算法上的漏洞。任务中NPC的属性设置是否合理也属于游戏AI的范畴，这也需要反复的调试和演算才能够最终确定。

4、 战斗系统设计：把这部分单拉出来的目的就是要强调战斗系统设计的重要性。对于大部分游戏来说，战斗是消耗时间的有力武器，如果没有一套完善的战斗体系玩家是没有精力耗在里面慢慢升级的。让玩家能够感受到升级后战斗力的增强，以及获得新装备后添加的新能力是对玩家最好的奖励！另外，战斗过程中的一些具体算法也要极为重视，一些很小的漏洞就有可能成为游戏致命的BUG。攻击和防御的计算，绝招的使用次数以及装备物品栏的容量都是需要认真考虑的细节问题。幸好现有的游戏已经提供了很多的现成例子，研究一下暗黑、星际和仙剑就基本上知道如何设计你的游戏算法了。

5、 地图一览表：游戏地图可以按照总地图和任务地图来划分。由于游戏类型不同，游戏地图的设计区别也很大，但无论是2D还是3D，是俯视还是斜视，地图都要按照透视比例来进行设计，并确定好坐标。全部的地图都应该是一致的，就是说同一个地点，在两副不同的地图系统中其相对坐标都应该一样。地图编辑器在这里会起到重要的作用，作为游戏引擎的一个重要组成部分，地图编辑器可以大大加快游戏的开发速度。对于地图编辑器的制作与使用这里不做介绍，你可以研究一下星际争霸和魔法门之英雄无敌的地图编辑器，会给你很多启发的。

　　上面几个大部分只是一个大纲，而具体的工作还要根据实际情况进行协调安排。对于策划来说，完成这些文档的设计工作至少需要1、2个月的时间。当你看到自己长达几百页的策划文档时，千万不要激动，因为还有更艰巨的任务等着你要完成呢！

上面几项原则是我在绘制流程图的过程中总结出来的，并不是说一定要遵守这些规则，只是如果这样做了会让你的图更清晰明了。但也有很多特殊情况是要灵活掌握的，比如一些特殊含义的线段以及特殊的处理框都是经常会遇到的。值得一提的是，由于这个流程图并不是最终的程序流程图，并不需要非常详细。这里也不给出具体流程图的例子，对这方面有兴趣的朋友可以学习一下VISIO的使用，对你的策划过程会大有帮助的！
如果细心一点，你就会发现上面的流程图和程序设计非常相象：模块化的分类，分支和循环以及各种过程应用。因为在这个阶段，主策划的主要工作就是如何把自己的思路告诉给主程序，让主程来分析哪些东西是可以实现的，并如何实现。程序员的思维模式和策划的思维模式是不同的，他所面对的是需要严谨的逻辑结构体系，很多细节问题在这时都要开始实施了。好的创意必须要用计算机可以表现的形式由程序和美术来实现，否则一切设想都是空谈。流程图尽可能按照程序的结构来设计，就可以最大程度的减少程序员的理解困难，并快速把你的想法落实。
为什么要按照模块来划分流程图呢？因为整个游戏的策划工作不是一个人就可以完成的，无论设计还是编程都需要很多人进行协同配合。在早期设计阶段就把整个项目进行合理的分工，并按照逻辑顺序进行流程划分能够在实施阶段快速安排工作，制订起来项目进度表也有据可查。
这个流程图并不是说策划写完了就没有事情了，其合理性和正确性还需要进一步的验证。草图完成后，方案提交给项目组，由开发小组集中讨论，主程确定程序实现难度及准确性，美术预估工作量。策划最后根据该流程图完成设计文档，再次开会讨论，定稿后负责人签字归档，确定版本为流程图1.0。以后每次修改都要小组会议决定，更新文档版本，这样才可以保证文档的准确和版本的一致。
另外，要有专人进行文档保管和整理。利用一些文档管理工具比如LOTUS NOTES等软件可以更加系统化的对文档进行整理，根据需要自己设计一套数据库系统也是可行的。否则在项目完成后根本就没有任何积累对任何项目来说都是非常可怕的，在中国这种现象十分普遍，为了赶工期而不重视文档整理的项目比比皆是。要杜绝这种现象也只有从管理的根源入手，从开发之初就进行严格的规范，并派专人管理落实才可以保证项目和文档的同步。
在流程图最后定稿后，整个游戏的体系就算完成了。下面就要一点一点来把所有的模块都实现，让我们头脑中的游戏变成现实吧！

上面的一个图是描述各个模块之间的关系图。生存体系和地图系统是整个游戏的基础：生存体系中包括所有可能出现的角色属性，可能会在设计过程中不断添加新属性。地图系统是游戏中涉及到的全部位置和地点，是设计中最为头痛的一个部分。这两个系统构成了游戏的基础，几乎所有的游戏都有这两个模块。
升级系统的所有数据都要来源于生存体系中的人物属性，如何设计升级算法让游戏更好玩，更耐玩是升级系统设计的关键。掌握好整个体系的平衡性，尤其在多人游戏时更为重要。升级体系的重要性也体现在游戏时间的控制上，既要让玩家感受到升级后的变化，又要合理控制升级的速度，难度是相当大的。大量的时间被用在反复的演算上，这时先用程序设计个小模型是个比较好的办法。
NPC设计和AI设计是一个整体，在这里把两者分开来是有目的的。NPC的作用有很多，有时是放道具的箱子，有时是完成任务的触发器，有时是你的敌人，有时是你的朋友。NPC设计和地图位置也有关系，每个NPC都有一定的活动范围，应根据剧情需要指定活动地点。AI是指游戏中的人工智能设计，和NPC的设计结合很紧密。由于该系统往往由程序和策划协调着设计，所以把这个部分单拉出来形成一个单独模块。一般的AI设计包括寻路算法、战斗方式选择以及对话应答等，由于该部分极为复杂这里就不再详细描述。
战斗系统是一个笼统的概念，一些竞技比赛也可以归入到战斗系统中。战斗系统需要前面介绍的5大模块的支持，具体的实现就是战斗模式设计和战斗效果设计。有的游戏没有战斗，就可以跳过这个部分，但纵观现有的知名大作，哪个不是依靠独特的战斗系统来吸引玩家的呢？
进入到任务系统的设计部分，游戏框架就基本上已经快完工了。如何利用已经完成的其他模块来推动剧情的发展，巧妙的设计一些任务引导玩家进入到游戏的世界中来就要看设计人员自己的功底如何了。
上述几个部分之外，就是更为高层的界面设计和操作设计。这两个部分直接关系到用户对该游戏的接受程度，良好的界面和快速的上手操作所带来的第一感觉甚至可以决定着玩家会不会继续把这个游戏玩下去，其重要性可见一斑！
这些模块一起构成了游戏的主框架，从什么方面切入，如何由下到上或由上到下的逐渐完善，直到最终游戏成型并设计完界面与操作体系。对于一个要参加比赛的入门策划而言把握好这些零部件就可以控制好自己的思路，不至于在搭建骨架的时候自己就陷入到了无限的混乱中去。游戏的框架是为了让你自己整理思路，但你的策划案是要给别人看的，怎么让其他人迅速理解你的想法呢？让我们来看看系统流程图的绘制过程吧！

在完成了上述几个模块的划分之后，你的整体思路已经建立起来了。在进行模块设计的同时，你的游戏世界就逐渐呈现在你脑海之中。这些内容很混乱，因为各个部分都是相通的，而且关联很紧密。如何理清思路保持清醒的头脑才是最终成功的关键，这一点对于策划来说尤其重要。设计人员在早期脑子就是一团糨糊，那进入了开发阶段肯定是一团糟！上面描述的都是一个大体的模块划分，具体的游戏框架搭建还是远远不够的。在第四部分中会针对这些模块进行详细的讲解，以一个网络游戏为例简要的描述一下作为策划要如何完成一个庞大的世界体系。

5、 游戏开发进度：开发进度是要求产品经理或项目经理根据现有的条件来确定的。对你的上司来说，他最看重的也是这个部分。因为开发周期的长短会直接影响到游戏制作的成本，而且何时能够完工也决定着上市能否赶上最好的档期（比如暑假档），所以开发进度很多时候能够直接决定着这个游戏是否会被老板枪毙。
游戏的开发进度一直是困饶着国内开发团队的大问题，国外也一样。由于开发人员的熟练程度不同，预留时间很难确定。对于参加比赛的各位同志来说，只要大致计算一下需要多少人/月就可以了。
6、 开发人员列表及职责：最后一项，就是对人员进行分工。已经到位了的，直接进行工作安排；还没有到位或者需要招聘的，向人事部门发送申请。报告中要对人力情况进行估算，以及各项费用的评估。对比赛而言这部分就可以省了，费用的评估是需要有丰富经验的市场和管理人员才可以计算的。

好了，在完成了上述各项工作的汇报之后，如果你的预算和公司的计划相符，那么恭喜你，你可以开始下一步的安排了。否则，就只有等机会或者重写你的报告，但这种情况往往是没有结果的。项目建议书并没有一个固定的格式，你的目的就是通过它来说服你的老板（在这里就是说服评委对你策划的支持）。但是这又是不可或缺的一个必要条件，项目建议书分析的越透彻，这个项目可能获得的支持也就越多，最终成功的机会也就越大。
我们假设你已经通过了老板的测试，就让我们再回到你的故事中去，来看看如何让你的故事更容易被人接受，如何把它变得更丰满，更有趣吧！

上面的三种情况是最容易被忽视的因素，还不是要考虑的全部。其实一个有经验的策划在刚开始有想法的时候就应该把大部分可能发生的问题都预测到，这样才可以保证这个项目有存在下去的必要和价值。而一个刚入门或者准备入门的新手，也最容易忽略上面三个因素。可能由于自身条件的限制，你对技术并不是很熟悉甚至是门外汉，那么你就一定要找一个做程序或者有经验的策划询问一下你的想法是否可行。如果有了一个念头就一头扎进去，最后的结果很可能是浪费了精力和时间，却一无所获。
你可以把自己的可行性分析过程记录并整理出来，这就是你的可行性设计文档，也是整个策划中一个很重要步骤。有了这份文档，程序就知道这个东西要实现什么，自己要做什么样的技术准备；部门负责人就可以估算大概需要多少费用来开发，开发周期大概有多长；人事部门就知道还要招聘什么样的人才能满足项目的需要。如果这些文档根本经不起推敲或者你自己都认为不可行，那就最好换个想法或者继续修改。越早发现问题就能够避免更大的损失，想成为一个策划就要从全局的角度来看问题。如果只是想做一个执行策划或者脚本设计就可以忽略这部分，因为你要干的事情就只是听从主策划的任务分配并按时完成工作就可以了。而你想成为一名合格的主策划或者项目管理者，那么可行性分析就是你要掌握的第一个重要步骤。
对于参加这次比赛的业余人士，你可以先不用考虑经济和人力等方面的问题，只要从技术和开发周期两个角度来考虑你的设计就足够了。首先，你要明确你的玩家用户群是哪些，也就是说你的游戏是为哪些人而设计的。然后你要大致明确你设计的游戏是哪个类型或者倾向于什么类型，这样才可以保证自己的思路不至于太混乱。最后就是要确定你的游戏要利用哪些技术，可能要分成几个阶段来完成。在完成了上面三个过程的思考后，你就知道你的这个游戏是否能够拿出来参加比赛了！只有你的可行性分析能够考虑到市场和人力方面等因素，这个想法才有可能成为一个商品化的游戏，否则它只能是一个参加比赛的作品而已。
整理完你的设计思路并整理出一份合格的可行性报告，这就为你的全部策划开了一个好头。下面就是写一个完整的项目建议书，这是拿来给你的部门负责人看的。还是那句话，如果你只想做一个执行策划，这个部分可以跳过；但想成为一个合格的主策划，就让我们来看看项目建议书该怎样写吧！

(1) 设计公平交易系统的目的

最基本的目的：
促进游戏中玩家的交易
在日常交易中，正常（公平状态下）的交易量要远远大于非正常的交易量（玩家出于骗人的目的和乐趣而进行的交易）。

当交易处于公平状态下时，玩家交易的愿望不会由于系统的原因的失败，此时交易量才会在最大范围。如果交易处于不公平的状态，确实可以增加交易的乐趣，或者可以作为一个玩点，但是却会遏制正常交易的进行。所以我们要使用公平交易系统。

(2) 交易方式

·物、物之间的交换；

·钱、钱之间的交换；咋听起来比较奇怪，但是在使命中不同的种族拥有不同的货币。

·钱、物之间的交换；

只要没有违背双方意愿的交易系统我们都可以称之为公平交易系统，单方面给予物品也是一样。

(3) 影响公平交易的因素

·由于系统的操作方法不了解而自己导致的不公平交易；

解决方法：简化交易之间的操作，并且尽量做到在公司所有的游戏中交易方式是一样的。

·由于交易过程中对方突然更换物品而自己没有及时中断交易产生的；

解决方法：对方如果更换物品即系统自动中断交易。

·由于对物品价值不了解而产生的；

解决方法：全屏交易频道的存在，使得其他玩家在平时即可接触到一些物品的价格。

·由于多次重复的失败的交易行为导致急躁而交易产生的；

解决方法：系统自动给予提示，如果同两个人之间交易连续中断3次，系统即提示玩家注意对方所摆放的物品的真伪。

·由于一些高价值物品无法一次完成交易的；

解决方法：如果确实有这样的物品存在，比如点卡这些，可以通过系统公正的方法来解决。

·违反玩家意愿的交易确定行为，一般为外挂造成。

解决方法：这个只能在构造系统中尽量减少不安全的因素，并对外挂进行有效监督。

总之，在公平交易的同时系统应该注意系统提示的制作，并且要注意提示的醒目而且又不能破坏游戏的整体感觉。但是需要注意的是：在游戏中正常交易行为的发生要远远大于异常交易的产生，包括玩家之间的骚扰，所以不能够为了尽力做到公平而失去了交易的连续性和易用性，这就失去了交易系统的基本目的。

(4) 公平交易的漏洞

公平交易系统最大的漏洞就是：几乎在所有的游戏中，复制物品的BUG决大部分是通过公平交易系统进行，预防的方法有：

双方交易的时候服务器要进行即时存盘。

(5) 公平交易的证据

另外为了GM工作的方便，在公平交易的时候需要在客户端生成LOG，当然通过LOG还可以分析玩家的消费倾向等，当然用log分析是麻烦了一点，也可以直接dump相应的数据。

§1.2 界面设计

界面设计中的注意点：

·交易界面的位置不能与物品界面有冲突；

原因：金钱的查看，以及玩家与自己现有的一些物品做比较。

·交易界面最好不要与人物属性界面有冲突；

原因：玩家在一些交易当中需要参照自己的属性。

·聊天消息框：

原因：玩家在交易的时候需要彼此的交流。

·系统消息提示框

原因：玩家在交易中的时候用于一些系统消息提示。

·交易界面与物品界面之间的相互位置关系需要满足多数玩家（右手习惯玩家）的操作习惯。

·交易界面应该将双方的物品位置用明显的分界线分开。

原因：防止玩家混淆双方的物品或者金钱。

·交易中的确定等按钮要与界面本身底色有明显区分，每个按钮的两态要有明显区分。

·并且需要考虑游戏中最高价值物品与一般等价物间的换算关系，并且基于此换算交易界面需要有足够空间。

·交易界面的所有空间要在一页内显示，即交易界面中尽量不使用物品栏翻页功能。

以上不是固定的设计，设计者可以根据不同游戏的要求来要求。

§1.3 界面因素

(1) 一般需要

·对方名称：用于显示对方的名称，并起到避免发生交易对象错误的问题。

设计要点：这个和其他地方不同，如果玩家当中名字有空格或者其他空字符时，系统应该自动加上一些醒目的特殊字符，有需要时还可以做出醒目的系统提示。

·金额栏：用于显示双方交易的金额。

设计要点：显示金额的时候应该加上千分位的显示，如果有需要在金额后面显示此金额的单位。

·双方的物品栏：用于显示双方交易的物品。

设计要点：物品栏的数量要能够符合大部分或全部交易行为的最小需要量，即贵重物品与一般等价物之间的交易，尽量不使用翻页功能。但是如果物品栏实在不止一页，提示玩家翻页的效果要做的非常明显，并且也需要提示玩家目前所翻到的页数。

·金钱确认按钮：用于确认金额。

设计要点：一定要做的特别醒目，以方便玩家确认自己的金额。

·交易确认按钮：在交易双方确认交易物品和金钱后，点击按钮即可完成交易。

设计要点：注意点击按钮的时候不同的提示。一般有：

1、  对方还没有完成确认自己的物品。

2、  自己没有确认好金钱的数量。

·申请交易按钮：用于向对方申请交易，或同意申请，以及打开交易界面。

设计要点：注意申请交易之后的鼠标指针的变形，还有如何申请交易的系统提示。

·其他交易项目：如果是养宠游戏，那么交易界面中还应该专门添加用于交易宠物的栏目。

设计要点：如果是可以改名字的宠物一定要显示其原来的名字，并且可以查看宠物的属性。

·关闭按钮：用于关闭交易界面，即取消交易。

设计要点：最好不要设计在容易点击的位置，否则玩家会误操作关闭界面

·物品悬停信息。给出物品的详细信息。

设计要点：也可以使用其他方式给出，但要与整体游戏做到统一。

(2) 其他需要

·玩家的等级：提醒玩家交易时注意是否使用的是小号；

· 玩家的负重：玩家在交易时受到限制的因素之一；

·玩家的头像：需要突出社区时，也在一定程度上避免了玩家交易对象错误；

·玩家的其他属性：对方的性别、职业、种族等等，能够使玩家更好更快的确认对方是不是自己要交易的对象

§1.4 交易操作

·最好不要使用拖动交易物品进入交易框的方式，防止丢到地上，如果实在需要采用也没有关系，只要加上贵重物品提示功能即可解决。

·操作设计要求：玩家在游戏过程中能够非常快捷的与他人实现交易或者提出交易请求，对方能够得到请求明显准确交易消息。

·如果两个界面的位置较远则需要考虑物品在两个界面中的移动需要省时省力，而且这个操作要考虑不与游戏本身和物品界面本身的操作相冲突。

·玩家确定交易物品以后，无法再更换物品。

·玩家在交易进行阶段对其他请求一概拒收，以免破坏交易的连续性。交易的弹出消息也需要考虑到对玩家游戏连续性的破坏。即要考虑到玩家恶意骚扰的交易请求，这在即时类游戏中的影响尤其大。

解决方法：以往弹出提示框的方法采用显示提示消息的方法来提醒玩家去点击提示框，而不是直接弹出界面需要玩家进行确认。

§1.5 一般交易流程

1.玩家点击交易请求按钮，鼠标指针变形，系统提示：点击对方进行交易。

2.玩家点击对方，发出交易申请，系统提示：交易申请已发出。

3.对方接受到交易请求，点击提示消息后，弹出提示框提示：XXX请求与你交易。点击提示框确定，同意请求，双方进入交易界面。点击提示框取消，拒绝请求。发出请求方得到系统提示：对方拒绝交易。

4.进入交易界面，同时物品界面打开。上方或屏幕非正中心一方为对方，下方或屏幕中心一方为自己，单击物品或拖动物品至交易栏。在金钱输入栏输入金钱点击金钱确定按钮。最后点击加以确定按钮。等待对方。

5.如果输入金钱后没有点击金钱确定而点击交易去确定，则系统提示或弹出提示框提示：请点击金钱确定按钮

6.如果输入的金钱大于身上现有的金钱时，系统提示或弹出提示框提示：身上的金钱不足

7.对方进行第四步正确操作，点击确定按钮，交易成功

8.交易过程中任何一方点击取消按钮，交易失败

9.交易成功或失败均关闭交易界面。

10.交易过程中物品栏与交易栏的拖动为单方面，即只能从物品栏将物品移至交易栏

11.交易过程中金钱只能输入一次。

12.每放入一个物品，交易界面刷新一次，交易的一方每放置一样物品，在对方的交易界面上也会显示此物品对应的图像。

13.金钱确定后交易界面刷新一次

14.交易过程中，一方有位置移动或移动一定范围外后，交易失败

15.一方打开与交易界面相冲突的界面时，交易失败

以上是一般游戏的公平交易设定流程，如有特定需要，可以在此基础上做一定改动。

§1.6 一般按钮功能

l         确定金额按钮：（但是最好考虑使用鼠标点击输入框即会自动弹出输入框，要求玩家自动输入金钱的数目并点击确定，这样就可以取消确定金额按钮的设定）

玩家输入金钱之后即可点击金钱确定按钮，这样输入的金额将会显示在对方的界面上，而且输入完金额后将不能对输入的金额再做改动。如果一方没有确定金额或者没有输入任何金额，那么在对方的界面上“对方金额”将会显示为0。

确定按钮一共有三个状态：

·没有输入金额时，按钮是不可以操作的。

·输入金额后，按钮自动变成可以操作，使用醒目的颜色来做这个按钮，以便提示玩家。

·点击按钮后，被点击的效果。

·确定交易按钮：

点击此按钮之后即可向对方提请交易，对方也按下确定按钮后，系统提示交易成功。当一方按下确定按钮之后，那么另外一方将会收到系统消息：对方同意交易，请确定。

·帮助按钮：

点击此按钮将会弹出和交易相关的帮助主题。

·取消按钮：

点击此按钮之后此次交易将会被取消，

·取消方收到的系统提示为：您取消了交易。

·对方收到的系统提示为：对方取消了交易。

§1.7 其他设定

·物品交易即时物品是摆在交易界面上，实际上此时物品还是保留在玩家自己的身上。

·双方的交易界面超过一定的距离即会自动取消。

·如果对方放置不下物品，则交易自动取消并作出提示。

·玩家死亡的时候系统会作出判断，如果交易没有成功，那么交易将会先被取消，然后交易的东西也算身上的物品。

·如果玩家正在拖物品的时候交易界面关闭。那么物品将会自动回到物品栏中。

·如果道具或者宠物可以更改名称，那么在交易的时候要以醒目的颜色标明此物品原有的名称。

·另外系统选项当中玩家可以完全禁止另外一方交易的申请。

§1.8 公平交易系统的细节表现

以下由设计人员自由取舍：但是在设计的时候有重要的一点，那就是公平交易在游戏中属于经常性行为，因此在普遍层次上的不要做的太繁琐，当然一些额度最大的交易可以做的好一点。比如系统频道的公告（当然没有必要公告出双方的名字）

·在公平交易系统可以加入音效的表现。

即游戏在公平交易进行的时候伴随着音效。

·在公平交易系统可以加入光效的表现。

比如超过多少金额的交易完成将会有礼花出现。

·可以在系统中发布公告。

一些特殊物品交易成功可以在系统中发布公告，比如点卡交易等。

·加入双方表情动作

交易进行或者交易完毕后双方通过动作进行致意。

1.数字化评分
1.1 评分说明：
1.1.1 评分标准：
 a.最低得分-10分,最高得分为+10分。导致玩家离开给予负分，能吸引玩家继续游戏给予正分。
 b.能直接决定玩家去留，给予8~10分
 c.对玩家的去留产生催化作用，给予5~7分
 d.对玩家参与游戏积极性产生影响，给予2~4分
 e.对玩家影响比较小的调整，给予0~1分
1.1.2 更新分类：为了便于分析，本人将收集到的官方公开信息分为4类：重大更新、游戏调整、游戏介绍、其它公告。
 a.重大更新：添加新内容，增加新元素。
 b.游戏调整：对游戏进行调整。
 c.游戏介绍：针对游戏玩点与功能介绍。
 d.其它公告：其它对游戏有影响的公告。
1.1.3 其它说明：所有评分的内容来源于官方公开信息，评论部分则是100%游戏内的真实体验。(每天平均在线12小时以上，连续近3个月）虽不敢妄言所述是梦幻国度的绝对真相，但却是本人3个月来的亲身感受。为了防止因个体差异而可能导致的误差，本人耗费巨大精力，接触上千名梦幻国度玩家，并在游戏内或游戏外了解他们对此游戏的感受，并在3个月内与上百名梦幻国度玩家保持比较密切的联系，经常交换对于游戏的看法，以上就是本文的前期准备。
1.1.4 基础分值：梦幻国度可以说是2004年度玩家最期待的国产网游之一，在盛大处心积虑的宣传和诱惑下，在广大梦幻玩家心里，它的初始分值应该在90分以上。为了便于计算，暂定90分。

1.2 评分清单
2005-1-19    《梦幻国度》敢说才是新派宠物！
类型：游戏介绍   评分：+2  总分：92
评论：当初的敢说，官方可是宣传了近半年，但是呢？直到今天我们也没看到当初宣传的“敢说”。期望与现实之间的冲突，结论就是梦想的破灭。（关于当初宣传的“敢说”，有心人请自行前往官方网站查阅相关资料，这里不转贴占用篇幅了，下同）
    其实，梦幻国度的敢说跟RO里的宠物、怪物说话没有太大的差别，甚至还不如RO里的宠物与怪物说话。RO的宠物与怪物说话仅仅用2个xml文件就实现了比较完善的“敢说”内容（比梦幻国度现在的“敢说”内容丰富很多，而且触发条件也丰富一些），而且自由度方面也比梦幻国度的好（玩家可以自由DIY，可以说RO的宠物说话才是真正实现了我的游戏我做主），最主要的是这个功能是在2003年初就有了。梦幻国度把RO 2年前的东西现在拿出来炒冷饭，还说什么新派宠物...我对盛大除了佩服也真的是无语了。终于明白牛为什么会飞了...同时请大家跟我BS新干线，把RO这样的好游戏运营得如此平庸，简直是暴殓天物！！！（新干线老是把问题推给外挂，坦白说外挂的影响比较小，关键还是新干线高层对游戏缺乏必要的爱心。即便过了2年多了，RO比现在国内Q版网游也一点儿不逊色，甚至在很多方面都比后出的游戏还完善。中国的所谓自主研发大大们抄完了传奇，估计下一个目标就是研究怎么抄RO，现在盛大和QQ都对RO下手了，而新干线手里捧着聚宝盆却还在发呆...跑题了，话题打住！）

【废话】宠物/怪物说话毕竟是梦幻的一个特色，虽然是RO N年前玩剩的，更让人失望的是，梦幻的宠物说话不仅没能达到RO的宠物说话程度，而且还大大的退步了。抄都抄不好，不知道该怎么说好。

2005-1-22   警告：不要在宝宝心烦的时候招惹它
类型：游戏介绍   评分：-5  总分：87
评论：从图片我们可以看出2点：a.游戏研发之初玩家是可以同时带2只宝宝出现的；b.人物可以与宠物进行简单的人机对话。但现实呢？我想不用再说什么了，这点期望也不知道何年何月能实现了。就目前来看，根据官方公布的下半年研发计划，今年内是没有希望了...
【废话】纯粹的虚假宣传，严重误导玩家。

2005-1-24  《梦幻国度》1月25日火爆内测 五大旅团出炉 
类型：其它公告   评分：+4  总分：91
评论：第1次封闭内测据说很抢手，毕竟是期待了整整1年，而且是盛大世纪录3部曲的最后1章，相信任何玩家都无限期待。从参加过1测的多名玩家那里我了解了大概:严格的说，1测也就是游戏功能性测试，大家所熟知的α测试阶段。游戏中怪物直接爆药、爆装备、金钱、卷叶，6月底，当我再次跟1测玩家聊天的时候了解到新的变化。在他们眼里，梦幻国度最美好的时期正是这个1测阶段，后面是越改越乱，越改越差。
【废话】曾经的梦幻国度虽已远去，但体验过的玩家永远不会忘记那一个月的美好时光。

2005-2-25   公告：封闭内测玩家可直接登陆1.2版测试服务器
类型：其它公告   评分：-5  总分：86
评论：在这个公告中我们可以看出几点：
    a.1测的测试工作基本上告一段落了，时间持续了仅仅1个月;
    b.预告了2测试开放时间为3月16日;
    c.扩大测试人员数量；测试人员除1测人员之外，按男女1:3的比例重新招募新的测试人员；
    d.除了以上说明外，1测与2测并没有明确的测试目标说明，一切都以“版本优化及配平调整”模糊带过。
    就功能性测试范围的BUG而言，现在公测阶段依然存在的包括：幻灵师的卡技能、猎奇士的卡招式、装备变面粉或资源、掉线部分回档、修理装备不能等等问题。而一大堆问题经过了1测，走完了2测，伴随着公测一起出现在万千玩家面前，原因何在？两个字：时间。回顾1测、2测，让我感触最深的就是梦幻国度项目组一起在与某个时间赛跑。无论出现任何问题，无论问题有多严重，一律都被放下了，因为时间紧迫。而存在的问题，我作为1名2测玩家，从GM05第一次上线收集问题开始，每次都不厌其烦的重复跟他说过无数次一些常见问题，但每次的结果都是遥无音讯。问题依然，BUG依旧，一切都没有改变。请允许我再废话几句：梦幻国度的研发时间据说有3年之久，既然3年都等过去了，为什么还要急这一时三刻？这里请让我再举一个例子。暴雪的游戏之道：无论自己失言多少次，无论让痴心的玩家失望多少回，只要游戏还存在问题，就决不上市，也正因为暴雪的这份坚持，十年来它赢了玩家的一致拥戴：暴雪出品，必属精品。相信这话，任何一个真正的玩家都不会陌生。
【废话】1测留到现在的众多历史遗留BUG相信任何一个梦幻国度的玩家都会觉得是不可思议，毕竟从1测开始就有无数玩家反映过的问题，到了现在收费运营了依然存在，加上层出不穷的新问题，-7分不过分，但考虑到梦幻项目组对于部分问题的解决速度还算快，应该加+2分，（比如合成数量出错等问题很快就解决了）综合得分：-5分）
   
2005-3-14 头饰显示系统加入 1.2版测试延期至3月25日
类型：游戏介绍   评分：+2  总分：88
评论：原定3月16日开始的2测，由于加入头饰显示系统而推迟到3月25日。在公告中我们还可以知道2测与1测的细微差别：a.增加了送信任务与采集任务;b.游戏内物品掉落做重大调整:不直接爆物品，仅仅是爆资源与消耗品（如香草面包粉）。另外，在关于延期的原因中，官方使用了“即使全日无休的连续工作，实际工作量也超过了预期”，这里让我感受到的依然是那两个字：时间。正如上面所分析的：梦幻项目组一直在与某个时间赛跑，全组上下长期处于满负荷紧张工作状态，我们先不谈人的体力与精力是否能支撑这样的消耗战，我只想问问这样的疲劳战下工作效率将任何保障呢？联想到一系列因为更新而出现的新问题，这难道还不能发人深省吗？
【废话】增加了梦幻国度的一个玩点：收集漂亮的头饰，虽然截止7月初累计出现的外观头饰还不到20款，但好歹添加了这个功能。真是不容易！

一、在任务中成长！

1、任务的相对难度和玩家当前的状态应该是密切相关的！
伴随着玩家在游戏中的进度，玩家应该始终面临和自己身份角色相当的游戏任务。比如：初期只是做一些新手任务、到中后期就可以做一些和职业情节相关的任务。

2、在任务中成长VS为成长而任务
以上只是“在任务中成长！”的第一层含义；深一点来看，相对与“为成长而任务”。玩家为提升自己的等级，在游戏的过程中持续做一些给予经验的任务；这是一种从怪物身上剥离出经验和金钱，变成一种给予对等奖励的任务；表面上是玩点的丰富化，实际上成为本来就枯燥无味练级的沉重负担。
失败的典型：A3
以A3的任务系统首当其冲，是功利性极强的任务系统；任务N多，但是流程很简单。找NPC接任务——→杀任务指定的怪物——→回去交付任务——→获得奖励（金钱、经验）
A3的任务系统是完全依附在玩家练级的过程中的，可以看作是成长的一种手段。看下表的对比：
 
1 2 3 4    
找NPC接任务 杀任务指定怪 回去交付任务 获得奖励    
找NPC买补品 杀当前级别怪 杀怪掉落物品 再次购买补给  
可以看出，做任务和打怪练级的流程是结合在一起的；玩家在NPC处购买任务和补给品，再去杀当前级别最合算的怪物（一定有对应的任务怪），杀了足够数量的怪物时玩家的补给品也消耗的差不多了，再次回到村庄补给和接任务。
如此循环，做任务也变成了升级的一部分。听高级别的A3玩家说过，所有做任务的钱和打怪掉的钱刚好能购买当前级别所需要的装备。似乎就是把练级所能获得的经验和钱拆分成两部分，一部分变成了传说中的任务！
高丽人拿着手中的栗子，说：“嘿！猴子们！朝三暮四好吗？”
可惜中国人早就知道这个道理，所以A3一副半死不死的样。
赚足钱的角：梦幻西游
为成长而任务是一种很枯燥的任务系统，但是依然会制造出游戏业的成功者。最有代表性的就是梦幻西游了，其师门任务已经完全脱离打怪，变成一种只需要跑动就能够获得经验和钱的任务，从根本上替代了网络游戏的练级，这改不掉它枯燥的本质。但是它是成功的，因为他赚够了钱。
但是真正让他赚够了钱的不是师门任务，而是将三类不同玩家完美的整合在一起了！游牧民、贵族、新手。
游牧民：游牧民的特点是虽然有不少的时间，但是金钱上拮据，他们不愿意也不可能在一款游戏上投入大量的金钱，加上
贵族：贵族们有足够的人民币，他们也许在时间上并不富裕；但是他们也想在虚幻的世界有自己的一席之地，去满足他们那自我满足的虚荣心。
新手：没有玩过任何的网络游戏，他们需要一个比较繁荣的游戏，最好还有一些朋友；这样他们就可以很容易的进入这款游戏。
结合！：游牧民在游戏中通过跑商等任务赚钱获得经验和钱，提升自己级别的同时，用获得虚拟货币，在系统中购买贵族寄售的点卡。（游牧民解决了人民币不够的问题）贵族用人民币购买游牧民的游戏币，用钱堆积起一个个人民币战士；由于有足够多的游牧民维持系统的繁荣，贵族们的强大变的有炫耀之地，他们于是愿意丢钱进去！“这个游戏很多人玩的！”一句话，吸引了无数不知游戏为何物的新手；他们自觉也不自觉的将自己划入不同的游戏阶级中，于是梦幻西游成功了，在萧条的网络游戏背景下。
在任务中成长——我的定义
任务应该是伴随玩家成长，了解游戏世界的手段；当玩家完成旧的任务时，等级能力各方面应该获得提高，而同时也会面临新的任务。任务应该是构架与世界背景之下的，玩家通过做任务去了解自己所在的游戏世界的文化，就好比小说中的故事情节。

二、任务的新鲜感觉

关键字：新鲜感
人之所以有玩游戏的需求，有一点可以十分肯定；那就是现实生活往往是有规律的，每天都在重复中度过。这产生一种很强的疲劳感和无聊感，于是有人开始玩游戏，他们在游戏中能看到许多现实生活中看不到的东西，这让他们觉得很好奇！可是一旦这些东西也被他们所熟悉时，没有其他东西可以吸引他们的情况下（比如：人于人的竞技性），游戏就变的不是那样有意思了！
所以，个人认为，游戏一定要给人新鲜的感觉！

1、接任务的新鲜感觉
    接任务的新鲜感觉，就好比现实生活中一些随机和偶然的事件；比如走在路上突然有人搭讪的感觉，再比如在教室里上自习突然发现脚下有十块钱！
现在网络游戏的任务一般固定在NPC的身上，玩家需要找到正确的NPC激活对应的任务；然后完成任务再找NPC寻求奖励！
以下是我现在所想到的增加接任务的新鲜感的方式：
从怪物身上掉落任务卷轴！
按规律在游戏中移动的NPC，遇上游戏玩家时会给予任务！
当玩家达到某些条件时，会收到NPC写给玩家的信，可以在NPC处激发隐藏任务！
玩家每天可以在NPC处接一随机任务，任务的奖励也可以是在几种物品之中随机选择的！
游戏世界定期发生，所有玩家的行为决定任务的结果！

2、任务奖品的新鲜感
玩家在任务中获得的奖品应该是具有一定的特殊性！如果任务中获得的奖品可以轻易的被其他的方式所替代，那玩家往往会选择更加简洁和方便的方式来替代任务。再者，如果游戏任务给予的奖励不能够给予玩家足够的兴奋感，玩家也很难提起对游戏任务的兴趣。
正面的典型：魔力宝贝
魔力宝贝的任务奖品系统是最丰富多猜的，有别与一般网络游戏只给一些经验、金钱或物品（可替代品）；魔力宝贝往往奖励一些称号、首饰（无法通过其他手段获得的属性）。
现在还记得当初玩魔力，做“传说中的勇者”任务，看到别人有这个称号，不顾一切也要做完任务获得称号，有了称号以后又在服务器里整天整天的溜达，生怕别人不知道。

3、任务的故事情节
任务应该建立在曲折的故事情节之上，最少应该建立在曲折的迷宫之上！如果任务只有时间、地点、人物、事情，那将是毫无吸引力的！拖个反面例子出来先：（来自A3）
初次出发
这是第一个任务!
在艾高尼打猎最软弱的怪物巨枭10只后
找到1个巨枭的耳朵去送给艾密叶吧。
     再来看看暴雪在魔兽世界一个叫完美烈酒的任务吧，为了让玩家融入任务的背景之中。做了一段算是挺长的背景描述，这很容易吸引玩家进入游戏设计者预想的状况之中！
完美的烈酒
任务目的: 　帮Brewnal村庄的瑞旧德找到6个微光草。
任务说明：　我正在寻找制作完美烈酒的方法，我肯定能找到它的。我有酿造的天分。只要让我找到合适的处方就能做到了，霜鬃巨魔有一种植物-微光草，他们在东北方向的洞穴里。他们拿它当成一个奇草用在部落的典礼上，我们矮人到没有发现它有什么大用处。不过他尝起来相当奇特。我想也许能够拿来酿酒。
　从霜鬃巨魔那里帮我找到一些微光草。你只要从巨魔的篮子直接拿就行了。

三、链状的任务

关键字：链状任务 应用范围
链状任务是在任务链之中，前一个任务是后一个任务的前提条件；必须从完成第一个任务切入任务链之中，才能继续完成下面的任务。链状的任务适合描述故事的发展，适合伴随玩家的成长，也适合做一个欲望的诱饵。

1、故事情节的发展
    例子：魔力宝贝
不好意思，又是魔力宝贝。魔力宝贝的主线任务并不刻意强调其链状特性；但是当玩家在一个环境下成长的羽翼丰满，会自然而然需要完成新的任务，进入下面的游戏环节。采用链状的方式，能够最好的诠释故事的发展。

2、伴随玩家的成长
新手入门任务基本上在每款网络游戏都会出现，是伴随玩家成长的典范。一款网络游戏如果不是操作极其简单，那就需要一个好的新手入门系统；如果一款游戏上手十分困难，难到有点象在学一门新的语言或手艺，那么玩家在被游戏的乐趣所吸引之前就有可能放弃。

3、永远抓不到的香蕉
    永远抓不到的香蕉！如果一定要将链状任务和玩家比做什么的话；我喜欢把玩家比做猴子，把链状任务比做香蕉。怎么样能够让玩家变的更加积极？更加充满兴趣？简单的来说就是香蕉永远在前方，但是你却永远差那么一点点抓到的过程！
自己想了个简单的例子来说明怎么样用香蕉吸引猴子。
链状任务的前后两个分别是：“蜘蛛线”“白狐皮”。玩家在完成“蜘蛛线”的任务时，NPC给予新的任务“白狐皮”。任务描述：真的很感谢你帮我收集蜘蛛线，用这东西缝制的衣服再结实不过了；用来缝制一般的材料真是浪费，如果能够得到充满灵力的白狐皮，我一定能够制作出“白狐皮衣”。即使是普通人穿上它也能拥有无穷的力量！年轻人，再帮我收集一些白狐皮吧。如果数量够多的话，作为报答，我将为你免费制作一件“白狐皮衣”。
    玩家在这种情况下，很自然的就会继续下去；因为“白狐皮衣”的诱惑。（注：如果白狐皮衣丢的一地都是，随便打个怪就掉，或者在商店里就能买到。那么这个任务将彻底变的无趣！因为遍地都是香蕉，你手上拿的那一根对猴子已经没有任何吸引力啦！）

四、非线性的任务

关键字：非线性任务 封闭式 开放式
    游戏绝对是不同与小说的艺术形式，游戏往往能带给玩家更强烈的参与感；因为玩家在面临问题的时候能够做出自己的选择，小说不可以。
每个人的思维方式、人生观、价值观是不一样的，于是在相同的情况下，不同的人会做出不同的选择；而这些不同的选择所带来的结果是不一样的，这种对外部事物的改变能力能够给予玩家最强烈的自身价值认同。

1、封闭式非线性任务
在任务之中多添加一些选择，在不同的选择之下，最终可能都能够完成任务；但是完成任务的路径不同，最后获得的奖励也不同。
拿“完美的烈酒”制造一个非线形的任务吧。玩家来到霜鬃巨魔所居住的洞穴前，发现门口有两个巨魔守卫。这时候弹出任务提示：杀掉门口的守卫有可能会惊醒洞内的霜鬃巨魔，看看周围有没有什么秘密入口能够进入洞穴之中吧。
这时候，玩家面临选择，是杀掉巨魔守卫直接冲进去还是找秘密路口；杀掉巨魔守卫会引来巨魔酋长与玩家作战，如果玩家能力足够强的话能够与之对抗，否则有可能无法完成任务。
玩家在附近转了转，发现有一个小洞能够爬进洞穴之中；于是玩家选择爬入洞穴之中。在洞穴之中转了会，终于发现了微光草。当玩家将微光草放在手心时，发现这种东西拥有神奇的力量，能够减缓体力的消耗。
这个时候，玩家自然而然就面临选择了。是将微光草交出来？还是自己留着。

2、开放式非线性任务
开放式非线形任务，是在游戏世界某些条件达到以后；系统自动激活，所有玩家将共同面临出现的状况，玩家可以感觉的到因为自己的选择，游戏世界发生的变化。
例子：玩家大量的猎杀怪物，怪物们对玩家的仇恨达到一定程度。激发任务“怪物的复仇”，系统公告：“东南方有大批怪物正在集结，他们的目标是攻陷我们的城堡！去给予他们痛击吧！让他们滚会自己肮脏贫瘠的世界去吧！”
玩家在这种情况下，将面临选择是否要去打击怪物呢？假设大部分的玩家选择不去杀怪物的话，就有可能出现怪物大量集结攻入城堡，难以抵挡的状况。
在网络游戏里还从来没见过这种任务形式，不过这有可能成为未来网络游戏最震撼人心的任务系统。

五、任务中的怪物
怪物是任务系统十分重要的一个环节，强大的而智慧的怪物会让人激动兴奋！而愚蠢弱小的怪物会让人觉得索然无味。这和人生很象，当你击败了自己一直很想打败的人，你会变的异常兴奋和激动不已。

1、时间的把握
当玩家已经将某个BOSS锁定为自己想要战胜的目标，那么在时间上，他将面临两个时间段。前一段，征途开始到到达BOSS所在的目的地。后一段，与BOSS作战。
在这两个时间段上，玩家在前一段时间将处于焦虑和好奇的状态。随着时间的推移焦虑和好奇的感觉将逐渐增加，最终到达一个顶点；然后开始下降，取而代之的是一种害怕失落抱怨的感觉，这种感觉也会越来越强。从前一段进入后一段的时间应该是玩家到达顶点之后的一点点时间，就是开始有些士气低落的时候。
与BOSS作战也一样，时间的把握应该是适中的。如果BOSS太弱小，游戏索然无味；反之BOSS太强大，玩家将彻底失去信心。
这种时间的把握并没有什么固定的公式可以追寻，只能是一种大概的感觉。

2、怪物的强大程度
怪物的强大程度应该是适中的，不断的让玩家有心惊肉跳的感觉，但是也不断的让玩家感觉到希望就在前方，只要再坚持一下就能打败他！如果怪物太过弱小，几下就轻易的被解决掉，那很无趣；如果怪物太强大，给人的感觉象是不可战胜，那玩家也会失去战胜怪物的勇气。
鄙视一下：鄙视有些游戏，法师用魔法远程打击怪物，怪物一直跟着跑就是打不到法师，一直到被打死。尤其是一些BOSS级别的怪物也这样！这很无聊，玩家很快就会从为自己的小聪明洋洋得意而转变为提不起精神来。

记：以上是个人对游戏任务系统的看法了，只是一家之言，离专业差很远，表达能力也不太好；只是根据自己对游戏的思考和对游戏策划一职的向往，写下来的东西。希望自己能够找到游戏策划的工作。人应该为理想活着吧。

场景管理之消息发送

    好久没有写东西出来和大家共同揣摩，真是对不住大家了。现在终于腾了一些时间来继续和大家研究网络游戏制作技术，在这一节中，我就要向大家介绍网络游戏服务器中World场景划分和场景中消息分发问题。

    在前面我基本向大家讲述的都是一些基本的技术问题，从某种意义上讲。属于纯技术范畴的东西，但现在要向大家讲的，应该是属于服务器功能设计范畴的。在这里，我未必讲的很好，有遗漏之处就请大家谅解和指正。

    对于有一定游戏服务器开发基础的朋友而言，应该都明白一个网络游戏服务器和客户端之间的一个基本关系： 玩家客户端是游戏服务器一个局部COPY表现。这个说法听起来可能有一些绕口，简单的解释下也就是说：客户端所具备的区域信息也就是游戏服务器相同区域数据的一份COPY，而表现的意思，也就是说，CLIENT端将这样的数据信息图形化，并且通过屏幕来进行显示，从而来呈现出一个多姿多彩的游戏世界。这样说大家应该能够听懂了吧？再不懂的话，就自己琢磨了。

    说了上面那么多，大家一定要问“SERVER和CLIENT这种关系和我们的消息发送又有什么关系呢？”。其实，我们要讨论的问题点也就在这里。但现在我还不说场景消息到底该如何进行分发。我们还是再来研究一个问题：什么能够使我们的游戏世界变的内容丰富？
大家先不要看我所说的，先自己想想。

    大家应该都思考过了，我就来说一下我的个人想法和理解，可能和大家不一样（我想到的你没有想到的你补上，反之，我补上）。

    在我们的MMOPRG游戏世界中，造成游戏世界变的丰富多彩一般无外乎两个大方面：NPC动作、玩家动作。呵呵，看起来就只有简单的两个方面，但具体分析这些动作起来，可就会让各位包括我都会头大的。先我们来说NPC动作吧，NPC动作通过AI逻辑进行控制，一般情况可以分为一下几个动作：待机、移动、物理攻击、技能攻击、魔法攻击、死亡等，而游戏中玩家动作的产生是由现实中玩家进行操控的，动作类型基本上也不外乎以上几种。既然在服务器游戏世界中存在这样的一些动作，那是如何进行获取的呢？其实就只有两个字：消息（Message）。而消息的产生方又分为两种：Client消息，Server消息。既然有消息产生，我们就将涉及到另外一个问题：如何将产生的消息分发出去呢？

    下面通过我自己的实现经验来简单介绍场景消息的分发原理（详细介绍写的太多，有点懒！！），应该不是最佳的，我只是提一个开头，更好的处理实现方式还是需要大家来共同研究。有好的想法也希望告诉我下，我也从中学习些新的东西。

    先看场景示范图（我画的，比较土，只是表明一个意思。呵呵）

 
    通过上面设计示范图，我来具体介绍：关于场景消息分发，我的设计和分析过程：
    第一步：将场景网络化，也就是说将我们的游戏服务器大场景进行逻辑上的区域划分，每个单独区域所占的面积可以考虑比屏幕区域稍微大点。同时为每一个单独的区域创建Player标志信息（SOCKET或者其他）列表。

    第二步：将单独区域四分化，也就是说对于每一个小区域，再次划分为四个更加小的区域，同时为每一个小的区域建立一个包含三个对象的整数数组。数组的作用是为了保存此小区域的亲缘区域。例如： 小区域1的亲缘区域就是： A、B、H，小区域2的亲缘区域就是：B、C、D等。

    第三步：在上面两步基础上，就是实际处理消息分发了。如果Player/NPC在区域中进行消息动作，我们通过Player/NPC的当前位置就可以首先确定Player/NPC所在大地图中的具体区域。在我们确定好了具体的区域后，我们要继续确定在那个具体的小区域。在这些小区域都确定后，我们就可以将我们的动作消息发送到亲缘区域中的Player(玩家)。

    第四步：对于第三步的改变优化，用CPU处理量来换取消息数量，具体做法也就是，在亲缘区域中继续区域化。也就是说消息不是发送到亲缘区域中的所有Player(玩家)，而是有选择的发送到自身一定区域的玩家。这种优化改革从某种意义上讲，可以减少服务器总消息数量，但增大CPU处理量，而对于具体实现，就需要大家去权衡了。

    以上也就是这个分析和处理过程了。同时关于这个场景处理的.h文件，我也就简单的写下，大家参考了。

Class    GmapRegion
{
   public:
GmapRegion();
~ GmapRegion();
void   GetBoardCastMsgList(POINT current_pos,LIST *);  //获取当前位置广播消息的Player列表。
……..
   private:
        void   Init();
        voud   Release();
        bool   InitMapRegion(int  map_wis,int map_hei);         //地图区域化
        
   protected:
}

线程同步和服务器数据保护

最近因为自己主持的项目出现些问题，太忙了，所以好久都没有继续写东西和大家进行探讨制作开发部分了。在这一节中就要向大家介绍另外一个重要的部分，并且也是最头疼的部分：线程同步和数据保护。

关于线程的概念我在前面的章节中已经介绍过了，也就在这里不累赘—“重复再重复”了。有一定线程基础的人都知道，线程只要创建后就如同脱缰的野马，对于这样的一匹野马我们怎么来进行控制和处理呢？简单的说，我们没有办法进行控制。因为我们更本就没有办法知道CPU什么时候来执行他们，执行他们的次序又是什么？

有人要问没有办法控制那我们如何是好呢？这个问题也正是我这里要向大家进行解释和说明的，虽然我们不能够控制他们的运行，但我们可以做一些手脚来达到我们自己的意志。

这里我们的做手脚也就是对线程进行同步，关于同步的概念大家在《操作系统》中应该都看过吧！不了解的话，我简单说说：读和写的关系（我读书的时候，请你不要在书上乱写，否则我就没有办法继续阅读了。）

处理有两种：用户方式和内核方式。
用户方式的线程同步由于有好几种：原子访问，关键代码段等。

在这里主要向大家介绍关键代码段的处理（我个人用的比较多，简单实用）。先介绍一下它的一些函数，随后提供关键代码段的处理类供大家参考（比较小，我就直接贴上来了）

VOID InitializeCriticalSection(    //初始化互斥体
  LPCRITICAL_SECTION lpCriticalSection  // critical section
);

VOID DeleteCriticalSection(        //清除互斥体
  LPCRITICAL_SECTION lpCriticalSection   // critical section
);

VOID EnterCriticalSection(         //进入等待
  LPCRITICAL_SECTION lpCriticalSection  // critical section
);

VOID LeaveCriticalSection(         //释放离开
  LPCRITICAL_SECTION lpCriticalSection   // critical section
);

以上就是关于关键代码段的基本API了。介绍就不必了（MSDN）。而我的处理类只是将这几个函数进行了组织，也就是让大家能够更加理解关键代码端
.h
class   CCriticalSection                //共享变量区类
{
public:
CCriticalSection();
virtual ~CCriticalSection();
void   Enter();                   //进入互斥体
void   Leave();                  //离开互斥体释放资源
private:
   CRITICAL_SECTION  g_CritSect;
};
.cpp
CCriticalSection::CCriticalSection()
{
InitializeCriticalSection(&g_CritSect);
}

CCriticalSection::~CCriticalSection()
{
DeleteCriticalSection(&g_CritSect);
}

void  CCriticalSection::Enter()
{
EnterCriticalSection(&g_CritSect);
}

void  CCriticalSection::Leave()
{
    LeaveCriticalSection(&g_CritSect);
}
由于篇幅有限关键代码段就说到这里，接下来向大家简单介绍一下内核方式下的同步处理。
哎呀！这下可就惨了，这可是要说好多的哦！书上的罗罗嗦嗦我就不说了，我就说一些我平时的运用吧。首先内核对象和一般的我们使用的对象是不一样的，这样的一些对象我们可以简单理解为特殊对象。而我们内核方式的同步就是利用这样的一些特殊对象进行处理我们的同步，其中包括：事件对象，互斥对象，信号量等。对于这些内核对象我只向大家说明两点：
1．内核对象的创建和销毁
2．内核对象的等待处理和等待副作用

第一：内核对象的创建方式基本上而言都没有什么太大的差别，例如：创建事件就用HANDLE CreateEvent(…..),创建互斥对象 HANDLE CreateMutex(…….)。而大家注意的也是这三个内核对象在创建的过程中是有一定的差异的。对于事件对象我们必须明确指明对象是人工对象还是自动对象，而这种对象的等待处理方式是完全不同的。什么不同下面说（呵呵）。互斥对象比较简单没什么说的，信号量我们创建必须注意我们要定义的最大使用数量和初始化量。最大数量>初始化量。再有如果我们为我们的内核对象起名字，我们就可以在整个进程中共用，也可以被其他进程使用，只需要OPEN就可以了。也就不多说了。

第二：内核对象的等待一般情况下我们使用两个API：
DWORD WaitForSingleObject(        //单个内核对象的等待
      HANDLE hHandle,        // handle to object
      DWORD dwMilliseconds   // time-out interval
);

DWORD WaitForMultipleObjects(     //多个内核对象的等待
      DWORD nCount,             // number of handles in array
      CONST HANDLE *lpHandles,  // object-handle array
      BOOL fWaitAll,            // wait option
      DWORD dwMilliseconds      // time-out interval
);
具体怎么用查MSDN了。
具体我们来说等待副作用，主要说事件对象。首先事件对象是分两种的：人工的，自动的。人工的等待是没有什么副作用的（也就是说等待成功后，要和其他的对象一样要进行手动释放）。而自动的就不一样，但激发事件后，返回后自动设置为未激发状态。这样造成的等待结果也不一样，如果有多个线程在进行等待事件的话，如果是人工事件，被激活后所有等待线程成执行状态，而自动事件只能有其中一个线程可以返回继续执行。所以说在使用这些内核对象的时候，要充分分析我们的使用目的，再来设定我们创建时候的初始化。简单的同步我就说到这里了。下面我就将将我们一般情况下处理游戏服务器处理过程中的数据保护问题分析：

首先向大家说说服务器方面的数据保护的重要性，图例如下：

用户列表

                                  用户删除

                                  用户数据修改
                                  
                                  使用数据

加入队列

对于上面的图例大家应该也能够看出在我们的游戏服务器之中，我们要对于我们用户的操作是多么的频繁。如此频繁的操作我们如果不进行处理的话，后果将是悲惨和可怕的，举例：如果我们在一个线程删除用户的一瞬间，有线程在使用，那么我们的错误将是不可难以预料的。我们将用到了错误的数据，可能会导致服务器崩溃。再者我们多个线程在修改用户数据我们用户数据将是没有办法保持正确性的。等等情况都可能发生。怎么样杜绝这样的一些情况的发生呢？我们就必须要进行服务器数据的保护。而我们如何正确的保护好数据，才能够保持服务器的稳定运行呢？下面说一下一些实际处理中的一些经验之谈。

1．我们必须充分的判断和估计我们服务器中有那些数据要进行数据保护，这些就需要设计者和规划者要根据自己的经验进行合理的分析。例如：在线用户信息列表，在线用户数据信息，消息列表等。。。。。

2．正确和十分小心的保护数据和正确的分析要保护的数据。大家知道我们要在很多地方实现我们的保护措施，也就是说我们必须非常小心谨慎的来书写我们的保护，不正确的保护会造成系统死锁，服务器将无法进行下去（我在处理的过程中就曾经遇到过，头都大了）。正确的分析要保护的数据，也就是说，我们必须要估计到我们要保护的部分的处理能够比较快的结束。否则我们必须要想办法解决这个问题：例如：
         
         DATA_STRUCT  g_data;
         CRITICAL_SECTION  g_cs;

         EnterCriticalSection(&g_cs);
         SendMessage(hWnd,WM_ONEMSG,&g_data,0);
         LeaveCriticalSection(&g_cs);
以上处理就有问题了，因为我们不知道SendMessage（）什么时候完成，可能是1/1000豪秒，也可能是1000年，那我们其他的线程也就不用活了。所以我们必须改正这种情况。

         DATA_STRUCT  g_data;
         CRITICAL_SECTION  g_cs;

         EnterCriticalSection(&g_cs);
         PostMessage(hWnd,WM_ONEMSG,&g_data,0);
    LeaveCriticalSection(&g_cs);

或者        DATA_STRUCT  temp_data;

         EnterCriticalSection(&g_cs);
         temp_data = g_cs;
         LeaveCriticalSection(&g_cs);
         SendMessage(hWnd,WM_ONEMSG,& temp_data,0);

   3．最好不要复合保护用户数据，这样可能会出现一些潜在的死锁。

简而言之，服务器的用户数据是一定需要进行保护，但我们在保护的过程中就一定需要万分的小心和谨慎。这篇我就说到这里了，具体的还是需要从实践中来进行学习，下节想和大家讲讲服务器的场景处理部分。先做事去了。呵呵！！有好的想法和建议的和我交流探讨，先谢谢了。

线程池处理部分

续上在这里我将要向大家简单介绍一下游戏服务器中必须要处理另外一项主要技术：

线程池技术

开始 我来向大家简单来介绍一下线程池的概念，先简单了解下线程先，线程可以理解为一个function , 是一个为了进行某一项任务或者处理某一项具体事务的函数。例如：

UINT  WINAPI  FunctionCtrl(void *)              //线程处理函数
{
    进行某一项任务或者处理某一项具体事务
    ………….
    return  EXITFUNCTION_CODE;               //退出码
}

而我们的线程池自身可以理解为是很多线程的一个管理者也可以说是一个很多线程的统筹者。因为我们的线程池具有生成线程功能也具有撤消线程的权利。这就是简单的线程池的概念（我的理解，呵呵！！）接下来就来具体介绍线程池了！！

首先 介绍我们为什么要使用线程池技术呢？大家都知道我们的游戏服务器端要处理大量的用户请求,，同时需要发送大量的游戏数据到客户端，从而来驱动客户端程序的执行和维持游戏的进行。那我们的服务器端是如何进行处理的呢？其实在这里我们就充分用到了线程池技术。
那么用这种技术有什么好处和优点呢？以下就来简述这些，有不足之处和不当之处希望有心人指正，呵呵！！

大家都了解在我们服务器整个运行过程中，我们将整个运行时间分成很多个时间片。而对于这些已经分成的各个微小的时间片而言，在各个不同时间片中要处理的用户请求和需要发送到用户端的游戏数据量也将是不一样的。而处理用户的请求和发送数据到客户端的工作都是由一系列的线程来执行的。

鉴于上面，这样我们就可以感性的设想下服务器运行中的两种情况：
第一种在我们服务器运行到某个时间片需要处理大量的用户请求和发送大量数据，有这样繁重的工作任务，我们就需要有很多的工作者线程来处理完成这样的任务，以此来满足我们的工作需要。这样说我们就必须拥有很多工作者线程。

第二种在我们服务器运行到某个时间片需要处理的用户请求和发送数据工作量比较小，由于任务比较少，我们用来处理任务的工作者线程也就不需要很多。也就是说我们只要有少量的工作者线程就可以达到我们的工作要求了。
    
对于上面的两种情况，我们可以说明这样的一个事实，也就是说我们服务器在运行过程中运行状态是动态改变的，呼忙呼闲，时急时慢的。服务器的这样的行为动作和性质可以做一个如下比喻：服务器就是一个企业，在企业业务非常忙的时候，公司的员工数量就必须要增多来满足业务的需要。而在企业不景气的时候，接的业务也就比较少，那么来说就会有很多员工比较闲。那我们该怎么办呢？为了不浪费公司资源和员工自身资源，我们就必须要裁减员工，从而来配合公司的运行。而做这样工作的可能是公司的人力资源部或者其他部分。现在就认为是人力资源部了。呵呵。

对于上面的比喻我们来抓几个关键词和列举关键词和我们主题对象进行对照，以此来帮大家来简单理解服务器运行和线程池。

企业        ：  游戏服务器
人力资源部  ：  线程池
职员        ：  工作者线程

在说了这么多的废话后，就具体的将线程池模型  ThreadPool.h文件提供以供大家参考：

class   GThreadPoolModel
{
friend static   UINT WINAPI  PoolManagerProc(void* pThread);  //线程池管理线程
friend    static   UINT WINAPI  WorkerProc (void* pThread);       //工作者线程
enum SThreadStatus                                        //线程池状态
{
BUSY,
NORMAL,
IDLE
};
enum SReturnvalue  //线程返回值
{
MANAGERPROC_RETURN_value  = 10001,
WORKERPROC_RETURN_value  = 10002,
…………….
};
public:
GThreadPoolModel ();
virtual ~ GThreadPoolModel ();
    virtual bool  StartUp(WORD static_num,WORD max_num)=0;   //启动线程驰
virtual bool  Stop(void )=0;                                //停止线程池
virtual bool  ProcessJob(void *)=0;                          //提出工作处理要求
protected:
virtual bool  AddNewThread(void )=0;                        //增加新线程
virtual bool  DeleteIdleThread(void)=0;                       //删除空闲线程
static  UINT WINAPI PoolManagerProc (void* pThread);        //线程池管理线程
    static  UINT WINAPI WorkerProc (void* pThread);            //工作者线程
GThreadPoolModel::SThreadStatus  GetThreadPoolStatus( void ); //获取线程池当前工作状态
private:
void    Init();
void    Release();
protected:
………………………..
private:
};

以上是线程池模型的一个简单class，而对于具体的工作处理线程池，可以由此模型进行继承。以此来满足具体的需要。到这里就简单的向大家介绍了线程池的处理方式。有不对之处望指正。同时欢迎大家和我交流。

服务器程序设计部分

续上在这里我将要向大家简单介绍一下游戏服务器中必须要处理另外一项主要技术：
内存分配处理技术也可以称为内存池处理技术（这个比较洋气，前面通俗的好，呵呵）

开始向大家介绍一般情况下我们对于内存的一些基本操作。简单而言，内存操作就只有三个步骤：申请、使用、销毁。而对于这些操作我们在C和C++中的处理方式略有不同:

在C中我们一般用malloc(….)函数来进行申请，而对应销毁已经申请的内存使用free(…)函数。
在C++我们一般使用new操作符和delete操作符进行处理申请和销毁。
大家一定要问了，我们一般都是这样处理的呀！！没有什么可以说的哦！！呵呵，我感觉就有还是有一些东东和大家聊的哦。先聊简单几条吧！！
1．Malloc(…..)和free(….), new ….和 delete …必须成对出现不可以混杂哦，混杂的话，后果就不可以想了哦！！（也没有什么，就是内存被泄漏了，呵呵）
2．在我们使用new …和delete ….一定要注意一些细节，否则后果同上哦！！什么细节呢？下面看一个简单的例子：
char  *block_memory  = NULL;
block_memory  = new  char[1024];
delete  block_memory;
block_memory = NULL;
大家沉思一会。。。。。。。。。
大家看有错吗？没有错吧！！
如果说没有错的，就要好好补补课了，是有错的，上面实际申请的内存是没有完全被释放的，为什么呢？因为大家没有注意第一条的完全匹配原则哦，在new 的时候有[ ]，我们在delete 怎么就没有看见[ ] 的影子呢？ 这就造成了大错有1023个字节没有被释放。正确的是 ： delete []block_memory;

关于内存基本操作的我是说这两条，其他要注意还是有的，基本就源于此了。

了解了上面那些接下来就想大家说说服务器内存处理技术了。上面都没有弄清楚了，就算了。呵呵。

大家都知道，我们的服务器要频繁的响应客户端的消息同时要将消息发送到客户端，并且还要处理服务器后台游戏World的运行。这样我们就必须要大量的使用内存，并且要进行大量的内存操作（申请和销毁）。而在这样的操作中，我们还必须要保证我们的绝对正确无误，否则就会造成内存的泄漏，而内存泄漏对于服务器而言是非常可怕的，也可能就是我们服务器设计失败的毒药。而我们如何进行服务器内存的正确和合理的管理呢？那就是我们
必须建立一套适合我们自己的内存管理技术。现在就向大家说一说我在内存管理方面的一些做法。
基本原理先用图形表示一下：

回收内存块
超大块内存
       现在要申请的内存块

上面的意思是：我们在服务器启动过程中就为自己申请一块比较大的内存块，而我们在服务器运行过程中需要使用内存我们就到这样一块比较大已经申请好的内存块中去取。而使用完后要进行回收。原理就是这么简单。而最重要的是我们如何管理这个大的内存块呢？
（非常复杂也比较难，呵呵）
首先 就内存块操作而言就只有申请（类似 new）和回收（类似 delete）。
其次 我们必须要清楚那些内存我们在使用中，那些是可以申请的。

关于上面我简单将这样的一些数据结构和class定义在下面供大家参考使用。

   typedef  struct  MemoryBlock           //内存块结构
{
    void  *buffer;                      //内存块指针
    int    b_Size;                      //内存块尺寸
} MemoryBlock;

class   CMemoryList                  //列表对象类（相当于数组管理类）
{
    public:
        CMemoryList();
        virtual ~ CMemoryList();
        void   InitList(int  data_size,int data_num);//初始化列表数据结构尺寸和数量
        void   AddToList(void *data);           //加入列表中
        void   DeleteItem(int index);            //删除指定索引元素
……………..
private:
    void   Init();
    void   Release();
private:
    void  *memory;
int    total_size;
int    total_num;
    protected:
};

classs   CMemoryPool                                   //内存池处理类
{
    public:
        CMemoryPool(); 
        virtual ~ CMemoryPool();
        bool   InitMemoryPool(int  size);                 //初始化内存池
void *  ApplicationMemory(int size);               //申请指定size内存
void   CallBackMemory(void *,int size);            //回收指定size内存

    private:
        void   Init();
        void   Release():
        MemoryBlock  *UniteMemory(MemoryBlock  *block_a，MemoryBlock  * block_b);                                                  //合并内存

    private:
       MemoryBlock  memoryPool_Block;                 //内存池块
       CMemoryList  *callBackMemory_List;              //回收内存列表
       CMemoryList  *usingMemory_List;                 //使用中内存列表
       CMemoryList  *spacingMemory_List;               //空白内存列表
    protected:
};

以上就是这个内存管理类的一些基本操作和数据定义，class  CMemoryList  在这里不是重点暂且就不说了，有空再聊。而具体的内存池处理方法简单叙述如下：

   函数InitMemoryPool（）：  初始化申请一块超大内存。
   函数ApplicationMemory（）：申请指定尺寸，申请内存成功后，要将成功申请的内存及其尺寸标示到usingMemory_List列表，同时要将spacingMemory_List列表进行重新分配。以便于正确管理。
   函数CallBackMemory（）：回收指定尺寸内存，成功回收后，要修改spacingMemory_List列表，同时如果有相邻的内存块就要合并成一个大的内存块。usingMemory_List修改使用列表，要在使用列表中的这一项删除。

以上就是一些简单处理说明，更加详细的就需要大家自己琢磨和处理了。我就不细说了。呵呵。不足之处就请大家进行指正，以便让我们大家都提高。先谢谢了。

续上在上面我简单的说了一下服务器完成端口处理部分，接下来我想大家介绍一下关于如何建立服务器和客户端的联系规则，也就是服务器和客户端的游戏协议部分。有不足之处希望大家和我进行交流。

首先解释一下这里协议的概念，协议大家都了解是一种通信规则，例如：TCP/IP，UDP等等，这些是我们在网络通信过程中所处理使用的协议。而我们这里的协议是我们的游戏服务器和客户端的通信规则。简而言之，也就是客户端发送到服务器的数据包和服务器发送的数据包双方解释规则。下面就通过几个部分来具体介绍这种协议的建立和处理。

消息头定义

如果我们能够解释双方的数据包的意义，我们就必须为双方数据包定义一个统一规则的消息头，我是这么定义消息头的。服务器数据包和客户端数据包分别定义不同的消息头。以下就是双方消息头的简单定义。

struct    ServerMsg_Head             //服务器消息头
{
   WORD  s_version;                //版本信息
   BYTE   s_flages;                 //消息标志
   BYTE   s_who;                  //消息驱动者
   BYTE   s_sort;                   //消息类别
   BYTE   s_value;                 //消息值
   WORD  s_len;                   //消息长度
} ;

struct    ClientMsg_Head             //客户端消息头
{
   WORD  c_version;                //版本信息
   WORD  c_flages                  //消息标志
   WORD  c_sort;                   //消息类别
   WORD  c_value;                  //消息值
   WORD  c_scene;                  //场景信息
   WORD  c_len;                    //消息长度
};

以上是我个人简单定义的消息头，具体的各个参数意义，就是需要规划设计的人来定了。这些我就不多说了。

在我们处理完我们的消息头后，我们就可以将我们的具体游戏数据进行打包。关于数据打包，我们必须要处理两件事情：数据打包，数据加密。为此我就建立相应的class来处理这样的一些操作。DataCtrl.h处理如下：

class  Ppackage类可以拆解为两个单独处理类，打包类和解包类。而此处我就用下面一个类来进行处理。只是给大家开个头，要设计的更好还是靠大家共同来进行斟酌呀！！

class   PPackage                                   //游戏数据包处理类
{
public:
PPackage(BYTE msg_type);                      //设置所打包消息类型
virtual ~PPackage();
//消息数据打包部分
void  SetMsgHead(void  *);                    //设置消息头
void  AddByte(BYTE  data);                   //加入一字节
void  AddWord(WORD  data);                 //加入二字节
void  AddDword(DWORD  data);               //加入四字节
void  AddPoint(POINT  data);                  //加入八字节
void  AddBuf(char * data ,int  data_len);          //加入多个字节
//消息内容获取
void  FinishPack();                            //完成打包
char  *GetPackage();                           //获取数据包
int   GetPacketLen();                          //获取数据包长度

//消息数据解包部分
void     SetMsgPackage(char *buf,int _Len);       //将获取消息进行录入
void    *GetMsgHead();                        //获取消息头数据
BYTE   GetByte();                            //获取一字节
WORD  GetWord();                            //获取二字节
DWORD GetDword();                           //获取三字节
POINT * GetPoint();                            //获取四字节
char  *  GetBuf(int buf_len);                    //获取多字节
bool     IfFinishGet();                         //是否完成解包

private: 

void     Init();
void     Release();
void     StartBindPakage();       //开始打包
void     StartUndoPackage();     //开始解包
    bool     MessageEncrypt();       //消息加密
    bool     MessageUndo();         //消息解密

private:

private:
    BYTE   msg_type;               / /{1-SERVER_PACKAGE=1,2-CLIENT_PACKAGE=2}
char  *  msg_buffer;
char  *  buffer;                 //后备缓冲区
int      msg_len;
//消息内容长度
Server_Msg_Head  msg_Head;     //消息头
int      buf_Len;
int      current_pos;             //指针的当前位置
protected:
};

以上就是关于服务器和消息打包类的一些建立和解释，这些方面知识其实也没有什么，主要是“仁者见仁，智者见智”了。而对于网络游戏的制作最重要的还是在于Game World的规划和设计，同时这个方面也是最难和最不好处理的。随后将和大家进行探讨。。

1．网络通信模块
2．协议模块
3．线程池模块
4．内存管理模块
5．游戏规则处理模块
6．后台游戏仿真世界模块。

现在就网络中的通信模块处理谈一下自己的看法！！

在网络游戏客户端和服务器端进行交互的双向I/O模型中分别有以下几种模型：
1． Select模型
2． 事件驱动模型
3． 消息驱动模型
4． 重叠模型
5． 完成端口重叠模型。
在这样的几种模型中，能够通过硬件性能的提高而提高软件性能，并且能够同时处理成千上百个I/O请求的模型。服务器端应该采用的最佳模型是：完成端口模型。然而在众多的模型之中完成端口的处理是最复杂的，而它的复杂之处就在于多服务器工作线程并行处理客户端的I/O请求和理解完成端口的请求处理过程。
对于服务器端完成端口的处理过程总结以下一些步骤：
1． 建立服务器端SOCKET套接字描述符，这一点比较简单。
例如：
SOCKET  server_socket;
Server_socket = socket(AF_INET,SOCK_STREAM,0);
2.绑定套接字server_socket。
    Const int SERV_TCP_PORT = 5555;
    struct sockaddr_in  server_address.
    
memset(&server_address, 0, sizeof(struct sockaddr_in));
    server_address.sin_family      = AF_INET;
    server_address.sin_addr.s_addr = htonl(INADDR_ANY);
    server_address.sin_port        = htons(SERV_TCP_PORT);
//绑定
Bind（serve_socket,( struct sockaddr *)&server_address, sizeof(server_address)）；

2． 对于建立的服务器套接字描述符侦听。
Listen(server_socket ,5);
3. 初始化我们的完成端口，开始的时候是产生一个新的完成端口。

   HANDLE  hCompletionPort;
   HCompletionPort = CreateIoCompletionPort(NULL,NULL,NULL,0);
4. 在我们已经产生出来新的完成端口之后，我们就需要进行系统的侦测来得到系统的硬件信息。从而来定出我们的服务器完成端口工作线程的数量。

SYSTEM_INFO   system_info;
GetSystemInfo(&system_info);

在我们知道我们系统的信息之后，我们就需要做这样的一个决定，那就是我们的服务器系统该有多少个线程进行工作，我一般会选择当前处理器的2倍来生成我们的工作线程数量（原因考虑线程的阻塞，所以就必须有后备的线程来占有处理器进行运行，这样就可以充分的提高处理器的利用率）。
代码：
WORD threadNum = system_info. DwNumberOfProcessors*2+2;
for(int i=0;I{
    HANDLE  hThread;
    DWORD    dwthreadId;
    hThread = _beginthreadex(NULL,ServerWorkThrea, 
(LPVOID)hCompletePort,0,&dwthreadId);
        CloseHandle(hThread);         
}
CloseHandle(hThread)在程序代码中的作用是在工作线程在结束后，能够自动销毁对象作用。
6． 产生服务器检测客户端连接并且处理线程。

HANDLE  hAcceptThread;
DWORD   dwThreadId;
hAcceptThread= _beginthreadex(NULL,AcceptWorkThread,NULL,
&dwThreadId);
CloseHandle(hAcceptThread);

7.连接处理线程的处理，在线程处理之前我们必须定义一些属于自己的数据结构体来进行网络I/O交互过程中的数据记录和保存。

首先我要将如下几个函数来向大家进行解析：
1.
HANDLE CreateIoCompletionPort (
      HANDLE FileHandle,              // handle to file
      HANDLE ExistingCompletionPort,  // handle to I/O completion port
      ULONG_PTR CompletionKey,        // completion key
      DWORD NumberOfConcurrentThreads // number of threads to execute concurrently
);
参数1：
可以用来和完成端口联系的各种句柄，在这其中可以包括如下一些：
套接字，文件等。

参数2：
已经存在的完成端口的句柄，也就是在第三步我们初始化的完成端口的句柄就可以了。

参数3：
这个参数对于我们来说将非常有用途。这就要具体看设计者的想法了， ULONG_PTR对于完成端口而言是一个单句柄数据，同时也是它的完成键值。同时我们在进行
这样的GetQueuedCompletionStatus（….）(以下解释)函数时我们可以完全得到我们在此联系函数中的完成键，简单的说也就是我们在CreateIoCompletionPort(…..)申请的内存块，在GetQueuedCompletionStatus(……)中可以完封不动的得到这个内存块，并且使用它。这样就给我们带来了一个便利。也就是我们可以定义任意数据结构来存储我们的信息。在使用的时候只要进行强制转化就可以了。

参数4：
引用MSDN上的解释
[in] Maximum number of  threads that the operating system allows to concurrently process I/O completion packets for the I/O completion port. If this parameter is zero, the system allows as many concurrently running threads as there are processors in the system.
这个参数我们在使用中只需要将它初始化为0就可以了。上面的意思我想大家应该也是了解的了！嘿嘿！！

我要向大家介绍的第二个函数也就是
2.
BOOL GetQueuedCompletionStatus(
    HANDLE CompletionPort,       // handle to completion port
    LPDWORD lpNumberOfBytes,     // bytes transferred
    PULONG_PTR lpCompletionKey,  // file completion key
    LPOVERLAPPED *lpOverlapped,  // buffer
    DWORD dwMilliseconds         // optional timeout value
);
参数1：
我们已经在前面产生的完成端口句柄，同时它对于客户端而言，也是和客户端SOCKET连接的那个端口。

参数2：
一次完成请求被交换的字节数。（重叠请求以下解释）

参数3：
完成端口的单句柄数据指针，这个指针将可以得到我们在CreateIoCompletionPort（………）中申请那片内存。
借用MSDN的解释：
[out] Pointer to a variable that receives the completion key value associated with the file handle whose I/O operation has completed.A completion key is a per-file key that is specified in a call to CreateIoCompletionPort.
所以在使用这个函数的时候只需要将此处填一相应数据结构的空指针就可以了。上面的解释只有大家自己摆平了。

参数4：
重叠I/O请求结构，这个结构同样是指向我们在重叠请求时所申请的内存块，同时和lpCompletionKey,一样我们也可以利用这个内存块来存储我们要保存的任意数据。以便于我们来进行适当的服务器程序开发。
[out] Pointer to a variable that receives the address of the OVERLAPPED structure that was specified when the completed I/O operation was started.（MSDN）

3．
int WSARecv(
    SOCKET s,                                               
    LPWSABUF lpBuffers,                                     
    DWORD dwBufferCount,                                    
    LPDWORD lpNumberOfBytesRecvd,                           
    LPDWORD lpFlags,                                        
    LPWSAOVERLAPPED lpOverlapped,                           
    LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine  
);
这个函数也就是我们在进行完成端口请求时所使用的请求接受函数，同样这个函数可以用ReadFile(………)来代替，但不建议使用这个函数。

参数1：
已经和Listen套接字建立连接的客户端的套接字。

参数2：
用于接受请求数据的缓冲区。
[in/out] Pointer to an array of WSABUF structures. Each WSABUF structure contains a pointer to a buffer and the length of the buffer.（MSDN）。
参数3：
参数2所指向的WSABUF结构的数量。
[in] Number of WSABUF structures in the lpBuffers array.（MSDN）

参数4：

[out] Pointer to the number of bytes received by this call if the receive operation completes immediately. （MSDN）

参数5：
[in/out] Pointer to flags.（MSDN）
参数6：

这个参数对于我们来说是比较有作用的，当它不为空的时候我们就是提出我们的重叠请求。同时我们申请的这样的一块内存块可以在完成请求后直接得到，因此我们同样可以通过它来为我们保存客户端和服务器的I/O信息。
参数7：
[in] Pointer to the completion routine called when the receive operation has been completed (ignored for nonoverlapped sockets).（MSDN）
4．
int WSASend(
    SOCKET s,                                               
    LPWSABUF lpBuffers,                                     
    DWORD dwBufferCount,                                    
    LPDWORD lpNumberOfBytesSent,                            
    DWORD dwFlags,                                          
    LPWSAOVERLAPPED lpOverlapped,                           
    LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine  
);
参数解释可以参考上面或者MSDN。在这里就不再多说了。

下面就关client端用户连接（connect（……..））请求的处理方式进行

举例如下：
const int BUFFER_SIZE = 1024;
typedef  struct  IO_CS_DATA
{
   SOCKET  clisnt_s;         //客户端SOCKET
   WSABUF  wsaBuf;     
   Char   inBuffer[BUFFET_SIZE];
   Char   outBuffer[BUFFER_SIZE];
   Int     recvLen;
   Int     sendLen;
   SYSTEM_TIME start_time;
   SYSTEM_TIME start_time;
}IO_CS_DATA;

UINT WINAPI  ServerAcceptThread(LPVOID param)
{
SOCKET  client_s;
HANDLE  hCompltPort = (HANDLE) param;
struct sockaddr_in  client_addr;
int addr_Len = sizeof(client_addr);
    LPHANDLE_DATA  hand_Data = NULL;  
while(true)
{
   If((client_s=accept(server_socket,NULL,NULL))
==SOCKET_ERROR)
{
printf("Accept() Error: %d",GetLastError());
return 0;
}
hand_Data = (LPHANDLE_DATA)malloc(sizeof(HANDLE_DATA));
hand_Data->socket = client_s;
if(CreateIoCompletionPort((HANDLE)client_s,hCompltPort,
(DWORD)hand_Data,0)==NULL)
{
printf("CreateIoCompletionPort()Error: %d",
GetLastError());
}
else
{ 
game_Server->RecvDataRequest(client_s);
}
}
return  0;
}

在这个例子中，我们要阐述的是使用我们已经产生的接受连接线程来完成我们响应Client端的connect请求。关于这个线程我们同样可以用我们线程池的方式来进行生成多个线程来进行处理，其他具体的函数解释已经在上面解释过了，希望不懂的自己琢磨。
关于game_Sever object的定义处理将在下面进行介绍。

class   CServerSocket : public CBaseSocket
{
public:
CServerSocket();
virtual ~CServerSocket();
bool   StartUpServer();                  //启动服务器
void   StopServer();                     //关闭服务器
//发送或者接受数据（重叠请求）
bool    RecvDataRequest(SOCKET client_s);     
   bool    SendDataRequest(SOCKET client_s,char *buf,int b_len);

   void    ControlRecvData(SOCKET client_s,char *buf,int b_len);

void    CloseClient(SOCKET client_s);  
private:
friend  UINT WINAPI GameServerThread(LPVOID completionPortID);          //游戏服务器通信工作线程
private:
void   Init();
void   Release();
    bool   InitComplePort();
bool   InitServer();
bool   CheckOsVersion();
bool   StartupWorkThread();
bool   StartupAcceptThread();
private:
enum   { SERVER_PORT = 10006};
UINT   cpu_Num;        //处理器数量
    CEvent g_ServerStop;   //服务器停止事件
CEvent g_ServerWatch;  //服务器监视事件
public:
HANDLE hCompletionPort;     //完成端口句柄
};

在上面的类中，是我们用来处理客户端用户请求的服务器端socket模型。