最近闲得有些手抽筋，平时就是看看shaderX，看看各种设计性讨论，然后看看能弄到的完整的游戏源代码。
于是，有幸十分粗略的看了一下quake3的源代码，明白了此前一直困惑的关于游戏引擎的其中一种表现形式。
早在入门之处，曾看到文章这样描述游戏引擎：像汽车引擎一样，是一个exe文件。不同的外壳搭建在引擎上，就构成了不同的汽车；那么，不同的资源dll导入到exe文件中，也就形成了不同的游戏。
new guy是很难轻易明白这样一种表达的，因为没有办法构建直观的认识。随着学习的深入，对引擎的理解渐渐趋于一种中间件的形式：图形引擎，音频引擎，网络引擎，物理引擎，配合着各种编辑器，游戏就把具体的逻辑搭建在这些中间件之上。exe是游戏，dll是支持各种功能的中间件。这就是我一直一来对引擎的直观认识。

通过阅读quake的源码，理解了最初看过的描述。大体是这样的，quake.exe就类似于一个CGameSystem对象，这个对象提供了一个几乎适用于所有游戏类型的大框架，而具体的游戏逻辑的不同部分，则被封装到不同的CGameModule对象中。每个CGameModule对象都有其对应的刷新频率，由CGameSystem对象根据频率调用其主循环，完成各部分的逻辑。而各个module间的通讯，则由game-system提供的变量池完成。
具体而言，game-system对象必须为每个module提供如下功能：
1，变量池，每个module都可以向此注册变量，设置/获取该变量的值，来完成和其他module之间的通讯。
2，控制台/命令池，每个module都可以向此注册它所感兴趣的命令，当向game-system键入命令后，它会把命令派发到相关的module。
3，中间件（游戏无关）。
这些东西被组织到game-system中，然后编译成quake.exe，即成为所谓的游戏引擎，就像一个发动机，可以跑，但是什么也没有，仅仅是空转。

接着，是游戏的逻辑代码。quake系列，将module分为3部分，server-game，client-game，ui。这3部分由quake.exe驱动执行不同的任务，并且彼此间通过变量池通讯。
简单起见，忽略server-game。考虑client-game，就像纯粹的单机游戏中的规则的逻辑代码，持有的render-stuff，只能请求quake.exe将其载入和渲染。ui部分，则又独立于client-game，只关心ui的交互，并设置变量池中对应的值，而client-game则会对其感兴趣的值予以响应。
module和中间件直接的耦合是相当弱的。可以更换不同的module，制作不同的quake，也可以更换新的quake.exe，来运用新的中间件。


PS：曾一度以为，cn/cpp博客挂掉了，因为一直是页面无法访问。今天才发现，要国际连线才能登陆，faint~