第2步：编译lua
使用任意ANSI C编译器，在这里使用VS2005编译LUA。具体步骤如下：
a.打开vs的命令行工具，工具-->visual studio 2005 command prompt
b.跳转到[Lua]目录，例如：cd  D:/Program Files/Lua
c.执行：etc\luavs.bat（ 注意，是 \ 不是 /,写错了不能执行编译 )
d.然后lua51.dll, lua51.lib, lua.exe, and luac.exe就生成在 src 路径下了
e.在windows环境变量中把[Lua]\src添加到系统Path中去,

第3步：创建lua脚本
下载LuaEdit http://luaforge.net/frs/download.php/1037/LuaEdit_2_5.zip 他是Lua脚本的编辑工具，还可以对Lua脚本进行语法检测和调试。你也可以其他的纯文本编辑工具写一个文件test.lua，注意后面没有“;”

function f ( x, y)
    return x + y
end

// Win32Console.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

extern "C"
{
#include "D:/Lib/Lua/lua.h"
#include "D:/Lib/Lua/lualib.h"
#include "D:/Lib/Lua/lauxlib.h"
}
#pragma comment( lib ,"D:/Lib/Lua/lua51.lib")
lua_State *L;

//调用lua
double fun( double x, double y )
{
 double ret;
 lua_getglobal( L, "add");        // 获取全局变量f
 lua_pushnumber( L,x);          // 操作数压栈
 lua_pushnumber( L,y);          // 操作数压栈
 lua_call( L, 2, 1);            // 执行：2个操作数，1个返回值
 //lua_pcall( L, 2, 1, 0);      // 保护模式的lua_call,0为错误处理码。具体应用暂时不明，在使用手册中有粗略介绍
 ret = lua_tonumber( L, -1);    // 将栈顶元素转换成数字并赋值给ret
 lua_pop( L, 1);                // 从栈中弹出一个元素
 return ret;
}

//被lua调用的方法
static int average(lua_State *L2)
{
    /**//* get number of arguments */
    int n = lua_gettop(L2);
    double sum = 0;
    int i;
    /**//* loop through each argument */
    for (i = 1; i <= n; i++)
    {
    /**//* total the arguments */
    sum += lua_tonumber(L2, i);
    }
    lua_pushnumber(L, sum / n);
    /**//* push the sum */
    lua_pushnumber(L, sum);
    /**//* return the number of results */
    printf("average called. [ok]\n");
    return 2;
}
//==============================================
// Main Functions
//==============================================
int main( void)
{
 int error;
 L = lua_open();          // 创建Lua接口指针（借用DX的术语，本质是个堆栈指针）
 luaopen_base(L);     // 加载Lua基本库
 luaL_openlibs(L);     // 加载Lua通用扩展库
/**//*
 可能有的文章会采用以下写法，手工控制加载哪些库：
 luaopen_table(L);     // 加载table库
 luaopen_io(L);           // 加载IO库
 luaopen_string(L);    // 加载string库
 luaopen_math(L);     // 加载math库
 经过测试，luaopen_io(L);该句执行异常，可能跟Lua的IO库有关系。具体原因暂时没有追究，将来如果有机会弄清楚，再回头来阐述。
*/
 
 /**//* load the script */
 lua_register(L, "average", average);
 error = luaL_dofile(L, "hellow.lua");    // 读取Lua源文件到内存编译

 double ret = fun( 10, 3.4);                // 调用模版函数f
 printf( "ret = %f\n", ret);                // 输出结果，C语言的东西，跟Lua无关
 lua_close( L);
 return 1;
}

function add ( x, y)    
    file = assert(io.open("data.txt", "w"))
    file:write("abcde\n")
    file:write("ok!\n")
    file:close()

    --DataDumper(1,2,3,4)
    file = assert(io.open("data.txt", "r"))
    str = file:read("*a")
    io.write(str)
    io.write("\n")
    
    avg, sum = average(10, 200, 3000)
    print("The average is ", avg)
    print("The sum is ", sum)
    
    return x + y
end

在tc2中，所有的对象都被认为是object，以object作为基类，以1.2.3格式表示继承关系，如：1 --> object  ；1.2 --> worldobject。1.2表示worldobject继承自1（object）。下面列出完整的对象继承族谱。

1、                 Object

1.1                 Item               【物品，比如武器】

1.1.1              Bag                 【包裹，特殊的物品，可以容纳其他物品】

1.2                 WorldObject     【显示在地图上的物体】

1.2.1              Corpse            【尸体】

1.2.2              DynamicObject 【动态生成的对象，比如魔法，生命周期比较短】

1.2.3              GameObject     【游戏物品，这个分类很难从字面上理解，后面会比较详细的介绍】

1.2.3.1           Transport         【传送点】

1.2.4              Unit                 【游戏中有生命的单位】

1.2.4.1           Creature          【生物，非玩家】

1.2.4.2           TempSummon   【临时召唤物】

1.2.4.2.1         Minion              【宠物】

1.2.4.2.1.1      Guardian          【守卫】

1.2.4.2.1.1.1   Pet               【玩家的宠物，比如猎人的宠物，或者术士的恶魔，除非主人解散，否则一直存在】

1.2.4.2.1.2      Puppet             【傀儡，有一定的存在时间。比如德鲁依的树人】

1.2.4.2.1.3      Totem              【图腾，萨满的图腾】

1.2.4.2            Player              【玩家，就不用多解释了】

将整个魔兽世界分解静态物体和静态物体的行为，就比较好理解了。事实上，现实世界也是如此。将世界划分为时间和空间2个维度，现实物体就是空间的概念，行为就是空间物体在时间维度上的变化。象光或者其他不可见或者没有空间占位的物品也可以看作特殊的空间物体。我在这里先将空间维度将分离出来分析。

差点忘了介绍GameObject这个另类。在GameObject.h中，有个struct GameObjectInfo定义，里面有个union能大概看出GameObject究竟指的是哪些东西。

0、GAMEOBJECT_TYPE_DOOR，指的是门

1、GAMEOBJECT_TYPE_BUTTON，应该是按钮，锁之类的。

2、GAMEOBJECT_TYPE_QUESTGIVER任务物品

3、GAMEOBJECT_TYPE_CHEST箱子

4、GAMEOBJECT_TYPE_BINDER没定义，估计没有用上。

5、GAMEOBJECT_TYPE_GENERIC通用的，跟任务相关的东西

6、GAMEOBJECT_TYPE_TRAP陷阱

7、GAMEOBJECT_TYPE_CHAIR椅子

8、GAMEOBJECT_TYPE_SPELL_FOCUS没搞懂啥玩意儿。

9、GAMEOBJECT_TYPE_TEXT文本

10、GAMEOBJECT_TYPE_GOOBER应该是果实一类的吧。

11、GAMEOBJECT_TYPE_TRANSPORT传送点

12、GAMEOBJECT_TYPE_AREADAMAGE区域性伤害，没搞懂啥玩意儿。

13、GAMEOBJECT_TYPE_CAMERA照相机，再研究下

14、GAMEOBJECT_TYPE_MAPOBJECT地图对象，空着

15、GAMEOBJECT_TYPE_MO_TRANSPORT地图对象的传送，不知道啥玩意儿。

16、GAMEOBJECT_TYPE_DUELFLAG决斗标志，估计就是PK，插旗吧。空着没用

17、GAMEOBJECT_TYPE_FISHINGNODE钓鱼点

18、GAMEOBJECT_TYPE_SUMMONING_RITUAL仪式，不知道干啥。估计跟术士拉人那东西有关。

19、GAMEOBJECT_TYPE_MAILBOX邮箱

20、GAMEOBJECT_TYPE_DONOTUSE顾名思义，没用

21、GAMEOBJECT_TYPE_GUARDPOST岗哨，是某种生物

22、GAMEOBJECT_TYPE_SPELLCASTER魔法施放。

23、GAMEOBJECT_TYPE_MEETINGSTONE集合石

24、GAMEOBJECT_TYPE_FLAGSTAND不知道啥玩意儿。

25、GAMEOBJECT_TYPE_FISHINGHOLE估计也是钓鱼点

26、GAMEOBJECT_TYPE_FLAGDROP掉落标记

27、GAMEOBJECT_TYPE_MINI_GAME也没懂是啥玩意儿。

28、GAMEOBJECT_TYPE_CAPTURE_POINT应该是部落和联盟争夺地区

29、GAMEOBJECT_TYPE_AURA_GENERATOR灵气

30、GAMEOBJECT_TYPE_DUNGEON_DIFFICULTY地下城难度

31、GAMEOBJECT_TYPE_BARBER_CHAIR理发师的椅子，唉，都啥玩意儿啊。

32、GAMEOBJECT_TYPE_DESTRUCTIBLE_BUILDING可摧毁的建筑

33、GAMEOBJECT_TYPE_GUILDBANK工会银行，空，不可见。

34、GAMEOBJECT_TYPE_TRAPDOOR陷阱的门。

应该说，GameObject是描述游戏中，除装备、生物、魔法外，无法准确归类的东西，比较杂，因此只能笼统归结为游戏对象

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/romandion/archive/2009/10/27/4733596.aspx

　　在大部分的MMOG中，游戏对象的类型都大同小异，主要有物品、生物、玩家等。比如在wow中，通过服务器发下来的GUID我们可以了解到，游戏中有9大类对象，包括物品(Item)、背包(Container)、生物(Unit)、玩家(Player)、游戏对象(GameObject)、动态对象(DynamicObject)、尸体(Corpse)等。

　　在mangos的实现中，对象使用类继承的方式，由Object基类定义游戏对象的公有接口及属性，包括GUID的生成及管理、构造及更新UpdateData数据的虚接口、设置及获取对象属性集的方法等。然后分出了两类派生对象，一是Item，另一是WorldObject。Item即物品对象，WorldObject顾名思义，为世界对象，即可添加到游戏世界场景中的对象，该对象类型定义了纯虚接口，也就是不可被实例化，主要是在Object对象的基础上又添加了坐标设置或获取的相关接口。

　　Item类型又派兵出了一类Bag对象，这是一种特殊的物品对象，其本身具有物品的所有属性及方法，但又可作为新的容器类型，并具有自己特有的属性和方法，所以实现上采用了派生。mangos在实现时对Bag的类型定义做了点小技巧，Item的类型为2，Bag的类型为6，这样在通过位的方式来表示类型时，Bag类型也就同时属于Item类型了。虽然只是很小的一个技巧，但在很多地方却带来了极大的便利。

　　从WorldObject派生出的类型就有好几种了，Unit、GameObject、DynamicObject和Corpse。
         
         Unit为所有生物类型的基类，同WorldObject一样，也不可被实例化。它定义了生物类型的公有属性，如种族、职业、性别、生命、魔法等，另外还提供了相关的一些操作接口。游戏中实际的生物对象类型为Creature，从Unit派生，另外还有一类派生对象Player为玩家对象。Player与Creature在实现上最大的区别是玩家的操作由客户端发来的消息驱动，而Creature的控制是由自己定义的AI对象来驱动，另外Player内部还包括了很多的逻辑系统实现。

　　另外还有两类特殊的Creature，Pet和Totem，其对象类型仍然还是生物类，只是实现上与会有些特殊的东西需要处理，所以在mangos中将其作为独立的派生类，只是实现上的一点处理。另外在GameObject中也实现有派生对象，最终的继承关系图比较简单，就不麻烦地去画图了。

　　从我所了解的早期游戏实现来看，大部分的游戏对象结构都是采用的类似这种方式。可能与早期对面向对象的理解有关，当面向对象的概念刚出来时，大家认为继承就是面向对象的全部，所以处处皆对象，处处皆继承。

　　类实现的是一种封装，虽然从云风那里出来的弃C++而转投C的声音可能会影响一部分人，但是，使用什么语言本身就是个人喜好及团队整体情况决定的。我们所要的也是最终的实现结果，至于中间的步骤，完全看个人。还是用云风的话说，这只是一种信仰问题，我依然采用我所熟悉的C++，下面的描述也是如此。

　　随着面向对象技术的深入，以及泛型等概念的相继提出，软件程序结构方面的趋势也有了很大改变。C++大师们常说的话中有一句是这样说的，尽是采用组合而不是继承。游戏对象的实现也有类似的转变，趋向于以组合的方式来实现游戏对象类型，也就是实现一个通用的entity类型，然后以脚本定义的方式组合出不同的实际游戏对象类型。

　　

         在游戏编程精粹四有三篇文章讲到了实体以及实体管理的实现方案，其中一篇文章说到了实体管理系统的四大要素：定义实体怎样沟通的实体消息，实现一实体类代码和数据的实体代码，维护已经注册在案的实体类列表，和用来创建、管理、发送消息的实体管理器。

　　关于实体消息的内容之前讨论事件机制的时候做过一点说明，其实这也就是按接口调用和按消息驱动的区别，现在mangos的做法是完全的接口调用，所以引擎内部就没有任何的实体消息。实体代码实现和实体管理器是我们重点要讨论的内容。

　　另有一篇文章也提到了使用类继续的方式实现游戏对象的两大问题，一是它要求系统中的所有对象都必须从一个起点衍生而成，也就是说所有对象类在编译的时候已经确定，这可能是一个不受欢迎的限制，如果开发者决定添加新的对象类，则必须要对基类有所了解，方能支持新类。另一个问题在于所有的对象类都必须实现同样的一些底层函数。

　　对于第二个问题，可以通过接口继承的方式来避免基类的方法太多。在mangos的实现中就采用了类似的方法，从Object虚基类派生的Unit和WorldObject仍然还是不可实例化的类，这两种对象定义了不同的属性和方法，分来实现不同类型的对象。在游戏内部可以根据对象的实际类型来Object指针向下转型为Unit或WorldObject，以调用需要的接口。方法虽然不够OO，也还能解决问题。但是第一个问题是始终无法避免的。

　　所以我们便有了通用实体这么一个概念，其主要方法是将原来基类的接口进行分类，分到一个个不同的子类中，然后以对象组合的方式来生成我们所需要的实际游戏对象类型。这个组合的过程可以通过脚本定义的方式，这样便可以在运行时生成为同的对象类型，也就解决了上面提到的第一个问题。

　　通用实体的实现方法在目前的游戏引擎及开源代码中也可以看到影子。一个是BigWorld，从提供的资料来看，其引擎只提供了一个entity游戏对象，然后由游戏内容实现者通过xml和python脚本来自由定义不同类型的entity类型，每种类型可有不同的property和不同的方法。这样原来由基类定义的接口完全转移到脚本定义，具有非常强的灵活性。

　　另外还有一个是CEL中的entity实现。按照CEL的描述，entity可以是游戏中的任意对象，包括玩家可交互的对象，如钥匙、武器等，也可以包括不能直接交互的对象，如游戏世界，甚至任务链中的一部分等。entity本身并没有任何特性，具体的功能实现需要靠附加property来完成。简单来说，property才定义了entity可以做什么，至于该怎么做，那又是依靠behavior来定义。所以，最终在CEL中一个游戏对象其实是由entity组合了多个property及多个behavior而生成的。

　　但是CEL中的property与BigWorld中的property意义不大一样，在CEL中可定义的property其实是引擎内部要先提供的，比如其示例中所举的pcobject.mesh、pcmove.linear、pctools.inventory等，而BigWorld中的property是完全的自由定制。从这个角度来讲，其实可以把CEL中的property看作是游戏的逻辑系统，也就是我们上面所描述的，接口分类后所定义的子类。

　　由引擎内部提供可选择的property与BigWorld所采用的完全自由定制property其实本质上是相同的。在用BigWorld实现的游戏中，也不可能为每种游戏对象类型都完全从头定义property，基于代码利用的原则，也会先定义一些小类，然后在entity类型定义时以自定义property的方式来包含这些小类。当然，我没有使用过BigWorld，上面的描述也只是基于游戏实现的大原则所做出来的。

　　描述的依然有些抽象，我们可以用wow及mangos代码来说明一下。mangos中为object定义了一个属性集合，根据对象类型的不同，这个属性集的大小及保存数据也会有差异，另外游戏对象内部含有处理不同游戏逻辑的系统，如RestSystem、FloodFilterSystem、VariousSystem等等，在player.h中以接口组的方式进行定义。

　　如果要将这种结构改为我们描述的通用entity系统，可以让object只提供property注册和删除的接口，这里的property定义与CEL中的相同，放在mangos中也就是上面说的RestSystem、FloodFilterSystem、VariousSystem这些。然后也通过xml文件的方式定义我们所需要的游戏对象类型，如player,creature,item等，不同的对象类型可以选择加载不同的property，加载的原则是需要哪些功能就加载哪些property。

　　对象的定义按上面的方法完成后，对象的实现也需要做一些修改。以前客户端的消息是直接交由player来处理，AI也是直接调用creature的接口来完成一些功能，现在通用的entity内部已经没有任何可用的方法，所有的实现都转到了property中，所以需要由各个property实现自己来注册感兴趣的事件及消息，entity实现一个消息的转发，转给对此感兴趣的property来处理。其余的实现就没有什么不同了。

　　当然，我们再做一点扩展，让property不光由引擎来提供，用脚本本身也能定义property，并且可以通过xml来注册这些property，这样便实现了与BigWorld一样的完全自由特性。这其实也就是将很多用C++实现的功能转移到了python中，这种做法可作为参考，但不一定对所有人合适，至少在我看来，这样的实现也基本只能由程序员来做，所以让程序员选择自己最擅长的语言可能会更易于开发和调试。




有关游戏对象实现的描述，前面两篇文章中说的不甚清楚，主要是一直都要引用网上能够找到的资料来进行描述，以避免与公司引起不必要的麻烦。所以语言有些拼凑的感觉，举的例子也很不恰当，今天正好看到了游戏编程精粹五和六上的两篇文章，内容都差不多，<<基于组件的对象管理>>和<<基于组件的游戏对象系统>>，说的也是我上两篇文章想要描述的内容，所以再补一篇，引用其中的部分文字进行明确的说明。

　　传统的游戏对象管理系统采用继承的方式来实现，例如，所有的子类都从CObject派生。大多数情况下，直接派生的也是抽象类，其中带一些功能而另一些子类则不带这些功能，比如可控制/不可控制，可动画/不可动画等。mangos的实现中基本就是这种情况，从Object直接派生的Unit和WorldObject都是不可直接实例化的类。

　　传统方法的问题在于无法应对需求的变化，如要求武器也有动画效果时就无法处理了。如果硬要是这样做，那随着需求的啬，很多的方法会被放到基类中，最终的结果是继承树变得越来越头重脚轻，这样的类会丧失它的内聚性，因为它们试图为所有对象完成所有的事。

　　就是说到最后，基类会有一个很长的接口列表，而很多的游戏对象类型根本不需要实现其中的一些甚至大部分接口，但是按照这种结构却又必须去实现。以至于于实现一个非常庞大的对象，而且想要修改一点功能会导致系统的大调整。

　　我们希望的系统是可以将现有的功能组合到新的对象中，并且在将新的功能添加到现有的对象中时不需要重构大量的代码和调整继承树的结构。

　　实现的方法就是从组件来创建一个对象。组件是一个包含所有相关数据成员和方法的类，它完成某个特定的任务。把几个组件组合在一起就可以创建一个新的对象。如把Entity组件、Render组件和Collectable组件组合在一起生成了一个Spoon对象。Entity组件让我们可以把对象放到游戏世界中，Render组件让我们可以为对象指定一个模型进行渲染，而Collectable组件让我们可以拾取这个对象。

　　关于组件的实现，所有的组件都从一个基础组件接口派生，可称其为IComponent。每个组件也有自己的接口定义，并且这个接口也需要从IComponent派生，类似于这样：IComponent -- ICmpRender -- CCmpRender M

　　这里的每个组件也就是我在上一篇中所说的由引擎提供的属性，或者说在BigWorld中自己实现然后定义的属性，或者使用mangos中的定义，就是一个个的System，虽然mangos并没有将其完全做成组件，但是通过其代码注释可以看到，接口也是按功能组进行了分类，如果要拆分成组件也是比较方便的。

　　组件之间的通信有两种方法，一是用组件ID查询到组件接口指针，然后调用接口方法；二是使用消息的方式，向对象中所有组件发消息。在初始化的时候，每一个组件类型都会告诉对象管理器应该接收什么样的消息。

　　查询接口的方法也就是直接的方法调用，只不过接口不是全部在基类中，所以必须先查询到指定的组件然后才能调用其接口。消息的使用前面已经说过多次，其实现方案也有过说明。

　　最后是关于游戏对象功能的扩展和游戏对象的定义。需要扩展功能也就是需要实现一个新的组件，或者修改现在组件。在大多数情况下，扩展都不会引起结构的很大调整，受影响的最多只是使用到该组件的部分代码。

　　游戏对象定义可采用完全数据驱动的方式，使用xml或者脚本语言来定义对象类型，以及每个类型需要加载的组件。对象类型注册到对象管理器后，由管理器提供创建指定类型的对象的方法。数据驱动的方式能够让策划自由定义游戏对象类型，并且随时可自由创建新的对象类型。

事实上呢，第一个问题是个非常简单的问题，不过之所以我 提出这个问题来，是提醒大家在设计自己的消息结构的时候，需要把这个因素考虑进去。而对于第二个问题，则是一个挺麻烦的问题，大家可以来看这么个例子： 比如有一个玩家A向服务器发了条指令，说我现在在P1点，要去P2点。指令发出的时间是T0，服务器收到指令的时间是T1，然后向周围的玩家 广播这条消息，消息的内容是“玩家A从P1到P2”有一个在A附近的玩家B，收到服务器的这则广播的消息的时间是T2，然后开始在客户端上画图，A从P1 到P2点。这个时候就存在一个不同步的问题，玩家A和玩家B的屏幕上显示的画面相差了T2-T1的时间。这个时候怎么办呢？ 有个解决 方案，我给它取名叫 预测拉扯，虽然有些怪异了点，不过基本上大家也能从字面上来理解它的意思。

要解决这个问题，首先要定义一个值叫：预测误差。然后需要在服务器端每个玩家连 接的类里面加一项属性，叫TimeModified，然后在玩家登陆的时候，对客户端的时间和服务器的时间进行比较，得出来的差值保存在 TimeModified里面。还是上面的那个例子，服务器广播消息的时候，就根据要广播对象的TimeModified，计算出一个客户端的 CurrentTime，然后在消息头里面包含这个CurrentTime，然后再进行广播。并且同时在玩家A的客户端本地建立一个队列，保存该条消息， 只到获得服务器验证就从未被验证的消息队列里面将该消息删除，如果验证失败，则会被拉扯回P1点。然后当玩家B收到了服务器发过来的消息“玩家A从P1到 P2”这个时候就检查消息里面服务器发出的时间和本地时间做比较，如果大于定义的预测误差，就算出在T2这个时间，玩家A的屏幕上走到的地点P3，然后把 玩家B屏幕上的玩家A直接拉扯到P3，再继续走下去，这样就能保证同步。

更进一步，为了保证客户端运行起来更加smooth，我并不推荐直接把玩家拉扯过 去，而是算出P3偏后的一点P4，然后用(P4-P1)/T(P4-P3)来算出一个很快的速度S，然后让玩家A用速度S快速移动到P4，这样的处理方法 是比较合理的，这种解决方案的原形在国际上被称为（Full plesiochronous），当然，该原形被我篡改了很多来适应网络游戏的同步，所以而变成所谓的：预测拉扯。 另外一个解决方 案，我给它取名叫 验证同步，听名字也知道，大体的意思就是每条指令在经过服务器验证通过了以后再执行动作。具体的思路如下：首先也需要在每个玩家连接类型里面定义一个 TimeModified，然后在客户端响应玩家鼠标行走的同时，客户端并不会先行走动，而是发一条走路的指令给服务器，然后等待服务器的验证。服务器接 受到这条消息以后，进行逻辑层的验证，然后计算出需要广播的范围，包括玩家A在内，根据各个客户端不同的TimeModified生成不同的消息头，开始 广播，这个时候这个玩家的走路信息就是完全同步的了。

这个方法的优点是能保证各个客户端之间绝对的同步，缺点是当网络延迟比较大的时候，玩家的客户端的行 为会变得比较不流畅，给玩家带来很不爽的感觉。该种解决方案的原形在国际上被称为（Hierarchical master-slave synchronization），80年代以后被广泛应用于网络的各个领域。

最后一种解决方案是一种理想化的解决方案，在国际上被 称为Mutual synchronization，是一种对未来网络的前景的良好预测出来的解决方案。这里之所以要提这个方案，并不是说我们已经完全的实现了这种方案，而 只是在网络游戏领域的某些方面应用到这种方案的某些思想。我对该种方案取名为：半服务器同步。大体的设计思路如下： 首先客户端需要在 登陆世界的时候建立很多张广播列表，这些列表在客户端后台和服务器要进行不及时同步，之所以要建立多张列表，是因为要广播的类型是不止一种的，比如说有 local message,有remote message,还有global message 等等，这些列表都需要在客户端登陆的时候根据服务器发过来的消息建立好。在建立列表的同时，还需要获得每个列表中广播对象的TimeModified，并 且要维护一张完整的用户状态列表在后台，也是不及时的和服务器进行同步，根据本地的用户状态表，可以做到一部分决策由客户端自己来决定，当客户端发送这部 分决策的时候，则直接将最终决策发送到各个广播列表里面的客户端，并对其时间进行校对，保证每个客户端在收到的消息的时间是和根据本地时间进行校对过的。 那么再采用预测拉扯中提到过的计算提前量，提高速度行走过去的方法，将会使同步变得非常的smooth。该方案的优点是不通过服务器，客户端自己之间进行 同步，大大的降低了由于网络延迟而带来的误差，并且由于大部分决策都可以由客户端来做，也大大的降低了服务器的资源。由此带来的弊端就是由于消息和决策权 都放在客户端本地，所以给外挂提供了很大的可乘之机。

综合以上三种关于网络同步派系的优缺点，综合出一套关于网络游戏传输同步的较完整的解决方案，我称它为综合同步法（colligate synchronization）。大体设计思路如下： 首先将服务器需要同步的所有消息从划分一个优先等级，然后按照3/4的比例划分出重要消息和非重要消息，对于非重要消息，把决策权放在客户端，在客户端逻辑上建立相关的决策机构和各种消息缓存区，以及相关的消息缓存区管理机构，如下图所示： 上图简单说明了对于非重要消息，客户端的大体处理流程，其中有一个客户端被动行为值得大家注意，其中包括对服务器发过来的某些验证代码做返回，来确保消 息缓存中的消息和服务器端是一致的，从而有效的防止外挂来篡改本地消息缓存。其中的消息来源是包括本地的客户端响应玩家的消息以及远程服务器传递过来的消 息。

对于重要消息，比如说战斗或者是某些牵扯到玩家一些比较敏感数据的操作，则采用另外一套方案，该方案首先需要在服务器和客户端之 间建立一套Ping System，然后服务器保存和用户的及时的ping值，当ping比较小的时候，响应玩家消息的同时先不进行动作，而是先把该消息反馈给服务器，并且阻 塞，服务器收到该消息，进行逻辑验证之后向所有该详细广播的有效对象进行广播（包括消息发起者），然后客户端收到该消息的验证，才开始执行动作。而当 ping比较大的时候，客户端响应玩家消息的同时立刻进行动作，并且同时把该消息反馈给服务器，值得注意的是这个时候还需要在本地建立一个无验证消息的队 列，把该消息入队，执行动作的同时等待服务器的验证，还需要保存当前状态。服务器收到客户端的请求后，进行逻辑验证，并把消息反馈到各个客户端，带上各个 客户端校对过的本地时间。如果验证通过不过，则通知消息发起者，该消息验证失败，然后客户端自动把已经在进行中的动作取消，恢复原来状态。如果验证通过， 则广播到的各个客户端根据从服务器获得校对时间进行对其进行拉扯，保证在该行为完成之前完成同步。 至此，一个比较成熟的网络游戏的同步机制已经初步建立起来了，接下来的逻辑代码就根据各自不同的游戏风格以及侧重点来写了。 同步是网络游戏最重要的问题，如何同步也牵扯到各个方面的问题，比如说游戏的规模，游戏的类型以及各种各样的方面，对于规模比较大的游戏，在同步方面可 以下很多的工夫，把消息分得十分的细腻，对于不同的消息采用不同的同步机制，而对于规模比较小的游戏，则可以采用大体上一样的同步机制，究竟怎么样同步， 没有个定式，是需要根据自己的不同情况来做出不同的同步决策的 网游同步算法之导航推测（Dead Reckoning）算法： 在了解该算法前，我们先来谈谈该算法的一些背景资料。

大家都知道，在网络传输的时候，延迟现象是很普遍的，而在基于Server/Client结构下的 网络游戏的同步也就成了很头疼的问题，在保证客户端响应用户本地指令流畅的情况下，没法有效的保证的同步的及时性。同样，在军方也有类似的事情发生，即使 是同一LAN里面的机器，也会因为传输的延迟，导致一些运算的失误，介于此，美国国防部投入了大量的资金用于研究一种比较的好的方案来解决分布式系统中的 延迟问题，特别是一个叫分布式模拟运动（Distributed Interactive Simulation）的系统，这套系统呢，其中就提出了一套号称是Latency Hiding & Bandwidth Reduction的方案，命名为Dead Reckoning。呵呵，来头很大吧，恩，那么我们下面就来看看这套系统的一些观点，以及我们如何把它运用到我们的网络游戏的同步中。 首先，这套同步方案是基于我那篇《网络游戏的同步》一文中的Mutual Synchronization同步方案的，也就是说，它并不是Server/Client结构的，而是基于客户端之间的同步的。

下面我们先来说一些本文中将用到的名词概念：网状网络：客户端之间构成的网络节点：网状网络中的每个客户端极限误差：进行同步的时候可能产生的误差的极值 恩，在探讨其原理的之前，我们先来看看我们需要一个什么样的环境。首先，需要一个网状网络，网状网络如何构成呢？当有新节点进入的时候，通知该网络里面 的所有节点，各节点为该客户端在本地创建一个副本，登出的时候，则通知所有节点销毁本地关于该节点的副本。然后每个节点该保存一些什么数据呢？首先有一个 很重要的包需要保存，叫做协议数据包（PDU Protocol Data Unit），PDU包含节点的一些相关的运动信息，比如当前位置，速度，运动方向，或者还有加速度等一些信息。除PDU之外，还有其他信息需要保存，比如 说节点客户端人物的HP，MP之类的。然后，保证每个节点在最少8秒之内要向其它节点广播一次PDU信息。最后，设置一个极限误差值。到此，其环境就算搭 建完成了。下面，我们就来看看相关的具体算法： 假设在节点A有一个小人（路人甲），开始跑路了，这个时候，就像所有的节点广播一次他 的PDU信息，包括：速度（S），方向（O），加速度（A）。那么所有的节点就开始模拟路人甲的运动轨迹和路线，包括节点A本身（这点很重要），同时，路 人甲在某某玩家的控制下，会不时的改变一下方向，让其跑路的路线变得不是那么正规。在跑路的过程中，节点A有一个值在不停的记录着其真实坐标和在后台模拟 运动的坐标的差值，当差值大于极限误差的时候，则计算出当前的速度S，方向O和速度A（算法将在后面介绍），并广播给网络中其他所有节点。其他节点在收到 这条消息之后呢，就可以用一些很平滑的移动把路人甲拉扯过去，然后重新调整模拟跑路的数据，让其继续在后台模拟跑路。 很显然，如果极 限误差定义得大了，其他节点看到的偏差就会过大，如果极限偏差定义得小了，网络带宽就会增大。如果定义这个极限误差，就该根据各种数据的重要性来设计了。 如果是回合制的网络游戏，那么在走路上把极限误差定义得大些无所谓，可以减少带宽。但是如果是及时打斗的网络游戏，那么就得把极限误差定义得小一些，否则 会出现某人看到某人老远把自己给砍死的情况。 Dead Reckoning的主要算法有9种，但是只有两种是解决主要问题的，其他的基本上只是针对不同的坐标系的一些不同的算法，这里就不一一介绍了。好，那么我们下面来看传说中的最主要的两种算法：第一：目标点 = 原点 + 速度 * 时间差第二：目标点 = 原点 + 速度 * 时间差 + 1/2 * 加速度 * 时间差呵呵，传说中的算法都是很经典的，虽然我们早在初中物理的时候就学过。 该算法的好处呢，正如它开始所说的，Latency Hiding & Bandwidth Reduction，从原则上解决了网络延迟导致的不同步的问题，并且有效的减少了带宽，不好的地方就是该算法基本上只能使用于移动中的同步，当然，移动 的同步是网络游戏中同步的最大的问题。 该方法结合我在《网络游戏的同步》一文中提出的综合同步法的构架可以基本上解决掉网络游戏中走路同步的问题。相关问题欢迎大家一起讨论。

有关导航推测算法（Dead Reckoning）中的平滑处理： 根据我上篇文章所介绍的，在节点A收到节点B新的PDU包时，如果和A本地的关于B的模拟运动的坐标不一致时，怎么样在A的屏幕上把B拽到新的PDU包 所描叙的点上面去呢，上文中只提了用“很平滑的移动”把B“拉扯”过去，那么实际中应该怎么操作呢？这里介绍四种方法。 第一种方法，我取名叫直接拉扯法，大家听名字也知道，就是直接把B硬生生的拽到新的PDU包所描叙的坐标上去，该方法的好处是：简单。坏处是：看了以下三种方法之后你就不会用这种方法了。 第二种方法，叫直线行走（Linear），即让B从它的当前坐标走直线到新的PDU包所描叙的坐标，行走速度用上文中所介绍的经典算法：目标点 = 原点 + 速度 * 时间差 + 1/2 * 加速度 * 时间差算出：首先算出从当前坐标到PDU包中描叙的坐标所需要的时间： T = Dest( TargetB – OriginB ) / Speed 然后根据新PDU包中所描叙的坐标信息模拟计算出在时间T之后，按照新的PDU包中的运动信息所应该达到的位置： _TargetB = NewPDU.Speed * T 然后根据当前模拟行动中的B和_TargetB的距离配合时间T算出一个修正过的速度_S： _S = Dest( _TargetB – OriginB ) / T 然后在画面上让B以速度_S走直线到Target_B，并且在走到之后调整其速度，方向，加速度等信息为新的PDU包中所描叙的。 这种方法呢，非常的土，会让物体在画面上移动起来变得非常的不现实，经常会出现很生硬的拐角，而且对于经常要修改的速度_S，在玩家A的画面上，玩家B的行动会变得非常的诡异。其好处是：比第一种方法要好。 第三种方法，叫二次方程行走（Quadratic），该方法的原理呢，就是在直线行走的过程中，加入二次方程来计算一条曲线路径，让Dest( _TargetB – OriginB )的过程是一条曲线，而不是一条直线，恩，具体的实现方法，就是在Linear方法的计算中，设定一个二次方程，在Dest函数计算距离的时候根据设定的 二次方程来计算，这样一来，可以使B在玩家A屏幕上的移动变得比较的有人性化一些。但是该方法的考虑也是不周全的，仅仅只考虑了TargetB到 _TargetB的方向，而没有考虑新的PDU包中的方向描叙，那么从_TargetB开始模拟行走的时候，仍然是会出现比较生硬的拐角，那么下面提出的 最终解决方案，将彻底解决这个问题。

最后一种方法叫：立方体抖动（Cubic Splines），这个东东比较复杂，它需要四个坐标信息作为它的参数来进行运算，第一个参数Pos1是OriginB，第二个参数Pos2是 OriginB在模拟运行一秒以后的位置，第三个参数Pos3是到达_TargetB前一秒的位置，第四个参数pos4是_TargetB的位置。 Struct pos { Coordinate X; Coordinate Y; } Pos1 = OriginB Pos2 = OriginB + V Pos3 = _TargetB – V Pos4 = _TargetB 运动轨迹中(x, y)的坐标。 x = At^3 + Bt^2 + Ct + D y = Et^3 + Ft^2 + Gt + H （其中时间t的取值范围为0-1，在Pos1的时候为0，在Pos4的时候为1） x(0-3)代表Pos1-Pos4中x的值，y(0-3)代表Pos1-Pos4中y的值 A = x3 – 3 * x2 +3 * x1 – x0 B = 3 * x2 – 6 * x1 + 3 * x0 C = 3 * x1 – 3 * x0 D = x0 E = y3 – 3 * y2 +3 * y1 – y0 F = 3 * y2 – 6 * y1 + 3 * y0 G = 3 * y1 – 3 * y0 H = y0 上面是公式，那么下面我们来看看如何获得Pos1-Pos4：首先，Pos1和 Pos2的取值会比较容易获得，根据OriginB配合当前的速度和方向可以获得，然而Pos3和Pos4呢，怎么获得呢？如果在从Pos1到Pos4的 过程中有新的PDU到达，那么我们定义它为NewPackage。 Pos3 = NewPackage.X + NewPackage.Y * t + 1/2 * NewPackage.a * t^2 Pos4 = Pos3 – (NewPackage.V + NewPackage.a * t) 如果没有NewPackage的情况下,则Pos3和Pos4按照开始所规定的方法获得。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wolfcoder/archive/2009/02/16/3897672.aspx

http://space.itpub.net/17007506/viewspace-616852

上一篇 / 下一篇  2009-10-19 13:54:17 / 个人分类：服务器构架

  【上篇：从腾讯QQ升级游戏之“快速加入游戏”功能的实现缺陷看C/S之间如何正确分配相关协作】

    腾讯QQGame游戏同时在线的玩家数量极其庞大，为了方便组织玩家组队游戏，腾讯设置了大量游戏室（房间），玩家可以选择进入属意的房间，并在此房间内找到可以加入的游戏组（牌桌、棋盘等）。玩家选择进入某个房间时，必须确保此房间当前人数未满（通常上限为400），否则进入步骤将会失败。玩家在登入QQGame后，会从服务器端获取某类游戏下所有房间的当前人数数据，玩家可以据此找到未满的房间以便进入。

    如上篇所述的原因，如果待进入房间的人数接近上限时，玩家的进入请求可能失败，这是因为服务器在收到此进入请求之前可能有若干其他玩家也请求进入这个房间，造成房间人数达到上限。这一问题是无法通过上篇所述调整协作分配的方法来解决的，这是因为：要进入的房间是由玩家来指定的，无法在服务器端完成此项工作，游戏软件必须将服务器端所维护的所有房间人数数据复制到玩家的客户端，并让玩家在界面上看到这些数据，以便进行选择。这样，上篇所述的客户端与服务器端协作分配原则（谁掌握数据，谁干活），还得加上一些限制条件，并让位于另一个所谓"用户驱动客户端行为"原则--如果某个功能的执行是由用户来推动的，则这个功能的实现应当放在客户端（或者至少由客户端来控制整个协作），并且客户端必须持有此功能所依赖相关数据的副本，这个副本应当尽量与服务器端的源保持同步。

  图一"进入房间"失败示意

    注意：点击图片可以放大观看

    QQGame还存在一个明显的不足，就是：玩家如果在游戏一段时间后，离开了某个房间，并且想进入其它房间，这时QQGame并不会刷新所有房间的当前人数，造成玩家据此信息所选的待进入房间往往实际上人数已满，使得进入步骤失败。笔者碰到的最糟情形是重复3、4次以上，才最后成功进入另外某个房间。此缺陷其实质是完全放弃了客户端数据副本与服务器端的源保持同步的原则。

    实际上，QQGame的开发者有非常充分的理由来为此缺陷的存在进行辩护：QQGame同时在线的用户数超过百万甚至千万数量级，如果所有客户端要实时（所谓实时，就玩家的体验容忍度而言，可以定为不超过1秒的延迟）地从服务器端获取更新数据，那么最终只有一个结果--系统彻底崩溃。设想一下每秒千万次请求的吞吐量，以普通服务器每秒上百个请求的处理能力（这个数据是根据服务请求处理过程可能涉及到I/O操作来估值的，纯内存处理的情形可能提高若干数量级），需要成千上万台服务器组成集群方能承受（高可用性挑战）；而随着玩家不断地进入或退出游戏房间，相关数据一直在快速变化中，正向来看，假设有一台中心服务器持有这些数据，那么需要让成千上万台服务器与中心保持这些动态数据的实时同步（数据一致性挑战）；相对应的，逆向来看，玩家进入房间等请求被分配给不同的服务器来处理，一旦玩家进入房间成功则对应服务器内的相关数据被改变，那么假定中的中心服务器就需要实时汇集所有工作服务器内发生的数据变动（数据完整性挑战）。同时处理上万台服务器的数据同步，这需要什么样的中心服务器呢？即使有这样的超级服务器存在，那么Internet网较大的（而且不稳定的）网络通讯延迟又怎么解决呢？

    对于软件缺陷而言，可以在不同的层面来加以解决--从设计、到需求、甚至是直接在业务层面来解决（例如，08年北京奥运会网上购票系统，为了解决订票请求拥塞而至系统崩溃的缺陷，最后放弃了原先"先到先得"的购票业务流程，改为：用户先向系统发订票申请，系统只是记录下来而不进行处理，而到了空闲时，在后台随机抽选幸运者，为他们一一完成订票业务）。当然解决方案所处的层面越高，可能就越让人不满意。就上述进入房间可能遭遇失败的缺陷而言，最简便的解决方案就是：在需求层面调整系统的操作方式，即增加一个类似上篇所述"自动快速加入游戏"的功能--"自动进入房间"功能。系统在服务器端为玩家找到一个人数较多又未满的房间，并尝试进入（注意，软件需求是由用户的操作目标所驱动的，玩家在此的目标就是尽快加入一个满意的游戏组，因此由系统来替代玩家选择目标房间同样符合相关目标）。而为了方便玩家手工选择要进入的房间，则应当增加一个"刷新当前各房间人数"的功能。另外，还可以调整房间的组织模式，例如以地域为单位来划分房间，像深圳（长城宽带）区房间1、四川（电信）房间3、北美区房间1等，在深圳上网的玩家将被系统引导而优先进入深圳区的房间。

    不管怎样，解决软件缺陷的王道还是在设计层面。要解决上述缺陷，架构设计师就必须同时面对高可用、数据一致性、完整性等方面的严峻挑战。

    在思考相关解决方案时，我们将应用若干与高性能服务器集群架构设计相关的一些重要原则。首先是"分而治之"原则，即将大量客户端发出的服务请求进行适当的划分（例如，所有从深圳长城宽带上网的玩家所发出的服务请求分为一组），分别分配给不同的服务器（例如，将前述服务请求分组分配给放置于深圳数据中心的服务器）来加以处理。对于QQGame千万级的并发服务请求数而言，采用Scale Up向上扩展，即升级单个服务器处理能力的方式基本上不予考虑（没有常规的主机能处理每秒上千万的请求）。唯一可行的，只有Scale Out向外扩展，即利用大量服务器集群做负载均衡的方式，这实质上就是"分而治之"原则的具体应用。

    图二 分而治之"下的QQGame游戏服务集群部署

    然而，要应用"分而治之"原则进行Scale Out向外扩展，还依赖于其它的条件。如果各服务器在处理被分配的服务请求时，其行为与其它服务器的行为结果产生交叉（循环）依赖，换句话讲就是共享了某些数据（例如，服务器A处理客户端a发来的进入房间#n请求，而同时，服务器B也在处理客户端b发来的进入房间#n请求，此时服务器A与B的行为存在循环依赖--因为两者要同时访问房间#n的数据，这一共享数据会造成两者间的循环依赖），则各服务器之间必须确保这些共享数据的一致完整性，否则就可能发生逻辑错误（例如，假定房间#n的人数差一个就满了，服务器A与B在独自处理的情况下，将同时让客户端a与b的进入请求成功，于是房间#n的最终人数将超出上限）。而要做到此点，各服务器的处理进程之间就必须保持同步（实际上就是排队按先后顺序访问共享数据，例如服务器A先处理，让客户端a进入房间成功，此时房间#n满员；此后服务器B更新到房间#n满的数据，于是客户端b的进入请求处理结果失败），这样，原来将海量请求做负载均衡的意图就彻底失败了，多台服务器的并发处理能力在此与一台实质上并没有区别。由此，我们导出了另外一个所谓"处理自治"（或称"行为独立"）的原则，即所有参与负载均衡的服务器，其处理对应服务请求的行为应当不循环依赖于其它服务器，换句话讲，就是各服务器的行为相对独立（注意，在这里，非循环依赖是允许的，下文中我们来分析为什么）。

    由此可见，简单的负载均衡策略对于QQGame而言是解决不了问题的。我们必须找到一种途径，使得在使用大量服务器进行"分而治之"的同时，同时有确保各个服务器"处理自治"。此间的关键就在于"分而治之"的"分"字上。前述将某个地域网段内上网的玩家所发出的服务请求分到一组，并分配给同一服务器的做法，其目的不外乎是尽可能地减少网络通讯延迟带来的负面影响。但它不能满足"处理自治"的要求，为了确保自治，应当让同一台服务器所处理的请求本身是"自治"（准确的说法是"自闭包"Closure）的。同一台服务器所处理的所有请求组成一个服务请求集合，这个集合如果与其它任何与其无交集的（请求）集合（包含此集合的父集合除外）不循环依赖，则此服务请求集合是"自闭包"的，而处理此请求集合的服务器，其"行为独立"。我们可以将针对同一房间的进入请求划分到同一服务请求分组，这些请求相互之间当然是存在循环依赖的，但与其它分组中的请求却不存在循环依赖（本房间内人数的变化不会影响到其它房间），而将它们都分配给同一服务器（不妨命名为"房间管理服务器"，简称"房间服务器"）后，那个服务器将是"处理自治"的。

    图三 满足"处理自治"条件的QQ游戏区域"房间管理"服务部署

    那么接下来要解决的问题，就是玩家所关注的某个游戏区内，所有房间当前人数数据的实时更新问题。其解决途径与上述的方法类似，我们还是将所有获取同一区内房间数据的服务请求归为一组，并交给同一服务器处理。与上文所述场景不同的是，这个服务器需要实时汇集本区内所有房间服务器的房间人数数据。我们可以让每个房间服务器一旦发生数据变更时，就向此服务器（不妨命名为"游戏区域管理服务器"，简称"区服务器"）推送一个变更数据记录，而推送的数据只需包含房间Id和所有进入的玩家Id（房间服务器还包含其它细节数据，例如牌桌占位数据）便可。

    另外，由于一个区内的玩家数可能是上十万数量级，一个服务器根本承担不了此种负荷，那么怎么解决这一矛盾呢？如果深入分析，我们会发现，更新区内房间数据的请求是一种数据只读类请求，它不会对服务器状态造成变更影响，因此这些请求相互间不存在依赖关系；这样，我们可以将它们再任意划分为更小的分组，而同时这些分组仍然保持"自闭包"特性，然后分配给不同的区服务器。多台区服务器来负责同一区的数据更新请求，负载瓶颈被解决。当然，此前，还需将这些区服务器分为1台主区服务器和n台从属区服务器；主区服务器负责汇集本区内所有房间服务器的房间人数数据，从属区服务器则从主区服务器实时同步区房间数据副本。更好的做法，则是如『图五』所示，由房间服务器来充当从属区服务器的角色，玩家进入某个房间后，在玩家进入另外一个房间之前，其客户端都将从此房间对应的房间服务器来更新区内房间数据。要注意的是，图中房间服务器的数据更新利用了所谓的"分布式对象缓存服务"。

    玩家进入某个房间后，还要加入某个游戏组才能玩游戏。上篇所述的方案，是让第一个加入某个牌桌的用户，其主机自动充当本牌桌的游戏服务器；而其它玩家要加入此牌桌，其加入请求应当发往第一个加入的用户主机；此后开始游戏，其对弈过程将由第一个加入用户的主机来主导执行。

    那么此途径是否同样也符合上述的前两个设计原则呢？游戏在执行的过程中，根据输赢结果，玩家要加分或减分，同时还要记录胜负场数。这些数据必须被持久化（比如在数据库中保存下来），因此游戏服务器（『图六』中的设计，是由4个部署于QQ客户端的"升级"游戏前台逻辑执行服务，加上1个"升级"游戏后台逻辑执行服务，共同组成一个牌桌的"升级"游戏服务）在处理相关游戏执行请求时，将依赖于玩家游戏账户数据服务（『图六』中的所谓"QQGame会话服务"）；不过这种依赖是非循环的，即玩家游戏账户数据服务器的行为反过来并不依赖于游戏服务器。上文中曾提到，"处理自治"原则中非循环依赖是允许的。这里游戏服务器在处理游戏收盘请求时，要调用玩家游戏账户数据服务器来更新相关数据；因为不同玩家的游戏账户数据是相互独立的，此游戏服务器在调用游戏账户数据服务器时，逻辑上不受其它游戏服务器调用游戏账户数据服务器的影响，不存在同步等待问题；所以，游戏服务器在此能够达成负载均衡的意图。

 

    图四 存在"非循环依赖"的QQ游戏客户端P2P服务与交互逻辑部署

    不过，在上述场景中，虽然不存在同步依赖，但是性能依赖还是存在的，游戏账户数据服务器的处理性能不够时，会造成游戏服务器长时间等待。为此，我们可以应用分布式数据库表水平分割的技术，将QQ玩家用户以其登记的行政区来加以分组，并部署于对应区域的数据库中（例如，深圳的玩家数据都在深圳的游戏账户数据库中）。

    图五 满足"自闭包"条件的QQ分布式数据库（集群）部署

    实际上，我们由此还可以推论出一个数据库表水平分割的原则--任何数据库表水平分割的方式，必须确保同一数据库实例中的数据记录是"自闭包"的，即不同数据库实例中的数据记录相互间不存在循环依赖。

    总之，初步满足QQGame之苛刻性能要求的分布式架构现在已经是初具雏形了，但仍然有很多涉及性能方面的细节问题有待解决。例如，Internet网络通讯延迟的问题、服务器之间协作产生的性能瓶颈问题等等。笔者将在下篇中继续深入探讨这些话题。

我们一开始的游戏逻辑层是基于网络包驱动的，也就是将 client 消息定义好结构打包发送出去，然后再 server 解析这些数据包，做相应的处理。

写了一段时间后，觉得这种方案杂乱不利于复杂的项目。跟同事商量以后，改成了非阻塞的 RPC 模式。

首先由处理逻辑的 server 调用 client 的远程方法在 client 创建出只用于显示表现的影子对象；然后 server 对逻辑对象的需要client 做出相应表现的操作，变成调用 client 端影子对象的远程方法来实现。

这使得游戏逻辑编写变的清晰了很多，基本可以无视网络层的存在，和单机游戏的编写一样简单。

• 懂至少一种编程语言。 迄今为止， C++因为性能和效率的优越性成为游戏开发者的首选。 Visual Basic, Java 或者 C# 可能也是不错的选择。
  
• 熟悉一种图形库。通常的选择是SDL, OpenGL, 或者DX/D3D。(译者注：网上也有很多免费/付费引擎下载和出售)
• 选择一种网络通讯库。 你可以从WinSock, SDL_net, 或DirectPlay中选择。(译者注：很多人喜欢开发自己独特的网络库，这并不复杂，似乎ACE也是一种选择)
  
• 对游戏开发有大体的经验。 例如，事件循环， 多线程， GUI 设计，等等。

• C/S结构通讯。
• 多平台开发。 你可能希望设计一个MMORPG, 尤其是服务器能运行在多种操作系统。为此，我推荐使用SDL, OpenGL 和SDL_net。
  
• 网站开发。如果你想让用户通过网站查看玩家统计，服务器信息和其他信息，这是必须的。(译者注：其实网站可以交给其他人开发，如果有必要的话)。
• 安全管理。 你当然不想因为有人攻击你的服务器而浪费时间！
• 团队组织能力。 你需要一个你能成功领导和管理的团队。
  

• 创建一个新角色
• 保存那个角色(服务器端)
• 用那个角色登陆
• 能够和其他人交谈
• 能在3D空间游览

• Offset 0: 1 字节 表示传输的命令。
• Offset 1: 2 字节，传输的数据长度。
• Offset 3: 变长，消息内容。

• 服务器响应会更加平滑，因为如果一个玩家需要大量时间(例如从数据库中读取数据)，这会在它自己的线程中完成，不会影响其他人。(译者注：也许作者的意思是每个玩家都有独立的线程，但这对MMORPG不太现实)
• 难以恰当的实现和调试：你可能需要大量同步，并且一个小疏忽就会导致灾难性的后果( 服务器瘫痪，物品复制，等等)。
• 可以利用多处理器。

• 实现和调试更简单。
• 响应速度慢。

• 至少3 个程序员： 1 个做服务器，两个客户端(或者一个客户端，一个负责工具，例如美术插件，世界编辑器，等等)。有6个程序员是最好的，更多就没必要了。这取决于你的领导能力。最少一个美工，2到3个更合适。如果这是个3D游戏，你需要一个3D美工，一个2D美工(制作帖图，界面，等等)，一个动画师，和一个美术部负责人。美术部应该由有经验的人组织和安排，除非你就是个艺术家。,
• 少数世界构建者:创建所有地图是个漫长的过程， 并且直接关系到游戏的成败。再次，你需要一个世界构建部的负责人。你的世界需要协调一致，所以不能只有一个意气用事的人。
• 一个 网站管理员是必须的，除非你精通网站设计，并且愿意花时间做网站。音效和音乐不是必须的，但是有音效和音乐的游戏比没有的会更吸引人。
• 一个游戏经济系统 设计师.。你也许觉得那很简单，可以自己来做，但事实上那是最复杂的工作之一。如果经济系统设计不良(比如物品没有平衡，资源在地图上随意放置，等等。)玩家会觉得无聊并且退出游戏。我们早期的进展存在很大的问题，尤其是因为经济系统主要是由我(一个程序员)设计的，它没有被恰当的计划。 于是，我们花费了两个月来重新思考和建立一整个新的经济系统。这需要一次完全的物品清除。我告诉你，玩家会很不乐意你删除他们的物品。幸运的是，大部分玩家赞同这个想法，但是这么多小时的争论，妥协，解释和时间的浪费还是让我们丧气。以后会更多。
  

• 你无法制作MMORPG, 只有大公司才可以。
  我不同意。虽然制作一款像魔兽世界(World of Warcraft)，无尽任务2(Ever Quest 2)，亚瑟王的召唤2(Asheron's Call 2)，血统2(Lineage 2)，和其他一些游戏对一个小型的自发团队是不可能的，但是做一款像样的游戏还是可以的，只要你有经验，动机，和时间。,你需要1000小时的编程来制作一个可运行的测试版，大概10~15k小时完成几乎完整的客户端和服务器。但是作为团队领导者，你不能只编程。保持团队团结，解决争执，维护公共关系(PR)，技术支持，架设服务器，惩罚捣乱分子，自由讨论，等等都是你的职责。你可能会被非编程的任务淹没。你很可能需要上班/上学，这减少了你花费在项目上的时间。我们很幸运，没有成员离开团队，但是如果这种事情发生，那的确是大问题。假设你的美工半途离开。或者更糟糕，他/她没有给你使用他/她作品的许可。当然这可以通过和他们签订合同来解决，但找另外一个美工仍然很麻烦。一个工程中有两种不同的美术风格也是问题。
• 需要大笔金钱(通常 4-6 位数) 用来架设一个 MMORPG 服务器.
  当然，这不是真的。我见过专业服务器，1000GB/月，不到100美元/月(2~300美元的初装费)。除非你的数据传输协议设计非常不合理，1000GB/月对一个1000玩家在线(平均)的服务器来说足够了。当然，你还需要另一个服务器做网站和客户端下载(客户端下载会占用大量流量，当游戏变得流行的时候)。我们的客户端有22MB，有时候会有400GB/月的传输量。而我们还没有很流行(仍然)。另一件事，我们不需要另一台专用服务器开启这个工程。ADSL/cable服务器可以胜任，直到你的同时在线人数达到20~30。然后要么找一个友好的主机公司，用广告交换免费主机，要么就只能自己掏腰包了。  
  
• 制作一个MMORPG很有趣。
  这不是真的。你可能认为每个人都会赏识你，玩家会支持你，你标新立异，并且，当然，很多玩家都玩你的游戏。玩家可能让人讨厌。即使是完全免费的游戏，他们也能找到理由抱怨。更糟糕的是人们经常会抱怨矛盾的事。战士会抱怨升级太难，商人会对战士掠夺大量钱财很失望。如果你减少怪物掉落物品，有些玩家就会威胁说要退出游戏。如果你增加，同样的一群人会不满新手能更简单赚钱的事实。 真是左右为难。改革和改进是必须的。如果你决定改变某些东西，例如给加工物品增加挑战性，有些人会说太难了。如果你不做，他们又会说太简单无味。你会发现满意的玩家通常不会说什么并且感到满意，同时破坏者会怨声载道。
  

当WOW终于来到中国时，我一边欣喜着终于可以在艾泽拉斯的大陆上自由翱翔，一边却咒骂着9C的破服务器，动不动就宕机。当然，身为游戏程序设计师的我明知道，这大部分的错误都不应归罪于代理商9C，但是，谁让blizzard是我心目中的神，谁又让WOW成为我游戏制作的教科书呢。好吧，我知道上面这段极力追捧blizzard跟WOW的话可能早已让你恶心连连，不堪入目了，对不起，忘了这一节，让我们继续。

服务器宕机后都发生了些什么？

显然的，宕机后玩家会骂，就像我在玩WOW时那样，骂游戏公司，骂老板，骂GM。非常抱歉，我们可爱的玩家们似乎并不清楚，这个时候最该骂的其实是我们这些程序员们。长久的遗忘被我们当成了包容，以至于游戏程序员在公司里都养成了趾高气扬，不可一世的坏毛病：看吧，策划们，你们做的太烂了，数值不平衡，玩法没新意，只会照抄WOW跟大菠萝，能怪玩家骂你们吗？运营不得力，买服务器的钱不知道去了哪里，游戏里卡的要死，偶尔办个活动还没半点吸引力，能不被玩家骂你是无良运营商吗？GM们能不天天被骂家指着骂吗？……呃，又扯远了。

赶紧先把服务器重启吧。老板正站在你的身后，一脸愁容，虽然暂时还没有发作，但看得出来：老板很生气，后果很严重！

玩家们很快又回来了，不得不为玩家们的毅力和执着精神而感动，更为自己的错误而愧疚，凌晨时分，服务器启了又宕，宕了又启，如此反复，可热情的玩家们依然陪着我在折腾。哦，当年安其拉开门的时候，我也曾这样折腾过。

这个时候不是你一个人在战斗。GM们在忙碌地处理着玩家不断打来的投诉电话：刚买的装备在宕机后消失了；花光了身上所有材料合成的武器回档了，但材料却没有还给我……数据库维护组的同事们也在紧张的恢复着数据，尽可能的将玩家的损失减到最少。

真是一件令人沮丧的事。

真的该试着做点什么了吧！

既然我们非常不愿意看到宕机的情况发生，但又无法100%保证写出来的服务器程序一定不会出错，那我们就在当机发生后的抢救措施上花点功夫，让玩家的损失不至于太大，也让我们的维护人员少些压力吧。

一个最简单也最有效的做法是为每一台服务器都配备物理冗余，同步更新冗余服务器上的状态，当宕机发生时，立即将处理切换到后备服务器上。只是，物理冗余的代价太大，从成本方面考虑，老板可能不大愿意点头。

既然不能做硬冗余，那就再来考虑软的吧。

如果只是简单的启动冗余进程，其实是换汤不换药的做法。原来能跑1000人的服务器，由于同时运行了两个相同的进程，使得CPU和内存开销都翻了倍，结果是只能跑500人了。还是要加服务器。

看来只能更深一层，从架构设计上来动手了。

假设我们的游戏世界是由多个独立场景构成的，那么在实现上我们可以让这些场景在进程上也独立，这样做的好处是可以使得一个场景的宕机不会影响到其他场景的正常运行。如果我们的游戏世界物理上没有分隔，是一个无缝的大世界，我们也可以人为的将其分成多个独立区域，所需要做的额外工作是处理好那些站在区域边界附近的对象。事实上，现在的无缝大世界也都是这样实现的。

有了这样一个前提，我们再来看这个已宕掉的场景该如何处理。

还是老办法，赶紧先把它拉起来吧。一个具体可行的方案是，由场景管理器，或者你也有可能叫它世界服务器，来监视各个场景进程的运行状态，当某个场景异常失去联系时，由管理器来将其重新启动。这里需要再花点心思的是，如何让玩家数据正常地发送到新启动的场景进程中，而且这个过程对于客户端来说是透明的。

这个方案听起来似乎不错，只是，如果宕掉的是场景管理器进程，那该怎么办呢？

按照前面的描述，场景管理器可以看作是整个游戏世界的中心，它以一个指挥者的身份维护着游戏世界的有序运行，所以它的宕机对整个游戏世界的影响也将会是巨大的。

有没有什么办法能够使得场景管理器进程再次启动后能够恢复先前的状态呢？

我们可以为管理器和场景进程定义一套协议，使得管理器不仅能够创建并恢复一个已有场景，而且场景管理器还能通过现有的场景进程数据恢复出自己。

一个理论上可行的方案是，场景管理器与场景进程间保持TCP长连接，并以一定频率进行心跳联系，任意一方发现联系中断或长时间未收到心跳包后都会立即做出处理。

如果是管理器发现场景进程失去联系，那就启动新的场景，如前面所描述的那样。如果是场景进程发现管理器失去联系，那就立即启动重连过程，直接再次连接上管理器，然后立即将自己当前的状态和负责的场景ID报告给管理器。管理器通过这些上报的数据就能恢复出游戏世界内的场景对应关系表，也就是恢复出了自己原来的状态。

进程是恢复出来了，可我们忘了最重要的内容：数据。当场景进程宕机后，上面保存的玩家属性数据也随之丢失了，虽然我们能够再次将这个场景创建出来，并把原来在这个场景内的客户端数据重新定向过来，但这些客户端对应的玩家对象的数据却没有了，游戏仍然无法继续。

也许我们可以再做一点修改，把场景内的玩家数据分离出来，保存到一个独立的进程上，比如，我们可以把这个进程叫做数据服务器，或者数据中心之类的。一个隐含的要求是，数据服务器的逻辑实现非常简单，简单到你可以认为它是绝对安全的，不会宕机。所以，保存在这里的玩家数据也就是绝对安全的。

让我们在这个问题上稍微再深入一点。

场景进程上每次执行玩家的游戏逻辑时都要异步地到数据服务器上来存取数据，这个开销可能太大，而且会使得一些游戏逻辑的实现变的很复杂，那么，把一些会频繁使用到的数据直接保存在场景进程中，当数据发生改变时同步更新到数据服务器上，这样可能会比较容易接受。

老板全都满意了吗？

从理论上来说，我们已经解决了场景进程宕机和管理器宕机后的状态恢复问题，并且在场景恢复后也不会因为丢失了玩家数据而无法继续进行游戏，而且，只要处理得当，这个过程对客户端来说可以是完全透明的，也就是玩家根本不知道服务器上有个进程意外结束，我们做了这么多的工作来将它恢复了。

事实上，这个过程的透明也是必须的，我们并不需要嚷嚷着告诉我们的用户，也就是玩家，我们做了多少多少事情来让你玩的更顺畅，又花了多少多少精力来解决因为服务器宕机而引起的麻烦，对于最终的用户来说，他只需要享受最好的服务。闲话少说，让我们继续。

真的已经完全解决了所有问题吗？

想象这样一个场景：我带着几个刚刚降临到艾泽拉斯大陆的伙伴冲向了艾尔文森林，去开荒霍格！正在霍格只剩下一丝血的时候，服务器稍稍卡了一下，等我缓过神来，面前的霍格骤然消失，地上也不见尸体。找了一圈，它正在出生点摇头晃脑，也在四处张望，但头顶上的血条分明是，满血！

怎么回事？

处理这张地图的场景进程意外结束了，服务器的宕机处理机制很快地恢复了这个场景进程，并且把我的客户端数据重新定向到了新场景。只是，事情并不是一切都完美。因为这个场景是完全重新创建的，这意味着所有的怪物也是重新创建并被摆放到了初始位置，所以，只剩下一丝血的霍格碰上了好运气……

类似的还有，正在护送NPC返回营地，在稍微停顿了一会儿之后，NPC又重新回到了原来的地方，等等。

虽然这比起最初的“客户端被迫断开连接，服务器端数据丢失”要进步了许多，但会给我工资的老板仍然可能不太满意，他希望，霍格应该还在我的面前，而且只有一丝血，那个跟着我的NPC也应该还在我旁边……

我要是不能说服老板，这是“根本不可能完成的任务！”，那也就只能坐下来再试一试。

也许，可以考虑将所有对象的数据都保存到数据服务器上，当然，这要求每个怪物都跟玩家一样，有一个唯一ID，这一点实现起来可能会有些麻烦。

再不然，为对象提供一个从已有的内存数据构造的方法，这样便可以使用共享内存来保存现场数据，再从共享内存中恢复出原来的对象。理论上来说，这个方法是可行的，只是，这三十多个字的文字描述要用C++来实现也可能将会是一项极大的挑战，所以，这也仅只是可供参考的一个尝试方案。

我想，我们走的够远了

让我们先暂停一会儿，回过头来看一看最初的目的。其实我们想要的只是尽可能的让服务器进程不要宕机，如果实在是没有办法，就尽可能的让宕机后的玩家损失比较小，不需要我们做大量的工作去做善后处理。

很简单的需求，似乎我们纠缠的有些过头了。

写出能够稳定运行的程序是对程序员的最基本要求，如果一个程序连稳定性都不具备，那根本都不用再去考虑功能啊、扩展啊等其他标准了。但是，正如我最开始所说的，没有一个人能够100%保证他写出来的服务器程序是绝对不会崩溃的。我们所能要求的只是尽可能的仔细，尽可能的多一些必要的测试，离安全尽可能的更近一步。

剩下的就是在宕机后如何降低损失的问题了。

对于一般的MMOG来说，玩家在进入游戏时会从数据库中将该玩家的所有相关数据读到内存，以便快速的进行游戏逻辑的处理，而在玩家下线时再将数据的改动存回数据库。

显然的，当服务器进程出现意外宕机时，内存中所有的数据都丢失了，这也就造成了玩家数据的回档，而且玩家在游戏中呆的时间越长，回档的损失就越大。所以，一个被广泛采用的做法是为玩家数据实现一种定时存盘的机制，就像现在大多数的单机游戏一样，AutoSave。比如，每5分钟自动为玩家存一次盘，这样就可以使得回档的最大损失控制在5分钟以内。

另外，对于一些重要数据的变动，比如玩家花大量游戏货币购买了一件贵重的武器装备，这时可将玩家数据立即做一次存盘操作，这也将有效的减少玩家的重大损失。

听起来这是一项不错的技术，在意外宕机的时候最多只回档5分钟，而且还没有贵重物品的损失，玩家应该是可以接受的吧。

我已经听到了数据库维护员的咆哮

“数据库已经快要崩溃了，你就不能让每秒需要执行的SQL语句少一点吗？”

“呃………”

我一直以为我们的数据库非常强大，可以处理任何的数据，唯一的缺点就是查询速度比直接内存读取要慢很多。所以我使用了异步数据存取的方法，并且开启了多个数据库操作线程来并行的执行我的请求，运行的效果看起来还不错。

也许，我应该来算一算，每秒种究竟丢了多少条操作请求给数据库。

请允许我再自私一回，我已经很久没有提到WOW了……

大概可信的数字是，WOW一组服务器的玩家数量在3000到5000之间，去掉最大的数，再去掉最小的数，最后的平均值是，4000吧，就算4000。

4000人在线，假设也是每5分钟定时存盘一次，再假设所有玩家的存盘时间是平均分布的。这样算下来，每秒种就会有67个玩家向数据库发出存盘请求操作。

才67个，数据库维护组的同事就跟我说不堪重负了？笑话，这数据库服务器是谁买的？

先别急，67是玩家数，但是每个玩家的存盘请求不会只有一条SQL语句。

虽然每个游戏的内容都各有差别，但是一款MMOG需要存入数据库的数据少不了会有技能、物品、任务、宠物、好友、公会这些东西。取决于游戏的类型差异，每个游戏都会有自己的存盘方式，比如我可能会把所有的技能ID作为一条数据来存储，但是我也有可能把每个技能作为一条单独的记录来存储，这样可以方便对技能附加数据的扩展，等等。

但是，游戏中的物品存储大概都是相同的，只能是一件(组)物品作为一条记录来存储。

而且，可以说游戏中存储量最大的就是物品数据。算一算你的角色背包有多大，50格？ 100格？还是200格？不要忘了银行、摆摊位、装备拦、宠物背包和邮箱这些地方也能放物品。并且，在游戏进行过程中，玩家背包中物品数据的变动也是相当的频繁，不断的有药品被用掉，不断地又有些小玩意儿被捡起来，不久后，它们又被卖给了NPC。

虽然你可以使用一些巧妙的比较算法来过滤掉那些实际上没有发生变动的物品更新，另外也不是所有的玩家物品数据变动都很频繁，但在实际运营中，尤其是当玩家的背包格数都很多的时候，物品数据的存盘的确会成为一个很大的问题。

除了物品，还有玩家的基本属性存盘，社会关系存盘等等，再加上全局公共数据的存盘，如公会数据，拍卖行物品数据，如果老板也要我在游戏中开上一家拍卖行的话。

这么一算下来，似乎是有些多了。

再一次的挑战

具体的数字将取决于游戏的类型和设计的数据表结构。

而数据库服务器能承担的每秒查询数则取决于数据库服务器的软硬件配置情况。

但是一般来说，数据库维护人员可能会告诉我，当每秒执行的SQL语句数达到1000条时，数据库服务器将会感受到明显的压力，我可能也会看到数据库执行队列中的请求数一直在增长，也可能会看到数据库服务器间歇性地拒绝响应，等等。

看起来我们又一次的面对到了巨大的打冷战。

这个问题的起因是什么？我们不希望服务器进程宕机时回档太久，所以我们增加了一个玩家数据定时存盘的机制，结果却导致了数据库请求的骤然增多。

那再退回到这个起点处，将定时存盘的时间间隔延长点，比如10分钟才存一次？数据库的压力会有缓解，但最初的问题却又会有所暴露。真是个两难的问题。

既想要玩家数据存盘间隔时间短一点，又不想给数据库造成的压力太大。

同样的需求似乎出现过很多回了：在中间加一层代理做缓冲。我们姑且称这一层代理为数据库代理服务器，它所要完成的工作是从场景进程收集玩家的定时存盘请求数据，再以一个低一点的频率写入到数据库。

听起来这又像是一个换汤不换药的做法，写入数据库的时间间隔还是变长了。但实际上在前面我们就曾经描述过，如果服务器进程不会出现意外的宕机，玩家数据只需要在他上线时读取，在他下线时写入即可，中间添加的这些定时存盘过程完全只是为了防范宕机回档所造成的巨大损失。

因为这个中间代理层的加入，我们把场景进程宕机的隐患与数据丢失的后果隔离开来了，现在即使场景进程宕机，数据还在数据库代理服务器上，当然这里又隐含了一个条件：数据库代理服务器需要足够稳定，不会在场景进程之前先宕掉。事实上，因为这个代理进程的工作是，我们完全有理由相信，这个进程是非常稳定的，那样的话，多久时间才把缓存的数据真正写入数据库，就看你自己的喜好了。

该结束了吧

是否有些似曾相识的感觉？

没错，前面我们曾经描述过一个数据服务器，也是这样说的。

所以，数据服务器，数据库代理服务器可以合并到一起，来共同保证数据的安全。

再加上场景进程与管理器进程的恢复协议，让服务器的重启对玩家保持透明。

看起来这个晚上可以睡个安稳觉。

目前在做一个超大地图MMORPG的场景管理部分，客户端通过动态预读解决了超大图量的动态加载，但是在做人物行走的时候遇到了一些问题：
　　一张地图上的PLAYER和NPC等是存放在一个list中的，地图超大那么上面的PLAYER就可能超多（预计大于２００），这样的话每个行走动作都要发送２００条以上的消息，这对于服务器是一种很大的负担，而且这种负担是呈级数增长（10个玩家都走一步服务器将发送10*10=100条消息，而200个的话就是200*200=40000条消息！），可能任何服务器都无法负担。
　　肯定有很多朋友都遇到了类似的问题，很想知道大家是怎么解决的？
　　

方案一：
　·服务器上每个场景用一个list来保存上面的player和NPC
　·玩家行走、进入和离开等事件发给list中的所有player
　·客户端的list保有该场景上的所有player和npc
　优点：处理起来简单直接
　缺点：发送的消息会随玩家数量的增加而暴增、客户端负担很重

方案二：
　·服务器上每个场景用一个list来保存上面的player和NPC
　·玩家行走、进入和离开等事件只发给该玩家一定范围内的Player
　·客户端的list只保有本玩家附近的player和npc
　·在服务器可以考虑使用hash表来优化查询速度
　优点：减少了服务器发送消息的数量、减轻了客户端的负担
　缺点：实现相对复杂，服务器负担大大加重（因为要不断判断玩家间的位置关系）

方案三：
　·在服务器上把场景划分为小区域（大于屏幕大小）。每个区域对应一个list，场景中的所有对象按他们的位置加入到对应区域的list中，那么每次行走只需要把消息发送给最多４个相临区域的Player
　·客户端的list只保有本玩家附近的player和npc
　优点：大大减轻了服务器遍历list的负担、减少了发送消息的数量、减轻了客户端的负担
　缺点：实现非常复杂、而且在服务器需要不断判断玩家是否跨越区域

方案四：
　·服务器上场景的每个TILE保存一个Object指针用来绑定该格子上的player或NPC
　·玩家行走、进入和离开等事件发给玩家周围一定范围内的player
　·客户端保有该player周围一定范围内的player和npc
　优点：处理起来极为直接、避免了耗时链表遍历（典型的以空间换时间）
　缺点：地图每个TILE都要加入一个指针变量（管理不善容易出错）、每次发送场景广播要遍历所有TILE

方案五：
　·服务器上每个场景用一个list来保存上面的player和NPC
　·不使用事件通知，而使用状态位置通知的方式通过定时发送状态来更新客户端的player和npc状态
　·客户端保有该player周围一定范围内的player和npc
　优点：处理比较简单
　缺点：实时性太低，对于要求同步比较精确的ＡＲＰＧ不太适合

一、游戏世界的划分

理想状态的游戏世界仅由一个完整的场景组成，在《魔兽争霸 III 》、《 CS 》这样的单机游戏中，所有玩家位于该场景中，在理论上，位于该场景中的任意玩家都可以看到游戏中所有玩家并与之交互，出于公平性和游戏性（而不是技术上）的考虑，游戏中并不会这样做。

然而，目前的 MMORPG 中，几乎没有任何一款可以做到整个游戏世界只包含一个场景，因为在一款 MMORPG 中，同时在线的玩家数量成百上千，甚至是数万人同时在一个游戏世界中交互。以现在的网络技术和计算机系统，还无法为这么多玩家的交互提供即时处理。因此， MMORPG 的游戏世界被划分为大小不等、数量众多的场景，游戏服务器对于这些场景的处理分为分区和无缝两种。

在分区式服务器中，一个场景中的玩家无法看到另一个场景中的玩家，当玩家从一个场景到另外一个场景跨越时，都有一个数据转移和加载的过程（尤其是从一个分区服务器跨越到另外一个服务器时），玩家都有一个等待的时间，在这段时间内，服务器的主要工作是实现跨越玩家数据的转移和加载以及后一个场景中玩家、 NPC 等数据的传输，客户端的主要工作是实现新场景资源的加载和服务器通信。主要时间的长短主要取决于后一个场景中资源数据的大小。分区式服务器的优点主要是各分区服务器保持相对独立，缺点是游戏空间不够大，而且，一旦某个分区服务器中止服务，位于该服务器上的所有玩家将失去连接。

所谓无缝服务器，玩家几乎察觉不到场景之间的这种切换，在场景间没有物理上的屏障，对于玩家而言，众多场景构成了一个巨大的游戏世界。场景之间，甚至服务器之间“没有了”明确的界线。因此，无缝服务器为玩家提供了更大的游戏空间和更友好的交互，实现了动态边界的无缝服务器甚至可以在某个服务器中止服务时，按一定策略将负载动态分散到其他服务器。因此，无缝服务器在技术上要比分区服务器更加复杂。

目前国内上市的 MMORPG ，大多采用分区式服务器，做到无缝世界的主要有《完美世界》和《天下贰》等，国外的 MMORPG 中，像《魔兽世界》、《 EVE 》等，都实现了无缝世界。

无缝服务器与分区式服务器在技术上的主要区别是，当位于场景 S1 中的玩家 P1 处于两个（甚至更多）场景 S1 、 S2 的边界区域内时，要保证 P1 能够看到场景 S2 中建筑、玩家、 NPC 等可感知对象。而且边界区域的大小要大于等于 P1 可感知的范围，否则就可能发生 S2 中的可感知对象突然闪现在 P1 视野中的异常。

无疑，无缝世界为玩家提供了更人性化和更具魅力的用户体验。

二、无缝世界游戏服务器的整体架构

MMORPG 的服务器架构从功能上主要划分为三种：

1、 登录服务器（ Login Server ）

登录服务器用于玩家验证登录，并根据系统记录玩家信息得到其所在节点服务器，并通过世界服务器为登录玩家和对应节点服务器建立连接。

2、 世界服务器（ World Server ）

世界服务器将整个游戏世界划分成不同场景，将所有场景按一定策略分配给节点服务器，并对节点服务器进行管理。世界服务器的另一功能是与登录服务器交互。因此，世界服务器是登录服务器、节点服务器的沟通桥梁，当然，一旦玩家登录成功，世界服务器将主要处理节点服务器间的通信。因此，世界服务器对于玩家是透明的。

3、 节点服务器（ Node Server ）

节点服务器负责管理位于该节点的所有玩家、 NPC 的所有交互，在无缝世界游戏中，由于边界区域的存在，一个节点服务器甚至要处理相邻节点上位于边界区域的玩家和 NPC 的信息。

在具体实现上，不同的 MMORPG 为了便于管理，可能还会具有 AI 服务器、日志服务器、数据库缓存服务器、代理服务器等。

三、 无缝世界游戏服务器的主要技术需求

1、 编程语言（ C/C++ 、 SQL 、 Lua 、 Python ）

2、 图形库（ Direct 3D 、 OpenGL ）

3、 网络通信（ WinSock 、 BSD Socket ，或者 ACE ）

4、 消息、事件、多线程、 GUI

5、 OS

三、无缝世界游戏服务器需要解决的主要问题

1、 资源管理

无论是服务器还是客户端，都涉及到大量资源：玩家数据、 NPC 数据、战斗公式、模型资源、通信资源等。当这些资源达到一定规模，其管理的难度不可忽视。而且，资源管理的好坏，直接关系到游戏的安全和生命。

2、 网络安全

安全永远是第一位的，我们无法指望所有的玩家及其所持的客户端永远是友好的。事实上，威胁到游戏的公平性和安全性的大多数问题，归根结底，都是由于网络通信中存在的欺骗和攻击造成的，这些问题包含但不限于交易欺骗、物品复制。

3、 逻辑安全

逻辑安全按理说应该是游戏中最基本的考虑，覆盖的范围也最广最杂。随机数系统是一个非常值得重视的问题，随机数不仅仅用于玩家可见的一些任务系统、战斗公式、人工智能、物品得失等，还可用于网络报文加密等。因此，随机数系统本身的安全不容忽视。另外一个常见的逻辑安全是玩家的移动，最主要的就是防止加速齿轮这样的变态操作。

4、 负载均衡

MMORPG 中的负载均衡包括客户端及服务器资源管理和逻辑处理的负载均衡，其中最难预知的是网络通信的负载均衡，正常情况下的网络通信数量是可以在游戏设计时做出评估的，但因恶意攻击造成的网络负载是无法预测的。因此，负载均衡所要处理的主要是实时动态负载均衡和灾难恢复。负载均衡需要解决的问题包括负载监控、负载分析、负载分发和灾难恢复。

5、 录像系统

录像系统的构建，主要用于重现关键数据的输入输出，如玩家交易、玩家充值，或者当 bug 出现后，为逻辑服务器（泛指上文提到的所有类型服务器，主要是节点服务器）相应部分启动录像系统。待收集到足够数据后，通过录像系统重现 bug 。为了使逻辑服务器不受自身时间（如中断调试等）的影响，还可以专门设计心跳服务器来控制数据传输。

四、总结

在 MMORPG 中，真正的 bug 永远存在于将来。从这一点出发，关于 MMORPG 中游戏世界的构建，怎样苛刻的思考都不为过。

参考资料：

1、 [美] Kim Pallister编, 孟宪武 等译. 游戏编程精粹5, P467-474, P516. 人民邮电出版社, 2007年9月. 北京.
2、 [美] Thor Alexander编, 史晓明 译. 大型多人在线游戏开发, P174-185. 人民邮电出版社, 2006年12月. 北京.
3、 [美] Dante Treglia编, 张磊 译. 游戏编程精粹3, P117-122. 人民邮电出版社, 2003年7月. 北京.
4、 [美] Mark DeLoura编, 王淑礼 等译. 游戏编程精粹1, P90-93. 人民邮电出版社, 2004年10月. 北京.
5、 [美] Douglas 等著, 於春景 译. C++网络编程 卷1. 中国电力出版社, 2004年11月. 北京.
6、 [美] Stephen D. Huston 等著, 马维达 译. ACE程序员指南. 中国电力出版社, 2004年11月. 北京.
7、 [美] Erich Gamma等著, 李英军 等译. 设计模式. 机械工业出版社, 2000年6月. 北京.
8、 游戏引擎全剖析. http://bbs.gameres.com/showthread.asp?threadid=101293.
9、 服务器结构探讨：登录服的负载均衡. http://gamedev.csdn.net/page/351491d0-05ad-48a4-85e1-77870bc1eef3.
10、服务器结构探讨：最终的结构. http://gamedev.csdn.net/page/28695655-974c-4291-8ac4-2589c4e770d3.