作为一个引擎程序员，在我以往经历的项目中经常会遇到这样的问题，这个功能是不是该市现在引擎中，似乎放在逻辑中
（或者客户端）也可以。每当举棋不定的时候我都会想引擎到底该做什么！？
我这里我说说我的想法。
很久以前并没有什么引擎，所有东西都是写在一起的，当开发新的游戏时基本上都是从头开始，这样就有大量重复的工作。后来
一些聪明的程序员将那些可以在各个游戏中使用的代码独立出来，并作成一个库，这样便有了引擎。
其实这已经很清楚了，引擎应该是可以在各个项目中进行重用的部分，或者说可以公用的模块。虽然现代的引擎更加复杂，模块
更加丰富，但他依然没有改变它原有的职能。如果说某个所谓的引擎在拿到其他项目时需要进行大量的改写，那么可以说这个东
西不是引擎，至少是很糟糕。
接下来简单说一下我的ZeusEngine引擎的一些分层设计思想
引擎逻辑
||
\/
引擎功能模块集合
||
\/
底层
从上到下越底层重用性越高。
引擎逻辑作为引擎与游戏直接相关的一层，就这一层而言既可以实现在游戏逻辑部分（客户端）也可以单独增加这么一层作为游戏
逻辑与引擎之间的隔离。这一层可以在同类型游戏之间进行重用。
引擎功能模块集合这一层就是通常所说的引擎，什么声音系统呀，物理系统呀，场景管理呀等等都在这里实现。他和底层一起构成了引擎，并且一定要保证其不针对任何游戏，这样才能最大限度重用。
至于底层则是一些内存管理，线程控制，文件系统，网络通信，等等这些操作系统相关的东西，他作为对上层的支撑。同时这一层即
便不做游戏引擎，随便拿出来也可以直接用到其他地方，甚至是非游戏的项目。
除此之外在资源层面也存在游戏相关的问题，比如某游戏对于导出的模型有特出要求，这时就要去考虑到底是导出插件直接支持还是
按照通常到处之后增加一个针对此类游戏的二次加工配置文件。这个问题并不是简单的工作量问题，而是更深远的重用问题。
我个人更倾向于底层资源就是通常的模型，动画，纹理等等，可以在此基础上增加一些具体应用的配置文件，来对这些资源进行配
组合来实现具体游戏的需求，这样在资源这个层面也可以进行重用。
作为引擎开发人员，在项目过程中，通常并不能一开始就明确知道到底该对逻辑层面支持到什么程度，面对这个问题，我个人的做
就是凡是还定不下来的，那通常就是游戏逻辑相关，而不是引擎相关，在此时此刻他不应该是现在引擎中（随着日后需求的明确并且
具有通用性，则可以添加到引擎中）。作为类比只需要想想ansi c中的文件操作就行，作为ansi c的开发人员并不知道用户将操作文
件的格式，所以他们只提供了fopen,fwrite,fread,fprintf,fscanf这样的函数，这就已经足够了。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Leo1981816/archive/2010/04/25/5527192.aspx