首页 > 未分类 > 引擎层次化设计
2019
11-29

引擎层次化设计

作为一个引擎程序员,在我以往经历的项目中经常会遇到这样的问题,这个功能是不是该市现在引擎中,似乎放在逻辑中
(或者客户端)也可以。每当举棋不定的时候我都会想引擎到底该做什么!?

我这里我说说我的想法。

很久以前并没有什么引擎,所有东西都是写在一起的,当开发新的游戏时基本上都是从头开始,这样就有大量重复的工作。后来
一些聪明的程序员将那些可以在各个游戏中使用的代码独立出来,并作成一个库,这样便有了引擎。

其实这已经很清楚了,引擎应该是可以在各个项目中进行重用的部分,或者说可以公用的模块。虽然现代的引擎更加复杂,模块
更加丰富,但他依然没有改变它原有的职能。如果说某个所谓的引擎在拿到其他项目时需要进行大量的改写,那么可以说这个东
西不是引擎,至少是很糟糕。

接下来简单说一下我的ZeusEngine引擎的一些分层设计思想

    引擎逻辑
       ||
       \/
引擎功能模块集合
       ||
       \/
      底层

从上到下越底层重用性越高。
引擎逻辑作为引擎与游戏直接相关的一层,就这一层而言既可以实现在游戏逻辑部分(客户端)也可以单独增加这么一层作为游戏
逻辑与引擎之间的隔离。这一层可以在同类型游戏之间进行重用。

引擎功能模块集合这一层就是通常所说的引擎,什么声音系统呀,物理系统呀,场景管理呀等等都在这里实现。他和底层一起构成了引擎,并且一定要保证其不针对任何游戏,这样才能最大限度重用。

至于底层则是一些内存管理,线程控制,文件系统,网络通信,等等这些操作系统相关的东西,他作为对上层的支撑。同时这一层即
便不做游戏引擎,随便拿出来也可以直接用到其他地方,甚至是非游戏的项目。

除此之外在资源层面也存在游戏相关的问题,比如某游戏对于导出的模型有特出要求,这时就要去考虑到底是导出插件直接支持还是
按照通常到处之后增加一个针对此类游戏的二次加工配置文件。这个问题并不是简单的工作量问题,而是更深远的重用问题。
我个人更倾向于底层资源就是通常的模型,动画,纹理等等,可以在此基础上增加一些具体应用的配置文件,来对这些资源进行配
组合来实现具体游戏的需求,这样在资源这个层面也可以进行重用。

作为引擎开发人员,在项目过程中,通常并不能一开始就明确知道到底该对逻辑层面支持到什么程度,面对这个问题,我个人的做
就是凡是还定不下来的,那通常就是游戏逻辑相关,而不是引擎相关,在此时此刻他不应该是现在引擎中(随着日后需求的明确并且
具有通用性,则可以添加到引擎中)。作为类比只需要想想ansi c中的文件操作就行,作为ansi c的开发人员并不知道用户将操作文
件的格式,所以他们只提供了fopen,fwrite,fread,fprintf,fscanf这样的函数,这就已经足够了。

 

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/Leo1981816/archive/2010/04/25/5527192.aspx

最后编辑:
作者:搬运工
这个作者貌似有点懒,什么都没有留下。