最近一段时间以来，本人参与了公司下一代游戏编辑器的开发，从而有机会针对编辑器设计做一些简单的思考——如何设计更好的抽象，从而达到在客户端，服务端，以及游戏编辑器中复用尽可能多的代码？如何能够尽可能的缩短游戏设计师（策划）及美术设计师（3D/2D场景美术）的工作流程？市面上优秀的引擎往往都附带有所见即所得编辑器，这样的编辑器应当如何设计？网络游戏编辑器又有哪些可以从中借鉴和学习之处？

将尚不是很成熟的思考结果总结成本文。本人水平所限，许多错漏之处难免考虑不周全，如果有同学对本文所述的问题有任何想法，亦或是有其他文章与此相关，欢迎一起交流。

客户端逻辑的复用

把游戏客户端进行拆解，可以将其看成一个拥有输入、输出及内部逻辑循环的系统。玩家通过鼠标键盘发送消息给客户端，服务器通过网络接口发送消息给客户端，然后客户端于每一帧把当前对应的表现绘制到屏幕上。

客户端输入包括：Windows消息（键盘，鼠标，windows的其他消息，快捷键，定时器，摇杆等），网络消息（通过服务器或者其他玩家发送来的消息）；输出包括：屏幕显示，网络消息（发送给服务器的响应或请求）。

事实上一个游戏编辑器也可以简单的看成类似于上述的系统，其输入包括：Windows消息（键盘，鼠标，windows的其他消息，菜单快捷键等，定时器等）；输出则包括了屏幕显示，正常情况下编辑器不需要接受或发出任何网络消息（这里指与服务器进行逻辑上的通信，而非指通过版本控制系统进行数据的同步管理）。

实际上编辑器与客户端程序实际上都拥有相似的输入接口(Windows消息)，只是同样的消息引发了不同的逻辑——在这里我们可以对输入接口做以抽象，并使用不同的实现来分别实现其逻辑，从而达到在编辑器中拥有热切换编辑状态和游戏状态逻辑的能力。（许多知名的游戏引擎都拥有类似上述的可在编辑器中切换编辑/游戏状态的功能，比如Crysis的SandBox编辑器，再如RunicGames的TorchLight编辑器等）。 (more…)