【毕业学位论文】（Word原稿）内核无关的数据驱动组件式游戏引擎架构-软件工程

硕士学位论文 （专业学位） 内核无关的数据驱动组件式游戏引擎架构 姓 名： 李铮 学 号： 1021170025 所在院系：软件工程学院 职业类型： 专业领域： 指导教师：贾金原 副指导教师： 肖广 二 一 三 年 六 月 A in 2010 2013i 1021170025 摘要 现代的游戏产业经过了多年的发展，已经从一种简单的娱乐形式转变为多样化大众化的符合娱乐模式。游戏的类型不断 地增加，受众面的覆盖越来越广，游戏平台也开始由传统的电脑与游戏主机扩展到手机等非专用平台上。随着市场的不断扩大，用户对于游戏的 要求也越来越高，竞争也日渐激烈。游戏开发商必须要持续不断地推出高质量的新作以维持市场地位， 并且新作必须尽量多的覆盖各种主流游戏平台。 然而游戏质量的高要求带来了开发周期的延长 与紧凑的发售日程之间的矛盾日益尖锐 ，这对他们带来了很大的制作开发压力。 目前的主流游戏引擎为了提高开发效率，都具备了开发流程中各个环节的配套工具 ，这些工具中最重要的便是游戏编辑器 。 但是 现有引擎框架中编辑器 功能针对性 强 ， 可复用性低，在实际游戏开发中往往需要根据内核针对性的开发专门的编辑控件，从而导致开发效率低下并且维护困难 。 针对这种情况， 我们需要改进现有的架构，做到让编辑器 独立存在 且 不需要 在 内核的改动 是 进行 人工 修改 ，以达到提高实际游戏开发制作效率的目的。 本文以实际游戏项目为背景，设计并开发了一套基于 数据驱动模式的 动态化组件结构的游戏引擎与配套编辑器的架构模式。 该架构模式 通过分离出游戏内核逻辑，做到 内核无关，使得 诸如 编辑器等 引擎配套工具不依赖于内核代码，而是通过接口规则动态匹配 并生成 编辑控件 ，达到 在不同项目切换环境下的 自动适应 。此外，还能 提高数据兼容性与容错度。 使得编辑器的游戏资源制作与本地代码开发可以同步执行，大大提高了游戏制作的效率。基于数据驱动的架构也使得维护与版本升级更加容易与安全。 关键词 ： 游戏引擎， 数据驱动，组件式架构，类型数据库 目录 第一章 引言 . 6 题的研究背景与意义 . 6 戏引擎的发展 . 6 内外发展现状 . 7 文主要研究内容与组织结构 . 10 第二章 引擎架构概述 . 11 构的设计理念 . 11 计概念和设计特色 . 11 块结构 . 11 于组件的游戏实体结构 . 13 型数据库 . 15 语定义 . 16 章小结 . 17 第三章 引擎数据架构的设计 . 18 计目标与结构组成 . 18 展 统设计 . 20 用运行时类型识别 . 20 计思想的结合 . 21 应用 . 22 管封装与创建托管实例的实现 . 23 心功能的封装与实例化 . 23 型的封装与实例化 . 24 章小结 . 25 第四章 核心数据系统的设计 . 26 计目标 . 26 展的类型元信息与属性数据的设计 . 27 册属性信息的 实现 . 27 象与属性信息的序列化与反序列化实现 . 29 象的序列化 . 29 性信息的序列化 . 30 章小结 . 31 第五章 动态编辑器组件的设计 . 32 计目标 . 32 心数据流的整合应用 . 32 性接口的实现 . 33 戏对象的树形组成结构 . 33 种策略的设计与对比 . 34 件与数据绑定 . 35 础编辑控件的选择 . 35 性接口类的实现与编辑控件扩展 . 36 章小结 . 37 第六章 结论与展望 . 38 论 . 38 一步的工作方向 . 38 参考文献 . 39 第一章 引言 题的研究背景与意义 一个软件的架构，是指其 在组件，彼此间和与环境间的关系，引 导设计发展原则中体现的系统的基本结构。 它是一个软件系统从整体到部分的最高层次的划分，一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。 可以说软件架构是软件的大局规划，为具体开发提供指导与限制， 它的设计决定了这个软件的功能结构 与扩展潜能。 现有 主流的游戏引擎的前身都是一些成功的游戏项目， 由于其核心在游戏中表现出色被人所接受，于是便在其之上构建出的一套完整的引擎系统。 这些引擎的着重点都在于游戏应用的性能而对于开发便利度不够重视，其次它们的架构针对性很强可塑 性差，在原型以外的游戏 类型中 应用 难度 很大 灵活性很低 ， 进而 影响到了开发效率 。 所以 本文针对这些问题，旨在通过优化引擎架构的方式，改良游戏引擎在开发中的通用型与灵活性。 通过这些改进 来提升引擎在游戏项目中的开发效率与易用性。 戏引擎的发展 早期的游戏引擎大多数以功能库的形式存在，当时的游戏开发者将现有的代码进行整合，从中抽离出可复用的模块，以达到减少重复工作、提高开发效率的目的。这些功能库一般涵盖了图形、数学、内存与线程管理、资源管理、声效、物理与网络等底层功能。这些库涵盖了每个游戏所必须的功能，其性能 优劣直接影响到游戏的表现。性能优秀的底层引擎会非常受到游戏开发者的欢迎，因此，便出现了职业的游戏引擎开发者。 早期的游戏引擎无论性能多么强大，其面对的用户都是程序员。随着游戏场景与关卡逻辑的日渐复杂，转职的游戏设计师（策划）加入到游戏开发中来。这些设计师通常缺乏编程功底，因此为了让他们能够高效的工作，便开始采用使用所见即所得（ s 式的编辑器来进行关卡编辑。 设计师通过编辑器能够直接使用游戏资源构建场景，放置美术资源与逻辑触发器等。 一些 游戏 的关卡编辑器完善的功能与简单的操作让非专业人士也能轻松使用，甚至 会将 其公开 让玩家也能创建自定义关卡。 于是，关卡编辑器现在已经成为了游戏引擎不可或缺的一部分。 对于商业引擎而言，开发者不会使用引擎自带的美术与逻辑资源， 因此引擎都会带有配套的资源管线工具来处理资源，以及专门的脚本系统来扩充游戏逻辑。 较高端的引擎如 使用可视化状态机来简化部分 脚本 逻辑的编辑操作 ，或者引入了动态的脚本对象编辑工具（如 。 脚本级的功能扩展 非常 有限，并且依赖于内核代码并受到其限制 ，因此 部分引擎（如 了进一步增强扩展性会开放部分 内核 。 这样虽然给游戏本身的 功能实现 大大的增加了灵活性， 不过 为了 使用这些新加入的自定义功能， 将 它们 反映到编辑器上 ，仍然需要 额外 实现对应的编辑器脚本 甚至 使用编辑器 构建编辑控件。 图 擎编辑 器界面 内外发展现状 游戏引擎随着技术的发展越来越成熟，其功能区域完善的同时也变得愈发复杂。 现今的商业引擎越来越作为一个独立的产品来运作而不是像早期引擎那样 作为 一个游戏的定制核心组件存在。 其运作方式主要有两种：一种 是引擎配合 完整的工具与资源管线，利用场景编辑器导入美术资源并在现有框架上用脚本构建游戏逻辑，使用配套工具完成整个游戏的制作。 另一种是将内核按功能点来提供源 代码，用类似于第三方插件的形式以模块的形式来销售 。 对于 免费 /非商业引擎而言，由于无法做到大成本的开发投入，。虽然通过完全开源能够吸引 独立开发者共同完善，但整体效果与配套周边仍无法与商业引擎相比，因此往往用于小型游戏或者教育实验领域。 以下是当今三种有代表性的引擎对比； 业性质 完全免费 免费使用 购买套件与发布许可 收费 (对非商业使用免费开放 购买各平台发布许可 源码 开源 不公开 按模块购买 功能 底层核心功能 完整开发管线 完整开发管线 平台 移动平台 多平台 移动为主 多平台 主 开发 调用 底层代码 不同平台使用不同语言 使用编辑器 兼 容多种语言的 使用编辑器 独立语法的 本 ，带可视化编辑 根据授权开放底层代码 扩展 大量免费的第三方扩展版本 提供 第三方脚本与资源 共享平台 提供 为单个游戏进行引擎定制 工具 少量第三方工具 自带全部工具 支持开发编辑器组件 自带全部工具 支持开发编辑器组件 表 种有代表性的引擎对比 这三个引擎从逻辑架构而言， 为针对小型手机游戏的引擎，没有提供上层架构，需要开发者自行实现。 用了数据驱动的模块化脚本，开发便利但是完全无法接触底层功能，应用非 常受限。 供了可视化脚本编辑，但是其游戏逻辑都是针对 现的， 如果有额外要求，必须购买源码来进行引擎定制。 就 技术 趋势来看 ， 当代的引擎 逐渐都 采用了数据驱动和模块化的设计 模式 。 数据驱动编程是一种设计思想，在这种思想中，数据不仅仅是描述某个对象的状态，实际上还定义了程序的流程。 11其最初的核心是认为，数据比程序逻辑更容易驾驭，因此要尽可能把设计的复杂度从代码转移到数据上。 将抽象数据类型设计思想融合到面向对象编程中，就形成了数据驱动的的设计思路 13，其优势在于： 1 - 可读性更强，消息 处理流程一目了然。 2 - 更容易修改，要增加新的消息，只要修改数据即可，不需要修改流程。 3 - 重用，避免 重复的数据与代码，让代码更精简。 最基础的数据驱动游戏设计将游戏逻辑储存在数据文件中由运行时实例化，而非内嵌在代码里。这些数据包含关卡设计和脚本等，可以由工具来生成。通过使用关卡编辑器等工具制作游戏数据能够大幅的节省时间，降低开发门槛，让更专注于游戏过程的设计师在制作中减少对程序员的依赖。 除此之外更高级的数据驱动设计将本地代码功能原子化抽象化，把控制流放在数据中，使得引擎可以满足不同需求的复杂环境。其 次，低耦合的结构降低了代码的依赖性，能够让开发工作的分工更明确且更具针对性。当代引擎中， 采用了将逻辑代码脚本化的设计，通过脚本的驱动来连接关卡数据和本地代码来实现这种高级数据驱动特性。 组件化编程 （ 很早就实用于游戏开发中，第三方中间件就是一个典型的例子。游戏开发者在加载中间件后，直接通过固定接口来调用这些模块的功能操作 负责处理游戏中的一个特定功能 。与此同时，中间件的开发者保持其模块的持续优化与更新，使得 游戏开发者无需对自己的代码进行调整就可以使用到最新的功能。 对象管理小组（ “建模语言规范”中将组件定义为：“系统中一种物理的、可代替的部件、它封装了实现并提供了一系列可用的接口。一个组件代表一个系统中实现的物理部分，包括软件代码（源代码，二进制代码，可执行代码）或者一些类似内容，如脚本或者命令文件。” 2008组件化程序设计结构是为了解决软件复用，缩短开发时间，降低维护成本和实现程序 动态升级而出现的。其核心概念是接口，目的是粗粒度的复用，以满足应用程序定制与快速应用程序开发。 同面向对象编程 (比，面向组件编程是一种组织代码的思路，将系统看作一个个的组件，通过定义组件之间的写过关系来完成系统地构建。在属性和事件等更高级的概念支撑下，解决了面向对象技术中类依赖、消息传递问题，满足了组件的物理独立性和粗粒度的复用。 现代化的可服用组件已经同时涵盖了数据结构以及引用在其上的算法，它们建立在面向对象设计中的对象、架构、框架与设计方法等理论上，使得软件组件如同通信硬件组件一般能够不受限制的 组合使用。 19 基于组件的游戏引擎， 不仅仅是要 将引擎的底层实现进行模块化，上层的逻辑组成部分也 需要 进行了组件化。 游戏的逻辑实体 不再自行实现行为，而是将行为组件化 ，通过行为组件的组合来实现一个独立的实体。 组件的组合可以直接在引擎编辑器中完成，不需要单独的编码工作，这大大的简化了逻辑制作的复杂度。 以 例，它是较早实现用户 逻辑数据完全组件化的引擎之一 ，用户脚本中的类型继承 口后会被编译为脚本组件 ，附加于游戏物体上之后便能够直接操作该物体，从而实现游戏逻辑。 文主要研究内容与组织结构 本文旨在构建一种引擎架构 （暂名 数据 类型 组件框架 ，研究的重点在于架构的组织 设计 、模块分配管理、 重点模块的设计与实现、 以及相对应的资源管理部份。 本文的组织如下： 第二章对整个引擎的架构做一个简单的介绍 引擎 概述 第三章介绍 引擎的类型 数据库 第 四 章介绍 核心数据流 第五 章介绍 组件化逻辑结构与 动态 编辑器 组件的实现 第六 章对全文做一个总结和展望 总结 第二章 引擎架构 概述 构的设计理念 本课题 着眼于改进现有 引擎架构以使得其能够保持开发的低成本与高效率以满足 对游戏开发的日程、预算有高要求的开发环境。 针对游戏引擎的内核与编辑器等工具之间的架构关系进行优化 ， 旨在提高引擎在不同项目之间的通用性与重用效率 ，以达到实用一套引擎开发多类产品的目的 。 引擎架构暂名为数据类型组件框架（ 顾名思义其实现的核心 思想 是将 类型数据化，再把 数据转化为游戏组件 嵌入到框架中 ，以数据驱动的形式解决内核与工具耦合度的问题 。 因此，这个引擎架构应当包含如下特性： 含有核心接口规则，所有 的模块均需要支持此接口。 使用专门的 块 为所有的模块 提供底层支持 。 使用本地非托管代码提供底层功能支持。 并利用托管模块进行封装到块中。 块 独立存在 ，使用不同的启动器以不同的模式启动 ，包括托管服务模式与独立运行模式 。 块中会为所有的行为定义编辑接口 ，并在特定的服务模块中注册。 编辑器将针对这些编辑接口进行解析并动态生成编辑控件 。 游戏关卡资源均以数据 字段 （ 的形式存在 。 其存在不依赖于 控件 或本地属性 编辑器控件在载入数据字段时将进行反序列 化的解析与纠错。 计概念和设计特色 块 结构 据功能和代码实现特性，划分为多个模块。 每个模块在代码中都是以独立的工程实现存在的。 一个模块有可能包含多个工程，工程可以是静态的类库，也可以是输出 独立可执行程序。 本架构的模块结构划分如下： I E n g i n eG s I n t e r f a c eE i n g i e B a s eE n g i n e N a t i v eE n g i n e W r a p p e rE n g i n e I n t e r f a c e ( C L R )G s W r a p p e rG s C o m p o n e n t B o o t N a t i v eB o o t T o o l F r a m e w o r kB o o t C L 擎模块架构图 按照层次划分，从下到上可分为：基础层， 本地 层，接口层，应用层 。 基础层 基础层 即图表中的 块 ，这个模块将被本地层所引用 。 它 负责处 理所有的底层 功能 ， 例如渲染、内存、数学等 游戏运行提供必须的 部分 。 这些功能往往和平台有紧密联系 ， 因此为不同平台针对性的做实现， 在编译和运行时根据平台来加载对应的模块来为 上层提供服务。 本地层 本地 层 的内容主要为 游戏特定（ 的代码实现 。 专门针对当前项目使用 功能模块， 这些模块针对性非常强因此 基本不会被重用 。 它们可以作为功能点、库 或者 服务的形式存在 。 部分 功能，例如物理在实际使用中会对 的类型有引用依赖，因此这些功能会在 保留一个专门 的 封装 接口 来保持其独立 性。 本地层中除了实现 能之外，还需要对 定义的 服务接口（ 进行代码实现。 这些 服务接口不会直接依赖于 地的服务在实现后，只需要在服务接口中注册即可。 接口层 接口层包含 大功能模块。 这一层会被大部分的功能模块所引用。 来定义模块所需要提供的服务 ，其中并不包括具体实现 ，而是加载本地层中的模块来提供给更上层使用。 责对本地层 的接口进行 托管封装。 本地的 C+代码在利用托管 的C+/装后支持 使用特性 ，便可以在 境下（例如场景编辑器等工具）直接使用。 应用层 应用层 不包含任何 内容 ，其中的模块都会动态的读取 本地的或者块封装好的 接库，并通过特定接口访问本地模块中的功能。 直接加载本地代码启动引擎，即为直接独立运行游戏本身。 通过 修改 启动参数来加载数据包。 为启动编辑器。 编辑器会加载进行过 装的本地代码，并通过分析服务接口来获取本地类型的注册信息， 这些信息会被用来动态创建编辑器 组件 。 为使用托管方式启动游戏，一般会内嵌在编辑器中 ，为所见即所得的编辑模式服务。 于组件的游戏 实体 结构 组件化编程是现在大型软件架构的常用编程思想。 在游戏开发中，最典型的组件化编程即为将程序按照功能划分为组件模块 ，然后通过接口来调用组件的方法。 除了这些传统的核心模块组件化编程应用之外，游戏开发中还将基于组件的思想应用在了逻辑组织部分 ，这就是将游戏 实体 也进行组件化设计。 游戏实体 （ 是指在游戏运行时， 在游戏世界中 独立存在的 一个逻辑 实体 ，也是游戏世界的基本构成部分 。 游戏实体可以使任何东西，既可以是玩家、 制的角色，也可以是静态的模型、物理碰撞体，甚至灯光和特效，这些都是游戏实体。 每个实体有着自己的行为，可以同其他实体进行交互 但是并不会有直接依赖关系。 在传统的面向对象编程思想中，一个实体就是一个对象，在代码中表现为一个类的实例 ，实体的行为就是类的方法 。 对象类往往从一个基类扩展而来，逐步的派生 并细化、重写方法以满足不同对象所必要的特征。 这种面向对象的方法可以简单有效的解决游戏逻辑制作的要求，但是，在高度复杂的次世代游戏开发环境中，便会遇到很多问题，例如： 派生 是一个树形结构 ，一旦当前类型不能解决问题，便需要派生出一个子类来 重写部分方法 。 随着需求复杂度的提升，这个树形结构会变得极其复杂臃肿，类型的数量大幅增加。 树形派生结构的特性使得上层的类型无法随意修改， 直接导致维护困难 。 类型的方法调用受到基类（接口）的限制 ， 会遇到需要因为 扩充调用机制 而修改接口的情况，这 将会破坏接口的封装性并导致接口变得臃肿。 行为的细节均在本地实现， 配置不灵活， 开发效率低，难以重用。 因此，为了克服面向对象开发中出现的这些弊端， 对于游戏实例进行组件化设计 是很有必要的。 + U p d a t e ( )G a m e E n t i t y+ U p d a t e ( )C h a r a c t e r+ U p d a t e ( )+ I n p u t ( )P l a y e r+ U p d a t e ( )+ A i U p d a t e ( )E n e m y+ A i U p d a t e ( )+ D o A c t i o n ( )S o i l d e r+ A i U p d a t e ( )+ D o A c t i o n ( )+ D o C o m m a n d ( )O f f i c e r+ D o C o m m a n d ( )+ M a k e O r d e r ( )G e n e r a l+ U p d a t e ( )+ U p d a t e C o m p o n e n t s ( )- C o m p o n e n t C o n t a i n e rG a m e E n t i t o c a t i o n C o m p o n e n i s p l a y C o m p o n e n t o c i g a l C o m p o n e n t n p u t C o m p o n e n t h y s i c s C o m p o n e n t . .C o m p o n e n t C o n t a i n e rB a s e C o m p o n e n tL o g i c a l C o m p o n e n tP h y s i c s C o m p o n e n tS i m p l e C h a r a c t e r C o m p o n e n 向对象的实体结构与基于组件的实体结构对比 在这种结构中，游戏实体作为组件的容器存在，自身不包含任何逻辑。 组件对于实体而言是独立抽象的， 游戏实体会在自身的 法中，调用每个组件的 作。 同时负责游戏世界与组件之间的消息接口。 每个 立存在，其之间没有强制性关联。 实体本身不带有任何组件，组件都以自由组合的形式 动态的添加 。在实体初始化的时候，将会根据组合规则将所需要的组件全部初始化并加入 到 实体的组件容器 （组件池） 中。 组件的组合规则包括这个实体含有哪些组件，以及这些组件的初始参数、标签、注册信息等 。 这些 组件信息 都 会被保存在数据文件中 ，这些数据文件由编辑器生成和修改 的 。 虽然组件都是独立存在自由组合的，但是有一些负责特定功能的组件会带有一些特殊性质。例如一些组件是必须唯一 不能重复 的， 或者是游戏实体中必 要 的单例组件你。 例如位置 组件 、渲染器 组件 等。 这些组件就必须从组件池里抽离出来，单独设立接口 ， 当游戏实体被创建时，自动加入这些组件。 另外， 组件与实体相互依赖、组件之间有互斥规则的， 比如物理 组件、消 息组件等 。 这类组件也需要从组件池里抽离出来，并建立一个独立的专用组件池，利用特定的规则来维护。 型数据库 类型数据库 (一个引擎内部的，用来存放所有注册类信息的数据库。其作用是让程序能够随时获得通过类型名来获取对应注册类的类型信息，从而达到动态创建类型对象的目的。 在本引擎架构中，类型数据作为一个服务存在，并利用 装之后，支持 性，同时提供给本地和托管端（关卡编辑器等工具）的使用。 类型都在引擎的本地代码中实现，并在数据库的初始 化时调用类型的注册操作，因此这会对本地代码有依赖，属于 本地层模块。 块需要一个专门的 对其进行封装，并暴露出必要的借口函数。这个 是对 依赖的，但由于在 会被动态载入并反射创建数据库实体，因此只需要在这一步定义一个操作接口，就不会破坏其封装性或者造成循环依赖。 类型数据库的实现细节会在后续章节详细描述。 语定义 本文用到了大量的专业术语，部分词汇在本文中的含义和常见解释有少许区别，因此在这里进行解释以避免误解。 ” 运行库。在本文中，使用 C#或者 C+/发的，支持 性的模块，均被划分为“ 码”。使用非 言开发的，例如 C+，被划分为“本地代码（ 。 类 /类型 / 这三个词都是用来描述面向对象编程中类的概念。为了避免混淆，在本文中，“类”是专指代码中的一个 现；“类型”是对于 抽象和广义的统称； 特指 的 ，每个 型都含有其象，其中包含了类型的元信息。 全称 “缩写，指为特定一个游戏服务的代码或功能模块。如果一个模块是 ，就意味着它只为某个或某几个特定的项目服务，是具体、非通用的。 块会根据项目开发，有可能是全新实现的，也有可能是对于现有的非 块的改写与扩展。例如：一个人形角色的骨骼逻辑可以是非 ，但一种特殊怪兽的骨骼逻辑由于其非通用的针对性，就是一个 能点。 在本引擎中， 务）的定义比较宽泛：全局的 ，提供特定功能支持的，都可以算作 通常意义上的服务不同，这些服务往往会对与本地代码有依赖，因此不会严格遵照接口规则工作，而是通过在务提供者，服务工厂）中注册与请求来使用。 由于两者中文直译都是资源，为了区分，将 译为“资源”，将 译为“资产”。 - 资产（ 般指模型、材质、音效等美术资源，资产都单独存在没有相互的依赖。 - 资源（ 这里特指逻辑资源，或者叫做策划资源。它可以是玩家数据、管卡信息，也可以是对资产的引用和封装。资源均为逻辑信息，不包含外部对象。资源之间会有依赖和引用关系。 章小结 在这一章节中，我们简要介绍了 本地引擎的 模块结构与设计思想， 并对模块功能做了简要的描述。在接下来的章节中，将会详细的介绍本地模块 中 最重要的类型数据库的实现。 第三章 引擎数据架构的设计 类型数据库 （ 是 核心功能之一，是实现数据驱动、编辑器与内核无关的重要组成部分。 在完全面向对象的编程环境下，类和对象已经不仅仅是对于数据属性和操作的封装体，而是 作为整个程序的构成而存在。系统中一切皆为对象，类型就是对于对象共同特性的划分与抽象。在这样的环境下，能够随时随地获得所有对象的类型信息至关重要。类型数据库的设计目的便是为了满足这一要求。本章就将对这一关键模块的设计进行详细的论述。 计目标与结构组成 类型数据库中的核心便是所有类型的信息，将这些信息组织起来便是类型数据库的工作。 其在引擎中的功能便是管理所有的本地注册类，并同时提供本地和托管的接口供所有模块访问，为本地内核与编辑器提供服务。 由于在本引擎中，类型数据库要同时支持本地代码和编辑器代码 ， 因此 类型数据库要在本地实现，根据模块划分会有多个类型数据库存放在不同的工程中，其实例以服务的形式储存于引擎的服务列表里。当引擎初始化时会扫描列表中所有的类型数据库，收集所有的注册类型信息并动态注册。 对于编辑器而言，其调用本地方法的目的一般是将本地功能内嵌到编辑器中使用。但是对于类型数据而言，其主要目的是获取核心数据流以及数据的组织结构。编辑器需要获得类型的字段信息来为动态生成编辑器服务，但并不需要在托管端创建类型的实例。 因此，类型数据库只需要将类型的字段收集作为一段描述数据，并在托管端利用这些字段生成一个容 器类作为动态生成编辑器的依据。我们将在后面章节中详细讨论与动态编辑器生生成相关内容。 + C o n s t r u c t o r ( i n p A d d r e s s : v o i d * )+ D e s t r u c t o r ( i n p A d d r e s s : v o i d * )+ G e t N a m e ( ) : s t r i n g+ S e t N a m e ( i n n a m e : s t r i n g )+ G e t S i z e ( ) : i n t+ S e t S i z e ( i n s i z e : i n t )+ S e t B a s e C l a s s ( i n b a s e C l a s s : M e t a C l a s s )+ I s K i n d O f ( i n t a r g e t : M e t a C l a s s )- n a m e : s t r i n g- s i z e : i n tM e t a C l a s s+ R e g i s t e r A l l C l a s s ( )L i b C o n f i g+ G e t I n s t a n c e ( ) : s t a t i c C l a s s D a t a B a s e *+ A d d C l a s s ( i n m e t a C l a s s : M e t a C l a s s * )+ G e t M e t a C l a s s N u m ( ) : i n t+ G e t N a m e B y I n d e x ( ) : s t r i n g+ G e t M e t a C l a s s ( i n n a m e : s t r i n g ) : M e t a C l a s s *- m e t a c l a s s M a p : M e t a C l a s s *C l a s s D a t a B a s eI n t e r f a c e+ C r e a t e O b j e c t ( )I O b j e c tB a s e O b j e c t+ R e g i s t L i b ( )+ R e g i s t A l l C l a s s e s ( )E n g i n eW r a p p e J E C T _ C P P _ C R E A T J E C T _ H H _ C R E A T 型数据库在本地代码中的结构示意 如图所示，类型数据库 系统在本地实现，主要分为三大部分：数据库、数据库模块 以服务的形式 单独存在 ， 是 本地引擎的一个组成部分。 其功能 负责保存 和管理类型的元数据信息，并提供索引查找等操作接口。 一个特制的扩展元类 模块。 每一个 型都需要有一个对应的 让它在类型数据库中正常工作。这个对应的 一个静态类型，以及对应的获取该类型的静态方法。这些共通的方法将被登陆在两个宏定义中，将这两个宏定义加入到类型的声明中便能快速的实现 该 元类。 详细方法会在后续章节中介绍。 型配置） 模块 分布在各个 程中，用来收集和注册当前模块中的类型 元 信息。 其中 法便是用来将收集的类型信息注册到类型数据库中的过程。 每一 个 程中的都需要根据模块内的类型情况重写这个方法。 由于类型数据要为整个引擎服务，因此需要在主循环启动之前完成注册。因此，需要在引擎初始化的时候，注册并扫描所有的 块，调用每个模块的 法，完成所有元类的注册工作。 : : I E n g i n e L i b C o n f i gR e g i s t e r A l l C l a s sC l a s s D a t a b a s eA d d M e t a C l a s s ( )R e g i s t e r L i bI n i tS c a n A l lL i b r a r i e sW r a p p e r : : C l a s s D a t a b a s eG e n e r a t e D a t a b a s e ( C L R )图 型数据库的初始化顺序 展 统 设计 对于本地代码而言，一个基础的 统 的作用是用 来获取类型的运行时信息 。 但是在本引擎架构的设计中，类型的信息除了要为本地代码服务以外，要需要提供必要的信息给编辑器，用来作为所见即所得场景中的实例操作，以及动态的生成类型所对应的编辑器来使用。 因此，在为本地提供信息的基础上，必须 扩展改进传统架构， 为 编辑器端的使用提供新的功能接口。 用 运行时类型识别 通用 运行时类型识别） 是