游戏开发笔记(五)——服务端系统分层

        本来很想按顺序写下来,到了第五篇是打算先写架构的,无奈这东西暂时没办法弄的比较通透,拖了很久也还是觉得写起来有困难。有一个客观因素是这阵子有点忙,很多东西要做,也没办法留出许多时间用来学习。

        还是先写已经有点概念的东西吧....

 

关于架构:

        一个复杂系统开始施工前首先要设计其架构,但这个暂时没能力说太细,所以只简单一提。

 

        什么是架构呢?

        我理解的架构就是一组能够描述服务端功能的概念模型,它能把复杂的问题使用相同统一的方式进行描述,或者说可以把一个复杂的现实问题转化为相对可控的工程问题。它甚至不需要任何代码,不需要复杂的UML图,不管通过任何方式只要能够简化并描述问题。而且并不是只有最上层的架构才叫架构,我觉得它应该是一棵决策树,每一个节点的架构设计都可以叫做解决该问题的架构。

        对于一套完整的服务端架构来说,应该包含软件架构和硬件架构。有时候一些软件上极难解决的问题却可以通过硬件方案轻松解决,所以对于网络游戏这种相对大型的软件来说,硬件方案设计也是不可缺少的。

        对架构的要求包含两个方面,第一个是硬性要求,要求能够在这套架构的基础上完成预期的游戏功能并具有一定程度的可用性;第二个是优化要求,条件允许的情况下尽可能的使得架构基础上的功能开发清晰简单,尽可能做到对未知需求具有良好的伸缩性,尽可能的对运行期效率有所保障等等(你所能想到的好的方面)。

 

系统分层:

        系统分层是软件架构设计的一个重要方面,分层的思想在《代码大全》里有相对详细的描述,应该是比较早就提出了,是降低系统复杂度的一种比较常见的做法。

 

        分层的粒度是根据问题的复杂程度以及具体的业务内容来决定的,对于简单问题使用过细的分层不只是杀鸡用牛刀的问题,实现起来也会变得啰嗦冗长,简单的问题会被搞复杂。这可以理解为对简单问题赋予了太多的概念,概念这种东西最好保持精简,这是设计范畴的问题了。 

        游戏的服务端根据游戏的类型和公司的实际情况会有许多差异,限于个人知识没办法一一比较说明,我只写我相对熟悉的MMOARPG的服务端设计。

一般也是类似软件业比较经典的三层划分(没记错的话应该是 系统层、业务逻辑层、表现层),首先是系统层,然后是引擎层,最后是逻辑层。下面分别介绍:

 

· 系统层:

        之所以需要有这么一层主要是因为程序语言层面能够提供的功能十分有限,更强力的功能常常要通过操作系统获得(比如线程和线程的各种锁)。当然您也可以试试避免直接从操作系统获得这些功能,而全部改用第三方库来解决问题,但他们的底层特性肯定也只能是来自操作系统,区别只是是不是你自己来做这些事情而已。

        该层设计的目标是要把所有依赖特定系统的逻辑全部隔离在这一层内,防止上层逻辑对操作系统产生直接依赖。同时,根据上层需求向上层提供足够多的底层功能。大概不会涉及比较复杂的程序编码,但这层实现起来也是相当不轻松的,因为现在基本都会有跨平台的需求,所以一定要在系统层考虑好程序移植问题,把程序规划好,尽量在移植的时候只需要按定义好的接口用最少量的代码再实现一个该系统的版本。同时,开发系统层也是需要对主流操作系统编程有一定经验(因为这个地方常常许多坑),防止系统API误用导致后期BUG追查起来十分困难。

        一定要处理的干净稳定,这样才称得上是为上层开发打下一个良好基石了。

 

· 引擎层:

        游戏的逻辑层有着海量的游戏逻辑,所以为了简化问题,还是把其中一些和游戏内容关联不大但必不可少的功能抽取出来单独作为一层。即去掉具体游戏逻辑的血肉,剩下来的其实都可以囊括到引擎中去。除此之外,设计引擎层也是比较经济的做法,因为和具体游戏逻辑不关联,又包罗万象集合了许多公共组件,它日做其他项目的时候可以完完全全的复用起来。引擎层铺设在系统层的基础上,与操作系统相隔离。

        一般而言引擎层会涉及的问题:通信、日志、数据库、场景管理、配置管理、主循环、脚本系统、计时器、内存管理、线程管理、容错机制、基础游戏对象、视野管理等。具体项目不一定这么划分,但一般认为这套功能是MMOARPG服务端标配了。各个模块意思也很清晰,所以我想不用一一介绍也不影响理解引擎层是怎样的东西。

 

· 逻辑层:

        逻辑层建立在引擎层的基础上,一般不需要操心除游戏功能以外的东西(如果不是的话通常暗示结构设计不合理)。到了逻辑层当然就是指那些与游戏内容密切关联的程序了,项目对游戏功能的要求越高,逻辑层的代码就越多。多是一定的,但具体多多少,增长的快不快还是一定程度上取决于开发者对游戏的理解,看看是否能对一些功能进行简单合理的抽象。

        逻辑层的主要就堆堆逻辑(十分琐碎),一般对编码能力要求不高,但实际上对设计的要求颇高,代码多则BUG多,太多功能写起来要命维护起来就更要命了...但据观察写逻辑的一般是程序部门人数比重最大的,而且对编码能力又没那么高的要求,所以一般都拿来控制成本了,所以良好设计什么的是不能有太多期待。要么就是先派一俩强力党先把核心功能写好,避免让后期纯粹来写逻辑的人来设计模块,这样可能还比较稳妥些。

        逻辑层一般包括:具体游戏对象(玩家、NPC)、基本游戏行为(聊天、战斗,移动常常会被抽到引擎层去)、帮会、任务、道具、技能、副本、宠物、好友、PK等。

        关于逻辑层的设计有许多东西可以讲,这里先不展开。

  • 3
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值