romandion的专栏

http://www.cppblog.com/Fox/archive/2007/12/16/game_world_architecture.html Author: Fox一个MMORPG（Massively Multiplayer Online Role Playing Game）的架构包含客户端和服务器两部分。客户端主要涉及计算机图形学、物理学、多媒体技术等

地图数据在MMO中占据重要的位置，不但数据量大，还具有基础性地位。在魔兽世界中，地图数据分布于几个mpq文件中，一般说来，他存在于mpq内部目录/world/maps/下，而maps也会被划分成多个目录，比如东部王国和卡里姆多。每个地图中，都会有一个wdt和多个adt文件构成，实际上，还有一个wdl文件，只是tc2中没有提到，估计是文件列表。每个wdt文件被划分成64×64个格子（GR

以前介绍了TDB0.0.5的渊源，现在继续介绍TDB内部的一些细节。从[TC2 wiki]可以查到TDB_0.0.5结构比较详细的介绍。在一个完整的TDB_0.0.5的MYSQL安装库中，你可以看到已经安装的库包括：1、realmd；2、characters；3、world。realmd库的表比较少，主要是realmlist和account比较重要，realmcharacters主要记

上次简单介绍了下trinity-realm的概况，现在开始介绍trinity-core。这部分是trinity core2的重要部分，完成绝大部分的工作。trinity-core的构成十分复杂，我们首先摒除和业务逻辑相关部分，首先介绍下他的主要构成。1、网络部分，这部分他是使用现成的ACE框架。2、地图部分，这个部分有2块，一个是从mpq中导出的map文件，居多。另外一个似乎是trinit

trinity core2是由trinity组织的项目，我想在他们基础上衍生一个新的版本。不过这个新版本不可能提交到他们的公共库，同时又要获取他们的更新，这是个挑战。经过研究之后，我最后决定采用git来干这活。大概方法如下：1、$ hg clone https://dev.trinitycore.org/trinitycore2/ 从官方获取最新的版本到本地2、使用 git d

【http://www.mgcore.com/redirect.php?fid=21&tid=31243&goto=nextnewset】   MANGOS源码连接地址MaNGOS 项目源代码git地址：    git clone git://github.com/mangos/mangos.gitMaNGOS 项目源代码SVN地址：    svn://svn.mgco

TDB_0.0.5 ，又叫【Phoenix】是配合trinitycore2的数据库，他的官方网站在【http://www.trinitydatabase.org/】，下载地址在【http://svn.assembla.com/svn/trinitydatabase/trunk/】，wiki【http://trinitycore.info/w/Main_Page】。从作者对他的描述，我们

trinitycore2从【http://dev.trinitycore.org/trinitycore2】下载。配合Mysql + TDB【http://svn.assembla.com/svn/trinitydatabase/trunk/】就可以自己开个3.1.3的魔兽私服玩玩。如果谁有兴趣，可以私下交流。 trinitycore2的架构主要包括trinity-realm和tr

http://www.cppblog.com/Jedimaster/archive/2006/10/14/13674.aspx  Wow 服务器解析（一）        最近抽空研究了一下 WOW 的服务器结构，也顺便从那些项目中又复习了一下 ManGOs 中

trinity core2的主要工作进程是trinity-core，他实际上扮演的是一个服的作用。一个进程带多个线程的架构。本篇主要介绍每个线程的作用，以及相互之间的关联。1、主线main.cpp，主线程main函数完成配置信息读取之后，会启动sMaster，sMaster不是线程，他实际是工作逻辑总体框架的封装。主线程的循环在sMaster.Run()中实现。2、sMaster是个单

假设世界突然静止，你能够从中单独去掉的物体就是构成这个世界的对象，包括玩家、怪物、武器、矿石等。魔兽世界是个大型的网游，里面的种类十分丰富，更不用说对象了。当我看着trinity-core2的源码中，game目录的时候，有种傻眼的感觉，实在太多了。为了理解方便，我们抽丝剥茧，分析出类的继承关系。在tc2中，所有的对象都被认为是object，以object作为基类，以1.2.3格式表示继承关系，

系统重演是服务系统一个很重要的特性，但基本上很难。除了某些对系统可靠性要求很高的系统，比如交易系统。系统重演就像魔法时光回溯那样，将所有的过程不失真的完全执行一遍。这是个理想状态，但最大可能性的重演具有很高的意义，我希望能在单一世界中，实践这个特性。我们首先界定下，什么是系统重演。我们认为对于系统，任何时间，任何环境下，只要相同的输入，都会得到相同的结果，那么，这个过程就是系统重演。这个定义借

请求代理相当于网关或者是前置机，负责接收客户端的请求报文。为了兼容原来的服务器，必须开发一个代理，负责解析报文以及做部分分发，允许将部分功能转到接新的服务模块。单一世界本身的通讯量非常大，因此，完全依靠单一服务器来接收请求是不合理。这也是为何必须开发请求代理的原因。另外一个原因是，我认为系统的升级和变更应该是渐进式，将新系统融入并逐步替换旧系统。因为，旧系统虽然存在许多问题，但已经稳定地运行了

我们知道，报文在网络上的流转主要是以二进制方式传输，而报文具体的含义依赖于收发双方的私有约定。而XML设计于一种通用标准，在业务上具有更广泛的适用性，但其解析上有较高的复杂度，带来性能损失。我们需要设计一种高效、简单、更强业务描述能力的报文协议，显然，在报文定义具体业务含义的内容是不可行的。我将这个报文协议命名为GEST协议，全称是A GENERAL 、 EFFICIENT 、SIMPLE TRA

单一世界的构想和规划，已经准备了很多时间。虽然，理论上已经有了雏形，不过实践上，依然要依赖于魔兽世界的私服来实现。后面相关内容都将围绕这个主题展开。我将这个系统命名为Single World，依照传统，简称为S端。从现有端的构成上，基本分成：1、基础库，比如ACE 、SSL等；2、基础架构、如地图等；3、游戏逻辑；4、数据库；5、人工智能。让我从头开始，显然出成果会是很遥远的未来，因此，我必须

隔了很长一段时间没有写魔兽世界私服trinitycore2的架构分析，现在重新开始写，也许是最后一章了。其实个人感觉剩下应该都是比较琐碎的细节了。人工智能在一个大型网游系统中，是很重要的部分。在trinitycore2中，人工智能有2个重要分支，一个分支是数据库化的，将每个步骤作为一个命令，而输入参数就作为一个记录的字段，这种方式在很多地方都被使用。另外一个是事件化，针对不同的事件接口，做出不同的

 TC2中，很多是通过script来完成。这个script和我们通常意义上的脚本有很大的不同，但他完成了许多功能，不可或缺。首先，要看下ScriptMgr.h中，Script的定义，他主体是有很多回调函数构成的，如：    bool (*pItemUse             )(Player*, Item*, SpellCastTargets const& );显然，这是在用户使用

 T端的原文是英文的，但T端库本身是支持国际化。我在（6）中介绍了国际化机制。现在，我提供一种方案，能够自动从M端，或者其他T端中导入他们的汉化成果。而且，即使你用sql/FULL覆盖掉原来的库，也能够保证很快的还原。首先，我提供一个SQL脚本：1、《T端国际化建库.sql》，这个脚本创建了locale库，以及他需要的表，主要有2种，一个类似item_template表，里面有entry/

 在T端中，是由数据库保存终端的显示信息，比如物品的名称。默认情况下，他们是enUS英文的。不过，我们需要将他们修改为中文模式。在芒果以及国内比较著名的私服中，都是直接在原地修改的，我原来也是。不过后来发现这样很容易出错，所以仔细研究了下T端的初始化过程，发现了很多有趣的事情。下面，我们先描述下这个过程：1、客户端在登录认证的时候，会提供一个国家代号，uint8[4]，比如：    enU

单一世界的服务部署有很大的讲究。我曾经在论坛上提到过大分布小集群的概念，就是跟服务器部署有关系。我们知道，单一世界会遭遇很大的网络流量和用户数，使用集群只能解决计算能力，却解决不了网络流量。我们如果将所有的地图集中放在中国某地的一个集群中，那么该集群将承受巨大的带宽压力。和http不同的是，单一世界是持续性的网络流量。我们以中国区为例，我在各个省放置一个集群，然后在北京、上海、广州各放置一个中

和其他网游不同的是，单一世界具有庞大的地图，比如一个地球，这种情况和导致地图的数据量很大，几个G都是正常的事情。在这种情况下，处理策略有很大的不同。以魔兽世界为例，所有的客户端和服务端都有相同的地图，这样保证在设计地图的计算时，不需要从服务端得到地图数据，减少数据传输量。在第二人生和激战中，有些不同，本地没有全部的地图。激战在跳跃到新的地方时，需要有个很长的延时，似乎是从服务端读取地图数据。

由于分区计算，所以相邻区之间的冲突问题解决是很关键的，不论是静态分区，还是动态分区。边界冲突的核心是由于分区引起的。当一个逻辑上独立的实体跨在分区的边界上，那么，从分区的理论上，就会导致该实体被硬性的分割为2个实体。其中一个分区为计算该实体的行为时，比如走动，那么他就必须同时获取另外一个分区中，该实体的状态；而另外一个分区遇到的也是同样的问题，这就是产生了边界冲突。表现的连续性要求和实现的分区技术

静态分区，让每个服务器负责特定区域，技术上相对简单；而动态分区实际上更接近于集群技术，按照负载自动调整区域，但技术更加复杂。上面所论述的计算迁移就是为了讨论动态分区做的准备。在魔兽世界中，暴风城和闪金镇是2个典型，暴风城是个主城，人多、地形复杂，而闪金镇周围都是森林，人也多是匆匆过客，除了少数升级做任务。一般说来，我们可以拿2个服务器，一个负责暴风城，而另外一个负责闪金镇。显然，这种划

海量在线，意味着海量的数据，比如10M的在线人员的个人资料。如果处理呢？依赖数据库可不行，那肯定被拉死了。更可怕的是，所有的数据还必须是实时的。当一个人从地上捡取一个金币的话，那么他的金币总额必然要增加。这个稍微简单点，因为只要在原有数据上加个值就可以了。但是，他要是捡取一个设备时，稍微要复杂点。因为要添加这个设备的部分属性到该角色上。还有更复杂的是，即时战斗中，生命或者魔法值都必须在很短时间内被

现在我们进入实质性的探讨阶段，首先是登录管理。单一世界中海量在线数是个很重要的问题。多数架构都是用代理服务器来分散连接，这里提供一个方法，既能满足海量连接，还能实现单点登录，细节看了再说。单点登录，意味着，所有的请求都将被一个IP处理。而海量请求，意味着所有的登录管理都会在一个IP的完成，天啦，如果到了10M那是什么概念。即使1M/S的处理速度，也要10S才能完成一个登录管理，那我估计

进程迁移是集群中关键性技术，计算迁移的概念继承自进程迁移，但为单一世界架构量身定制，同样，他也是单一世界架构的核心技术之一。首先，我们先界定下计算迁移的概念：某个计算过程离开原来的计算环境，在另外一个计算环境中继续完成。这里涉及到2个子概念，什么计算，什么迁移。我们来研究下计算的历史，分为几个阶段：1、函数，这是很核心的基础概念，原来基于汇编指令的计算，没有实际意义，就不再探讨。函数过程，最基

如果说，还有什么最令我好奇的是，单一世界架构就是其中之一。我在网络上查了一些资料，但对单一世界真正建立，还是有很多问题需要解决。个人认为，这个架构将会是里程碑式的。我融合现有架构以及一些自己的思考，在下面将逐渐铺开。我曾经看到过的，和单一世界相关的文章主要是云风的和一个可能是传奇架构的。已经实现的架构，一个是澳洲的《BigWorld》引擎，另外一个是《EVE》。EVE虽然宣称是单一世界，但他有

在单一世界中，分布了众多的终端，如果没有利用终端计算能力，实在是浪费巨大的资源。有些人在探讨P2P模式，但我认为P2P仍然不是最好的利用方式。我们在前面曾经探讨过，在单一世界中，网络延时以及玩家众多是很致命的影响因素，如果P2P的话，是很难保证客户端之间的传输速度的，那么在高实时的游戏中，玩家体验就比较差了。一般说来，C和S之间的传输数据是不对等的，C传输的数据量要远少于S，不过S的计算能力要

如果说局部性是一个核心原理，那么可预测性推论就是实现的核心基础。为什么呢？理由很简单，如果一个角色的行为能够在1秒之前被预测，那么客户端与服务端的网络延时可以容忍在1秒。一般洲际之间的网络在200－300毫秒之间，因此，跨洲际的单一世界的实现就成为了可能。 这个可预测推论是否正确呢，其实我们通过观察可以得到，推论本身是正确的，唯一不正确的是预测的时间范围。我们知道当客户端按下了攻击键，那么

我们可以想象，在单一世界架构中，肯定需要大量的服务器来支持，但反映在虚拟世界中，时间的流动是唯一的。全部服务器的时间流动就是整个世界的时间之轴，也就是时间之轴的流动是整个世界的标准时间。在实现中，单一世界显然是由很多服务器构成了，每个服务器之间必然存在时间差，这种时间差可能导致基于时间相关的行为发生混乱。比如P1/P2两个玩家互相攻击，P1在T1时间作出攻击行为，P2在T2时间作出攻击行为

和传统的服务器不一样，单一世界之间的服务器的通讯量十分庞大，也许瞬间的局域网传输量可以到1G，传统TCP/IP的移动窗口，拥塞控制，定时器等已经无法满足这个要求。高速局域网的理论和实践已经十分丰富，我不准备再拾人牙慧，重新再叙述。我在这里只提出这个问题。我们还可以考虑利用LFS，以及集群等思想来改造所有的服务器。

角色视野理论和世界粒度有密切的关系，主要为了解决客户端的计算量而单独提出来的。以前的例子曾经提到过国战的例子，都是从服务器角度来解析如何实现，却从来没有考虑客户端的情况，而角色视野就是从客户端角度来解决国战的例子。我考察下，国战时，对客户端会有什么影响呢？首先，在角色视野将充斥大量的人和事物；其次，各种魔法和战斗将频繁发生；再次，和服务器的通讯量将激增；最后，本机计算量将飙升。很多质疑单一世界

对服务器来说，没有什么粒度的概念，世界粒度主要还是从客户端的角度来看的。其实这个也好理解，你坐狮鹫从空中看到的地狱火跟面对面看到的地狱火完全是2个概念。虽然说，其实地狱火完全是一样的，可是因为观察粒度的不同，看到就是2个东西。另外一个例子，应该举个现在多数游戏都有的小地图来说。小地图，我最早见于《暗黑破坏神》，当然，现在魔兽世界也有。3维如何实现不同粒度的显示，不是我所长，我就不探讨了

碰撞检测，我知道很重要，不过我没有接触和研究过，所以就转载了个比较全的出来，顺便添加些自己的看法。可以参考下面的网址：http://dev.gameres.com/Program/Visual/3D/bobic.htm首先，必须先申明我想法，我在看这边文章之前的想法。我觉得判断空间2个曲面是否相交，最简单的情况就是球面。确定2个球心和半径。所以将任何一个物体切割成多个球构成的空间物体，

RTP/RTCP主要应用于网络媒体数据传输的协议，和这里有2个比较接近的地方，一个是数据大另外一个是实时性。这个和单一世界的要求很接近，所以将本篇命名为RTCP启示，就是希望借鉴他们的优点。 我们知道，在单一世界中，任何2个实体都可以成为对方的数据源，也可以成为对方的发送目标，比如进入白骨荒野的任何人。这点和网络会议很象，参加会议的任何人都可以听到或者看到所有人。如果我们将进入白骨荒野

我们将以前的论述中，尽量将所有的模型简化。数据抽象的提出，将这个简化已经做到极致了。你想想，将一个复杂的运动简化为一个3维坐标的变化，是什么样概念。当然，这只是一种思想，而实际上，象碰撞检测这样需求的存在，投影世界并不是那么简单，但依然存在很大的空间。首先，我们将投影世界中，所有的实体进行分类，标记为角色、武器、装备、地图、植物、山川等类，再由角色衍生为人类、兽人、暗夜精灵、血精灵等各个种族，

为了分析服务端要处理的逻辑，我们按处理对象将单一世界划分为投影世界和表象世界。表象世界是客户端能看到的所有集合，而投影世界则是服务端要处理的所有数据和逻辑的集合。投影世界是表象世界在服务端的投影，所以叫投影世界。他是将网游世界中与架构无关的东西予以摒除，剩下一个部分投影的世界。比如一个角色可能有颜色等概念，但在投影世界中，只有三角形等抽象的数据。在单一世界中，每个角色和地形需要考虑的要素很多，比如

性价曲线的提出主要从商业角度探讨，毕竟一个网游的最终是以商业目的。我们运营成本来算下看看，应该包括机器采购成本，人员维护成本，还有运行成本。机器采购成本比较简单，就是服务器的买入价。人员维护成本主要是薪资和办公费用以及福利待遇等。人员这块有个地方估计需要注意，一般linux比win32薪资待遇都偏高点，当然不是绝对，但至少我见过的普遍如此。运行成本，就比较复杂了，包括电费，机房费以及托管费

主动模式在大型服务系统中，是完全必须的。在设计模式中，有个监听模式可以概括这种情况，而不完全如此。在监听模式中，往往需要先往目标注册，然后根据目标的状态变化，由目标通知监听者。但在这里，监听者却并不知道需要监听哪些东西。也就是说监听者和被监听者之间往往没有固定和必然的联系。我们可以想象，当一个人进入白骨荒野，这是个眼界很开阔的地图，对于你的进入，已经在白骨荒野的人应该可以看到你的存在，

DDOS防御是个很重要的课题，对于大公司来说，有很多资源可以调配，但对小型应用来说，却是灭顶之灾。这个主要讨论下，如何让小型的应用最大限度的抵御DDOS。首先，我们要针对的是，导致带宽耗尽的情况。至于碎片攻击或者针对操作系统漏洞的情况就不考虑了。我们知道，DDOS最常用的方式，是利用大量的肉鸡在同一时刻发起攻击，导致某个服务系统无法响应合法的请求。通常来说，一个网络服务总是以一个域名为标记的，