CN102215209A - 一种用于大型多人在线角色扮演的网络游戏引擎 - Google Patents

Abstract

本发明公开的是一种用于大型多人在线角色扮演的网络游戏引擎，其包括逻辑主服务器集群，与逻辑主服务器集群连接的副本服务器集群、数据服务器、登陆服务器、日志服务器，客户端登陆服务器相连接，数据服务器通过数据适配器与逻辑主服务器集群相连接；本发明提供了灵活多变、安全稳定的游戏环境。

Description

一种用于大型多人在线角色扮演的网络游戏引擎

技术领域

本发明涉及网络游戏技术领域，尤其涉及一种网络游戏引擎。

背景技术

大型多人在线角色扮演游戏为世界上最受欢迎的游戏类型，这种游戏类型的关键技术需要安全、稳定，因此必须具有灵活可变的游戏引擎。

目前的网络游戏引擎的底层普遍采用C++语言编写，游戏逻辑基本上都由底层语言直接编写，非常不灵活，如果游戏的制作人需要对游戏内数据进行调整，程序员就需要修改底层代码，非常不安全。而且修改完代码还需要数分钟甚至数小时的编译过程才能启动测试，速度慢。

早期的网络游戏承载量不大，内容不多，因此各大网络游戏引擎研发公司多采用集中式开发，即将各种服务逻辑例如网关服务器，地图服务器，逻辑服务器，数据库服务器，日志服务器等整合在一个软件进程中执行，对于用户的请求采用排队式处理，即先来先服务的处理原则。

最新设计的大型多人在线角色扮演游戏带来了网络游戏市场爆发式的增长。大型多人在线角色扮演的网络游戏对游戏引擎的要求很高，单个服务器组的承载量少则数千，多则上万。对于上万人的承载量来说，集中式的服务器引擎已经很难满足要求。例如，一个用户请求的处理时间为1毫秒，而10000个用户需要在同一时刻处理完则需要10秒，而用户需要流畅的游戏体验和节奏明快的游戏情节，长达10秒的延迟在游戏体验上完全不能接受。

在目前的大型多人在线角色扮演游戏中，采用传统的网络游戏引擎已经不相适应了。

发明内容

为弥补现有技术的不足，本发明目的是提供一种用于大型多人在线角色扮演的网络游戏引擎，提供灵活多变、安全稳定的游戏环境。

为了实现上述目的，本发明的技术方案如下：

一种用于大型多人在线角色扮演的网络游戏引擎，其包括逻辑主服务器集群，与该逻辑主服务器集群连接的副本服务器集群、数据服务器、登陆服务器、日志服务器，客户端与该登陆服务器相连接，该数据服务器通过数据适配器与该逻辑主服务器集群相连接。

根据上述的一种用于大型多人在线角色扮演的网络游戏引擎，其中，所述逻辑主服务器集群包含游戏实体；游戏模块，该游戏模块通过事件路由器连接该游戏实体并与之相互通讯；该游戏实体与协议报告器相连接；该事件路由器与该协议报告器相连接；该客户端连接该协议报告器；该客户端通过协议适配器连接该游戏模块。

根据上述的一种用于大型多人在线角色扮演的网络游戏引擎，其中，所述游戏引擎的架构底层是游戏服务逻辑服务器；中间层是网络适配层，该网络适配层包含移动设配协议适配器、客户端协议适配器和游戏管理员协议适配器；顶层是客户端、移动电话、游戏管理员客户端；该底层与该中间层相互通讯；该中间层与该顶层通过互联网相互通讯；该客户端协议适配器与该客户端相互连接，该移动设配协议适配器与该移动电话相互连接；该客户端协议适配器与该游戏管理员客户端相连接。

本发明的有益效果：

本发明提供的网络游戏引擎适合用于大型多人在线角色，整个构架的单台逻辑服务器预计满载承载量是20000人，稳定运行在10000-15000人左右。如果N台逻辑服务器，承载量＝10000*N。更多的玩家可以融入到一个完整的游戏世界中，从而在游戏中实现聊天，战斗，贸易，交友，动作互动都高实时性的游戏体验。本发明的游戏引擎作为大型多人在线游戏强有力的后台，能让所有想进入游戏研发领域的公司降低行业门槛，从而让这些公司主要在游戏的可玩性和游戏理念上给予创新，为广大游戏带来更多更优秀的游戏。

附图说明

以下结合附图和具体实施方式来进一步说明本发明。

图1为本发明系统组成示意图；

图2为逻辑主服务器集群的详细架构图；

图3为本发明网络游戏引擎的网络架构图。

具体实施方式

为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，下面结合具体图示，进一步阐述本发明。

参见图1，本发明一种用于大型多人在线角色扮演的网络游戏引擎，包含逻辑主服务器集群101，与逻辑主服务器集群101连接的副本服务器集群102、数据服务器103、登陆服务器104、日志服务器105。用户可通过任何与登陆服务器104相连接的客户端107登陆。数据服务器103通过数据适配器106与逻辑主服务器集群101相连接。

请见图2，为逻辑主服务器集群101的详细架构图。逻辑主服务器集群101包含游戏实体201，游戏模块202通过事件路由器203连接游戏实体201并与之相互通讯，游戏实体201与事件路由器203均与协议报告器204相连接，客户端205连接协议报告器204并从协议报告器204中读取数据，客户端205通过协议适配器206连接游戏模块202。

游戏实体201包含场景模块207，角色模块208，物品模块209，副本模块210，技能模块211，任务模块212，各模块均与脚本系统213相互连接。

图3为本发明网络游戏引擎的网络架构图。架构底层是游戏服务逻辑服务器301。中间层是网络适配层302，其包含：移动设配协议适配器303、客户端协议适配器304和游戏管理员协议适配器305。顶层是客户端306、移动电话307、游戏管理员客户端308。底层与中间层相互通讯。中间层与顶层通过互联网相互通讯。客户端协议适配器304与客户端306相互连接，移动设配协议适配器303与移动电话307相互连接，客户端协议适配器304与游戏管理员客户端308相连接。

玩家的角色数据是不能跨区使用的，即：在A区建立的游戏角色在B区是无法使用的，各区之间的数据保持各自独立性。我们将这样独立的A区或B区称为一个独立的服务器组，一个独立的服务器组就是一个相对完整的游戏世界。

本发明的游戏引擎服务器内分成两类的模块：场景相关的(如：行走、战斗等)以及场景不相关的(如：公会聊天、不受区域限制的贸易等)。其中这两类分别由两个独立的线程去完成，细分为四个独立模块场景服务器、服务器管理器、数据库代理服务器、AI服务器。各模块的主要功能：

场景服务器：它负责完成主要的游戏逻辑，这些逻辑包括：角色在游戏场景中的进入与退出、角色的行走与跑动、角色战斗(包括打怪)、任务的认领等。

非场景服务器：它主要负责完成与游戏场景不相关的游戏逻辑，这些逻辑不依靠游戏的地图系统也能正常进行，比如公会聊天或世界聊天，之所以把它从场景服务器中独立出来，是为了节省场景服务器的CPU和带宽资源，让场景服务器能够尽可能快地处理那些对游戏流畅性影响较大的游戏逻辑。

服务器管理器：为了实现众多的场景服务器之间以及场景服务器与非场景服务器之间的数据同步，我们必须建立一个统一的管理者，这个管理者就是服务器组中的服务器管理器。它的任务主要是在各服务器之间作数据同步，比如玩家上下线信息的同步。其最主要的功能还是完成场景切换时的数据同步。当玩家需要从一个场景A切换到另一个场景B时，服务器管理器负责将玩家的数据从场景A转移到场景B，并通过协议通知这两个场景数据同步的开始与结束。服务器管理器会与所有的场景服务器和非场景服务器保持socket连接。

AI(人工智能)服务器：由于怪物的人工智能计算非常消耗系统资源，所以我们把它独立成单独的服务器。AI服务器的主要作用是负责计算怪物的AI，并将计算结果返回给场景服务器，也就是说，AI服务器是单独为场景服务器服务的，它完成从场景服务器交过来的计算任务，并将计算结果返回给场景服务器。所以，从网络通信方面来说，AI服务器与众多场景服务器保持socket连接。

数据库代理服务器：它将数据库读写独立出来，单独作成数据库代理，由它统一进行数

据库访问并返回访问结果。

本发明的分布技术的核心是对象请求代管者(Object Request Broker，简称ORB)。作为一个透明的总线式模型，可以与本地或者远程的对象进行交互。本发明的游戏引擎对象对外呈现一组接口，客户端获取对象的引用，通过引用进行方法的调用。ORB负责查找对象的实现，发送请求并处理返回结果。为了调用一个服务，客户端需要调用远程对象实现的方法。服务器端提供的服务，封装成为一个对象，对象的接口使用IDL(Interface DefinitionLanguage)描述。客户端通过调用IDL中定义的方法与服务器端进行交互，不用关心实际对象的实现。支持面向对象的一些特性，例如：数据封装，多态，继承。本发明的游戏引擎支持多重继承，一个对象可以有多个接口。

为了调用一个远程的方法，客户端调用本地的桩函数，桩函数将参数封装成为请求，将请求发送给服务器端。服务器端将请求传递给Server Stub，对参数进行解包，并调用实际的函数。

在本发明的游戏引擎中，客户端的桩称为proxy，服务器端的桩称为stub。假设有一种Grid对象服务，Grid对象维护一个二维的整数，支持两组方法：第一组是get和set，可以设置某个格子上的数值；第二组是reset，复位某个格子上的数值。采用本发明的游戏引擎调用，则客户端端的处理步骤如下：

1.客户端调用本发明的游戏引擎库函数CoCreateInstance，使用CLSID_Grid和IID_IGrid1作为参数。

2.本发明的游戏引擎库请求服务器创建对象

3.服务器端本发明的游戏引擎获取指向CLSID_Grid的类工厂指针，调用其CreateInstance函数。

4.类工厂创建一个对象，然后服务器端调用QueryIntreface获取指向IID_IGrid1接口的指针。

5.本发明的游戏引擎库将指向pIGrid1接口的指针返回给客户。

6.客户端调用pIGrid1接口的get方法。

作为游戏中的一个角色。在服务器端和客户端同时存在，服务器端负责角色对象的逻辑，以及各种属性的更新；客户端负责角色对象的显示，与玩家进行交互。这应该是一种非常典型的分布式对象模式。但是目前的分布式对象技术，能够支持这种模式吗；答案是不支持。目前对于分布式对象的概念，一般指RMI、COBRA、DCOM等分布式组件技术。但是我们认为对象应该是具有属性的，不应该只有方法；在面向对象编程语言中的象概念更加贴切。而目前的组件技术，都是只提供了一个抽象的接口，即便是Web Service，也只供了远程调用的方法(可以看作是一个抽象的接口)，并没有提及属性，而且也不支持定义属性。在分布式应用中，对象的属性重要吗？目前的组件技术和Web Service技术，都没有定义属性，不是发展的很好，也能够方便的应用于各种场合下吗？

回答这个问题，这里简单的给出一个例子：对象在某些状态下(例如：忙)，某些接口不能够调用(例如：查询)，调用会返回错误。按照目前组件技术的描述方法，如下：

Interface obj ectclass{

char*Query(in int arg，out int result)；

}；

对于该组件的使用者，如何调用呢，反复调用Query函数，直到正确的结果吗？这个例子非常简单，但是使用目前的分布式组件技术，很难实现。对象的属性分布到客户端(调用者)，有利于客户端根据对象的状态，更加灵活地进行服务调用，为客户提供更好的服务。仅仅是对象的属性分布到客户端就够了吗？回想前面对于Web技术的发展过程中，javascript为什么引入，并得到迅速发展。在客户端和服务器端进行交互时，如果客户端能够进行一些预先的处理，也能够提供更好的服务。比如简单类似输入参数的校验问题，如果在客户端能够进行，则不再需要再发送到服务器，并等待几秒甚至几十秒之后，再得到错误的反馈。这需要把部分对象的脚本(甚至代码)也需要部署到客户端，Web Service和组件模型提出了一种新的编程模型，这也是出现和发展起来的原因。但是快速发展不能够说明这些技术本身不存在问题，对于相对复杂的Web服务，细粒度的组建服务，这些技术还不是很成熟，或者说，不能够进行处理。本文提出的SRP分布式对象模型，解决了这些问题。本发明的游戏引擎提出的分布式对象的概念如下：对象具有属性，方法和执行脚本(代码)。对象在服务器端和客户端同时存在，并且客户端对象有与服务器端相同的属性。客户端对象和服务器端对象通过唯一标识(一般使用UUID)建立一一对应关系。对象的属性，脚本(代码)如何分布到客户端，这就需要分布式对象管理系统。

针对上述的例子，如下：

Interface objectclass{

Int BusyFlag；

char*Query(in int arg，out int result)；

}；

这样客户端首先判断BusyFlag是否设置，如果设置，则不进行调用，如果没有设置，则可以调用。采用对象的概念，分布式对象管理系统可以为上层的应用，提供一个统一的接口，即分布式对象管理接口。通过该接口，可以获取对象，对象的属性，调用对象的方法，并接收对象的异步事件。对于前面Web技术和组件技术存在的问题，采用分布式对象的技术，则可以如下处理：

1.数据和资源文件反复下载

每种数据或者资源，都可以定义为一个对象，对象定义属性，说明数据或者资源的版本；

如果数据发生变化，则对象对应的版本属性发生变化，客户端判断属性发生变化之后，再重新下载。如果相同，则不需要下载，直接使用本地缓存的数据即可。

2.不方便维护客户端状态维护

分布式对象管理，支持常连接模式，以方便支持需要维护状态的应用。

3.服务器端不能够主动发起数据的传输。

分布式对象管理，支持常连接模式，服务器可以通过该连接，修改对象的属性，与客户端进行通信。

4.编码简单，通信传输的开销大

分布式对象管理，支持使用自定义通信。

5.细粒度模型

通过分布式对象管理，对象分布到客户端，客户端直接使用对象的属性或者调用对象的方法。不再需要针对每个对象，执行远程创建的过程，因此能够支持成千上午个对象。这种分布式对象模型，能够用于游戏中吗，答案是可以。对象属性同时在服务器和客户端存在，服务器端更新对象属性之后，由分布式对象管理将属性同步到客户端，客户端刷新显示。客户端可以调用服务器端的对象的方法，服务器进行逻辑控制，修改对象的属性。

基于前面的论述，本发明的游戏引擎分布式对象具有以下特点：

1.对象分布在服务器和客户端，两者通过唯一的标识进行对应。

2.对象的执行代码(脚本)，需要分布到客户端。

3.对象的属性，需要分布到客户端。

4.对象象管的数据，需要分布到客户端。

分布式对象管理功能，完成上述对象执行代码(脚本)，属性和数据的分布，并为其上的应用，提供基于对象的标准接口。对象包含属性，方法和数据三部分，其方法通过执行代码(脚本)来体现。为什么说数据是对象的一部分呢？举一个简单的例子能够很好的说明，比如图片对象，其属性有宽度，高度，编码格式，位宽等。很少认为图片实际的数据也是属性，因此将对象数据单独列出来，与属性和方法并列在一起，作为描述对象的一项，更加符合实际。纵观目前分布式对象的概念，不管是DCOM，COBRA等，都没有如此完善的定义，基于现有概念的实现，或多或少都受到一些限制。其实，本发明的游戏引擎分布式对象的概念，在目前的应用中，都有实际的对应。例如，在HTML网页中，如下一段描述图像的脚本：

＜IMG height＝10src＝

“..\images\***”width＝10border＝0＞描述中包含有图像对象的属性(宽度，高度，显示边界，图像文件名称)，实际的图像文件为图像对象的数据。还可以定义Jscript脚本作为图像对象的代码。与这里谈到的本发明的游戏引擎对应。该图像对象的内容，随着HTML文件，在HTTP响中传递给客户端。也即，图像对象的属性，方法和数据，通过HTTP协议分布到客户端。但是包含全了对象的内容(属性、方法和数据)，但是并没有对象的概念，因此基于HTML的应用没有层次结构，其应用扩展受到限制，如前文所述。本发明的游戏引擎分布式对象这些特点的实现，将会遇到一系列新的问题，也会引出对应的关键技术：

1.对象的唯一标识

服务器端和客户端一般分布在不同的物理实体上，其对象之间对应关系，需要唯一一个标识来确定，这里认为采用UUID是一个不错的选择，不同计算机上产生的UUID不重复，并且范围足够大，可以唯一在网络环境中标识一个对象。

2.对象和对象属性的分类

对象的属性，方法和数据为什么分布到客户端，进一步研究这个问题，就会发现，其目的是为了构造在客户端的运行环境，对象操作进行在客户端本地实现，以提高客户端应用的友好性和体验性。这点也可以从HTML，Jscript，AJAX的发展历程中总结得到。为了构造本地行环境，对象的属性需要有本地属性，记录本地运行对象相关的状态；对象的运行也可能依赖于其它对象，这些被依赖的对象可能是本地创建的，因此对象也分为全局对象和本地对象；对于全局对象，可以进一步分为与一个客户端相关的对象和与所有客户端相关的对象；与一个客户端相关的对象，称为客户对象。与所有客户端相关的对象，称为全局对象。总结起来，对象分为三类：全局对象，客户对象和本地对象；每个对象的属性分为两类：本地属性和全局属性。

3.对象执行代码(脚本)同步

在需要考虑效率的分布式饮用场景下，需要使用C/C++进行对象执行代码的编写，需要编译成二进制文件；分布式对象管理功能，必须支持将执行代码分布到客户端，以便客户端对象能够正常执行其功能。在同步过程中，不能够，也不假设对象的属性不变化，对象可能增加属性，可能删除属性，执行代码可能升级，这些情况，分布式对象管理模块必须能够正确地处理。

4.对象数据的下载

对象数据作为对象的一项内容，其特点与属性不同。在客户端运行环境中，某一时刻，可能不需要对象的所有数据，因此要根据需要进行下载。对象数据的更新，需要触发新的下载过程。分布式对象管理功能，需要支持对象数据的这些功能。

5.对象的分组

在复杂的应用中，客户端不可能同时需要所有的对象，因此可以根据需要，下载需要的对象，以便降低网络的传输。为此，对象需要分为不同的组，客户端根据执行的场景，选择下载不同的对象组。分布式对象管理功能需要包含对象组的管理，对象组在本发明的游戏引擎平台中称为服务项目。

这些问题的解决和实现，就构成了完善的分布式对象管理平台，在此平台上开发的应用，将更加方便，高效和灵活；同时具有类似BS浏览器免安装的特性。

应用本发明的网络游戏引擎，整个构架的单台逻辑服务器预计满载承载量是20000人，稳定运行在10000-15000人左右。如果N台逻辑服务器，承载量＝10000*N。更多的玩家可以融入到一个完整的游戏世界中，从而在游戏中实现聊天，战斗，贸易，交友，动作互动都高实时性的游戏体验，目前网页游戏发展的非常迅速，广大的游戏爱好者已经迷恋社区类休闲游戏带给他们的全新体验，本发明的游戏引擎Ev作为这种游戏强有力的后台，能让所有想进入此领域研发的公司降低行业门槛，从而让这些公司主要在游戏的可玩性和游戏理念上给予创新，为广大游戏带来更多更优秀的游戏。

Claims (5)

1.一种用于大型多人在线角色扮演的网络游戏引擎，其包含逻辑主服务器集群，与该逻辑主服务器集群连接的副本服务器集群、数据服务器、登陆服务器、日志服务器，客户端与该登陆服务器相连接，该数据服务器通过数据适配器与该逻辑主服务器集群相连接。

2.根据权利要求1所述的一种用于大型多人在线角色扮演的网络游戏引擎，其特征在于，所述逻辑主服务器集群包含游戏实体；游戏模块，该游戏模块通过事件路由器连接该游戏实体并与之相互通讯；该游戏实体与协议报告器相连接；该事件路由器与该协议报告器相连接；该客户端连接该协议报告器；该客户端通过协议适配器连接该游戏模块。

3.根据权利要求2所述的一种用于大型多人在线角色扮演的网络游戏引擎，其特征在于，所述游戏实体包含场景模块，角色模块，物品模块，副本模块，技能模块和任务模块；所述场景模块，角色模块，物品模块，副本模块，技能模块和任务模块均与脚本系统相互连接。

4.根据权利要求1所述的一种用于大型多人在线角色扮演的网络游戏引擎，其特征在于，所述游戏引擎的架构底层是游戏服务逻辑服务器；中间层是网络适配层，该网络适配层包含移动设配协议适配器、客户端协议适配器和游戏管理员协议适配器；顶层是客户端、移动电话、游戏管理员客户端；该底层与该中间层相互通讯；该中间层与该顶层通过互联网相互通讯；该客户端协议适配器与该客户端相互连接，该移动设配协议适配器与该移动电话相互连接；该客户端协议适配器与该游戏管理员客户端相连接。

5.根据权利要求3所述的一种用于大型多人在线角色扮演的网络游戏引擎，其特征在于，所述游戏引擎的架构底层是游戏服务逻辑服务器；中间层是网络适配层，该网络适配层包含移动设配协议适配器、客户端协议适配器和游戏管理员协议适配器；顶层是客户端、移动电话、游戏管理员客户端；该底层与该中间层相互通讯；该中间层与该顶层通过互联网相互通讯；该客户端协议适配器与该客户端相互连接，该移动设配协议适配器与该移动电话相互连接；该客户端协议适配器与该游戏管理员客户端相连接。

Images