青瓷引擎研发

我为什么要做青瓷引擎

　　写了十几年的游戏，从来没有想过自己去实现一个游戏引擎之类的。一来实现个游戏引擎并不是件容易的事；二来我不是个技术控的码农，不想自己去创造需求；三来算有点自知之明：水平距离那些技术大神太遥远了，用他们造的轮子就好了。

　　在2014年，青瓷开始关注HTML5游戏领域。随着HTML5标准的落地，整个生态发展非常的快。这期间也冒出来了诸多HTML5游戏引擎，比如国外的Phaser、PIXI、IMPACT、three.js等，国内的Egret、Cocos2d-js等。同时，《愚公移山》作为青瓷的试水项目，也获得了成功。年底，我们确定进入这个领域，面向玩家推出游戏编辑器。

　　但是首先我们得先找一款合适的游戏开发引擎；在我眼里，一款好的HTML5游戏引擎至少应该具备：

• 完整工具链。Unity3D的一站式工具链整合得非常好，其他大部分引擎的工具是非常分散的（有的甚至以“几十个工具”来标榜），而更多的就只是纯API了。一站式工具链肯定最高效最易用，这理念应该是有共识的，只是为什么很多引擎公司无法进行合理的整合，有点让我难以理解（我猜想的原因是：一开始没有做好回头太难了）
• 无浏览器插件。Flash之所以会死，容易发烫是一个原因，但可能更重要的是其安全性。浏览器插件的操作权限太高了，几乎可以为所欲为。说心里话，如果能把插件集成进各主流浏览器，我还是会用的（毕竟可以定制，性能摆在那），安全性对我这样的开发者没关心那么多。可惜的是，chrome和safari不见得愿意让你干这事。
• 原生。有一些引擎是使用其他语言（比如C\C++\ActionScript）来转换，并且宣称100%转换，并不怎么可信（在他们已知领域内可能真是100%）。一旦让你遇到一个转换不对的（我遇到好多次了），大部分普通程序员不具备这样的调试与排查能力。
• 界面与动画。我觉得一个2D游戏引擎最重要无非就2个功能：界面和动画。好的UI工具可以让开发效率提升一个数量级，但很多游戏引擎很容易忽略这一块。有些UI编辑器编辑后与实际运行效果有偏差，有些需要写非常多的代码来自适应各种屏幕分辨率（甚至有些引擎官网的Demo直接留黑边）。我期望的游戏界面实现流程是：美术人员拼好界面后，程序员直接拿来写业务代码就可以了。至于动画，很多引擎实现得挺好，这得益于Flash这款专业动画编辑器
• 专业。很多引擎实现得大而全，既可以用来做游戏，也可以用来做企业应用，什么都可以干。游戏引擎如果以此方向来做，很难做透做精，因此我更喜欢纯粹的“游戏引擎”。更有意思的是，有些游戏引擎的主刀，竟然从来没做过游戏，个人怀疑是不是真的靠谱（可能做游戏的大神都忙着写游戏赚钱去了吧？）！
• 开源。
• 性能。简单的2D渲染引擎，性能大部分是半斤八两（上插件的排除在外）。当然也有少部分引擎性能差得出奇，这些列到不合格程序员行列。

　　用了大半年来试用各种引擎，实在没有找到合适我用的。被Unity3D惯坏后，我们也不想随便拿个来将就，怎么破？“顺便自己做个游戏引擎吧”，请原谅我用“顺便”两个字，并非狂妄，因为游戏引擎并非我们的最终目的，产出游戏和游戏编辑器才是。这阶段性产品如果能让更多开发者更快做出游戏，同时也能丰富我们的游戏编辑器，就能实现共赢（从来就没有活雷锋啊，共赢！）。总结下：

• 市面没有的H5游戏引擎，开发效率无法满足我们的要求，这是最大主因
• 什么样的游戏引擎最适合开发者，我们更清楚：因为我们就是使用者
• 我们自己开发游戏实现快速迭代，引擎开发周期在可接受范围内
• 还有：游戏引擎，也可以实现盈利的

我理想中的引擎

　　有没有谁都喜欢的游戏引擎？答案应该是没有，包括其他任何软件。我们做出来的引擎应该有他独特的气质与特定用户群体，根据我们自己团队以及部分圈内兄弟公司的调研，圈定引擎的方向（或者说特点）：

• 漂亮的文档。 这里的漂亮有多层意思，并不是说外表包装得多漂亮。在重要程度，我选择把文档摆在第一位。
  • 完整。所有常用的API，所有功能的用户手册，所有功能点的demo范例，当然还应该包含各类型的完整游戏示例
  • 可读。良好的文档结构（由浅入深的）、化繁为简的描述、多给范例、多录视频
  • 持续更新。文档的错误描述、与引擎不一致、遗漏等，都应该升级为BUG来处理（一个错误的文档描述，可能带来灾难性后果，有被坑过的举爪）
• 集成工具链。 曾经我用某引擎写个DEMO，总共用了7个不同的工具，在不同工具进程之间切换严重影响了我的开发效率和心情。这个问题我一定一定一定不能再污染给其他开发者了
• 所见即所得。 这东西是被Unity3D惯出来的。以前开发排查问题，大部分就是Log、断点调试，自从Unity3D横空出世后，我暂停下查看现场就可以把无数BUG给直接修复了！所见即所得带来的直接好处就是：BUG现场排查快一个数量级。
  • 环境一致。 开发中所看到的，就应该是发布后的结果，两个环境应该是一致的。很多引擎开发环境是一套，发布导出后又是另外一套，经常出现效果对不上的情形；一些平台难以避免，但在HTML5上理论上可以做到这一点才对。
  • 游戏数据可见。便于BUG排查，便于实时修改数据，便于调效果表现等等
• 让策划、美术参与进来。 游戏引擎，不能定义为程序员的引擎，应该定义为：游戏制作工作流。他不应该是一堆傻傻的API和一堆生硬的工具。游戏程序员的真正工作，我觉得应该是折腾出工具让策划和美术配置出游戏，而不是无尽的迭代与沟通（或者说是扯皮）。引擎需要考虑到这点并努力去解决。
• 强大的UI系统。 可视化UI编辑器（美术人员一定要能直接使用）、自适应各种分辨率。以前端游（比如CGUI等）很多都要硬编码，更别提VC6时代了；最近公司在使用一款国内很流行的2D引擎研发一款游戏，这款引擎虽然有个简陋的UI编辑器，但需要非常多的硬编码来搞定界面自适应。相同一个界面使用UGUI（新版Unity3D界面系统）来制作，效率提升近4倍，而且还没算上后续的界面迭代。可见一个强大的UI系统，可以节省多少的人力物力啊！
• 易用高效的动画系统。 Flash是2D动画系统的标杆了，努力靠近他肯定没错
• 门槛足够低。 首先在语言层面，尽量只用一种语言就好（前后端尽量一致）；API应该少而精；接地气，常用功能直接给插件；更进一步：提供数百个成型游戏开发模板，配上文档。

渲染核心

渲染引擎是自己写还是使用开源的？基于程序员的创造冲动，团队不少成员自告奋勇希望自己来搞定，更可控。但我觉得意义不大，理由是：

• 2D渲染并不太复杂，技术门槛不高
• 一些开源渲染引擎已经足够好，没有致命缺陷
• 国外的一些引擎大牛，可不是吃素的；我们的水平不见得能超越他们，甚至远远不如他们

最终我们选择了Phaser、PIXI作为我们的底层渲染，并根据需求做一些定制和优化，这样一来，引擎开发成本被大大降低。

原型选择

我们的能力不足以全新造个不一样的轮子，并且还能比现有的更好用。有自知之明的做法，或者说更保险的做法是拿个标杆来模仿，再做点定制化功能。目前成熟的手游引擎主要有3个，Unreal、Cocos2d、Unity3D，这3个引擎我们都有使用过，因为对他们的优缺点就很好比较了：

• Unreal是个高大上的东西，或者说是不怎么接地气。使用的成本相对偏高，工具链也相对复杂，剔除在外。
• Cocos2d-x是个最接地气的引擎，特别是针对国内做的几个优化：引入Lua和渠道一站接入等。在当前环境中，能使用Lua支持热更新是个极大的诱惑力，应该说也是最大的优点。缺点也很明显，工具链只能说可用，但算不上好用；工具链整合能力比较差；UI系统没做好；引擎版本兼容性问题比较多；API设计得有点丑陋（这纯粹是我个人喜好了）；文档比较混乱，没建设好。
• Unity3D目前是全世界范围内最火的手游引擎了。早期Unity3D专注于3D市场，连基本的UI系统都没提供。后续出了大名鼎鼎的NGUI插件，再到当前官方的UGUI，Unity3D介入2D游戏。毫不客气的说，UGUI是我用过的最好用的游戏UI系统，没有之一。Unity3D的集成开发环境整合得非常好，编辑器定制简单且功能强大，其可视化开发完全释放了美术和策划的生产力；可视动画编辑器、关键帧调度等，非常方便实现界面效果。Unity3D绝对是敏捷开发的首选。当然，他也不完美，否则不就一统天下了。首先Unity3D是闭源的，一旦出现程序崩溃等问题难以自行排查；其次是无法支持热更新，这在国内市场比较致命（Appstore的提审周期可以搞死无数游戏不是）；Unity3D打包出来的游戏包会比较臃肿；Unity3D面向组件式编程虽然非常灵活与强大，但一定程度上提高了入门门槛。

很明显，Unity3D的致命缺点在我们这边可以被完美解决：我们的引擎开源、JavaScript支持热更新，因此Unity3D成为青瓷引擎的原型。因为青瓷引擎是个2D引擎，所以需要做一些“瘦身”，并且也需要融合一些其他引擎的优点（比如骨骼动画支持、Excel支持等）。总之，青瓷引擎会像是个“HTML5版的Unity3D”。

基于浏览器的引擎

初始我的想法是弄个V8引擎，做一些定制做成Native版本的引擎编辑器。但我们团队中有个十几年HTML5经验的同学，Hightopo是他的杰作。他的建议是放到浏览器不就完了？然后我们做了一些考量：

• 性能足够。在浏览器渲染类Unity3D的引擎界面，效果是很流畅的。当然，在发热量上肯定会高于Native，但可以容忍；
• 基础组件有积累。在Hightopo项目上已经有了比较多的沉淀与积累，可以拿来改造使用，不需要从零开始；
• 后续的游戏编辑器，需要有这方面的技术积累；
• 开发环境与发布环境可以保持一致，真正所见即所得；
• 完美利用浏览器自身的开发工具，比如chrome。那才是最强大的；
• 后续可能可以做云编辑，可以在平板上做部分开发工作，可以无缝的跨所有平台
• 还顺便可以装装逼，炫炫技术：我们能用HTML5技术完整构建整个引擎工具链

青瓷引擎应该是第一个敢于这么干的游戏引擎了。

谈谈runtime

做不做runtime在项目初期有过纠结，作为过渡浏览器插件带来的好处非常明显，他能很大部分解决android的一些问题：

• android下各浏览器兼容性不是很好，特别是声音与WebGL；
• 很多浏览器性能差，特别是国内的一些浏览器

如前面所说，坏处也很明显，否则Flash就不会死翘翘了。基于我们自己的考量与市场判断，我们的初衷是做HTML5游戏而不是照搬PC的页游模式，市场的规模不能只局限于国内少数平台而应该放眼全球，浏览器的发展需要时间但不会太久。最终我们决定将全部精力投入到原生支持的开发中，先全力做好HTML5市场。至于做不做加速器，等有app打包工具需求时再来考量也不迟。

产品驱动力

引擎开发的驱动力来源于两点：

• 自我游戏产品的研发需求
• 广大HTML5游戏开发者的实际需求

我们的引擎不是用来讲故事，做给投资者看，搞这些不是我们这群技术宅的长项；在我眼里，大部分开发者聪明、简单，对开发者吹牛忽悠只会招来反效果；开发者的要求其实很简单：能实实在在的帮我解决一些问题，别忽悠我少让我走弯路。在引擎的研发中，我会尽量把自己放在开发者的角度来思考问题。

秉承的做事态度

快速解决问题

每个项目都会有BUG，持续的开发并持续产出BUG，持续解决BUG并引入新的BUG……
对于版本的快速迭代非常重要，没有必要官僚的固定时间一个版本。在我看来，一天两个、三个版本都是可行的：一个新版本可能只修复1个BUG。
大部分引擎，都要等上很长时间才能解决开发者当前遇到的问题；在我看来，想方设法绕过问题或者等待别人解决问题，是件非常非常恶心的事情，我希望能改变这种状况。

技术支持：耐心、快速

“技术支持非常重要”，这个不少引擎公司不停的挂在口头上，但也就仅仅挂在口头上而已。技术支持要实际落地需要投入巨大的人力、物力，很多公司会觉得投入性价比太低。
在青瓷，有很好的基因来做这块。我们的游戏制作人和其他团队成员都会耗费大量的时间和玩家交流、沟通并回答问题，上到CEO下到普通的基层员工，无一例外。在引擎支持中，我们的要求是：

• 所有引擎研发人员，都是客服，都需要解决开发者问题
• 所有技术支撑工程师，都必须同时做游戏开发工作
• 有耐心。我们一定会遇到很多水平参差不齐的开发者，会遇到无数“重复的”、“随口一问的”、“没有提问技巧的”问题；我没有任何信心去改变这种现状，那么只能加几个数量级的耐心去解决问题
• 快速。提个问题，几个星期甚至几个月后再来回答，黄花菜早就凉了

开发者不是小白

诚然，引擎需要大量开发者的使用才会逐步稳定下来，这过程会躺到不少的坑。但绝对不能以此为借口，让无数开发者为我们的疏漏买单：我们有责任将坑降到最低，有责任自己带头先躺一遍。
“自己拉的屎自己先吃吃看”。因此，每个引擎开发者、每个客服团队成员都需要做游戏并保证上线；内部有N个其他团队使用引擎开发产品。

诚实

咱不来虚的，吹牛皮的事少干。
出错了就认，赶紧改正，粉饰太平的事少干。
别怕得罪人，有问题直接点指出来，当老好人的事少干。

做精、做透

不要追求大而全，找个点投入全部精力去做好。近来不少公司去做3D引擎，“青瓷会不会做3D引擎？”，近期肯定不会：

• 2D引擎都做不好，做神马3D的啊。我看过几个发布会，一些3D效果做得不是一般的渣，可还拿出来大吹特吹，至少在我看来是不认同的。如果把这些精力拿来先全力做好2D不是更好？
• 不具备炫技术的能力。3D引擎门槛是比较高的，我们团队短期还干不了，毕竟这方面的积累不多。做个渣引擎丢人现眼，我可不干这蠢事（以目前团队配置来看，估计弄3D的HTML5引擎9成以上就是渣了）
• 2D引擎做好了，市场就足够大了，并且更能贴合中小开发者
• 在HTML5领域，2D渲染性能目前问题还比较多，更别提3D了；短期内3D引擎的呼声没那么高

对位思考

更多的把自己定位为：游戏开发者、引擎使用者