3D engine ，中间层的缺失
我们的游戏引擎已经开发了一年半了，其中 3d 引擎部分也做了近一年。
一个好的引擎，渲染部分总是容易做的。因为面对的问题比较单一，资料也很丰富。需要克服的问题很有针对性，即使短期解决不了的问题，放在那里也关系不大。我们团队有两个同事拥有完整 3d engine 开发经验，所以在渲染引擎接口设计部分也不会走太大弯路。（不过事实上，因为基础构件的重写，渲染引擎也是几经修改的）
最近 3d engine 部分又面临一次大的重构。起因是这样的：
整个 client 引擎的最初构架中，我们并没有把嵌入式脚本语言放在一个首要的地位。我在项目开始半年后，才正式开始嵌入式语言的工作。而之前一直是在做更底层的构架。3d engine 的起步也在这个时期。
可以说，脚本语言和 3d 部分在整个游戏引擎中处于相同的层次在做。
最近的一些想法的改变，以及游戏逻辑开发启动，让我深刻感受到了其中的不足。以前做的游戏项目，一则是因为 2d 的比较容易控制，二则我参与的部分以图象引擎以及 UI 方面的基础设施为主。在做完整游戏引擎上，思考不足。或者说，以前完成的几个游戏，都没有一个特别完备的游戏引擎。
最大的问题是，游戏逻辑和渲染引擎作为两个不同的层次，之间还有没有别的东西？目前的想法是，应该有一个粘合层。但准确定义这个中间层的功能是个难题。
我们项目早期的做法是，让脚本可以直接控制 3d engine 的渲染。这样可以有足够的灵活性。按这个方法，我们在一周内堆砌了一个 3d demo :) 但是到现在，这个思路不想延续下去了。毕竟游戏不是 demo ，而且我们期望的游戏逻辑又是非常的复杂。
我想一个合理的中间层，应该有动态语言做粘合剂，而用 C 做渲染底层。中间层不应涉及游戏逻辑层的东西，比如角色的 HP 等。它解决的是对象于对象之间的空间关系，逻辑归属，消息转发，资源管理等等。良好的这个中间层应该尽量的隐藏渲染层的信息，可以很方便的把 3d 渲染层换成 2d 的，甚至换成文本交互的界面。
按这个思路，前段时间我重新写了一个简陋的中间层框架，并做了一个简单的 2d 渲染层于之吻合。然后尝试让 3d 渲染的部分可以配合上这个框架。一切都是摸索阶段吧，目前看起来，2d 的那个部分工作的满好，3d 的部分尚未竣工。和以前做的许多东西不同，这次嵌入的动态语言深入到了引擎的更底部，放弃用 C++ 做模块的粘合剂而换用纯 C + 动态语言的组合，可以算是我近一年来最大的编程思想变革吧。
Comments
Posted by: Mandi Zu | (6) March 24, 2007 11:10 PM
Posted by: albert | (5) January 25, 2007 11:28 AM
Posted by: dreamsun | (4) January 17, 2007 04:44 PM
Posted by: analyst | (3) January 16, 2007 05:20 PM
Posted by: ttt | (2) January 16, 2007 05:11 PM
Posted by: shinco | (1) January 16, 2007 01:57 PM