可复用的游戏服务器端开发框架之副本系统

在早期的联网游戏中，有两种典型的不同种类，一种是类似《传奇》的全地图，分区分服的MMORPG；另外一种则是类似QQ Game类型的“大厅-开房间”的全区全服游戏。

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

在“副本系统”中，最需要考虑的是游戏服务器的隔离性和生命周期。这时游戏服务器不再简单的代表一个静态的“虚拟世界”，而是一批动态的，不断生灭的小虚拟空间。同时我们还需要一个相对静态的“大厅”。

因此在副本系统中，最典型的模型就是：大厅、房间这两个概念。大厅提供玩家的接纳，了解房间的情况，提供玩家对房间的管理、操作；有很多游戏还需要提供自动匹配建立房间的功能。而房间则应该是一个对游戏关卡的容器，能承担任何一段游戏逻辑，但是需要大厅提供一组玩家和选择关卡作为输入，最后在结束时提供一个返回给大厅，修改房间的状态和触发玩家的关卡结算。对比与那些复杂的游戏逻辑系统，副本系统本身。

这个模型下各类的行为：

• 大厅
  • 列出所有房间
  • 使用关卡数据建立房间
  • 角色进入、离开房间
  • 启动房间游戏
  • 自动匹配玩家进入房间
• 房间
  • 输入关卡数据构建房间
  • 房间类型setter/getter:公开、加锁
  • 关卡数据getter/setter
  • 列出房间中所有副本角色
  • 列出房间所有者（队长）
  • 切换房间所有者（队长）
  • 启动关卡对应游戏
• 副本角色（与玩家角色类型绑定的模板类）
  • 根据玩家角色构建
  • 返回副本角色匹配数据：匹配数据为一个map类型自定义结构
  • 返回玩家角色对象
  • 准备就绪-锁定
• 关卡（与关卡数据类型绑定的模板类）
  • 关卡人数范围
  • 返回关卡对应游戏数据：游戏关卡数据为另外定义的特有类型，因此此方法应该为模板方法。
  • 启动关卡对应游戏（虚函数）：输入副本角色（玩家列表），根据自身具体游戏数据启动。
  • 副本角色中断副本，离线保存（虚函数）：当玩家断线或其他操作，系统调用此回调
  • 副本角色重新进入副本（虚函数）：当玩家重新进入游戏，系统调用此回调

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

总结

本文初步介绍了可重用的游戏服务器框架中的三层结构。其中底层的通用性强，技术含量高，关注非功能特性较多，事实上你可以用这个底层开发任何后台服务器，其对游戏最有意义的功能在于广播和复杂结构的本地数据缓存能力。

而框架的中层结构，提供了大量的游戏业务领域的建模，这些建模也许不是非常详细，不够详细，但是如果我们坚持分层设计原则，并且以库和开放源码的方式去维护，那么这些中层模型将日渐强大，成为可重用代码的核心模块，让游戏开发效率飞速提高。

游戏的高层模型更依赖于具体游戏内容，但是如果能在此框架下开发，那么其通用性将通过少量特异化修改来实现；同时这些高层模型，在一定积累和沉淀后，很容易的就能成为通用性更强的中层模块。这个转换并无任何硬性规定，而是随项目和使用团队（社区）的变化而变化的：当某个游戏设计成为“主流”，对应的实现代码就能成为可服用的模块——这正是整体框架想要表现的最重要功效。

感谢大家的阅读，如觉得此文对你有那么一丁点的作用，麻烦动动手指转发或分享至朋友圈。如有不同意见，欢迎后台留言探讨。