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

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

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

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

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

社交类系统的可复用模型

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

原文发布于微信公众号 - 韩大(handa1740168)

原文发表时间:2016-01-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏虚拟化云计算

2008到2018,Red Hat接手kvm十年

从2008到2018,Red Hat从Qumranet手中接过KVM后,已经有十个年头。

2615
来自专栏ThoughtWorks

技术雷达之微服务架构|洞见

最近几年,微服务架构异军突起,与容器技术相辅相成,成为架构设计领域热议的话题。而《技术雷达》作为ThoughtWorks出品的一份关于技术趋势的报告,在技术社区...

2743
来自专栏CSDN技术头条

Java 架构师最关键三个思维转变方式

很久没有写思维的文章,特别是在写完思维的逻辑和思维的框架后,对于理论层面的自己也不太想写。 但是对于实际案例层面的写起来又比较花时间,而且案例基本在IT专业领域...

4397
来自专栏用户3246163的专栏

你做的是微服务还是小单体?

先讲一个关于微服务的小故事:第一次接触到微服务这个概念的时候,我的第一反应以为微服务就是微信提供的某种服务。那段时间正是微信生态开始爆炸繁衍的时候,全中国好像把...

795
来自专栏架构师小秘圈

一名曾在BAT待过十年的资深Java架构师的经验之谈

所谓架构师,思考的是全局的东西,是如何组织你的系统,以达到业务要求,性能要求,具备可扩展性(scalability),可拓展性(extendability),前...

3234
来自专栏EAWorld

你适合微服务么:实施微服务的4个先决条件和重点工作

“Mesh App and Service Architecture”作为Gartner2016 十大战略技术趋势中之一,里面大量提到微服务的概念。微服务(Mi...

3316
来自专栏数据和云

DBA入门之路:关于日常工作的建议

今天上午在恩墨学院进行了一个简短的分享,引用了多年前我的一页PPT,其中记录了我对DBA日常工作的建议。 虽然这7点内容来自多年以前的总结,但是在今天仍然具有指...

2665
来自专栏JAVA高级架构

对软件架构的一些思维脑图整理

962
来自专栏数据的力量

你离高效仅『一步之遥』——模块化思维

模块化思维是指我们需要把工作分门别类,根据自己的工作职责和内容的特点,把工作内容切成相对独立的一些模块,然后根据模块的特点和重要性来采用不同的处理方式,高效地把...

994
来自专栏MongoDB中文社区

微服务下的数据架构

微服务是一个软件架构模式,对微服务的讨论大多集中在容器或其他技术是否能很好的实施微服务,而本文将从以下几个角度来和大家分享在微服务架构下进行数据设计需要关注的地...

642

扫描关注云+社区