论可复用的游戏服务器端开发框架（一）

本文试图以游戏服务器端开发的角度，探讨在需求高度变化的环境下，可重用模块构建的可能性和基本方案。

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

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

事实上，可重用的游戏服务器端框架，是完全可以设计和实用化的。因为理由也非常充分：一是国内游戏产品的游戏服务器端逻辑一般重，提供了丰富的实践需求；二是国内的游戏服务器端运行环境分类，还是比较统一的，其中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系统的可复用模型

社交类系统的可复用模型

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