可复用框架的必要性与可行性

在现代游戏产品的开发中，游戏服务器端程序已经几乎成为了标配。从最简单的正版保护功能，到玩家档案、成就的存储功能，到复杂的主要游戏逻辑运算，游戏服务器端系统都是必不可少的。但是和客户端丰富的游戏引擎不同，服务器端比较少这类可复用的软件产品出现。其原因可能有以下几个：一是欧美、日本的服务器端逻辑一般比较少，所以这类产品的需求也比较少；二是游戏服务器端本身涉及大量不同的运行平台、环境、语言，导致较难统一产品形态；三是游戏服务器端的需求变化比客户端更加“不可预测”，所以导致了产品特性在通用性上较难聚合。但是，游戏服务器端“引擎”，却有明确而清晰的市场需求。我们可以看到大量的游戏团队都在一遍遍的重复开发着类似的功能；而因为缺乏可复用的技术，有很多游戏死于“无法修改”；游戏服务器端程序员也和客户端程序员一样，长期经受着加班的折磨。

事实上，可重用的游戏服务器端框架，是完全可以设计和实用化的。因为理由也非常充分：一是国内游戏产品的游戏服务器端逻辑一般重，提供了丰富的实践需求；二是国内的游戏服务器端运行环境分类，还是比较统一的，其中C/C++在Linux上运行，是一个经典的选择；三是游戏服务器端的需求范围，通过认真的设计，完全可以抽象出可复用的模型。如果我们要找一个可行性的例子，也是有一个的：MudOS和MudLib的例子。

在“古老”的MUD（文字多人在线游戏）的世界里，游戏通常由两大部分组成：MudOS和MudLib。其中MudOS负责通用而基础的一系列功能，而MudLib实现具体丰富复杂的玩法。在这样一套体系下，我们看到几乎所有的Mud游戏，都能复用MudOS的代码。而大量不同的Mud游戏，在MudLib的复用程度上，也是非常高的。我所知道有些“大神”，能仅仅用3天时间，就把一个MUD改造成另外一个完全不同感观的游戏——这证明了MUD的这套体系在代码复用上的高度可行性。从MUD的体系上，我们可以学习到它在设计上的一些特点：

• MudOS 接口简单，功能通用
• MudOS让整个体系的部署、运行都非常简洁。整个游戏只依赖于MudOS，而对外界其他系统依赖很少。
• MudLib本身也是分层的，以游戏系统的共性先做建模，然后再实现具体的游戏逻辑
• MudLib是以脚本语言编写，以源代码形式开放给所有开发者，因此灵活同时强大。

可复用结构整体描述

根据我们对MUD体系的学习，以及长期游戏开发经验积累，我们发现，可复用的游戏服务器端框架，应该具有以下几个设计特征：

1-系统应该是典型的分层架构，需要同时具备灵活和强大这两个特征。

2-底层负责有限的功能：通信（请求-响应、单播、组播）、存储（对象缓存、持久化）、调度（并发、定时器）。

3-底层的关注点在非功能性需求，如可用性、扩展性、运维需求等。

4-中层建模是关键，要以游戏的业务模型来提供强大的功能，并提供足够的灵活性。因此应该是开放源代码形式，并且是以库的扩展方式提供。

5-顶层代码应该全部由具体游戏开发者编写，最好能支持脚本语言。

一般来说，我们对于“底层”的认识比较容易达成一致，也有很多业界的产品供参考，但是可惜的，一个完整功能的底层却不太容易找到开源的标杆。很多游戏团队都是自己组装或者搭建的。比如JAVA语言的团队会选择Netty+iBatis+MySQL；C语言的团队会选择ZeroMQ+Redis……。而一些游戏服务器端框架，所提供的能力也参差不齐，如SmartFoxServer主要提供的是通信中请求-响应和组播的能力，而FireFly和Pemelo则在通信功能外增加了调度能力中并发（异步）的支持。从非功能性特性来说，高可用和灵活扩展，以及丰富的运维能力，都难以找到非常好的例子。因此一个好的“底层”，应该是同时具备三大主要功能：通信、存储、调度；也能满足高可用、灵活扩展、丰富运维工具的需求。

由于本身服务器端的“底层”就缺乏统一的框架，所以对于中层的模块来说，更是无从获取可重用的代码，尽管很多游戏都有角色、道具、任务、商店……。同时，中层代码的建模，如果要做到高重用度，也需要认真分析各种游戏的共性和特性，并且在设计中遵循良好的接口规划原则，才能真正的实用。因此，我希望能提出几个典型的游戏系统模型，并且以此为出发点，尝试构建典型的游戏中层模型，并且辅以源码开放和库的使用形式，试图提出一个可重用的游戏中层的方案。这个方案包括5个主要部分：RPG系统；社交类系统；引导类系统；战斗系统模型；副本系统框架。

• 在现代游戏中，RPG玩法的设计非常通用，而RPG玩法本身是一个具有非常典型的模型的：成长和搜集的体验，承载体主要是玩家的属性、技能、装备、道具。尽管玩机的属性名称、数据各有不同，技能体系千差万别，装备和道具的类型功能有很大差异，但是其共性的“获得”“成长”“消耗”却是一致的，在这个角度来说，是完全可以产生可复用代码的。
• 社交类系统在现代游戏中，承载着玩家间交互的功能。这些功能表现好友系统、组队系统、帮派系统、聊天系统、邮件系统等，其核心模型，为玩家关系构建和玩家交互手段两类。只要我们对玩家关系管理进行建模，以及玩家交互手段（在线、离线）进行建模，基于这两个模型，就能很快速的搭建出上述的一系列社交系统。
• 引导类系统主要包括剧情系统、商店系统、任务系统、活动系统一类功能。这些功能的底层逻辑，主要是由“引导数据源管理”-“引导数据运作”两个部分构成。实际上这个抽象模型，在几乎所有现代游戏中都具备，而且高度相似。主要的设计难点在于其引导内容的复杂性。因为引导内容是一系列的玩家行为，针对行为的建模远比数据的建模要困难，但是我们也可以在开源的前提下，提供可供修改的模板代码，从而试图减少重复代码的开发。
• 战斗系统一直是游戏开发的重点和难点，也是游戏巨大差异性的重要部分。但是对于服务器端系统来说，战斗系统的核心一直都是一个“数值比较系统”，简单来说就是一个调用机制比较丰富的比大小函数。服务器端承载战斗系统的功能，往往是提供比较规则，运算比较结果，和玩家的战斗操作往往并不完全一致。当然，也有一些战斗服务器是完整的重现客户端的战斗逻辑，需要建立2d甚至3D的战斗模型，但是其中也一定会包含战斗规则的调用。从这个角度上来说，也是具备了一部分可重用的模块。
• 副本系统在非MMORPG中几乎是最基本的玩法结构，比如大厅开房间类的玩法，在QQGAME上是标准模型，更不用说《英雄联盟》《使命召唤OL》这类对战游戏。这类系统主要提供玩家在线匹配的功能，有手动选择或者自动组建的能力。其特化的需求主要是自动匹配规则和房间展现数据模型，是一个非常便于构建重用代码的部分。

RPG系统的可复用模型

RPG系统主要负责提供游戏中提供“积累、成长”的快感，也是驱动玩家反复进行游戏操作的重要系统。RPG系统能提供这种作用的最基本逻辑，是以玩家为中心，为其赋予了一系列的可成长的数值，然后这些数值可以用在战斗系统或者RPG系统本身。

因此，RPG系统是由一系列子系统构成，而这些子系统，又由一个内在逻辑驱动，具备一些共性的行为和数据特征。我们使用面向对象的方法，可以比较清晰的分析出来其结构。我们从需求侧可以看到，RPG系统包含的子系统有：

• 角色属性系统：提供玩家的等级、攻击力、防御力、敏捷、智慧等一系列游戏需要的数值属性，以及一些特殊的非数值属性，如“黑暗魔法抗性”“防穿刺物理攻击”
• 技能天赋系统：技能和天赋本质上也是角色身上的属性，但是技能是有一定的等级的，而天赋除了等级，还可以提供玩家自行分配的操作。有些天赋的分配会直接赋予玩家新的技能。
• 武器装备系统：武器装备主要指角色身上那些有装备栏位限制，但是可随意修改装备状态的系统。武器本身可以携带大量数值，这些数值会由其他系统计算读取。同时装备本身也有可以修改的空间，比如打孔、改名、升级，可以说是一个小型的角色系统。
• 物品道具系统：物品道具的主要内容包含名字、数量、作用。这些道具有一些是可以消耗的，而另外一些则会作为永久性唯一道具存在于玩家身上。它和武器装备的差异在于，一般没有很复杂的附加数值，但是数量会很多，甚至成千上万，通常以“堆叠”的形式出现。

我们基于这些系统的共性，可以大概总结出一个基础共性的模型。

对于以上的数据模型，其行为方法也是比较明显的：

l 角色

• 新建角色，返回ID
• 根据ID从持久化或缓存中读取角色load
• 把角色存储到持久化数据中save
• 属性的get/put/list
• 技能的get/put/list
• 背包内容的put/get/list
• 装备的arm/unarm/get_by_position
• 装备栏的add/remove/list

l 属性

• 根据ID构造
• 对于各成员属性的getter/setter

l 技能

• 根据ID构造
• 对于各成员属性的getter/setter

l 物品

• 根据ID+数量构造
• 对于各成员属性的getter/setter
• 使用（可能消耗）

l 装备

• 根据ID构造
• 对于各成员属性的getter/setter
• 被装备armed触发的效果回调
• 被脱下unarmed触发的效果回调

需要注意的是，这里的技能、属性、物品如果不带可修改的能力的话，可以采用单例以及享元的模式，这样可以大大减少对于内存的消耗，根据这些属性和方法，我们大概可以画出这样的类关系图：

对于以上设计，可能读者会问，这些系统完全没有考虑到游戏客户端和服务器通信的问题，也没有考虑登录在线的实现，仅仅是一些数据结构的列举，真的能用吗？为此，我就把相关的一些系统试着画一下类结构图。

这里的命令系统主要是负责网络通信的一套系统，把客户端的操作变成对“玩家对象”的方法函数的调用；而登录系统是一个负责玩家在线的缓存系统，可以让命令系统获得“玩家对象”；玩家对象则由负责通信的对象和负责数据的角色对象两者组合而成，玩家对象除了对数据的存取和读写外，还会使用通信的对象来完成诸如说话、战斗等操作。

像这种数据建模，从一开始看似乎并没什么特别的优势，但是如果你需要快速开发一个游戏的时候，你可以从一套模板代码开始扩展或者修改，会比完全从头开发要快的多。有一些通用的逻辑，比如背包大小检查，物品负重判断，天赋总数控制，都可以直接添加到这个中层MudLib的代码里面，这样就确确实实的减少了代码的编写。

社交类系统的可复用模型

在线游戏由于可以让不同的玩家在游戏中互动，所以产生了比单机游戏有趣的多的感觉。多人合作和竞争的操作，以及多种人际关系的玩法，都是现代游戏所热衷的设计，特别在国内的MMORPG中，对于玩家关系所依赖的玩法更加丰富，国战、结婚、帮派等等都是很常见的社交类系统。社交类系统包含我们常见的好友系统、公会系统、组队系统、聊天系统、邮件系统等等。而这些丰富的系统，其背后也由两个核心的逻辑系统组成：玩家关系；玩家间交互。常见的系统有：

• 聊天系统：一般有玩家间私聊、多频道聊天等功能，为在线沟通的主要系统。聊天内容除了文字外，还有表情图，角色、物品链接等功能。
• 邮件系统：则是离线沟通的主要系统，还承担着游戏内物品道具的寄送功能。很多任务、活动、交易系统都是用邮件系统来发物品给玩家。
• 公会系统：属于需要玩家主动建立的玩家组织，公会主要的功能是对玩家进行分组管理，并会根据玩家组织的数据，添加更多的附属功能。家族、帮派是公会系统的不同名称。公会系统除了展示成员，设置成员等级等等界面功能外，往往还附带公会基地、仓库，成员升级机制等等。这些理论上不属于社交类核心范畴，而属于扩展功能。这些功能的开发工作量也比较大，也许这一块的代码难以抽象到中层中去，但是如果中层可以服用，则部分高层倒是可以通过修改代码来重用的。
• 好友系统：每个玩家都有一个好友关系的列表。另外有的游戏还扩展出固定名称和人数的特异好友系统，如结拜系统、师徒系统、夫妻系统等。

交互系统和玩家关系是整个中层系统的核心，他们具备的数据关系可以大概如下记录：

以上类型的成员方法：

l 交互消息

• 内容的getter/setter
• 发送方/接收方的getter/setter

l 交互系统

• 发送一条消息
• 收取一条消息
• 设置收取回调通知

l 玩家关系

• 加入一个角色
• 列出所有角色
• 删除一个角色
• 新建关系列表，返回ID
• 根据ID从持久化或缓存中读取角色load
• 把角色存储到持久化数据中save

在实现社交类系统的时候，最常见的难题是对于社交系统对象的单例操作。由于游戏服务器可能是多进程多物理机器的。要实现跨机器投递交互消息，是需要额外的处理能力的。有一些实现者会采用ActiveMQ之类的消息队列服务来承载，有些则使用数据库存储做交换。但是增加额外的服务会增加整体的运维和开发的复杂度，因此GameOS（底层）提供的跨机器数据缓存就是必不可少的部分。基于这个基础功能，实现消息队列或在线消息投递都会非常的简单。

引导类系统的可复用模型

说到游戏中的“引导类系统”，最常见的就是所谓“新手引导”，这些专门设计的游戏流程，让玩家一步步的按规定顺序去操作游戏。而“任务系统”，也是最著名的引导类系统，这个最初只是基于NPC机关的小玩法，现在已经成为几乎所有游戏的标配。并且后续还出现了“每日奖励”，“日常任务”，“活动任务”，甚至“成就系统”等各种变种。这几个系统的核心逻辑，都是策划预设了一条“任务链”，让玩家通过操作，来改变自己在“任务链”上的位置。另外一种很特别的引导类系统，就是商店。最古老的游戏中都会有商店，到现在的游戏，商店系统的形态变得更加多样化，比如专门使用某种货币的兑换系统（使用人民币的商城系统）。拍卖行作为玩家的物品互动系统，实际上也是一种商店系统，只不过其价格和商品不是系统设置，而是玩家操作的而已。

虽然从产品角度来说，都是引导玩家进行某些行为，但是以上两类系统的核心逻辑是有所不同的，因此我打算分成两个部分来描述。

任务系统族：

任务系统的基础数据模型，是一个预设的任务库，存放着大量的任务链以及具体任务。而玩家则有一个任务列表，存放着已经完成的任务、接受后但未完成的任务。具体的任务最重要的是包含着任务完成条件和完成进度的数据，这些任务条件一般来说都是必须全部完成的。因此我们可以抽象出任务系统的基本数据模型：

“任务项”中的“接受条件容器”和“完成条件容器”中，都应该分别对应着两类对象，即“接受条件”和“完成条件”。“接受条件”可以有多个不同的子类型，如判断前置任务是否完成的，玩家是否符合等级，是否具备某个道具等等。而“完成条件/进度”也应该有多个子类型，如“对话操作”“杀怪操作”“物品收集操作”……游戏中一切的操作都应该可以成为完成条件，具体实现则由游戏的操作中，添加钩子处理程序，对玩家身上的完成条件的检索，然后根据游戏操作的逻辑，对这些玩家身上的“完成条件/进度”做修改。这些模型的方法应该有：

l 任务项

• 用ID从持久化中load出来并构造
• 各属性的getter/setter
• 返回此玩家是否能接受
• 更新并返回此任务的完成状态

l 玩家任务集

• 根据玩家ID，从持久化设备中save/load出玩家任务集
• 接受任务
• 放弃任务
• 输入一个“完成条件”的类型，返回所有符合此类型的“完成条件和进度”对象

l 接受条件

• 输入玩家对象，返回是否满足此条条件

l 完成条件和进度

• 返回已完成进度
• 返回总进度
• 修改已完成进度

由于任务系统的变种种类繁多，所以可能会导致设计大量的“接受条件”和“完成条件进度”类型，所以这些对象的部分属性如“描述文字”等静态内容，应该采用共享数据的形式出现，而不应该反复拷贝。下图初步描述了任务系统族类型的关系：

商店系统族：

商店系统的数据核心模型，是一系列可供展示、销售的商品，用于购买商品的货币，以及为这些商品提供展示之地的商店模型。当然这里的商品可能不一定对应于RPG系统里面的物品道具，因为有些商品是权限、等级等不能放入背包里的东西，也有可能是某种属性、状态等等。但是我们还是推荐用RPG系统中的道具来承载，这样编程的复杂度会比较低。

商店系统看起来非常简单，但是最复杂的地方在于“购买”环节，因为购买得到的商品，不一定是放入背包的货品，所以商品的“被购买”应该是一个可扩展的虚方法函数。这样商品也可以扩展为背包货品类商品和其他商品类。需要注意的是，买入玩家销售的物品，这个功能并不是非常容易重用，这涉及到如何对玩家物品的估价的问题，因此这个能力应该从最基本的“商店”系统扩展，而不应该加入商店系统中。商品系统的对象方法应该有：

l 商品

• 属性的getter/setter
• 以id从持久化设备中构造
• 被购买行为（虚方法）

l 商店

• 列出商品，可能带分页接口
• 卖出商品

商店系统的表现形式非常多样，但是核心逻辑关系却异常简单：

至此，已经描述完主要的引导类系统的设计。这些设计本身可能并不能完成非常复杂的游戏逻辑，但是其基础逻辑却足够简洁。这样基于其开发的上层代码，就具备了一个比较统一的实现结果，便于构造出更多能重用或修改使用的系统。

战斗系统的模型构建思考

战斗系统是一个游戏的玩法核心，也是游戏之间差别最大的地方，想要建立可复用的模型，可谓困难最大。但是，游戏的玩法本身也是有分类和传承的。需要特别注意的是，作为服务器端程序，战斗系统的职责是有多种不同层级的：

1-记录战斗结果，发放战斗奖励。很多开房间和按“局”算的游戏，如棋牌类，其游戏本身是分为很多“局”的。游戏是在一局结束后，才结算所有的奖励。另外如《地下城与勇士》（DNF），其游戏为一个个地下城“副本”，本身也是这种分局的。如果服务器端只是为了游戏完成一局后做“结算”，那么其逻辑还是比较简单的：主要就是校验游戏中的消耗与产出是否合理，有无作弊嫌疑，然后更具战斗数据，发放战斗奖励给玩家。这种模型下其实无需很复杂的模型，无论任何的玩法，实际上都可以用一个“校验与奖励”函数作为抽象即可。如果战斗过程中有消耗品使用或者奖励掉落，还要增加一个消耗品函数和奖励掉落函数即可。

2-在二维游戏场景下，对战斗过程进行模拟，且时常会结合帧同步广播来协调游戏。例子就如著名的《英雄联盟》。这一类战斗服务器，往往会作为“主广播器”，生成AI的行为，转发广播玩家的动作，同时计算每个战斗动作的“成败输赢”。这种做法其实和一个客户端计算战斗过程是差别不大的。这种战斗服务器的抽象模型是由几个部分组成：AI控制+状态广播+战斗判定。每一个战斗“帧”，服务器都会更新所有玩家、怪物的状态，然后判定战斗结果，最后广播状态和战斗情况给客户端。这种模型是相对比较复杂的，其最复杂的地方在于处理AI和判定战斗结果的时候，必须在内存中根据二维的战场状况，重现整个游戏情况。这对于一般来说不显示画面的服务器端程序来说，是比较复杂的。

3-在三维游戏场景下，对战斗过程的模拟和广播协调。很多FPS游戏都是这种，而著名的WOW也是这一类例子。其实这个模型和上面第2种情况是类似的，只不过3维空间的计算复杂程度比二维更高。

基于上面所说，一个战斗系统确实是游戏中最复杂的部分，因此我们的建模也不能很轻易简单的完成，而是应该分为几个不同的层次和阶段。第一个层次对应最简单的战斗结果校验和奖励模型：

在这里，我们使用“战斗关卡”这个模型来抽象战斗内容，“奖励对象”只是一个用于抽象可能存在的不同奖励内容的接口。一般来说我们的奖励是物品道具、货币，但是也有可能会有更复杂的内容，比如开通某种特殊权限，完成某个任务等等。这些复杂的“战斗奖励”也许不是一个RPG的物品基类能涵盖的。所以不如以组合的形式来耦合关卡奖励和具体的物品。由于战斗关卡的数据项目一般很少，所以就不列举数据属性的设计，而专门关注关键行为的模型：

l 战斗关卡

• 根据ID从持久化数据中构建关卡
• 返回战斗关卡的介绍，应该返回一个游戏自定义的介绍数据结构。
• 输入所有进入玩家对象，开始一局关卡游戏。有可能开始一局游戏会扣减某些玩家资源和检查是否能开始游戏。
• 输入玩家对象，计算关卡中掉落物品
• 输入玩家对象，计算关卡中消耗物品
• 判断关卡是否结束。根据战斗关卡的数据来判断是否应该结束关卡。
• 输入所有当前玩家对象，进行关卡结束的计算，返回关卡的奖励。此操作会计算游戏过程中的掉落物品和消耗物品。

l 关卡奖励

• 输入玩家对象，执行奖励（虚函数）

在第二个层次中，战斗系统的模型会变的复杂很多，其中有一块是关于AI模块的。关于AI的模型本文恐怕无法简单完成，因此可以把他看成是一个黑盒子。当然AI简单的用一个状态机实现也可以。在这种情况下，战斗的标准流程是：按帧接受玩家操作，AI产生怪物/NPC操作，计算战斗结果，更新战场状态，广播战场状况。因此模型大致如下：

在这个模型下，战斗主要执行逻辑对象，是由“帧同步广播器”来执行的，当然也有可能游戏不是帧同步模型的，但是无论如何都会有一个战斗驱动器来循环的调度战斗进行。如果这个战斗驱动器是帧同步或定时器的，那么游戏就会是实时游戏，如果这个战斗驱动器是由玩家命令触发（可能带超时触发）的，那么游戏可能会是回合制的。不过归根结底，战斗系统都是一个“战斗判定”循环，只是这个循环的定时器的快慢差别，以及是否能由玩家主动暂停或加速的差别。因此以上对象的主要行为应该包括：

l 战斗驱动器（此处是“帧同步广播器）

• 驱动帧（虚函数）函数：此函数可以由各种不同的情况触发，如定时器、玩家命令等。负责执行具体的战斗计算状况。

l 战场状态集。有时候关卡的战斗状态和这个对象是同一个对象。

• 获得战场状态：包括所有战场上角色对象及其2D、3D坐标
• 输入目标角色与技能范围，返回是否命中。（辅助函数，根据2D/3D的差别，会有很多不同的模型，如射线命中判断用于FPS）

l AI模块。AI模块可能包含复杂的状态机模型，但只有一个驱动函数而已。

• 输入游戏角色对象，执行其AI结果操作。（虚函数）

关于战斗驱动器的几种模型下表有一个分类：

关于战斗动作，在2维和3维下略有不同（同理，如果有1维的游戏也是一样的），但是仅仅是参数的区别。实际上，针对特定类型的游戏玩法，比如FPS或者MOBA&RTS类型，这里的战斗动作都具备相当高的可复用可能。这些动作的内容各有不同，但是其“动作”的主要行为是：

• 判断——是否碰撞（命中），返回碰撞对象
• 动作——修改发出动作对象以及碰撞对象状态

对于纯数值类型游戏，其实就相当于0维空间游戏，战斗动作的判断实际上返回的对象由动作本身确定，无需空间计算。这在很多RPG或者策略类游戏中是很常见的。

最后总结一下战斗系统的完整流程，在有些游戏中，关卡和战斗是配合一起操作的，但是有些游戏则没有关卡，只有战斗，不过这种游戏主要是世界地图的MMORPG，现在这类游戏已经渐渐式微了：

尽管战斗系统是如此的复杂和多变，但是其运作还是一个模拟状态变化的系统，所以还是有不同层次的可重用模型可以设计。核心的战斗驱动就是模拟时间因数，而战斗动作则负责对空间因数进行模拟。关卡系统是对战斗的一个时空区隔，也是各种奖励、消耗的小结，因此更常见于游戏当中。

副本系统的构建思考

在早期的联网游戏中，有两种典型的不同种类，一种是类似《传奇》的全地图，分区分服的MMORPG；另外一种则是类似QQ Game类型的“大厅-开房间”的全区全服游戏。这两种游戏在底层架构上有非常大的差异。但是，随着网络游戏的发展，在MMORPG中出现了类似开房间的“副本”系统，甚至出现了可以跨服跨区玩的“副本”；而开房间的游戏也离开了简单的UI界面，出现了《地下城勇士》（DNF）这类所有战斗都发生在关卡副本中的游戏。到后来，如《英雄联盟》《星际争霸2》这类复杂的游戏，都渐渐走上了全区全服开房间的架构。因此，本章的名字叫“副本系统”，其实也可以叫“大厅-房间”系统。

在“副本系统”中，最需要考虑的是游戏服务器的隔离性和生命周期。这时游戏服务器不再简单的代表一个静态的“虚拟世界”，而是一批动态的，不断生灭的小虚拟空间。同时我们还需要一个相对静态的“大厅”。因此在副本系统中，最典型的模型就是：大厅、房间这两个概念。大厅提供玩家的接纳，了解房间的情况，提供玩家对房间的管理、操作；有很多游戏还需要提供自动匹配建立房间的功能。而房间则应该是一个对游戏关卡的容器，能承担任何一段游戏逻辑，但是需要大厅提供一组玩家和选择关卡作为输入，最后在结束时提供一个返回给大厅，修改房间的状态和触发玩家的关卡结算。对比与那些复杂的游戏逻辑系统，副本系统本身。

这个模型下各类的行为：

l 大厅

• 列出所有房间
• 使用关卡数据建立房间
• 角色进入、离开房间
• 启动房间游戏
• 自动匹配玩家进入房间

l 房间

• 输入关卡数据构建房间
• 房间类型setter/getter: 公开、加锁
• 关卡数据getter/setter
• 列出房间中所有副本角色
• 列出房间所有者（队长）
• 切换房间所有者（队长）
• 启动关卡对应游戏

l 副本角色（与玩家角色类型绑定的模板类）

• 根据玩家角色构建
• 返回副本角色匹配数据：匹配数据为一个map类型自定义结构
• 返回玩家角色对象
• 准备就绪-锁定

l 关卡（与关卡数据类型绑定的模板类）

• 关卡人数范围
• 返回关卡对应游戏数据：游戏关卡数据为另外定义的特有类型，因此此方法应该为模板方法。
• 启动关卡对应游戏（虚函数）：输入副本角色（玩家列表），根据自身具体游戏数据启动。
• 副本角色中断副本，离线保存（虚函数）：当玩家断线或其他操作，系统调用此回调
• 副本角色重新进入副本（虚函数）：当玩家重新进入游戏，系统调用此回调

副本系统的整体调用流程：

总结

本文初步介绍了可重用的游戏服务器框架中的三层结构。其中底层的通用性强，技术含量高，关注非功能特性较多，事实上你可以用这个底层开发任何后台服务器，其对游戏最有意义的功能在于广播和复杂结构的本地数据缓存能力。而框架的中层结构，提供了大量的游戏业务领域的建模，这些建模也许不是非常详细，不够详细，但是如果我们坚持分层设计原则，并且以库和开放源码的方式去维护，那么这些中层模型将日渐强大，成为可重用代码的核心模块，让游戏开发效率飞速提高。游戏的高层模型更依赖于具体游戏内容，但是如果能在此框架下开发，那么其通用性将通过少量特异化修改来实现；同时这些高层模型，在一定积累和沉淀后，很容易的就能成为通用性更强的中层模块。这个转换并无任何硬性规定，而是随项目和使用团队（社区）的变化而变化的：当某个游戏设计成为“主流”，对应的实现代码就能成为可服用的模块——这正是整体框架想要表现的最重要功效。