Dream Engine 2 的一些事（一）

从今年初 DE2 开始开发到现在已二月有余，进度还算顺利，这次除了次世代的 3D 引擎之外，我们还开始了对象引擎和逻辑引擎的开发，同时对引擎的资源管理的设计也做了进一步的改进。实际上所谓的对象引擎就是基于 RTTI 的可扩展的对象系统，游戏可以根据引擎的 RTTI 规则来扩展自己的逻辑对象，无需重新编译引擎即可在引擎编辑器和游戏中使用游戏对象，同时这套机制也作为引擎核心对象的管理和反射机制。逻辑引擎实际上是一个可扩展的游戏逻辑框架结构，它基于对象引擎，在其内部存在一个逻辑驱动核心，这个核心主要的工作就是不停的更新当前的逻辑序列–更新每个逻辑序列的状态，每个逻辑序列由一系列的逻辑片段构成，逻辑片断通过某种机制关联在一起，形成完整的游戏逻辑流程，在每个逻辑片段内部都可以实现特定的逻辑，通过结合对象引擎的 RTTI 机制可以对游戏对象进行控制，这样就可以实现大部分的游戏对象间的交互。与此同时，通过提供可视化的逻辑编辑工具代替传统的手工编写游戏脚本逻辑，可以提高游戏开发效率，缩短迭代周期。实际上这种机制并不是什么革命性的技术，从本质上来说和传统的 脚本 + CPP = 游戏逻辑 的方式没有什么区别，只不过是提供了一个可扩展的框架结构，将所有用 DE2 开发的游戏的逻辑纳入其中来驱动。但是，目前还有些问题没有完全解决，比如：对于 Online Game 的 Server 和 Client 逻辑如何编辑和部署? 众所周知，网络游戏的逻辑分散在 S/C 两端，而且还不可避免的存在时序和验证问题，如果是单机游戏这种方式可以工作得很好，但是网络游戏的情况就比较复杂。而且这里还有两个细节的问题，一个是策划如何通过逻辑编辑器决定哪部分逻辑是运行在客户端，哪部分逻辑是服务器端？第二就是性能问题，RTTI 也好，逻辑引擎也好，天下没有免费的午餐，要做到可扩展，就要付出性能的代价，高度的抽象和游戏对象的运行时动态查找以及编辑势必带来性能开销，所以，在性能和扩展性上找到平衡点也是摆在我面前的一个难题。

3D引擎方面，DE2 重新设计的渲染架构在开发的过程中感觉到比 DE1 要好许多，因为它完全不需要关心渲染核心以外的数据结构，同时 SG 也实现了在只知道很少量的渲染信息的情i况下向渲染核心发送渲染请求的功能，这样 SG 和 Render Pipeline 就被隔离开来，实际上在系统中存在一个中间层，我们称之为 Render Primitive Manager, 它负责在 SG 和 Render Pipeline 之间沟通，也就是说这个 manager 同时知道两者，但它不需要太多细节就可完成渲染数据的构建工作。为了更好的适应今后的多核心平台，多线程渲染架构也是我一开始就考虑的功能。由于在开发之前做了充足的准备，以及在去年实现的多线程资源管理的基础之上，再加上新的 Render Pipeline 和 SG 的完全分离，我大概用了 2 天左右的时间就完成了开发及测试工作。为了做到和逻辑线程完全并行，渲染线程完全是 lock-free 模式，对渲染线程数据结构的操作完全是异步方式，同时提供方便的回调机制满足特定的渲染以及渲染结果查询需求。

材质系统是变化最大的系统之一，第一代引擎的材质系统完全被废弃，为了更好的扩展性，我们重新设计了 Shader 系统，这样做的前提是整个引擎的着色机制完全基于可编程管线，只保留 D3D 10 还保留的固定管线设置，在固定管线的数据结构实现上参考了 D3D10 的架构，这样将来在迁移到 D3D10 或者后续版本会更加容易。同时我们还设计了一套 Shader 编译机制，实现了在不同着色环境下的动态 Shader 生成，而且做到了和顶点生成结构无关，在这方面我们参考了 UE3 的材质系统和材质模板。目前已经开发完成了可视化的材质编辑器，基本上做到了 UE3 能实现的材质效果我们都可以实现。