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,我们来了!
Advertisements
此条目发表在DreamEngine 3D 图形引擎开发分类目录。将固定链接加入收藏夹。

7 Responses to Dream3D 引擎开发状态(二)暨引擎的 2007 回顾与 2008 展望

  1. ixnehc说道:

    呵呵,加油,共同进步!

  2. wu说道:

    粒子编辑器我觉得还是直接放在Max(或者别的美术创作工具)里比较好,美术可以建模的时候直接创建粒子,直接可以看到效果。程序也可以直接利用Max的一些ui的功能,省去很多麻烦。序列化我还是觉得远程调用里比较有用,因为如果做的比较通用的话,效率上不去,如果在序列化的过程中做特化,效率是上去了,写代码又比较麻烦,不如直接写。你的材质系统现在是美术直接可视化创作,还是你创建一个库,美术选择合适的材质,再调参数?或者是其他的方式?又做引擎又做项目?你太牛了。

  3. 说道:

    1.我给max插件的定位是只是做导出数据功能,不做编辑功能,所与粒子编辑器不会放在 max 中编辑,另外,由于 max 支持很多第三方的粒子编辑,如果在 max 作粒子编辑功能的话,势必要受到这些第三方(包括 max 本身的粒子编辑功能,尽管它很弱)的限制,不利于扩展,而且开发调试非常不方便。目前我们自己已经完成粒子编辑器的开发,编辑器所有的功能都可以根据自己的需要来进行更改和扩展,不会受制于人。而且根据经验,美术在作粒子的时候很少会启动 max,所以单独作为一个编辑器没有使用上的问题。
    2.这里的序列化概念与以往不太一样,指的是数据的存储和读取,这样的话就一定是特化的,因为每个引擎对象的数据结构都不一样,麻烦事避免不了的。不过正因为如此,效率上不会存在问题。
    3.目前材质系统由 shader 开发人员写好后提交给 max,再由美术在 max 进行选择,这是比较古老的方式,在今年我会争取开发一个可视化的材质编辑器,思路几个月前就有了,只是没有时间来开发,希望今年能够完成。
    4.我的主要工作内容还是引擎,不过由于公司的重点还是游戏,所以今年我估计主要还是关注游戏项目多一点。毕竟引擎是需要真正的商业项目来考验和完善的。

  4. shi说道:

    老大,wxWidget。。。你越来越像是在做unreal拉,呵呵。我也同意你说的关于max的说法,实时渲染和package软件支持的效果差异很大很容易造成Designer和programmer之间的误会,动态的东西还是在engine tool里面编辑预览后存binary最实际。我还是支持collada,呵呵,自己不用烦去写exporter阿。。。呵呵,对了,fifa内测了,有空帮忙宣传下 http://www.eafifaonline2.com

  5. wu说道:

    可能是我没说清楚啊,我说的是自己开发Max的插件,所以不存在有什么限制的问题。而且美术看到的就是在游戏中的效果,也不存在Designer和programmer之间的误会。有的效果是需要模型和粒子配合的,如果用单独的粒子编辑器,应该要先导出模型,再导到粒子编辑器里吧,再加上粒子。这样比较麻烦吧。

  6. wu说道:

    粒子系统有时候还会用到骨骼,在粒子编辑器里创建一个骨骼然后控制它运动?这样的话一是增加程序的工作量,二是增加美术的学习难度,因为肯定操作方式肯定不是和Max是一模一样的。

  7. 小西说道:

    5.1快乐~~~

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  更改 )

Google+ photo

You are commenting using your Google+ account. Log Out /  更改 )

Twitter picture

You are commenting using your Twitter account. Log Out /  更改 )

Facebook photo

You are commenting using your Facebook account. Log Out /  更改 )

w

Connecting to %s