上半年的最后一天，写一写自己最近想到的问题……

上半年的最后一天，今天。2007年，6月30日。

不作为已经很长时间了，这段时间研究了些别的引擎的代码，写了写文档，重新组织了一下思路。

这几个月，技术上或没有太大的变化，Interlocking Tiles是N年前的，BSP分割是去年的，编辑器，或许只有CLI编辑器才是这几个月工作上有那么点新意的东西。C++上，敢于使用Boost做点小东西了，没有太大的进步。其它的，看了些Occlusion的文章……世界还是那个世界，似乎一切都还静止不动。

目前，感觉到最大的变化，是对OGRE等引擎的抽象场景结构越来越有点怀疑，在这一点上，思路完全已经混乱，找不到方向。

OGRE几乎是从一开始接触游戏开发，就陪伴我的东西，可以说，是充满理想主义的史前时代的最后遗迹。从个人感情上说，不想抛弃它的设计理念，但是，事实是，很多经典的游戏引擎，拥有几乎静止不变的场景结构。场景的组成是一开始就决定好的，究竟是BSP+Portal+四叉，还是别的什么，一开始就确定了的。很少有决定给出一个抽象的场景结构，用户根据需要自己去扩展的。因为这对用户是一个不负责任的行为。

这种设计有些好处：维护的成本比较低。因为技术从一开始就可以确定，所以，针对结构进行的优化相对而言就很好办，很多优化可以干脆以硬编码的形态存在。另一方面，对用户而言，由于结构简单，会降低学习的成本。

而且就现在而言，游戏的类型可以千变万化，场景的组成模态无非就那么几种：MMORPG肯定会首选Portal＋四叉树室外地形，休闲类网游甚至可能都没有复杂的场景管理：赛车什么的一般都是室内BSP，更有甚者，可能干脆都不需要场景管理。以上是关于所谓的网游——也就是网上交互式虚拟社区——的。看看正宗的游戏，RTS没有Portal这几乎是必然的。一般的小RPG基本上不会使用Portal，因为八叉树已经完全可以将空间描述好，而Loading画面可以解决剩下的问题了。

对于这些模态，过于抽象的场景图，只不过是徒劳地增加了开发的成本——由于考虑到扩展需要，会有大量与逻辑无关，但却与结构相关的代码如雨后春笋——哦，不，如小强般——出现。对这些代码的维护和设计——其实他们没有关注任何游戏逻辑——将占用大量的时间和空间。如果您觉得这只不过是危言耸听，那可以自己去试一试，如果你能做得到在OGRE的四叉树、OGRE的BSP和OGRE还未出现的八叉树中加入互相之间的Linker以组成一个一般的MMORPG需要的引擎的话，那算我什么都没说——注意这个抽象的Linker需要考虑到各种可能的升级的情况，更要考虑到增加了其他场景类型的情况。

我这样当然不是在鼓吹早已经进了坟墓的“一个引擎一个游戏”的开发模式，而是，您不觉得，当这样的Linker写完之后，其成本远远高于一个仅实现BSP＋四叉树＋八叉树的场景体系么？而且它比这样的体系究竟好在哪里呢？如果Linker被你封装到一个新的场景系统插件中去了，那么，这除了比新写一个场景系统插件在代码上“优美”点外，还有什么好处？如果不这样，Linker让用户自己去管，无形之中又增加了用户的压力。

场景组成的模态，场景分割的算法，等他们变化的时候，与其绞尽脑汁让它符合过去的体系，不如干脆完成一个新的体系。

最近一段时间头疼于这些问题，所以，也没有最终的结论，甚至或者明天早上拜会周公归来，就会推翻今天的想法也说不定。但小生幼稚地认为：引擎的开发应该少些理想主义，多一点务实。很多时候了，我们总在想怎样去做个轰轰烈烈的系统出来，我在想，引擎的开发，如果真的即将成为一个行业的话，我们应该想的则应该是一些小到不能再小的问题——“如何去省下用户哪怕一分钟的开发时间”。

或许，引擎，什么是引擎？务实的，内敛的，敏捷的，高效的——然！这就是引擎！

可不可以做，不是问题，也不应该是宣传用语，可以做的事情太多……而我们的广告语应该是：

你不用再迷茫，因我们已经做了！！