很久以前开始，我就很膜拜“高大全”的设计思想的。可能是因为在我入门之初，OGRE对我的影响，使我曾经很固执地认为，引擎就应当如OGRE这样，优美到近乎艺术品般的设计，充满古典气息。

但在一段痛苦而又充满刺激的自我挑战过程中，我不断地褪下自己身上这层深深附着的皮。它曾试图阻止，并让我很疼痛，但，最终，还是意识到，在实践的过程中，没有最优的设计——NO SILVER BULLETS。我必须学会懂得放弃，必须学会放弃任何可能的束缚，以获得自我的救赎和新生。

直到今年年初为止，我还对那种能够“功能内敛，而向外抵御伤害”的体系抱有希望，但在现实面前，却最终发现，艺术品，当它放在高雅的地方，那它就不可亵渎；但如果是在沼泽之中，那么，它就于垃圾无二了。不幸的是，需求就是沼泽，它复杂多变，无法琢磨。很可能你这一脚还在为踩在石头上而兴高采烈，而下一脚已经迈向了死亡的通道……

如果我们把一切都放得简单一点，事实上，代码最终归结，总是在于每一个独立支撑的功能点，而重复的地方，也往往容易发生在具体的功能点上。封装，当然，可以按照教科书那样，被理解为面向一个体系庞大复杂，能够描述一个完整世界的自上而下的过程，但其实，又何尝不可理解为一个面向每个孤立的功能点和支撑点，构成一个个互相独立而自我完善的支撑点和接口的自下而上的过程呢？或者，事实上，更多的情况是：在上方自上而下的设计，和在下方自下而上的设计，在中间层发生激烈的交火和冲突，互相试图吞没对方，而又互相竭力保持着自己的影响。两个势均力敌的对手，从项目的开始就在这样的冲突，直到项目的结尾也毫不松懈。

归结到引擎。过去我的思路，正如我所说的那样，复杂的类结构，复杂的场景体系。但现在，我开始相信，一个完善的中间层，势必需要一个个功能独立，结构完善，接口明晰的底层模块的建立——这并不简单的在说那些VB/IB/Camera之类的东西。地形、空间、场景结构，我曾将之勾画到场景的核心之中，但带来的结果，除了使中间层的场景变得僵化之外，还迫使很多不必要的东西，被迫由这些本来应该简单而短小的模块去承受不该它们承受，它们也无法承受的重量。

举个例子说，实际上，地形就是一组特殊的mesh。而空间剖分和场景结构，一般也就是对一个现有mesh和mesh组的分析、重建、标定过程。这样，一般的，在相应的构件过程完毕之后，这些东西所剩下的应该仅仅是一组特色的工具方法（对地形而言，lod的确定，以及对空间而言，空间的定位和遍历）和大量的信息函数。物体？场景中的物体？交给中间层吧。

将一个完整的中间层作为你能发布的东西，但是，更底层的，引擎的核心，保留一些自由、僵直、自封闭、透明的孤立的功能点，或许是更好的设计？

我不敢确定，但，既然开始了，那就应该继续下去……

发表于 @ 2007年08月20日 22:50:00|评论(loading...)|编辑