白云哥

　　有段时间没有研究技术了，这次正好看到了新版的mangos，较之以前我看的版本有了比较大的完善，于是再次浏览了下他的代码，也借此机会整理下我在游戏服务器开发方面的一些心得，与大家探讨。　　另外由于为避免与公司引起一些不必要的纠纷，我所描述的全都是通过google能够找到的资料，所以也可以认为我下面的内容都是网上所找资料的整理合集。在平时的开发中我也搜索过相关的中文网页，很少有讲游戏服务器相关

　　有关State模式的设计意图及实现就不从设计模式中摘抄了，我们只来看看游戏服务器编程中如何使用State设计模式。　　首先还是从mangos的代码开始看起，我们注意到登录服在处理客户端发来的消息时用到了这样一个结构体：　　struct AuthHandler　　{　　　　eAuthCmd cmd;　　　　uint32 status;　　　　bool (AuthSocket::*hand

      关于这一节，这几天已经打了好几遍草稿，总觉得说不清楚，也不好组织这些内容，但是打铁要趁热，为避免热情消退，先整理一点东西放这，好继续下面的主题，以后如果有机会再回来完善吧。本节内容欠考虑，希望大家多给点意见。       有些类似于QT中的event与signal，我将一些动作请求消息定义为事件，而将状态改变消息定义为信号。比如在QT应用程序中，用户的一次鼠标点击会产生一个鼠标点击

    离我们的登录服实现已经太远了，先拉回来一下。        关于登录服、大区服及游戏世界服的结构之前已做过探讨，这里再把各自的职责和关系列一下。        GateWay/WorldServer   GateWay/WodlServer  LoginServer LoginServer DNSServer WorldServerMgr                |       

1. Introduction简介 The Saga of Ryzom is a persistent massively-multiplayer online game (MMORPG) released in September 2004 throughout Europe and North America, localised in 3 languages so far. It

有关位置同步的方案实际上已经比较成熟，网上也有比较多的资料可供参考。在《带宽限制下的视觉实体属性传播》一文中，作者也简单提到了位置同步方案的构造过程，但涉及到细节的地方没有深入，这里专门针对这一主题做些回顾。 最直接的同步方案就是客户端在每次发生位置改变时都向服务器报告 ，服务器再转发给周围的其他玩家，其他客户端将对应的游戏实体移动到新的位置上。 但是这样存在一个问题，每个玩家的位

在服务器组的架构下，我们一般会引入一个网关服务器，或类似功能的组件，所有的客户端连接都是到这里，数据然后转发给当前所在的地图服务器。 这样，在数据广播时便存在一个很大的优化可能性。以前的单服务器架构时，比如要广播移动消息，可以直接找出周围的玩家列表，构造要发送的数据，然后依次调用send即可。但是在多服务器架构下要是还这么做的话，那地图服务器与网关服务器之间的数据传输量将会非常大，而且这些

　　找了下，网上关于这方面的资料大多是讲随机迷宫生成算法的，但是MMO中的地下城不仅仅是迷宫这么简单，不是只要生成一条或多条通路就算完成，还包括怪物的摆放，一些事件触发器类物件的摆放，地表景观类物件的摆放，还有地表Tile块的指定等。就生成的通路来说，也不可能只有一种简单的石头地形，或者全是沙地路，而在遇到拐弯或小坡小坎的地形时，地形块的指定会更加的复杂。　　当然，这些问题都可以通过技术手段一

      最近一段时间在设计新项目的服务器架构，以及服务器基础模块和框架代码的编写，目前已基本成型。     这次是完完全全从头开始按照自己的想法来设计整个服务器的实现，经过前三年两三个项目的积累，或多或少对服务器架构及实现有了些自己的想法，包括以前觉得做的不够好，不够合理，但又无法彻底去改变的地方，这次有了机会来做一个全新的尝试。    每天都在给自己讲一些理由，分析出每个模块，每种方

  我不得不承认，我的能力不足以写出一个100%不会宕机的游戏服务器程序，这也不能全怪我的能力太弱，谁让咱国内网游玩家数量庞大，哪个游戏刚上线时没有挤的爆满过？还有些或是猎奇，或是谋私的个人和组织，在制造着千奇百怪，匪夷所思的数据包及操作流程来试探你的服务器。这些都曾是我在服务器宕机后向老板开脱的理由。 当WOW终于来到中国时，我一边欣喜着终于可以在艾泽拉斯的大陆上自由翱翔，一边却

    总体来说,如果是想做一个比较简单的虚拟现实服务,拿sfs来做还是很方便的,省去了前期构造服务器网络,实现数据库接口,数据同步等等一些基础功能的时间,可以一上来就直奔主题,开发自己项目相关的功能.     Sfs的接口封装也比较简单,基本上看到接口名就能知道是做什么用的,参数是什么意义,而且他的文档也比较详细,对于非服务器开发专业人员也比较方便.sfs的定义也主要在此,比如他最早支持的flash客户端api.     而随着sfs的成功,也开始将目标转向了目前新兴的iphone, an

 　　消息队列锁调用太频繁的问题算是解决了，另一个让人有些苦恼的大概是这太多的内存分配和释放操作了。频繁的内存分配不但增加了系统开销，更使得内存碎片不断增多，非常不利于我们的服务器长期稳定运行。也许我们可以使用内存池，比如SGI STL中附带的小内存分配器。但是对于这种按照严格的先进先出顺序处理的，块大小并不算小的，而且块大小也并不统一的内存分配情况来说，更多使用的是一种叫做环形缓冲区的方案，ma

　　既然说到了消息队列，那我们继续来稍微多聊一点吧。　　我们所能想到的最简单的消息队列可能就是使用stl的list来实现了，即消息队列内部维护一个list和一个互斥锁，putMessage时将message加入到队列尾，getMessage时从队列头取一个message返回，同时在getMessage和putMessage之前都要求先获取锁资源。　　实现虽然简单，但功能是绝对满足需求的，只

　　所谓服务器结构，也就是如何将服务器各部分合理地安排，以实现最初的功能需求。所以，结构本无所谓正确与错误；当然，优秀的结构更有助于系统的搭建，对系统的可扩展性及可维护性也有更大的帮助。　　好的结构不是一蹴而就的，而且每个设计者心中的那把尺都不相同，所以这个优秀结构的定义也就没有定论。在这里，我们不打算对现有游戏结构做评价，而是试着从头开始搭建一个我们需要的MMOG结构。　　对于一个最简单

　　回想一下我们在玩wow时的操作流程：运行wow.exe进入游戏后，首先就会要求我们输入用户名和密码进行验证，验证成功后才会出来游戏世界列表，之后是排队进入游戏世界，开始游戏...　　可以看到跟前面的描述有个很明显的不同，那就是要先验证帐号再选择游戏世界。这种结构也就使得登录服不是固定配备给个游戏世界，而是全区共有的。　　我们可以试着从实际需求的角度来考虑一下这个问题。正如我们之前所描述

　　讨论了这么久我们一直都还没有进入游戏世界服务器内部，现在就让我们来窥探一下里面的结构吧。　　对于现在大多数MMORPG来说，游戏服务器要处理的基本逻辑有移动、聊天、技能、物品、任务和生物等，另外还有地图管理与消息广播来对其他高级功能做支撑。如纵队、好友、公会、战场和副本等，这些都是通过基本逻辑功能组合或扩展而成。　　在所有这些基础逻辑中，与我们要讨论的服务器结构关系最紧密的当属地图管理

　　再强调一下，服务器结构本无所谓好坏，只有是否适合自己。我们在前面探讨了一些在现在的游戏中见到过的结构，并尽我所知地分析了各自存在的一些问题和可以做的一些改进，希望其中没有谬误，如果能给大家也带来些启发那自然更好。　　突然发现自己一旦罗嗦起来还真是没完没了。接下来先说说我在开发中遇到过的一些困惑和一基础问题探讨吧，这些问题可能有人与我一样，也曾遇到过，或者正在被困扰中，而所要探讨的这些基础问

　　都已经看出来了，这种每切换一次地图就要重新连接服务器的方式实在是不够优雅，而且在实际游戏运营中也发现，地图切换导致的卡号，复制装备等问题非常多，这里完全就是一个事故多发地段，如何避免这种频繁的连接操作呢？　　最直接的方法就是把那个图倒转过来就行了。客户端只需要连接到中心服上，所有到地图服务器的数据都由中心服来转发。很完美的解决方案，不是吗？　　这种结构在实际的部署中也遇到了一些挑战。对

　　正如我们在前面曾讨论过的，登录服要实现的功能相当简单，就是帐号验证。为了便于描述，我们暂不引入那些讨论过的优化手段，先以最简单的方式实现，另外也将基本以mangos的代码作为参考来进行描述。　　想象一下帐号验证的实现方法，最容易的那就是把用户输入的明文用帐号和密码直接发给登录服，服务器根据帐号从数据库中取出密码，与用户输入的密码相比较。　　这个方法存在的安全隐患实在太大，明文的密码传输

　　如果我们就此打住，可能马上就会有人要嗤之以鼻了，就这点古董级的技术也敢出来现。好吧，我们还是把之前留下的问题拿出来解决掉吧。　　一般来说，当某一部分能力达不到我们的要求时，最简单的解决方法就是在此多投入一点资源。既然想要更多的连接数，那就再加一台网关服务器吧。新增加了网关服后需要在大区服上做相应的支持，或者再简单点，有一台主要的网关服，当其负载较高时，主动将新到达的连接重定向到其他网关服上

　　当阅读一项工程的源码时，我们大概会选择从main函数开始，而当开始一项新的工程时，第一个写下的函数大多也是main。那我们就先来看看，游戏服务器代码实现中，main函数都做了些什么。　　由于我在读技术文章时最不喜看到的就是大段大段的代码，特别是那些直接Ctrl+C再Ctrl+V后未做任何修改的代码，用句时髦的话说，一点技术含量都没有！所以在我们今后所要讨论的内容中，尽量会避免出现直接的代码

　　前面我们只简单了解了下mangos登录服的程序结构，也发现了一些不足之处，现在我们就来看看如何提供一个更好的方案。　　正如我们曾讨论过的，为了游戏主逻辑循环的流畅运行，所有比较耗时的IO操作都会分享到单独的线程中去做，如网络IO，数据库IO和日志IO等。当然，也有把这些分享到单独的进程中去做的。　　另外对于大多数服务器程序来说，在运行时都是作为精灵进程或服务进程的，所以我们并不需要服务

　　前面一直都在说接收数据时的处理方法，我们应该用专门的IO线程，接收到完整的消息包后加入到主线程的消息队列，但是主线程如何发送数据还没有探讨过。　　一般来说最直接的方法就是逻辑线程什么时候想发数据了就直接调用相关的socket API发送，这要求服务器的玩家对象中保存其连接的socket句柄。但是直接send调用有时候有会存在一些问题，比如遇到系统的发送缓冲区满而阻塞住的情况，或者只发送了一

    在GameLook上看到一则新闻，说是完美研发出了一个名叫AX的系统，从评论上看评价挺高，于是找过去看了下。新闻地址在这里：http://www.wanmei.com/news/company/20101122/74306.shtml。     其中关于技术部分的内容摘录如下： “ 网络游戏的服务器大多采用多线程Distributed system模式，利用Thread编程处理数据，在利用CPU空闲时间的同时提高游戏运行效率。然而在多道Process指令下，程序会相互制约，隔断进程间实时通信，