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

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

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

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

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

相关文章

来自专栏企鹅号快讯

小程序运营的六大基础能力

很多自媒体运营,对小程序的使用,以及结合公众号的引导成交做的还不够好,小程序上线已经快一年了,各种能力的开放,也极大方便了自媒体运营,尤其是自媒体电商的转化。今...

2756
来自专栏web前端教室

前端工程师的未来亮点在哪

前端开发这个职业,在目前以我老旧的工作经验来看,虽然有些百花齐放的姿势,但根上依然是JS(ES5\6)、CSS(2\3)、HTML(4\5)。看的再聚集一点,依...

1666
来自专栏SEO

「知识」SEO策略的4个关键领域

1973
来自专栏网站设计制作、数字营销

企业网站设计趋势 网站如何做才显有档次

企业在互联网时代网站是必备的一项,无论是否在线上做数字营销,企业网站成为企业首要配置之一。那么在现代企业网站设计趋势下,企业网站如何做才显得符合国际化,显得上档...

833
来自专栏云计算D1net

如何最小化云API升级造成的中断?

云提供商升级API时,开发者必须升级并重新测试自己的软件,如何为这个过程做好准备并且最小化影响? 云提供商为了扩展和改善服务进行了服务升级,通常需要进行API升...

2673
来自专栏京东技术

移动测试避坑指南(第一篇):从流程到技术的知识概要

1674
来自专栏wblearn

什么是2016年最值得学习的编程语言?

对于标题这个问题,如果你问我什么是2016年最值得学习的编程语言?我只能老老实实地回答:我也不知道,只能说适合自己的才是最值得学习的编程语言。因为我不知道你对那...

771
来自专栏java一日一条

什么是2016年最值得学习的编程语言?

对于标题这个问题,如果你问我什么是2016年最值得学习的编程语言?我只能老老实实地回答:我也不知道,只能说适合自己的才是最值得学习的编程语言。因为我不知道你对那...

571
来自专栏大数据文摘

【干货】21个数据可视化利器

25011
来自专栏程序员的知识天地

五个案例简述Web设计原则:通用一致

《Web设计指南》是专门为广大Web内容生态提供一套简单实用的设计指南,目的是提升设计与开发的效率及质量,为广大用户提供优质的用户体验。

811

扫码关注云+社区