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

RPG系统的可复用模型

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

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

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

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

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

  • 角色
    • 新建角色,返回ID
    • 根据ID从持久化或缓存中读取角色load
    • 把角色存储到持久化数据中save
    • 属性的get/put/list
    • 技能的get/put/list
    • 背包内容的put/get/list
    • 装备的arm/unarm/get_by_position
    • 装备栏的add/remove/list
  • 属性
    • 根据ID构造
    • 对于各成员属性的getter/setter
  • 技能
    • 根据ID构造
    • 对于各成员属性的getter/setter
  • 物品
    • 根据ID+数量构造
    • 对于各成员属性的getter/setter
    • 使用(可能消耗)
  • 装备
    • 根据ID构造
    • 对于各成员属性的getter/setter
    • 被装备armed触发的效果回调
    • 被脱下unarmed触发的效果回调

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

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

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

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

社交类系统的可复用模型

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

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

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

以上类型的成员方法:

  • 交互消息
    • 内容的getter/setter
    • 发送方/接收方的getter/setter
  • 交互系统
    • 发送一条消息
    • 收取一条消息
    • 设置收取回调通知
  • 玩家关系
    • 加入一个角色
    • 列出所有角色
    • 删除一个角色
    • 新建关系列表,返回ID
    • 根据ID从持久化或缓存中读取角色load
    • 把角色存储到持久化数据中save

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

明天接着讲:

引导类系统的可复用模型

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

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

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

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序员宝库

程序员遇到 Bug 时的 30 个反应,你是哪一种?

来源:techug.com http://www.techug.com/post/programmer-reaction-with-30-bugs.html 开...

3809
来自专栏FreeBuf

神器分享:物联网黑客工具包

今天,我将在BSides San Francisco做一个题为“物联网黑客工具包”的演讲。我会准备一个幻灯片并且发布一篇博客去参加这个演讲,如果有我演讲的视频链...

1290
来自专栏养码场

总结了10余年工作经验,浪迹在知乎的“老”程序员给出了这50条建议

4、注释贵精不贵多。杜绝大姨妈般的“例注”。漫山遍野的碎碎念注释,实际就是背景噪音。

1202
来自专栏斑斓

如何在咨询项目开展Inception

本文通过我在咨询工作中的真实案例讲解了如何将敏捷开发的Inception与可视化咨询手段结合。2014初,我作为咨询师为客户提供咨询服务,负责一个新项目的敏捷咨...

3074
来自专栏大数据挖掘DT机器学习

如何入门 Python 爬虫?

刚做完一个跟python爬虫相关的项目,也来说说自己的经验,希望对想学习python爬虫的人有所帮助。 既然问的是如何入门,我想一定是助学者,而且我觉...

3699
来自专栏知晓程序

想要津津有味地撸代码?这 3 款小程序你一定用得到

但是,不是所有的程序员,都有机会跪在爱范儿前端女王大人的旁边,享受零 bug 光环的福泽。

1193
来自专栏java一日一条

程序员遇到Bug时的30个反应

开发应用程序是一个非常有压力的工作。没有人是完美的,因此在这个行业中,代码中出现bug是相当普遍的现象。面对bug,一些程序员会生气,会沮丧,会心烦意乱,甚至会...

663
来自专栏云计算D1net

将数据迁移到云:回到未来?

数百家公司现在已经证明,单一数据泄露可能会造成长期的经济,法律和品牌上的损失。除了数据保护之外,仅仅管理云中的数据是不同的,如果做法不当,成本,复杂性和风险会使...

1200
来自专栏互联网数据官iCDO

5招教你轻松获得手机App好评

引言:在应用程序方面,意见和评论也会影响到应用程序商店搜索结果的可见性,以及它们在app store中出现的概率。因此,如何能获得更多的好评呢?本文教你5招。 ...

3575
来自专栏HaHack

Wixo - a wiki theme for Hexo

1883

扫码关注云+社区