文档介绍：一、静态的痛苦
作为一个项目经验丰富的程序员，你经常会遇到游戏开发过程屮的“反复”(iterations)：今天美 术将一个静态的模型改为骨骼模型并添加了动|出i；明天企划会议上决定把所有未拾取武器山原先的闪 光效果改为原地旋转；后天你的老板告诉你：配合投资方的要求，需要提升AI的质址，这使得AI 需要响应特定的碰撞检测、可破坏的路径变化，甚至彼此的交互。哦，修改设计，按照教科书上的做 法我们必须对现有代码进行重构，你冋答道。但你的老板显然不这么认为。尽管全体程序员一致地、 强烈地反对，项目经理还是决定要在一周内把这些改动全部付诸实施。这是一场噩梦不是吗？于是工 程上的禁忌、代码层面的犯罪•…各种各样丹昵不堪的东西写进了游戏程序，除此Z外，你还搭上了 周末和女朋友约会的时间。更糟糕的是，当你周一凌晨提交代码后，发现原本“健壮”的游戏程序，经 常莫名奇妙地崩溃，这让你的老板在投资方那里出尽了洋相.....后果可想而知。
当然这不能完全责怪你的项日经理和老板，毕竟游戏不是一道纯软件大餐。而我相信，你的游戏 只要还被当作-件艺术品來制做，就永远无法避免反复。既然它至榛完美的必经之路就是设计上的反 复，那么我们总有办法将它的冲击降至最小。这里我耍讨论的是一个棊于组件的对彖系统：在游戏层 屮，它可以使対彖行为的改变变得异常简单，甚至可以在无需程序员介入的情况下，山企划或设计师 来动态组合成新类型的对彖，而作为应用该系统的--个副产品，它还能为你的游戏层代码降低耦合度。 下面让我们来看看，传统情况下我们是如何设计游戏层的：
所有的物体都是一个Object °它作为游戏中所有类型的基类，山许多子类來继承，诸如 Renderable、Movable. Collideable等等。顾名思义是为可渲染对彖、可移动对象、和计算碰撞 的对象准备的基类。继承Q Renderable X有一个名为Animatable的类，显然有经验的你也能猜 到它具有赋予类型以动画的功能。在Collider Z下有一个Inventory类,它定义了可拾取物件的一 些规则。在此Z下就是一些具体的类，例如会进行动画的、可移动的Character人物类，以及只能 渲染静态物件的、可拾取的Weapon类、Item类、Armor类。这样一个简单的类继承体系可以山 图1来表示。
Ot3ject
Renderatie Movable Coilidaue
图1 一个传统的、典型的、看上去不错的继承体系
嗯，这个继承体系看上去合理且T浄，绝对可以做教科书中的范例，而且对于这个简单系统來说 能工作得很好，立到有一天企划的设计发生了修改。就像乙前提到的，企划们从测试员或内测玩家中 获得了反馈：武器或者道具掉落在地上，如果没有一点显眼的表示，玩家很难注意到，甚至会让整个 游戏显得死气沉沉。于是他们告诉你武器掉落在地上需要原地旋转，就像Quake那样，而道具掉落 在地上，每隔2秒要闪烁一•下。你对照着类继承图比划了一下，觉得可以把Inventory类的继承关 系从Collideable下转移为多重继承Collideable和Animatable。于是你开始修改类继承结构,尽 管Armor不需要播放动画，一个空函数就可以打发它了。那么这个问题目前算是被解决了。可是好 景不长，关卡企划觉得U前刚体物理的效果还不错,决定广泛应用这一特性,而他失望地发现很多物 件都没有刚体物理的效果，只有RigidBody才拥有这项功能，而它的实现只有一些简单的盒子一类 的物体，用于做关卡设计。于是他告诉你需耍把屏幕上能看到的物体，尽量都赋予刚体特性。你同他 争执了一段时间，最后你妥协了，把Renderable整个拉到RigidBody继承体系下。这样尽管Tree 和Character并不能按照一个简单刚体來运动，但至少Weapon、Item、Armor可以了。在折腾 完关于刚体物理对彖的改动Z后，你再度审视这个继承体系时,发现它已经不像原先那般优雅了:大 量足义接口的基类被放在继承树的上方，而下方都是零散的各个具体类。这很让人倒胃口，你这么想 着，打算着手真止重构日前的代码。但时间不等人，第二天企划乂告诉你，他需耍用脚本來控制这些 刚体对象的位置，这下连Movable都无法幸免，你必须把它移动到RigidBody Z上，让所有的具体 类都能继承它。这样一个头重脚^(top-heavy)的继承树简直是一个教科书式的反面教材(如图2所 示)！坚持原则的你实在看不下去了，向项目经理提出了质疑，要求砍掉这个功能，或者开辟额外的 时间让你重构代码。但是很不幸，很多情况下，项目经理是不会理睬这种要求的。
图2在许多“合理”的设计改动后，继承树往往变成了这种头重脚轻的样子
如此这般的设计，