Jul.25, 2006
关于场景管理有了一些头绪，总算走出了被“选用哪种形式的场景管理”所困扰的烦恼。认识到场景的组织最关键的是应该以“逻辑层次+几何结构”来组织。加速渲染，对象剔除，碰撞检测都只是场景所应具有的功能，应该在不同的层次上区别的处理，而不能单纯的指望用一个“最优”的场景管理数据结构或算法来通吃。
当前的处理方式是用树来维持所有对象（层次间的关系以逻辑为主，几何结构为辅），每个节点上存储变换矩阵(LocalToWorld & WorldToLocal)渲染场景时从根节点起遍历场景树，每得到当前节点时都通过它的变换矩阵得到局部坐标系。
最重要的是这个场景树对关卡设计师而言一定要是可随时进行观察调整以及一定程度上的性能评估的，由于场景对象间的逻辑在程序引擎中很难管理(这些往往是由游戏设计师和关卡设计师共同拟定的)，所以场景树的结构管理权大部分应当由程序员转交至具体关卡的设计者。这样一是便于关卡设计师根据场景的复杂度和性能评估随时调整，二是便于后期针对特定的场景进行特定的优化，
最重要的一点是任意的节点与其所有子节点都成了逻辑相关的，逻辑相关的好处在于“对某个节点进行变换能够立刻应用于它的所有子节点”在大部分情况下都是合适的，因为需要一起变换的对象往往都是逻辑相关的。这样就免去了关卡设计师常常需要把某些对象并为一组一起移动的麻烦。打个生动点儿的比方，在即时战略中，所有的兵种由于不是逻辑相关的，所以我们需要用Ctrl+1,Ctrl+2等将其分队，将对所有对象的独立操作简化为组操作。但是如果所有的军队根据上下级所属关系成为逻辑相关的层次结构，我们只需选中一个连长就可以操作该连的所有单位，而选中司令则可以处理整个军队，这样对关卡的设计者而言显然效率有极大的提高。
关于游戏内建的编辑器，也有了一些想法，不一定所有的信息都需要在hud上显示出来，这样既麻烦也不便于显示和修改。改进的办法是在游戏外另开一个Editor窗口专用于显示信息和修改信息，比如选中对象时显示和修改被选中对象的信息，显示和修改场景树的节点间层次关系，等等。这样最大的受益者是拥有双显示器的关卡设计师。他们可以在一个屏幕上全屏运行游戏，而在另一个屏幕上修改场景树的属性。