游戏服务器的概念设计2

上一篇的文章里,zack记录了对于从概念到设计的思考。后来zack发现,其实这些思考并不仅仅局限于技术实现,而是从游戏机制设计的本质出发在考虑。所以,将标题更改为游戏服务器的概念设计要更合适些。

对于做应用开发而言,不理解产品和业务本身,是很难做出好的设计的。这如同木工若不了解自己所做的木具究竟是什么,也无法做出好的物品道理是一样的。

之前zack谈到,将游戏理解为基于规则的系统 (rule-based system)是一个比较好的开始。那么接下来的问题,便是合理的围绕rule确定相关的概念。理清这些概念,并不是纯粹纸上谈兵的空论。在实际生产过程里,对于实现数据驱动是很重要的事情。

规则 (Rule) 根据输入条件的不同产生不同的结果。那么输入和结果可以抽象为怎样的概念呢?这次所记录的,便是zack围绕这个问题的一些思考。

存在于游戏世界中的规则,其输入的源头自然是有些世界中的物件。对于一个游戏世界,其中最基本的构成的元素用资源 (Resource) 这个词来描述应该是比较适合的。具体一点来说,resource可以代表全部可以用整数来表示的游戏具体概念。比如在一个生产类的游戏里,我们可以定义的resource可能包括木材,矿石,人口等。在RPG游戏里,resource也可以作为HP, MP, 经验值,力量,敏捷,金币等等这些最基础属性的更高层的抽象概念。

当设计一个游戏时,总会从一些基础的专有名词开始,或者说从一个基本的属性系统命名开始。这些一开始的属性命名,其实都是resource的别名而已。

伴随resource的一个概念是pool。所谓pool,就是一组resource的集合,pool最重要的作用就是用来组合成为entity。在这里,逻辑上的概念和技术上的概念开始逐渐统一在一起了。现在的游戏引擎框架,很多都是基于一套entity系统来实现,而不是大量的,多层的面向对象中的继承关系。通常来说,entity具有许多的property,但zack认为,将大部分property用pool的组合去代替,是一个更好的概念。property还是作为程序实现中的保留概念,将游戏内容中需要展现,尤其直接面向用户的属性,转化为pool的形式。

例如,一个描述生物基本属性的pool中,包含了HP, MP, Strength, Agility这些resource。另一个描述财富基本属性的pool中,包含了gold这样的resource。那么,通过这些不同pool的组合,我们就能创造具有不同性质的entity。

但类似物品是个特殊的概念,所以对于pool来说,未实例化的entity,也可以作为pool可以持有的资源。也就是说,pool除了可以包含resource之外,还可以包含pool组合而成的entity模版。

那么,pool除了用于提供组合形成entity的模版之外,另外重要的特性就是pool中的resource是可以流动的。这种流动只有两种形式,pull和gain。Pull将从一个pool中提取一定的resource,gain则相反,一个pool从外部获得一定量的resource。Pool通常也可以有几种类型,比如有些pool可能具有某种无限的resource,有些pool不具备gain的行为,一旦resource消耗完,那么这个pool就不存在了。有些pool自发定时的会pull或者gain定量的resouce,有些pool则需要玩家去交互激活时才会发生pull或者gain的操作。

比如对于一个药水物品的entity,这个entity具有一个需要交互的pool,pool中有一个resource中包含有50 HP。当交互发生时,实际上是这个pool中的resource发生流动,被提取到了另一个pool中。或者比如装备这样的entity也是一样,至于这个交互的名字是被定义为“使用“还是”装备“都无所谓,从本质上来说,都是pull或者gain的触发。

zack认为这样的概念设计有一个好处,这可以让我们避免过早被构造entity的名字所迷惑,而可以专心于游戏核心规则和机制的设计。同时不难发现,其实游戏许多游戏核心系统本质就是在处理resource的转化问题,rule决定了某一步的转化是否能发生,如何发生,以及之后的结果如何。

下一篇里,在有了构造entity的基础模版概念之后,zack会继续记录在决定resource转化的rule的过程中,会需要设计哪些具体的概念。