关于游戏引擎结构上的思考

这两年接触了一些比较成熟的商业引擎, 慢慢得思想有所转变

以前总以为, 哪个引擎代码写得好看就牛, 太偏激了

很多商业引擎的代码那叫一个乱~

后来觉得引擎工具很重要, 没有经过成功项目的引擎不是好引擎

现在呢? 当然工具还是很重要, 但另一个很重要的因素是: 制作效率

能不能快速开发, 能不能快速搭建原型, 快速推出, 灵活定制才是一个引擎最有竞争力的地方

这扯得有点虚了, 来点实际的

在学习并抄袭够了各种技术细节后, 开始从另一个角度看待一下引擎开发

之前有说过, 引擎可以看作是一个资源管理器, 它的作用是对资源的创建, 编辑, 整合

那这三个大的方面可以从微观的角度看: 那就是它们都是一些基本元素的组合

拿一个模型来说, 可以拆成网格, 材质, 动画等, 网格可以拆成拓扑, 顶点, 顶点可以拆成位置, 法线, 纹理坐标等, 位置可以拆成float

那么从上层到底层, 其实就像原子构成分子, 分子再构成各种物质......

转成引擎术语, 其实就是基本数据类型构成属性, 属性构成组件, 组件组成实体, 实体组成场景, 再加上各种行为与事件, 成为一个游戏

这里面有三个关键的技术点, 那就是反射, 序列化, 组件模式

这三个技术点成就一个成熟引擎所具备的特征: 资源驱动

反射与序列化方面, C++天生不足, 很多引擎里压根没有系统地去考虑这个

在做功能开发时, 常常会发愁数据怎么保存, 怎么编辑

其实很简单, 做了序列化, 所有资源的格式可以进行统一, 不用为模型写一种模式, 地图写一种格式, 逻辑表格写一种格式了

你需要的只是一个Load和和一个Save而已

而序列化也是依赖反射的, 通过遍历属性去序列化, 就可以摆脱烦人的save/load/version编码了

然后是编辑

编辑是强烈依赖反射的, 做好反射机制, 你的编辑器就成功了80%

不管是场景编辑, 还是材质编辑, 甚至于行为, AI, 逻辑, 其实都可以看成属性编辑

在反射机制的基础上, 做一个PropertyEditor, 那你的编辑器就基本完成了

你再也不用开发一个功能就到面板上加一个控件, 改一下保存/加载的版本号了

到这, 引擎已经有一个很好的底层了, 再就是考虑怎么灵活地去进行游戏开发

组件模式就是为了资源驱动, 一个实体需要什么功能就加一个什么模块

模块的属性通过PropertyEditor去编辑

对于行为, 可以使用脚本去实现相应的组件

从这个角度来着, 脚本也就成了一种可以复用的组件资源

那么下一步就是弄个强大的脚本系统, 来配合反射/序列化/组件模式进行开发

好比UE的UnrealScript, Unity3D的UnityScript(Mono), 都是这种结构

对于组件模式, 一个不可缺少的东西就是Prefab, 或者叫Template

因为你所创建的实体都是各种组件的集合, 每次都去一个个的组装起来很麻烦

所以需要一个模板, 这个模板可以是一个物体, 也可以是多个

这些模板才是传统引擎中的resource的概念, 由它们去实例化出各种实体单位

好了, 有了这些东西后, 剩下的就是美术做内容, 程序写脚本, 策划调数值了