记得几年前在公司做引擎研发的时候，经常会看到一句话：引擎不仅仅是代码，更是完善的工具。那时，我只是用这句话来激励自己，找出引擎开发的原则和立场。然而，实际上，人们对这句话了解甚少。时隔多年，这句话犹在耳边，陪伴在我身边。亲身体验后，砍掉引擎项目，进入页游产品开发。在产品开发的第一周，我们面临着动画和场景剪辑的问题，这句话还是第一时间浮现在脑海中。于是，我们花了两周时间做了一个简单的动画编辑器和场景编辑器。动画编辑器只有简单的图片导入和锚点设置功能（因为怪物大小不一）。场景编辑器只有图片导入和怪物放置的功能。。。但是正是这两个简单的编辑器让我们的项目能够让策划者在不借助程序的情况下快速设计出关卡相关的内容。这也是我第一次觉得，工具能给项目带来的意义，不能用那两句话来概括。扩展和定制换了一家公司，做类似帝国时代的开发。这家公司的理念和我一样，先开发编辑器，再做游戏。这家公司开发了spriteeditor、aieditor、leveleditor。一切的愿望都是美好的，但唯一让我觉得惊艳的就是ai编辑器和关卡编辑器，耗费了大量的时间。同时，很多内置的东西使得每次需求变化时都需要维护相应的编辑器版本来实现相应的功能支持。现在回过头来看，用配置文件来做需求相关的事情不是更好吗？曾经以为这辈子要靠C++吃饭了。C++这么好的语言，图形和引擎底层都是用C++写的，上层逻辑自然要用C++写。而且脚本语言的效率是C++完全无法比拟的。这在当时只是一个想法。据我了解，成都的益海擎天很早就采用了C++底层+JAVA逻辑的开发模式。曾经嘲笑这种scheme，觉得是一堆不懂C++的奇葩东西。当我接触到UNITY3D的时候，我才意识到C+++JAVA模型的厉害。C++的高效特性无疑是底层的最佳选择，但好东西也是一把双刃剑。C++逻辑开发中遇到的各种问题，不是靠自己的努力就能解决的。现在在手机平台上，使用脚本作为上层开发语言更是普遍。原因是迷人的IOS。为了在游戏中更新游戏，必须使用脚本作为逻辑开发。这也让引擎使用C++底层+脚本逻辑走上了正轨。事实上，很多早期的公司或引擎也是这样做的。比如torque、unreal等的释放和部署。在端游时代，释放和部署可能不会被大佬看重，只要编译好放在合适的位置即可。随着多模态网页游戏的兴起，发布和部署的成本会增加，因为一些功能会针对不同的运营商进行定制。如果为每个运营商开发一个分支，维护成本会更高。.所以我们选择在同一个branch下做处理，针对carrier相关的东西做一些标志，根据不同的carrier加载。这不是结束，在一定程度上，我们可以解决问题。随着手游的兴起，先不说国产ANDROID平台的杂七杂八。首先，在面对IOS和ANDROID系统的时候，我们的引擎需要有针对性的进行优化。以图像处理为例。在IOS上，通常使用PVRTC4bp格式，而在ANDROID上，则使用ETC。如果两个版本有不同的分支，那就更不科学了。因此，我们需要做一些脚本编写，让我们的资源在发布前能够被打包或者转化为目标平台能够识别的资源。因此，在这个地方，SHELL工具又变得不可或缺，而不仅仅是用于策划和美工的编辑器Shell和python。很多时候，我们可以使用shell来解决很多问题，但是python作为一门强大的Scripting语言，它提供了多种shell无法比拟的工具库，比如文件搜索、MD5生成、图像处理等等。更让shell无法比拟的是python是跨平台的，这让我们可以在MAC、LINUX和WINDOWS上复用我们写好的工具。shell只需要做一些与平台权限相关的简单操作。如果用python可以做到，我们就尝试用它。因为手游的开发，往往MAC和Windows都需要。虽然Unity3D从来没有用过这个产品开发项目，但是自从2011年引擎项目被砍掉之后，我就一直在关注和研究它。一开始，我不接受它的做法。感觉把一个引擎和工具绑的这么紧，调试程序的时候不得不启动UNITY3DIDE，是一件很不爽的事情。感觉就像早期用FLASHCS开发FLASH游戏一样。一直期待UNITY3D能出FLASHBUILDER那样的纯代码开发环境。但后来发现，UNITY3D之所以强大，正是因为它的编辑器，而不是它的高端组件化设计。一个纯组件化的设计引擎，没有好的工具，是很难起到效果的，甚至会写很多代码。组件类型的巧妙设计，实际上可以将编辑器与项目需求解耦。也让我刷新了对引擎架构的认识------除了引擎的工具和渲染，一个好的上层建筑还是很重要的。Mono平台的引入，虽然UNITY3D送的包稍大，对于CPU较低的机型难度很大，但也没有劣势。很多人对此抱怨，但我想大家应该承认时代变了。Unity3d对2D的支持虽然推出的晚了点，但是充分展示了Unity3d对2D的冲劲。虽然沉重的MONO平台即使对于2D游戏也带来了一定的开销，但我认为还是有必要保证产品的稳定性和快速迭代。在这种情况下，它也被允许与一定数量的低端设备兼容。Cocos2d-x是说影响中国游戏开发行业的开源引擎，除了早期大名鼎鼎的OGRE，现在就只有一个了。很多人说它的结构很2，很多人说其实是山寨，还有很多人说他花点时间就能写出来。这些人的是非我们先不讨论，先看市场占有率。也许你会说它低俗。但事物的存在是合理的。一个引擎就可以满足你的项目开发需求，为你节省大量的时间。你有多少不使用它的理由？与其自己动手DIY一个蹩脚的引擎，还不如自己写出来的东西比别人坑的少？3.x版本的cocos2d-x与以往不同。很高兴看到cocos2d-x在代码结构上的创新。（不只是去掉CC前缀）虽然cocostudio还是个半残品，但是不得不说touch官方对商业级编辑器的开发功不可没，这在开源项目中还是少见的。我们应该给它时间成长。并在成长期，用最适合自己的方案搭建自己的项目。试想一下，在cocostudio出现之前，成功案例数不胜数。Irrlicht这是我一直以来最喜欢的引擎，它陪伴我度过了大学生活，我经常在宿舍里看它的代码和评论，虽然没有什么特别的收获（因为我根本看不懂），但它让我对引擎保持着热情.Nicko为这个引擎开发了一个irrEdit，但是随着时间的推移，这个东西一直没有更新，因为Nicko发现irrlicht是没有意义的，irrEdit和irrKlang用处不大。于是转而开发了一个superCube。supercube比较贵，支持flash、html5、androidapp、iosapp、windowsexe等版本。功能和特性都比较NB，但是界面和实际功能真的像小孩子做的一样。有兴趣的朋友可以试试OGRE。这是我接触的第二个引擎。它的巨大尺寸让我望而生畏。幸运的是，在研发过程中，我研究了天龙八部的代码和材料系统。整个东西还算可以，美中不足的是它就像一个仓库，什么都塞进去，很多东西还停留在学术层面。如果你想投资项目，你必须自己修改它。cocos2dx可以说是很直接了（有人说是因为2D很简单，但我觉得是因为cocos2dx定位明确，或者说cocos2d定位明确）。OGRE也没有附带编辑器。早期的项目并不是基于UNITY3D的解耦方式，很多都是针对特定类型的游戏定制编辑器。大唐、神漫、天机，还有刚才说的天龙八部的代码和编辑我都研究过。它们都是为MMORPG定制的，与游戏内容直接相关。这可能就是当时发动机的发展水平。Glitch是从Irrlicht开发的引擎。虽然核心部分有更多的扩展，性能和特性也与Irrlicht不尽相同，但核心部分仍然保持着Irrlicht的风格。唯一不同的是上层逻辑开发模型和UNITY3D完全一样，这也让我想起任何引擎都可以逐渐向UNITY3D的逻辑开发方式看齐，包括cocos2dx，甚至ogre。由于glitch是一个内部引擎，所以该工具也是自己定制的，不过该工具的设计思路与unity3d颇为相似。这可以说是让我非常感激了。时代在发展，行业在进步。我们必须跟上大众的步伐，才能在这场没有硝烟的战争中打赢属于自己的战斗……
