Dream3D 引擎开发状态（二）暨引擎的 2007 回顾与 2008 展望

昨晚 msn 上有人问我引擎开发的如何，是否有截图。说实话，我觉得截图只能说明引擎的的表象功能，比如渲染、工具的界面等，而这些还需要看渲染性能的好坏、工具的稳定与否、功能是否强大等等，只有通过使用引擎真正的开发一款游戏，才能了解一个引擎的真正能力。如果一个引擎能用几张截图就能说明其全部功能的话，我相信这是一个功能不完善的引擎。这一年的引擎开发让我也对引擎有了更进一步的了解，对引擎开发的认识也与以往有些不同。引擎到底是什么？如果放在5、6年前，这个问题还比较容易解释，但是近几年的 3D 引擎的发展，已经逐渐外延了引擎的概念。比如说 Unreal3 引擎，我个人认为它已经超越了传统的引擎的范畴，事实上它应该是 3D 次世代游戏的集成开发环境（IDE），从这一点来说，可以预见未来的 3D 引擎的发展将是越来越强大的开发工具和开发环境，使次时代游戏开发变得更容易、更快捷，缩短开发时间，减少开发成本。图形硬件技术的突飞猛进和 CPU\GPU 技术的不断发展，使得游戏本身变得越来越复杂，交互能力越来越强大，这直接导致了玩家希望能玩到越来越真实和更高交互能力的游戏的需求，从游戏开发商的角度来说，不断的超越竞争对手获得更大的市场回报使得更多更新的开发技术加入到游戏中，从而刺激玩家的的需求和硬件的发展，这是一个良性循环。言归正传，先说 2007 的回顾。起初我把 Dream 引擎定位在图形引擎，渲染方面达到本世代级别（farcry\unreal2）,部分达到次世代级别（doom3\unreal3）,因为是 3D 图形引擎不是游戏引擎，一开始这样定位也比较正确。不过目前 Dream 引擎已经不再是纯粹的 3D 引擎，（我做了层次结构，核心层还是图形，只是从整体功能来讲已经包含了游戏引擎的部分基础功能），实际上引擎的渲染功能在去年就开发完成了，到了现在也没有大改过。但是只有渲染是远远不够的，为了能达到灵活的图形表现，我用了前后近3个月的时间开发了材质系统（横跨 2006 ~ 2007），目的是使引擎具有自适应的渲染材质的能力，这样引擎本身不再限制渲染，而是通过编写不同的材质来设定渲染能力，这给后来的游戏开发带来了很大的方便，我也试过几种次世代渲染技术，有了这个系统，都比较容易的嵌入到引擎中。渲染是需要资源的，这又产生了对资源的管理，而我当初在开发资源管理时为了尽快地测试图形渲染功能，没有用太多的时间设计和开发，只是做了简单的加载、引用计数等功能，这部分一直是我的心病，我知道早晚要补上，2008 年上半年的工作目标之一就是开发全新的资源管理系统，稍后再细说。有了渲染、材质和简单的资源管理，静态的图形表现基本没有问题了，接下来就是动态表现，所以开发动画系统就很自然的成为引擎的 2007 年的又一个开发重点，在完成了渲染部分之后，引擎从 2 月份开始开发骨骼动画系统，后来逐渐加入了顶点动画、纹理动画、位移动画、粒子系统，而这些功能的开发，都对牵扯到资源管理系统，几乎每一次功能的开发都要对资源管理进行扩展和重构，这是当初轻视资源管理所带来的恶果，也反映出我们的引擎开发经验不足。相反，材质系统和渲染系统由于之前下足了功夫，所以没有太大变化。动画系统这部分另一个比较耗费时间的，当属 max 导出插件的开发，和上面一样，没有统一的设计和缺乏相关的开发经验也导致了 max 导出插件的多次重构，从功能上来说我自己也不满意，这部分也将作为 2008 年引擎重构一个重点。在这里详细说一下粒子系统，粒子系统进行过两次开发，第一次参考了 farcry 引擎的粒子编辑器，第二次参考了 unreal3 引擎的粒子编辑器，第二次的开发完全抛弃了原有的版本，因为看到了 unreal3 粒子编辑器的强大。从结构上新的粒子系统也与原有不同，尽管有些性能上的损失，但是带来的却是功能上的灵活和强大。实际上这之前引擎是有编辑器的，但是无论对于功能还是界面操作我都不满意，在第二次开发粒子编辑器的时候，我采用了 wxWidget 来开发界面，不过这也是无奈之举，MFC 或者 ATIL\WTIL 也可以做，这些我也用过，但是它们的结构复杂性太容易把代码搞乱，尤其对新人来说更是如此，MFC 是宏封装消息机制，ATL\WTL 是模板+宏，而 wxWidget 是完全面向对象的架构，虽然在实际开发上还有些麻烦，但是比较容易理解，门槛不高，但是其在架构上保证了一定的简易性，不象 MFC 使用那么麻烦和复杂，用好也不容易，如果让新人来写 MFC 程序恐怕难以维护。毕竟引擎不是开发完就可以了的，是需要不断维护的，否则人来人往，最后很容易就死掉。事实证明，一个毫无 GUI 经验的新手，用 wxWidget 很容易上手并且编写出很好的界面，至此，引擎的编辑器算是比较正规了。关于引擎的编辑器，也是 2008 年开发重点，目前我给引擎定位在这样几个编辑器：材质编辑器、粒子编辑器、地形编辑器、动画编辑器，其他的编辑器根据游戏需要再决定。我根据中国的上古十大神器来给引擎的编辑器命名，目前粒子编辑器被称为“神农鼎”，接下来还会有“轩辕剑、盘古斧、炼妖壶”等。2008 年另一个打算要做的扩展就是实现树形骨骼动画系统的功能，并且支持部分骨骼的 IK，最好能实现骨骼物理属性。引擎的性能优化也是 2008 年的开发内容，原计划在 2007 年下半年作性能优化，但目前游戏对引擎的功能要求比性能更加重要，所以可以放在游戏开发的后期再作性能优化。这部分主要包括数学库的计算性能，使用 CPU 扩展指令进行数学运算，多核技术的优化也在考虑之列，但如果要充分发挥多核的能力，需要对程序结构做一定的调整以适应多核，所以这部分还需要进行探索。前面提到了资源管理，实际上这部分内容还是不少的，从渲染层次上来说，资源管理是上层功能，资源管理需要更底层的文件系统来服务，所以这又引出文件系统。我打算实现抽象文件系统，屏蔽掉文件管理的细节差异，实现跨操作系统和包文件系统，12 月份就在作文件系统的设计和开发，期望在春节之前能全部开发完成。有了这一层次，在资源管理和文件系统之间就是引擎对象的序列化（或称之为持久化）层次，当然我不做那种面向对象的序列化，而且我也不认为序列化仅仅是指数据从内存到硬盘，从硬盘到内存也可以认为是序列化，只不过是方向不同，甚至可以是从网络到内存\硬盘，所以这个层次就是序列化框架，有个序列化接口，细节完全透明，目前已经实现了两种格式的序列化器：xml 和 Bin。对于需要序列化的引擎对象来说，直接使用这个接口来进行序列化。这个层次的存储的功能是通过抽象文件系统来完成的，每个对象要负责自己的数据序列。要达到这种程度，引擎还需要进行较大改动，因为这涉及到了引擎的很多个核心对象，同时还包括导出插件。有了这两个层次，资源管理的底层支持就完备了。动态的资源管理一直是我想要实现的功能，关于这部分功能以前也是没有什么思路，后来看了 云风 blog 上 的几篇关于资源管理的文章，再加上自己的思考和实际的需求，有了初步的设计，不过这需要在实际开发中去验证，同时后台资源加载也是我想要实现的功能，这对大型 mmo 来说也是一个必要的功能。
2008 年有许多工作要做，在这些工作中最重要的是目前我们在开发中的游戏，我们的目标是今年内能有一款 JCC 自己研发的游戏上市，，也是公司对上海研发方面的要求。2008 年公司对我的要求是负责管理整个游戏研发的技术，这就使我不仅要负责引擎的开发，还要负责游戏的开发，对我个人来讲是一个更大的挑战，我期望我能完成上面所说的引擎开发的内容，同时更希望能看到游戏的成功上市。道路曲折，而我喜欢富有挑战的生活，2008，我们来了！