游戏引擎不仅是代码，更多的是完善的工具

从洗脑开始

---

    记得若干年前，在做公司引擎研发的时候，时常会念到的一句话：引擎不仅是代码，更多的是完善的工具。当时只是用这句话还激励自己，找准引擎开发的原则和位置。 而实际上，对这句话的理解甚少。时隔多年，这句话油然在耳，伴随我左右

 

亲身体会

---

    后来，引擎项目砍掉了，进入了页游产品的开发。 在这个产品开发的第一周，我们就面临着动画和场景编辑问题，在脑海中第一时间浮现出的，依然是这句话。于是，我们花了两个星期来做了一个简单的动画编辑器和场景编辑器。动画编辑器只有简单的图片导入，和锚点设置功能（因为怪物大小不一样）。 而场景编辑器，则只有图片导入，怪物摆放功能……。但正是这两个简陋的编辑器，使我们的项目能够让策划在没有程序的帮助下快速进行关卡相关的内容设计。 这也是第一次，让我感受到，工具能够给项目带来的意义，绝非那两句话可以概括的。

 

扩展与定制

---

    换了一家公司，是做和帝国时代差不多的开发。这家公司的理念和我是一致的，就是先要开发编辑器，然后再做游戏。 这家公司开发了sprite editor,ai editor,level editor 一切的愿望都是美好的， 而唯一让我觉得神奇的，是ai editor和level editor，消耗了大量的时间。同时，内置的许多东西，使得每一次需求变更，都要程序维护相应的editor版本才能达到对应的功能支持。 现来回想起来，如果当初使用配置文件来做一些和需求相关的东西，岂不是更好

 

上层开发语言

---

    我曾经一度认为，这辈子就靠C++吃饭了。C++这么好的语言，图形和引擎底层都是用C++写的，上层逻辑自然应该用C++写。 并且脚本语言的效率，完全是C++没法比的。

    这只是当时的想法，据我所知，成都的逸海情天，在很早的时候，就已经使用 C++底层+JAVA逻辑的开发模式了。 曾经我还笑过这种方案，觉得是一堆不会C++的奇葩货弄出来的玩意儿。当我接触到UNITY3D后，我才发现，C++ + JAVA的模式，是多么的高大上啊。 C++高效率的特性用在底层无疑是不二之选，但好东西都是一把双刃剑，C++逻辑开发中遇上的各种问题，不是一己之力能够杜绝的。

    现在在手机平台上，将脚本作为上层开发语言就更是比比皆是了。 原因就是那让人神往的IOS。为了游戏能够在游戏中进行更新，不得不采用脚本作为逻辑开发。这也使得引擎使用C++底层+脚本逻辑走上了正轨。 而实际上，早期的许多公司或者引擎也是这样做的。比如torque,unreal等

 

发布与布署

---

    在端游的时代，发布和布署可能并没有受到在大的重视，只要编译好，放到适合的位置就可以了。

    而随着页游联运的兴起，发布和布署的成本就随之提升了，因为会针对不同的运营商做一些功能定制，若为每个运营商开发一分支，维护起来成本就更高了。因此我们选择在同分支下做处理，而将运营商相关的东西做一些标志，根据不同运行商进行加载。 这都还不是终点，在一定程度上，我们可以解决问题。

    随着手游的兴起，先不说杂七杂八的国内ANDROID平台，首先面对IOS和ANDROID系统，我们的引擎就需要针对性地做一些优化处理。拿图片处理为例，在IOS上，通常使用PVRTC 4bp格式，而在ANDROID上，则使用ETC。 如果两个版本做不同分支，就更不科学了。因此，我们需要做一些脚本化的东西，使我们的资源可以在发布前，打包或者转化为目标平台可识别的资源。 因此，在这个地方，SHELL工具，又变得不可缺少了，而不仅仅是给策划和美术使用的编辑器

 

Shell与python

---

    很多时候，我们使用shell就可以搞定许多问题，但是，python作为一个强大的脚本语言，它提供的各种工具库不是shell能比拟的，比如文件搜索，MD5生成，图片处理等等。 更让shell不能比的是，python是跨平台的，这就让我们在MAC，LINUX和WINDOWS上，可以复用我们写好的工具。 而shell则只需要做一些简单的平台权限相关的操作。 如果使用python能够搞定的，我们尽量使用它。 因为手机游戏的开发，很多时候MAC与windows都有需求。 

 

Unity3D 

---

    虽然从来没有使用过这货开发项目，但自从2011引擎项目砍掉后，我就一直关注它，研究它。一开始，我对它的做法是很不接受的，觉得将一个引擎与工具绑定得如此紧密，导致我在调试程序的时候，还要启动UNITY3D的IDE，是一件很不爽的事情。 很有早期使用FLASH CS来开发FLASH游戏的感觉。 一直期待UNITY3D能够像FLASH BUILDER一样，出一个纯代码的开发环境。 但后来发现，UNITY3D之所以强大，正是因为它的编辑器，而不是他那高端的组件化设计。 一个纯组件化设计的引擎，如果没有一个好的工具配合，是很难发挥效果的，甚至会多写许多代码。而组件式这种巧妙的设计，居然能够将编辑器与项目需求解耦。 也让我刷新了引擎架构方面的认知－－－－－引擎除了工具和渲染，良好的上层结构依然重要。 

    Mono平台的引入，虽然使UNITY3D发出的包略大，同时在CPU较低的机型上很吃力以外，没有任何不好的地方。许多人吐槽这东西，但我觉得，大家应该承认时代的变迁。

    Unity3d的2D支持引入虽然过晚，但充分说明Unity3d对2D方面的势头，虽然重型的MONO平台使得即使是2D游戏，也带来一定的开销，但我觉得，在保证产品稳定，快速迭代等前提下，少兼容一定量的低端设备，也是允许的。 

 

Cocos2d-x 

---

    要说影响中国游戏开发界的开源引擎，除了早期名噪一时的OGRE，如今就只有它了。 许多人说它的架构很2，许多人说他其实就是一个山寨货， 许多人说他自己花点时间就能写出来。 这些人的对与错我们不讨论了，我们来看市场占有率。 或许这样你会说很俗。 但一个东西存在即是合理的。 一个引擎，能够满足你的项目开发需求，同时为你省下大把时间，你有多少理由不使用它？ 而非要自己去DIY一个蹩脚的引擎， 你觉得你写出来的东西，坑就一定比别人少吗？

    3.x版本的cocos2d-x已经与往日不同了，我很高兴能够看到cocos2d-x在代码结构方面的革新。（不仅仅是去掉了CC前缀）

    cocostudio虽然还是一个半残品，但不得不说，触控官方出力开发一个商业级的编辑器，这在开源项目中还是很少见的。大家应该给它时间成长。 而在成长期间，还是用最适合的方案来构建自己的项目吧。试想，在cocostudio出现之前，也有无数的成功案例。

 

Irrlicht

---

    这是我曾经最喜欢的引擎，它伴随着我渡过了大学生活，我在寝室里，时常阅读它的代码和注释，虽然没有特别的收获（因为完全看不明白），却使我保持了对引擎的热情。

    Nicko为这个引擎开发了一个irrEdit，但随时时间的推移，这个东西已经不更新了，因为nicko发现，irrlicht没啥意思，irrEdit和irrKlang收益又不多。于是转而投入一superCube的开发。supercube卖得还挺贵的，支持flash,html5,android app,ios app,windows exe等发布。 功能和特性都挺NB，但是界面和实际的功能，真的好像小朋友做的。 有兴趣的朋友可以试试

 

OGRE

---

    这是我接触的第二个引擎，它的庞大使我望而怯步。有幸在研发过程中，研究过天龙八部的代码，以及它的材质系统。 整个东西都挺OK的，而美中不足的是它就像一个仓库，什么都往里塞，而很多东西，也是停留在学术层次，如果想投入项目，还得自己改造一番。cocos2dx可以说是很直接的了（有人说是因为2D很简单，但我觉得，是因为cocos2dx定位很明确，或者说，是因为cocos2d的定位很明确）。 OGRE也没有附带编辑器。 而早期的项目，都不是基于UNITY3D那种解耦方式，许多都是为特定类型的游戏定制编辑器。我研究过大唐，神咒，天机，以及刚刚说的天龙八部的代码和编辑器，都是为MMORPG定制的，且直接关联游戏内容。 这或许就是当时的引擎发展层次吧。

 

Glitch

---

    这是一个由Irrlicht发展而来的引擎，核心部分虽然有较多扩展，性能和特性也是Irrlicht不可同日而语的，但核心部分依然保持了IRRLICHT的风格。 唯一不同的是，上层逻辑开发的模式，与UNITY3D如出一辙，这也是让我想到了，任何引擎，都可以慢慢的向UNITY3D的逻辑开发方式靠齐，包括cocos2dx,更甚至是ogre。glitch由于是内部使用引擎，工具也是自家定制的，但工具的设计思路，也和unity3d颇为相似。这一点可以说是让我十分欣赏。

 

让爱随风飘 

---

……时代在发展，行业在进步，我们必须跟上大众的步伐，才能在这无硝烟的战争中，赢得属于自己的那一仗……