基于5层模型对象游戏描述法.docVIP

基于5层模型对象的游戏描述法 前言 建筑设计图纸对于建筑工程的作用是无容质疑的，那么对于游戏制作工程是不是可以有类似设计图纸的描述法呢？ UML确实是软件项目做需求分析的很好工具，但注意是“软件项目”，对于游戏制作涉及软件开发、美术和游戏规则等等项目来说，UML最多也只能描述三分之一，UML怎么描述游戏规则和美术呢？ 分散、无联系地各自用各自领域的描述法，项目团队的人们可以很快地了解到具体一个功能或者设计在软件开发、美术和游戏规则三者之间的联系吗？ 本文就是尝试解决上面的问题，在之前《游戏制作5层模型介绍》的基础上，加入GM游戏制作的建模方法，把层与层的联系对象化，提出一个或许可以整体性描述游戏的描述法。 正文 首先先简单说明下游戏制作5层模型，具体可以到我的blog（）或者到 搜索 我之前的帖子。 我把游戏制作分为5层，由上到下分别是：商业模式层、故事层、核心规则层、逻辑处理层和物理层（包括视音资源层和操作层两个子层） 游戏制作的时候主要关心底三层，即核心规则层、逻辑处理层和物理层，并且这三层和游戏规则、软件开发和美术三者有联系，所以下面主要关心如何在这三层上建立一个可以整体性描述游戏规则、软件开发和美术的描述法。 各层的一些简单定义： 物理层，包含两个分层， 1、操作层，是考虑玩家向游戏系统输入的相关设计 2、视音资源层，是考虑游戏系统向玩家输出的相关设计 逻辑处理层 通过程序控制，在物理层的两个分层之间建立可靠、预期的联系，并使到这个联系可以有核心规则层的介入 核心规则层 利用逻辑处理层的服务，实现玩家选择处理等功能，让玩家在“输入”和“反馈”中得到娱乐。 分层式结构究竟其优势何在？Martin Fowler在《Patterns of Enterprise Application Architecture》一书中给出了答案： 1、开发人员可以只关注整个结构中的其中某一层； 2、可以很容易的用新的实现来替换原有层次的实现； 3、可以降低层与层之间的依赖； 4、有利于标准化； 5、利于各层逻辑的复用。 概括来说，分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准定义。 一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同层面设计的开发人员就可以分散关注，齐头并进。例如游戏策划人员只需考虑规则如何用户体验到有挑战性和如何让用户沉迷，游戏程序的设计人员可以仅关注程序逻辑的设计和算法最优，而游戏美术设计人员也不必为自己画的图象可不可以以被程序引擎支持和满不满足游戏策划想要的风格而头疼了。每个开发人员的任务得到了确认，开发进度就可以迅速的提高。 上面是对5层模型的介绍和论述分层的好处，但是没有把层与层联系起来，所有都是废的，所以下面引入GM的一些建模方法，尝试把层与层联系起来。 GM（gamemaker）是一个很不错的游戏制作软件，利用GM做了1个半游戏后，在制作的过程体验到GM的一些建模方法很不错，并发现可以用来充实之前5层模型，于是通过一些时间的思考，整理出下面的东西。 首先要确定一些定义 spirit 元图 最基本的单元，装载基本图像 sub_image 子图象 由相关的元图组成或者形成的单元 object 对象 概念定义同C++的“对象”，在这里比较常用来装载子图象或者元图 objects 对象组 需要聚合在一起的对象 ps：一些名词和GM同名不同概念，需要注意 spirit，元图，在2D游戏中，概念等同于“帧”，既如果是动画人物的话，spirit元图就是每一帧的图象，sub_image 子图象就是 数个帧组合成的动画；如果是在3D游戏，spirit即是3D模型，sub_image 子图象是这个3D模型形成的一些连续动作，比如行走、攻击等等。 object，对象，在这里主要要分成两种对象，一种是加载子图象或者元图的显示对象；一种是仅仅逻辑控制的控制对象。 对象由属性和动作组成，属性的概念类似于“类”的“数据”概念，用于描述本对象的特征，如坐标、人物的HP等等，而元图和子图象是一个特殊的属性。和“类”的数据一样，也可以有私用属性、友用属性和公用属性之分；动作的概念也类似于“类”的“函数”概念，用于描述对象对属性的操作。 从定义中可以看出，动作本身就是一个控制对象，考虑到高层的很多时候都不考虑具体操作，增加动作这个名称，作为其控制对象的入口，一个对象的动作必然对应一个控制对象。 控制对象还分为三级。 元图级控制对象S2S_ctl_object，主要用来描述元图和元图间的控制，比如一个顺序播放的动画，“顺序播放”这个控制就是元图级控制对象； 对象内控制对象（OIN_ctl_object），主要用来描述对象内部的控制，对于显示对象而言，一般是控制更换不同的子图象或者元图，比如我