基于DirectX游戏引擎设计与实现-计算机技术专业论文.docxVIP

华中科技大学硕士学位论文 华 中 科 技 大 学 硕 士 学 位 论 文 PAGE 10 PAGE 10 1 绪论 1.1 课题研究背景 在 20 世纪 70-80 年代，处于萌芽的阶段的电子游戏业对游戏开发有着很简单的 做法，当时的游戏“自成一体”，游戏的开发者只关心如何尽量多的开发出新游戏， 并把它们发布出去[1]。在这种情况下，每个游戏的代码都需要重新编写代码，重复工 作很多。因此，一些可复用的组件自然被游戏开发工程师总结并提炼出来。实际的 游戏概念被剥离出去，以抽象的游戏概念取代。专门的函数定义被修改，形成通用 的游戏接口，游戏引擎应运而生。游戏引擎是一个由多个子系统组成的内核系统， 它可以包括文件管理、网络通信、图像方面的模型绘制、动画控制、光线效果、粒 子系统、物理方面的运动学、碰撞检测等，几乎包括了软件开发的各种内容。 一个游戏引擎是诸多游戏中可重用的部分，也是诸多游戏的框架基础。游戏引 擎工程师完成工作后，游戏策划、美工和工程师再在引擎的基础上添加游戏规则、 物体、物体模型和动画。游戏引擎占用很大比例的开发时间，也是游戏中极为重要 的部分。 目前在游戏产业曾用到的著名引擎有 MAX-FX、LithTech、Infinity、Aurora、 Doom、Build、Quake、Unreal、Dark 和 Orge 等。MAX-FX 的开发花费 4 年，共 70 万美金。Doom 引擎来自同名的游戏《毁灭战士》(Doom)，经改进后被用于开发《投 影者》(Shadow Caster)，《异教徒》(Heretic)，《毁灭巫师》(Hexen)，取得了很大的成 功。Build 引擎诞生于销售量很高的《毁灭公爵》(Duke Nukem 3D)，它被用于开发 《农夫也疯狂》(Redneck Rampage)，《七侠五义》，《血兆》(Blood)，《阴影武士》(Shadow Warrior)等[2]。 1.2 设计考虑原则 本文开发的游戏引擎命名为 Vec，在开发层次关系中处于如图 1-1 所示的关系中。 游戏剧情，脚本 NPC 系统，交易系统，故事编辑，界 面窗口 游戏规则，AI，脚本系统 游戏引擎 Vec 战斗规则，人工智能，脚本交互 角色，动力学，地形，碰撞检测，音 效 3D 图形渲染，2D 精灵，设备支持 WinAPI DirectX 硬件 Hardware 图 1-1 游戏引擎开发层次关系 （1）使用简单的类层次结构 一个庞大的游戏，可能会在同一个命名空间，或者说概念层面上同时存在上千 个类和概念。开发者最容易遇到的问题之一，就是类分解的过细，或者分解的过粗。 构造函数，虚函数，继承对游戏开发有极大的益处，因为在一个游戏中，必然会模 拟物体之间互动的情形，而构造函数，虚函数，继承则为这些情形提供了最好的载 体。但是，暴露给外界的类层次结构越多，支持重写的虚函数越多，不同情形下的 构造函数越多，就越容易使外层在不自觉间破坏内层的数据结构，这样的错误，既 难发现，也难以更改[3]。尤其在内层属于游戏引擎开发者，而外层属于游戏开发者， 他们之间不是同一个集体的时候。每个类应保持简单的访问机制，一般情况下，一 个类应该永远只有 3-10 个公开的方法。访问机制越简单，耦合性越低，日后移除/ 添加新类的时候越容易。如果当一个类的对外接口超过 10 个乃至几十个方法的话， 新的访问接口必定已经可以组成一个新的类了。 （2）使用组合机制替代继承 当一个对象是从另一个衍生的，或者一个对象是另一个对象的特定版本的时候， OOP 推荐使用继承来实现这一关系。当一个对象是由许多离散的部分组成时，应该 使用组合。换句话说，使用继承的最佳场景是，一个类的性质基本上或大部分，源 于或依赖于一个唯一的另一个类。但是，在实际应用中，能严格证明一个类是严重 依赖于唯一一个另一个类的情况不多[4]。若要求使用继承来使用某个特定的组件，那 该组件需要向子类开放多少属性是个很大的问题。如果大量的属性都是子类可访问 的，那这样的设计完全不符合低耦合开发的要求。一般情况下，每个类的继承层次 只应低于 4 层。从目标二进制代码的角度来看，两者生成的汇编代码基本是一样的， 它们拥有相似的性能。 （3）尽量少使用虚函数，多使用接口 《创世纪》游戏的开发者 Mike McShaffry 形容说，虚函数是被大多数程序员滥 用了的强大怪物。从概念上讲，一个虚函数各种重写将要做的是同一件事情，不同 的重写，在细节上各有不同。继承结构使得这些细节混成一块，要让它们之间不互 相干扰和互相破坏很难，特别是在有多个程序员协作开发的情况下。如何能使所有 人对所有细节都有完全一样的理解？这基本不可能。虚函数的功能，可以由接口来 代替。接口与虚函数相比优点有很多。首先接口强制要