learn, think, share, communication
网络游戏
在3D游戏中采用场景管理的意义
0我们常说3D引擎应当包含若干功能：材质，模型，动画等等，这些功能我们很好理解，模型是我们需要渲染的几何体，材质表现的是几何体如何对光照如何做出回应，动画（特别的，骨骼动画）往往是3D世界中可运动模型的基础。除了这些与渲染直接关联的概念之外，往往还有个与渲染看似无关的概念：场景管理。
游戏渲染当中常用的场景管理往往被称为Scene Graph：它的实现通常采用树状结构，构成它的基本单位是节点，一个节点可以有若干个子节点，并且（除了根节点之外）往往有且只有一个父节点。
在实际游戏当中，对于需要渲染的几何体，比如静态的Mesh或者有Skeleton的Mesh，其本身不包含世界变换信息，而是由其所处的节点决定其位置与朝向。很久以前读Ogre的源码看到它就是这么做的，然而问题是，为什么必须要这么做？我一直心存疑惑，如果不采用Scene Graph的方案，我们给每一个需要渲染的模型赋予世界变换信息，那么这个模型不是一样可以渲染么？为什么非要把变换信息与模型本身分离开？分开有什么好处？而不这样做又有什么缺点呢？
简述游戏逻辑及编辑器的抽象
0最近一段时间以来，本人参与了公司下一代游戏编辑器的开发，从而有机会针对编辑器设计做一些简单的思考——如何设计更好的抽象，从而达到在客户端，服务端，以及游戏编辑器中复用尽可能多的代码？如何能够尽可能的缩短游戏设计师（策划）及美术设计师（3D/2D场景美术）的工作流程？市面上优秀的引擎往往都附带有所见即所得编辑器，这样的编辑器应当如何设计？网络游戏编辑器又有哪些可以从中借鉴和学习之处？
将尚不是很成熟的思考结果总结成本文。本人水平所限，许多错漏之处难免考虑不周全，如果有同学对本文所述的问题有任何想法，亦或是有其他文章与此相关，欢迎一起交流。
客户端逻辑的复用
把游戏客户端进行拆解，可以将其看成一个拥有输入、输出及内部逻辑循环的系统。玩家通过鼠标键盘发送消息给客户端，服务器通过网络接口发送消息给客户端，然后客户端于每一帧把当前对应的表现绘制到屏幕上。
客户端输入包括：Windows消息（键盘，鼠标，windows的其他消息，快捷键，定时器，摇杆等），网络消息（通过服务器或者其他玩家发送来的消息）；输出包括：屏幕显示，网络消息（发送给服务器的响应或请求）。
事实上一个游戏编辑器也可以简单的看成类似于上述的系统，其输入包括：Windows消息（键盘，鼠标，windows的其他消息，菜单快捷键等，定时器等）；输出则包括了屏幕显示，正常情况下编辑器不需要接受或发出任何网络消息（这里指与服务器进行逻辑上的通信，而非指通过版本控制系统进行数据的同步管理）。
实际上编辑器与客户端程序实际上都拥有相似的输入接口(Windows消息)，只是同样的消息引发了不同的逻辑——在这里我们可以对输入接口做以抽象，并使用不同的实现来分别实现其逻辑，从而达到在编辑器中拥有热切换编辑状态和游戏状态逻辑的能力。（许多知名的游戏引擎都拥有类似上述的可在编辑器中切换编辑/游戏状态的功能，比如Crysis的SandBox编辑器，再如RunicGames的TorchLight编辑器等）。 (more…)