针对读者:
这一系列针对的读者是供有编程经验但想学习游戏编程的程序员.本系列介绍用库做什么以及如何做,内容涵盖了主要的任务以及广泛的主题. 这里,不会教你C/C++,因此,就至少需要有一些用C++编写OO程序的经验,否则你将是在浪费时间. 如果你只是想导入一个可运动的模型并在屏幕中看到其运动,那么此教程也是不适合你的,因为那样你可以只用Demo程序,然后让其为你做这个就行了.
在这个系列里介绍的东西将超越ExampleApplication 框架:你需要去除配制对话框,导入你自己的设置,控制资源的加载,手动地进行主循环的运行,等等.如果你的目标与这个一致,那么你就可以继续往下读了.
实际上,对于一个游戏的子系统而言,只有一个或两个可用的开源选项. 渲染: Ogre或Irrlicht, 声音: OpenAL或FMOD; 物理模拟:ODE或Newton等. 所选的库是什么并不重要,重要的是记住你所选择的库最好与我们选择的库的标准一致: 成熟,特性丰富,开发的活跃程序等.
这个系列的工程是基于OGRE渲染,OIS输入,CEGUI用2D GUI管理,RakNet用于联网,OpenAL用于声音,Gangsta用于物理抽象层.
这个文章描述了在你设计过程你需要考虑的东西. 假如你知道你需要做什么,那么现在要做的就是了解如何去做.对于这个系列而言,则变成”如何用Ogre完成你想做的事”.
忘记Demo程序
就像在介绍中所说一样,demo程序对于介绍功能或演示特性是很好的,但对于实际的应用程序来说不是太好. 示例框架做了一些对于你的主循环的假定，在这里，需要指出你最好对于你的应用程序实现一个FrameListener.原因是这些是Ogre的特性，而不仅仅是示例程序的特性，这些Events,假如任何监听者已经注册，不论你使用的是何种框架，将会触发这些事件。
而对于不做多个监听者的目的是你不知道其调用的顺序是如何。这主要是源于Root记录这些FrameListeners的时候用的是STL的Set,因此无法记录其顺序。如果你的应用程序依赖于一个确定的执行顺序，那么你应该只用一个frame listener,或者不使用它，而在你的主循环的renderOneFrame()之前实现你的游戏逻辑。
游戏配置框应由你游戏中来配置，而在启动的时候，由游戏配置中的选项提供给游戏来启动。用纯文本的配置文件可能不好,更好的是让你的程序用一个”config.ini”文件，并从中读取选项，把这些值传给Ogre并启动.
资源是游戏执行过程中依赖的内容.模型文件,配置文件,脚本等.
每个游戏都有一个主循环.游戏在进入主循环之前对所有的子系统进行初始化,而在你退出之后进行清理的工作.
对于输入的处理最好的方法是把所有的事件都抽象成”Actions”.这样的话,你就可以通过构造一个”ActionMap”来使得不同的输入设备可以很好的协作.这样的话,你的主程序需要处理的事件变成”对象A使用武器C”而不是＂按键F被按下＂，或＂鼠标二松开＂等信息。你需要将输入设备以及网络事件转化成＂Action”,然后再处理他们。