[原创]从思考游戏引擎的本质 谈 如何构建一个有着完善

liuzewei

这些天想接触下游戏编程，唉```晚了晚了```太晚了```高手如云```如果早点接触游戏编程那该多好啊

。

这些天想直接从做一个游戏“引擎”入手，从而达到学习与入门的目的。基于DX9，WINDOWS平台。

这些天下了N本DX电子书，逛了N个论坛。。。太难了````太晚了````

开发一个基础的东西，最重要的是架构，架构即逻辑，逻辑即抽象。（个人观点，不代表大众立场：）


一边看书入门，一边动手写自己的“引擎”代码，一边思考如何让引擎在逻辑上更独立而又更开放。参

考了几乎能找到的所有开源引擎代码，太复杂了，一个个解压，急速浏览一遍又一个个删掉咯```


无语```如何让引擎的架构在逻辑上更合理？？这些天脑袋没有停止过思考```却仍是徒然。


突变——今天休息，静下心来轻松的想了想——

引擎是什么？
为什么如此难以抽象，为什么无法跟其他基础类库一样有着简单清晰的模块与边界？
这是为什么？
为什么？
。。。


豁然——


任何在运行着而没有退出的程序都是一个死循环，否则，它自然就退出了。因为任何程序代码都是顺序

的，它运行起来，如果它不循环，那么等待它的必然就是程序执行结束，然后退出。本质上，任何程序

他都没有死这个概念，只有正在运行和已经退出两种状态。

引擎本质上是一个死循环，它是这样一个死循环。它接管了我们程序的阻塞式消息死循环（阻塞即不独

占CPU资源），特别关键的，它将其替换为非阻塞式的死循环，它从不等待，从不释放CPU时间片，从而

独占所有CPU资源。（当然，必要时我们可以主动Sleep()以减小CPU占用量）

程序分两大类：一类是启动，运行，完了就结束（乃通常意义上的程序，比如控制台小程序）；
一类是启动，运行，进入死循环。。。
然后，死循环从其“恶劣程度”从低到高分三种：
1、阻塞式消息死循环（普通WINDOWS应用程序，此类程序直接把脖子放在操作系统手里，死活由系统决

定，几乎不占CPU时间）
2、非阻塞式消息死循环（即游戏引擎类程序，它们从我们APP的WINMAIN手里就直接接手原消息循环，并

把脖子从操作系统手里抢了出来，然后做死的循环啊循环，但因同时处理了所有消息，所以整个界面不

死。CPU占用量几乎全部！）
3、非消息死循环（虽然它没“死”，但它限入了无止境的疯狂。界面死，同时CPU占用量也几乎全部）


所以。。。继续思考我们的游戏引擎是什么


引擎跟类库有本质的区别，类库提供给开发者一些方法模块，属于我们工程的从属角色。
        而引擎提供的是游戏的基石框架，当然，我们的工程可以比引擎更大更复杂。
        但是，在逻辑上，引擎永远是我们的主导，我们启动我们的APP，然后进如WINMAIN，然后
        该注册一个窗口并启用一个阻塞式消息死循环了。 慢着！ 我们的游戏引擎出场了，它从APP手       

里接过这个任务，并以非阻塞式消息死循环完成任务。 然后仍给我们一个MainLoop()，说：“以        后

我就是你的操作系统，当然，你可以干别的事，比如开发一些基础库基础代码，但，这些都是死的，如

果你要活，如果你需要交互类的工作，那你就只能到 MainLoop() 里来，在这里面，你可以查询        整

个系统的信息，我可以给你一组API，而且你可以向我请求你需要的资源。哦，对了，有什么事，我会在

MainLoop()里通知你，你记得听啊。”

——这，就是游戏引擎——它是我们的整个“操作系统”，而不仅是我们的基础类库。



接下来，我们该思考什么？
难道假设一个逻辑层次上有着完美抽象的引擎是不可能的吗？

哦，我觉得不。做到自己能做到的最好就是完美。以后我们在思考游戏引擎架构的时候，不要再用开发
基础类库的思维去思考它，并以此作为 抽象度是否足够好 的标准。我们知道，它们在本质上是不同的

。我们必须认识到，游戏引擎就等于是我们的虚拟操作系统，它直接面对着真实操作系统，并将我们完

全隔离。它给我们的显示器是我们的APP窗口，它给我们的虚拟外壳是 MainLoop(), 当然，他还给我们提供各类API，比如显示一个网格模型，比如渲染一个场景。


好了，知道了这些。我们就明白了我们要做的是什么东西，然后作出我们自己的决策，或许并没那么容易，但至少，我们有了可以借鉴并学习的有着此类经验的前人——MICROSOFT！是的，它们是操作系统开发者。


在Windows平台上，你可以开发出比Windows贵1000倍的软件，但——你永远无法颠覆你们之间的“主从”关系。



最后一句话——游戏引擎也是这样，HAVE FUN



还有最后一句，我是菜鸟，上面的都是想到那说到那，把自己思考的过程即时的纪录下来，可能连基本概念上就有错误。各位高手与前辈们，见笑了。：）

xikema

......最近总是受人启发中......而且都不是老鸟！
LZ的想法很有同感，我也觉得这才叫引擎。如果引擎能做的跟MFC一样那就太棒了~~~

whb9633

飘过……飘过……FREEBSD的开发者说：每隔几个月，他们就能全拿到一个或几个WINDOWS开发者们的笑话，因为他们范着UNIX几十年前相同的错误。哈哈

xikema

楼上... Microsoft的实力是不容否定的，认真看他们的代码，会发现很多智慧的结晶。即使范着愚昧的错误，但却占领了几乎所有的家用机市场。看别人的长处才能进步，冷嘲或热讽都是不可取的。

whb9633

楼上的说的有理…不过我笑笑不见得就是讽刺MS，我只是转贴了某FREEBSD程序员的话而已，不懂得吸取UNIX的经验，这说明MS也是楼上所批判的对象。最近MS对OGL的无耻行径也足够所有图形程序员好好BS他们一翻了。

航天奇侠

看不出有什么特别之处.

cproom

基本就是你想的这样，引擎接管一切，其根部就是一个消息循环，和游戏逻辑的死循环。以这个为出发点来写引擎是很好的，但引擎的大部分复杂度体现在各个子系统以及它们组合、交互的方式。写引擎和任何子系统前先从整体全局去了解它会给以后的工作一个稳固的基础，但这个稳固往往是一段时间内的，随着你对要做的事情有更多的了解，系统往往需要多次重构才能达到比较完美的状态。

liuzewei

迭代啊迭代`````写了好些天了，现在还只写了一点点`````呵呵````引擎涉及的东西实在不好做出完美恰当的抽象```

哪位高手指点下```

lingjingqiu

莫名。。。

卡特铁角

别的不太懂，不发表言论。但从一个游戏策划的角度来讲——哪有完美的抽象啊？

所有的抽象都是相对的，相对于那些“具象”的东西更抽象而已。抽象的过程其实是一个归纳——形成概念的过程。这样的过程总是要求忽略具体事物的一些细节信息，而在一定设计目的下被忽略的这些细节信息在其他的设计目的下可能恰恰又是关键的，需要抽象出来进行观注的信息。

在介绍面向对象编程思想的文章中，往往都会告诫读者——不要试图建立一个大而全的“完美抽象”或“终极抽象”，而仅抓住那些在设计目的下最为关键关键的特征就可以了。