最近这几天在搞一个GameFramework，其实就是在引擎基础上增加一个游戏框架，对游戏进行抽象，对引擎使用的一些封装。在进行具体设计的时候很多细节问题是值得思考的。总结如下
总的来说我所设计的游戏框架从功能上来讲就是两件事，一个是游戏的状态管理（什么菜单状态，游戏状态等等），在一个就是AI管理，又有一个有效的机制来负责对所有AI进行更新和维护还有交互。
对于一个所谓的通用框架需要考虑的是在各种不同游戏类型中的最小抽象是什么？那些东西是个各种类型游戏都需要有的，这个抽象如果过小很可能失去其意义，如果过大则很难做到普适，当然有些情况下想做一个通用的东西想法本身就是错误的。
根据我之前的单机游戏经验（当然都是动作类射击类为主的游戏），我把游戏抽象为以下几个部分
1. waypoint, 路点
这个路点是一个广义的概念，可以是出生点，也可以是一个寻路点，或者是其他什么有意义的位置。路点之间可以连通。他的属性在游戏编辑器中进行配置。在具体编码的时候会有一个waypoint的基类，他只有位置和连通关系。其他具体的路点什么出生点，寻路点等等，都从这个waypoint基类中派生出来，并具体处理。
2. trigger，触发器
和路点一样，这个触发器也是一个广义的概念，它可以是时间触发器（定时器），可以是区域触发器（进入区域，出区域），也可以是更复杂的条件触发器。他的属性同样是在游戏编辑器中进行设定，实现方法也和waypoint的差不多，先写一个积累，从其派生出具体的触发器。与此同时触发器上还需要配置一个脚本ID，用于在被触发时运行某个脚本使用。
3. script，脚本
这个比较简单，就是一个map<id, char*>, 他保存着lua脚本，并通过id进行索引（当然也可以换用其他索引方式），关于lua就不多说了。
4. map/scene
这个就是引擎提供的场景地图，这个也没啥好说的。
5. actor, 角色
游戏中所有有逻辑的东西都是actor，不论他是一个可以战斗的npc还是一个定时播放某动画的物体。游戏框架要负责维护和更新这些actor的列表。
在游戏开发过程中真正大量的工作量也都在每个actor的AI编写上。需要注意的是当actor和actor只见需要互动的时候不论是直接写道程序里还是通过脚本，都要有一套方面直观的方式能够进行actor的访问。以我的经验这些actor都是存在一个map上，使用名字的hashvalue进行索引，并提供方法来封装这个访问过程，同时在这个封装的函数内进行些日至，这样便于调试。
我想一个简单的抽象大致如此，在开发过程中一般waypoint和trigger的类型都是有数的，而且数量不多，真正需要编写大量编码的是actor和scrpit，而出现问题最多的也是scrpit如何能够方面快捷的访问actor和game数据等，这个需要结合不同的游戏进一步设计，而且要事先设计好。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Leo1981816/archive/2010/05/25/5621887.aspx