CN101266633A - 无缝超大规模虚拟游戏世界平台 - Google Patents

Abstract

由于服务器处理能力的限制，一个游戏世界的实例，通常会用一组服务器来共同服务，每台服务器服务游戏世界的个子集。每一个子世界可容纳的并发用户数非常少。由于单台服务器处理能力的限制，玩家在游戏世界中漫游时，不可避免的要跨越服务器的物理边界，如何让这种跨越不影响玩家的游戏体验就成了超大规模连续游戏世界的一个必须要解决的问题。同时，在游戏中我们还要关注玩家的兴趣域(Area of Interest，AOI)以及跨越服务器物理边界时对相关玩家的影响。在这种前提下，状态的同步和消息的发布与接受就变成一个复杂的而且必须要解决的一个问题。其次，当大规模世界的网络游戏运营时，往往把地图分成很多片，每片固定在某一个服务器上，当公测时，由于玩家众多，导致运营商需要准备很多的服务器，收费后，玩家数量下滑，这时就会产生服务器资源浪费，运营后大量玩家可能聚集在某一区域，如果服务器管理固定地图片集，将带来进行地图重新调整分配的不灵活性，最终造成局部过载而大量服务器闲置的后果，一般的以规则几何形状地图片作为搬家单位的动态搬家算法会给游戏设计人员造成很大的限制。另外，现在网络游戏服务器群组也普遍存在各功能系统关联过紧的问题，造成系统的可伸缩性很差。本发明正是为解决上述提到的问题而设计开发的。

Description

无缝超大规模虚拟游戏世界平台

A、技术领域

本发明涉及到大型多人在线虚拟世界、网络游戏、网络教育、网络金融和网络商务等相关网络虚拟开发技术。

B、背景技术

目前主流大型网络游戏的游戏世界都是由多块相互独立的子世界(Zone)构成。这一技术最早由EverQuest采用，后来经Sony进一步完善使得多个游戏世界的实例(Shard)可以运行在同一个物理服务器上以应对大量的并发用户。由于服务器处理能力的限制，一个游戏世界的实例，通常会用一组服务器来共同服务，每台服务器服务游戏世界的一个子集。以目前的技术水平而言，以45度角的2D游戏为例，每个游戏世界的实例一般可以支持2000-4000并发用户。每一个子世界可容纳的并发用户数就更少。由于子世界相互独立，每个子世界类似于一个个独立的房间，玩家在不同子世界间切换需要通过一些特别的渠道例如传送门等等。

这有两方面的问题：第一，对玩家和游戏设计者而言由于子世界的过度分割造成游戏世界的不连续感使得游戏世界与真实世界相似性降低，游戏世界给人的感觉是“假的”世界，限制了玩家体验和游戏设计的自由度；第二，在具体实现中，玩家在不同子世界间切换通常需要关闭已经建立的连接，并建立新的连接，在网络拥堵和服务器资源紧张的时候，新连接的建立经常会失败，以致于玩家会掉线，严重影响游戏体验，有时还会造成更加严重的丢失虚拟装备的问题，对运营商造成很大压力。造成该问题的本质是在目前的游戏开发平台中，游戏服务器集群中的服务器间不能进行协调工作，各自为政。

由于单台服务器处理能力的限制，玩家在游戏世界中漫游时，不可避免的要跨越服务器的物理边界，如何让这种跨越不影响玩家的游戏体验就成了超大规模虚拟游戏世界的一个必须要解决的问题。有别于普通分布式计算，例如大规模并行科学计算中的数据同步和指令同步，在游戏中我们还要关注玩家的兴趣域(Area of Interest，AOI)以及跨越服务器物理边界时对相关玩家的影响。在这种前提下，状态的同步和消息的发布与接受就变成一个复杂的而且必须要解决的一个问题。

其次，当大规模世界的网络游戏运营时，往往把地图分成很多片，每片固定在某一个服务器上，当公测时，由于玩家众多，导致运营商需要准备很多的服务器，收费后，玩家数量下滑，这时就会产生服务器资源浪费，运营后大量玩家可能聚集在某一区域，如果服务器管理固定地图片集，将带来进行地图重新调整分配的不灵活性，最终造成局部过载而大量服务器闲置的后果，一般的以规则几何形状地图片作为搬家单位的动态搬家算法会给游戏设计人员造成很大的限制。另外，现在网络游戏服务器群组也普遍存在各功能系统关联过紧的问题，造成系统的可伸缩性很差。

C、发明内容

一无缝的跨服务器的超大规模虚拟游戏世界

该方案可以附图1所示，游戏服务器集群中的相关服务器通过消息服务总线以发布者/接受者(Pub/Sub)模式进行相关信息的交换，并同时使用操作原语进行系统间的协作，共同完成对游戏世界的支持。关键技术包括高速实时消息服务总线，游戏世界动态划分算法及实现，游戏服务器间操作原语设计及实现，这些技术的合理集成决定了无缝的跨服务器超大规模虚拟游戏世界实现的鲁棒性、灵活性和实用性。其中的创新点包括基于规则的消息过滤及转发机制、规则驱动的游戏世界划分、服务器间实时对象转移机制；

二无缝的跨服务器边界角色迁移

该问题的解决方案由附图2所示，在相邻接的服务器之间的游戏世界有一定程度的叠加，就是说图中的灰色区域(3)由服务器x和服务器y共同处理。也就是说，假设玩家p最初由x处理，当玩家p进入区域3以后，他的状态由x和y一起处理，可以形象的比喻为p在y上有一个影子。这样一来，x和y就可以把p当作自己的处理对象进行相应的处理。技术关键是：

◆当多台服务器同时处理同一玩家时，该玩家状态在相关服务器上的一致性，特别是多个玩家在服务器边界交互的复杂技术问题，附图2.1，2.2，2.3，2.4解释了两个玩家A和B在服务器边界的不同位置情况下的交互流程，需要说明的是这些流程是由虚拟世界引擎的地图系统和分布式共享内存的内部算法，对游戏编程人员是透明的。

◆玩家实际跨越服务器物理边界时的对象和状态的实时转移以及更新

创新点

◆利用分布式共享内存的思想，借助近年来日益成熟的分布式对象技术，我们设计并初步实现了利用多台服务器物理内存但相互“共享”的分布式对象池，该技术可以保证对象的唯一性，使得编程得到简化，不需要考虑多服务器间的同步以及分布式对象的管理(创建，状态维护以及清除)。

◆对玩家自身、玩家间、玩家和机器人间的操作指令的基于规则的过虑和转发，比如只读信息的指令是不会被转发到其他服务器内的影子或复制体的。

◆玩家实际跨越服务器物理边界时的锁定玩家对象的指令协议

三为虚拟世界优化的分布式共享游戏对象

该方案可以如附图3所示，具体来讲所有游戏对象均由分布式对象系统来维护，而不是由处理它的每一个具体的服务器来完成。分布式对象系统对外提供对象生命周期管理功能，例如：对象的创建、对象的更新和对象的删除。

同时分布式对象系统有严格的同步机制，可以将多台服务器对同一对象的访问和操作优化的串行化，以保证对象的唯一性。以更新一个已经存在的对象为例来讲，当一台服务器要访问一个对象时要经过如下的主要步骤：

1.向分布式对象系统申请对某个对象的访问

2.分布式对象系统检测该对象的合法性，以及是否有其他服务器已经获得该对象的访问；如果任何一个条件不符合，将返回无效；否则对该对象进行加锁并返回该对象句柄；

3.服务器根据分布式对象系统返回作如下判断：如果无效将等待一定时间并返回1(或取消该请求；如果拿到对象句柄，进入4)

4.对该对象进行相关操作，并将更新后对象送回分布式对象系统；

5.分布式对象系统对该对象进行存储并且返回结果给相关服务器；对该对象进行解锁，允许其他服务器对其访问

技术关键

◆分布式对象系统的设计和实现中对象管理和存储的效率和有效性是一个关键点；此外对象锁机制的设计是另一个关键点。

创新点

◆为虚拟世界优化的分布式共享内存加内存中的分布式轻量级数据库

◆游戏对象主体和复制体在多台服务器间数据同步量的最小化，只有游戏对象在一个计算帧内被改变的属性才会被同步到其他服务器的复制体内。

四游戏世界的划分及管理

游戏世界的动态划分及动态负载分布方案由附图4所示，通过对服务器负载的实时监控，我们可以掌握游戏服务器集群中的负载分布情况，并通知地图划分服务，该服务将根据事前制定好的规则进行动态地图划分并通知和协调服务器集群进行负载的重新分布。负载的重新分布分为发散和集中两类型，发散的算法的总体概要流程用下面的伪代码给出：

        SpreadLoad(GSi，targetLoad)

        {

        //first try to distribute to neighbors

        leftLoad＝DistributeToNeighbors(GSi，targetLoad)；

          while(leftLoad＜＝targetLoad){

           //Find a new lightly loaded candidate

           GSj＝FindUnvisitedLightestServer()；

           if(not found)return；//No more resources

           //Distribute to lightest loaded game server

           PartitionGraph(GSi，GSj，targetLoad)；

        }

    }

    DistributeToNeighbors(GSi，targetLoad)；

    {

     while(GSi leftLoad＞targetLoad and

       neighbor unvisited){

       GSj＝GetLightestLoadedNeighbor(GSi)；

       PartitionGraph(GSi，GSj，targetLoad)；

    }

}

其中附图5的划分机制是将一个图划分成两个或多个具有强连接的子图，其权重的和应该尽可能接近划分目标。

附图5.1描述了地图搬家的整体控制流程，任何一步的失败都有完善的回退步骤以保证游戏世界信息的一致性和完整性。

创新点：

◆系统实时监控并且对获得的监控信息进行相关性处理已获得服务器集群的真实负载分布

◆高效的游戏世界的动态划分与融合算法

◆服务器集群负载转移的实现

D、附图说明

附图1：无缝的跨服务器超大规模虚拟游戏世界的解决方案

附图2，2.1，2.2，2.3，2.4：无缝的跨服务器边界角色迁移的解决方案

附图3：为虚拟世界优化的分布式共享游戏对象的解决方案

附图4：游戏世界的动态划分及动态负载分布方案

附图5，5.1：概要划分机制及搬家流程

附图6：系统架构

附图7：系统及周边系统的逻辑架构

附图8：智能负载均衡管理服务(ILM)的重新划分地图算法

E、具体实施方式

系统架构如附图6，图中代理服务器(Proxy)，游戏服务器(Game Server)都是基于Linux操作系统并且使用EPoll网络通信技术。基于上述平台的单台网络服务器并发连接能够达到数万个，稳定连接也能在一万左右。较之于Windows系统的服务器，大大减少服务器数目，极大地节省运营成本。附图7的逻辑架构图中描述了系统中的关键服务器都可以以群组方式伸缩，如代理服务器群，游戏服务器群，登录服务器群，数据库缓冲服务器群，和游戏数据服务器群，这样整体系统可以支持数百万人的并发连接和在同一巨大无缝世界的交互。

系统使用代理服务器(Proxy)集群组承担所有客户端(Client)连接，因此系统能够服务的人数只和代理服务器数目相关，通常可以服务的人数在10万到100万之间。对于网络游戏，这样的人数已经足够成为超大型游戏世界。代理服务器还在玩家跨服时提供透明路由的功能。

游戏服务器(Game Server)用于具体承担游戏世界的逻辑服务，例如玩家移动、战斗、交易、聊天等服务。游戏服务器从代理服务器接受玩家动作指示，根据游戏设计人员设计的响应逻辑计算结果，再通过代理服务器返回给玩家，就完成了玩家在游戏中的行为。以玩家聊天实例上述过程。首先玩家在客户端敲入想要说的话，通过游戏客户端发送到代理服务器，代理服务器将玩家聊天信息发到相应的游戏服务器处理，游戏服务器过滤玩家聊天信息后，将处理结果以及相应的信息发到代理服务器，再由代理服务器返回玩家，客户端显示聊天信息。

前面说到游戏服务器具体承担游戏逻辑，其中与实现无缝超大规模虚拟游戏世界相关连的概念是图中Map，系统将世界划分成若干个Map，将所有Map分组，每组由一台游戏服务器托管，也就是说世界增大就可以使用增加游戏服务器的方式来解决。

登录服务器集群(Login Server)和代理服务管理服务器(Proxy Manager Server)提供玩家登录和定位，以及智能分配两个代理服务器连接(互为备份)给玩家客户端的功能。

URS(Universal Resource Server)资源管理服务器提供虚拟世界动态资源的上传、管理和按需下载的功能。它与客户端配合一起提供支持玩家的最优的虚拟世界安装、浏览和交互的体验。

至此，无缝超大规模虚拟游戏世界搭建已经完毕。下面将解决因为玩家跨越游戏服务器引起的服务器之间的必须信息来往处理。依据Map划分的规则，当玩家发生行为时游戏服务器测知玩家与Map的关系以及相邻Map的关系，决定：

1.玩家位于游戏服务器托管Map的物理边界区域，需要通知相邻服务器创建该玩家的影子(Agent)，使相邻服务器中其他玩家能够看见该玩家，并且能够知道改玩家的行为。这样就使得后面的玩家跨越服务器的时候，不至于突然看见这个玩家冒出来。因此便能够实现玩家透明跨服。

2.玩家已经跨越服务器，也就是从他原来所在的服务器托管的Map到了相邻的服务器托管的Map。游戏服务器通知玩家新到的服务器，玩家已经在服务器里面了。这样原来的影子就无缝变成玩家，而玩家原来所在的服务器的人就变成影子，原服务器里面其他人仍然可以感知这个玩家的行为。实现玩家透明无缝跨服。

关于地图智能划分的概要流程、搬家流程、游戏对象优化同步的实现算法在前面的发明内容和图示中已详细描述过。下面描述ILM如何进行监视服务器状态并自动重新划分地图并发出搬家指令的详细流程。

一、ILM的配置文件

一个虚拟世界的地图被划分成若干个N×N的格子，这些格子是ILM计算的基本单位。

目前虚拟世界中的地图有三种情况：

1.普通格子，我们称其为MapUnit

2.不可拆分的若干个组合在一起的格子，我们称其为zone

3.孤岛，也就是不从物理上和大地图相邻的岛

假设一个游戏有两大片地图，两个孤岛，图如附图8.1：

zone的概念：假设游戏开发者规定1号和5号、7号和11号地图各自组成一个zone，每个Zone都必须在相同的服务器上。17号、21号、22号以及24号和28号也各自成为一个Zone。

孤岛的概念：孤岛就是只能通过传送到达的地图，比如监狱、副本。

用配置文件描述上面的图所示的一个4×4的map和一个4×3的map，在加上两个孤岛如下：

[map1]

MapUnit MapUnitName  ZoneID    MapID    ServerID

1       MapUnit1         1        1

2       MapUnit2         0        1

3       MapUnit3         0        1

4       MapUnit4         0        1

5       MapUnit5         1        1

6       MapUnit6         0        1

7       MapUnit7         2        1

8       MapUnit8         0        1

9       MapUnit9         0        1

10      MapUnit10        0        1

11      MapUnit11        2        1

12      MapUnit12        0        1

13      MapUnit13        0        1

14    MapUnit14        0        1

15    MapUnit15        0        1

16    MapUnit16        0        1

[map2]

MapID MapUnitName  ZoneID    MapID    ServerID

17    MapUnit17        3        2

18    MapUnit18        0        2

19    MapUnit19        0        2

20    MapUnit20        0        2

21    MapUnit21        3        2

22    MapUnit22        3        2

23    MapUnit23        0        2

24    MapUnit24        4        2

25    MapUnit25        0        2

26    MapUnit26        0        2

27    MapUnit27        0        2

28    MapUnit28        4        2

[map3]

MapD  MapUnitName  ZoneID    MapID    ServerID

29    MapUnit29        0        3

[map4]

MapID MapUnigName  ZoneID    MapID    ServerID

30    MapUnit30        0        4

ZoneID相同的为一个zone，搬家时不可拆分，必须作为一个整体添加或者删除。当MapUnit的ZoneID为0时，意味着该MapUnit自身是一个独立的Zone。

二、ILM的重新划分地图算法

大体算法需要解决的问题有：

●重新划分地图时需要考虑一个zone不能拆分的问题

●因为出现了zone，所以“桥“的概念由”连接同一服务器管理的两片地图的唯一MapUnit”变为连接同 一服务器管理的两片地图的唯一Zone”，如附图8.2，如果22和23作为一个zone，如果需要把22和23都要同时搬家，这样子就属于桥搬家，是不允许的。至于如何计算桥，举例，把22，23从地图列表中扣除，从17开始相邻拓扑，这个拓扑集合将会越来越大，如果这个拓扑集合把本服务器管理的所有的地图列表即(17，18，19，20，25，26，27，28)全都包含，那22，23将会是个桥。

●孤岛的迁移应该有一定的优先集，因为孤岛的迁移相对来说比较简单，不需要通过复杂的计算。所以一个服务器在比较多时应优先考虑把孤岛迁移出去

●跨连续地图管理的情况，也就是一个服务器管理了map1的若干个地图片和map2的若干个地图片。为了保持地图的连续性，我们应该尽量把一片地图划归一组服务器管理，另一片地图划归另一组服务器管理，在非常有必要的情况下才进行这种迁移，但需要只把一个map边界的地方搬给另外一个map的server组来接受，并且一有机会马上迁移回去，从而避免一片地图被更多的server管辖而造成频繁跨服。但这时也要考虑边界属于zone的情况。当这种情况发生时，要把迁移了的地图记录一个标志，并且这些地图的下一次迁移目的服务器必须是原最初搬来的服务器。

●初始化时如何把地图均等划分到各个server上，第一种流程，第一个服务器连接过来的时候，所有地图全部归它管理，第二个服务器加入的时候也放到空闲服务器列表里，第三个服务器加入的时候也放到空闲服务器列表里，直到达到需要重新划分地图的条件时再执行划分地图算法。

第二种流程，在配置文件里指定哪些地图规哪些服务器管理，这样必定整齐划一，以后的重新划分地图也是在这样良好的基础上进行管理，但该流程的灵活性差一些。根据虚拟世界的特性可以选用一种流程。

●当重新划分地图并制定搬家计划时，如果有若干路径都满足条件，应该选择待搬地图和目标服务器连接更紧凑的那种情况：

如附图8.3，每个不同颜色背景的MapUnit属不同服务器管理，假设背景淡蓝色的服务器需要被搬家，10和12都可以搬，但10和左侧的服务器有两条边相接，而12和上边服务器只有一条边相接，这种情况下我们搬10而不搬12。

这时可能也会产生一个问题：如果背景为粉红的服务器上有10人，而背景为白色的Server上有9个人或者8个人时应如何处理呢？虽然搬10从地图上的分布结构更合适些，但10的目标服务器人数却偏多，为解决此问题引入一个“可容忍差值”的定义。在可容忍差值范围内，尽量保证地图的完整性。所以同样在选择被搬地图的时候，需要把人数最小的MapUnit以及和其他MapUnit上人数和最小人数差值在“可容忍差值”内的所有MapUnit都作为待选MapUnit。

●评估，评估模块利用复合价值函数评估智能划分地图算法的意义迁移方案，函数的输入包括迁移后地图上的人数、服务器的CPU忙度和网络流量，比如一个地图从Server A搬到Server B的时候，发现搬完之后不合适，需要重新制定迁移计划。

综上所属，ILM重新划分地图算法并产生迁移计划的流程如附图8.4，另外，权衡出哪个地图需要被迁移的步骤中，优先考虑孤岛的情况，之后在下一步的“搬家后结果可行？”步骤中发现目的服务器加上孤岛后也需要被迁移，孤岛将不被搬走。

Claims (9)

1. 一种基于互联网通用协议，用于开发超大规模虚拟现实世界、游戏世界的中间件。

2. 一种用于实现权利要求1所述的集群基本软件模型，其特征是游戏服务器集群中的相关服务器通过消息服务总线以发布者/接受者(Pub/Sub)模式进行相关信息的交换，并同时使用操作原语进行系统间的协作，共同完成对游戏世界的支持。

3. 一种用于实现权利要求2所述的技术，其特征是高速实时消息服务总线。

4. 一种用于实现权利要求2所述的算法以及实现，其特征是游戏世界动态划分。

5. 一种用于实现权利要求2所述的设计及实现，其特征是使得游戏服务器之间的系统协作可以使用原语。

6. 一种用于实现权利要求1所述的无缝的跨服务器边界角色迁移系统，其特征是：

a)多台服务器处理同一个角色，该玩家状态在相关服务器上能够一致。

b)玩家实际跨越服务器物理边界时，对象和状态的能够实时转移和更新。

7. 一种用于实现权利要求1所述的分布式共享对象系统，其特征是所有游戏对象都由分布式对象系统来维护。分布式对象系统对外提供对象声明周期管理，提供对象的同步控制机制，提供分布式轻量级分布式数据库；并优化了对象的同步，使得同步的数量最小化。

8. 一种用于实现权利要求1所述的世界划分系统，其特征：

a)高效的游戏世界的动态划分与融合算法。

b)集群内负载转移。

9. 一种用于实现权利要求1所述的架构设计，其特征是使用登录服务器组承担登录任务、使用游戏服务器集群承担逻辑计算、使用代理服务器承担客户端与游戏服务器网络消息转发的任务、使用URS(Universal Resource Server)服务器承担实时客户端资源下载的任务。

Images