个基于组件的动态对象系统

个基于组件的动态对象系统

ID:29841766

大小:434.51 KB

页数:16页

时间:2018-12-24

个基于组件的动态对象系统_第1页
个基于组件的动态对象系统_第2页
个基于组件的动态对象系统_第3页
个基于组件的动态对象系统_第4页
个基于组件的动态对象系统_第5页
资源描述:

《个基于组件的动态对象系统》由会员上传分享,免费在线阅读,更多相关内容在应用文档-天天文库

1、一、静态的痛苦   作为一个项目经验丰富的程序员,你经常会遇到游戏开发过程中的“反复”(iterations):今天美术将一个静态的模型改为骨骼模型并添加了动画;明天企划会议上决定把所有未拾取武器由原先的闪光效果改为原地旋转;后天你的老板告诉你:配合投资方的要求,需要提升AI的质量,这使得AI需要响应特定的碰撞检测、可破坏的路径变化,甚至彼此的交互。哦,修改设计,按照教科书上的做法我们必须对现有代码进行重构,你回答道。但你的老板显然不这么认为。尽管全体程序员一致地、强烈地反对,项目经理还是决定要在一周内把这些改动全部付诸实施。这是一场噩梦不是吗?于是工程上的禁忌、代

2、码层面的犯罪……各种各样丑陋不堪的东西写进了游戏程序,除此之外,你还搭上了周末和女朋友约会的时间。更糟糕的是,当你周一凌晨提交代码后,发现原本“健壮”的游戏程序,经常莫名奇妙地崩溃,这让你的老板在投资方那里出尽了洋相……后果可想而知。   当然这不能完全责怪你的项目经理和老板,毕竟游戏不是一道纯软件大餐。而我相信,你的游戏只要还被当作一件艺术品来制做,就永远无法避免反复。既然它至榛完美的必经之路就是设计上的反复,那么我们总有办法将它的冲击降至最小。这里我要讨论的是一个基于组件的对象系统:在游戏层中,它可以使对象行为的改变变得异常简单,甚至可以在无需程序员介入的情况下

3、,由企划或设计师来动态组合成新类型的对象,而作为应用该系统的一个副产品,它还能为你的游戏层代码降低耦合度。下面让我们来看看,传统情况下我们是如何设计游戏层的:   所有的物体都是一个Object。它作为游戏中所有类型的基类,由许多子类来继承,诸如Renderable、Movable、Collideable等等。顾名思义是为可渲染对象、可移动对象、和计算碰撞的对象准备的基类。继承自Renderable又有一个名为Animatable的类,显然有经验的你也能猜到它具有赋予类型以动画的功能。在Collider之下有一个Inventory类,它定义了可拾取物件的一些规则。在

4、此之下就是一些具体的类,例如会进行动画的、可移动的Character人物类,以及只能渲染静态物件的、可拾取的Weapon类、Item类、Armor类。这样一个简单的类继承体系可以由图1来表示。图1  一个传统的、典型的、看上去不错的继承体系  嗯,这个继承体系看上去合理且干净,绝对可以做教科书中的范例,而且对于这个简单系统来说能工作得很好,直到有一天企划的设计发生了修改。就像之前提到的,企划们从测试员或内测玩家中获得了反馈:武器或者道具掉落在地上,如果没有一点显眼的表示,玩家很难注意到,甚至会让整个游戏显得死气沉沉。于是他们告诉你武器掉落在地上需要原地旋转,就像Qu

5、ake那样,而道具掉落在地上,每隔2秒要闪烁一下。你对照着类继承图比划了一下,觉得可以把Inventory类的继承关系从Collideable下转移为多重继承Collideable和Animatable。于是你开始修改类继承结构,尽管Armor不需要播放动画,一个空函数就可以打发它了。那么这个问题目前算是被解决了。可是好景不长,关卡企划觉得目前刚体物理的效果还不错,决定广泛应用这一特性,而他失望地发现很多物件都没有刚体物理的效果,只有RigidBody才拥有这项功能,而它的实现只有一些简单的盒子一类的物体,用于做关卡设计。于是他告诉你需要把屏幕上能看到的物体,尽量都

6、赋予刚体特性。你同他争执了一段时间,最后你妥协了,把Renderable整个拉到RigidBody继承体系下。这样尽管Tree和Character并不能按照一个简单刚体来运动,但至少Weapon、Item、Armor可以了。在折腾完关于刚体物理对象的改动之后,你再度审视这个继承体系时,发现它已经不像原先那般优雅了:大量定义接口的基类被放在继承树的上方,而下方都是零散的各个具体类。这很让人倒胃口,你这么想着,打算着手真正重构目前的代码。但时间不等人,第二天企划又告诉你,他需要用脚本来控制这些刚体对象的位置,这下连Movable都无法幸免,你必须把它移动到RigidBo

7、dy之上,让所有的具体类都能继承它。这样一个头重脚轻(top-heavy)的继承树简直是一个教科书式的反面教材(如图2所示)!坚持原则的你实在看不下去了,向项目经理提出了质疑,要求砍掉这个功能,或者开辟额外的时间让你重构代码。但是很不幸,很多情况下,项目经理是不会理睬这种要求的。  图2在许多“合理”的设计改动后,继承树往往变成了这种头重脚轻的样子  如此这般的设计,为什么无法满足游戏的快速反复的开发需要呢?我想主要原因有二:一是C++和其他强类型语言在继承上的强制性;二是我们恰恰让继承做了它所不擅长的事情。继承在很多强类型语言中,是一个静态的语言行为,是在编译

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。