Egret 的 童话 与 现实 #5

# Egret 的童话与现实 > 我要变成，童话里，你爱的那个天使 …… > > 你哭着对我说，童话里都是骗人的 …… --- ### 写在前面的一些话，不必要，但重要 我一直很少谈论Egret引擎，因为我对这样一款『打着HTML5游戏引擎旗号，实际以拉拢Flash开发者为主旨』的奇怪引擎不感冒。 但是最近Egret越来越多的出现在我的生活和工作当中，让我无法再继续无视它的存在。最近正好Egret联合创始人之一的7yue老师在知乎里阐述了一些Egret的想法和理念 ( http://www.zhihu.com/question/27078280 ) ，那我也就顺着那篇文章，把我的一些观点也拿出来说一说吧。 在开始之前，我先交代一些事情： - 写这篇文章的初衷，只是发表个人的观点，并不是『为了Egret好』。我没那么伟大，也没那种影响力去改变已经发布到1.5版本的Egret。 - 我们在谈论一件事时，其实很难把『人』的因素完全剥离开，所以『对事不对人』这种说法根本是异想天开。我说的每一句话都可能因事而伤人，先说声对不起了。 - 我不太会“有话好好说”，有时候会显得气急败坏、尖酸刻薄，不求大家的谅解，只求被冒犯者能够看开点，别把我当回事。 - 如果你觉得 我也是做技术的，我是因为『同行相轻』才看别人的引擎不顺眼的 ———— 那么，请你坚持自我，继续保持这种观点吧。像你这么狭隘的人 未来会很珍贵的。 - 我和Egret不存在任何竞争关系。相反，它的本意是来帮助我这种HTML5游戏开发者的。 - - Egret的联合创始人7yue老师是我很欣赏的Flash传教士（技术传教士想让我这种自以为有独立思考能力的人欣赏其实是挺难的，但7yue老师做到了）。他还曾经很热心的帮我介绍过投资人，对我有恩。 - HTML5梦工厂的创始人田爱娜 刚刚加入了Egret团队。娜姐是我这一生的贵人，没有她就没有现在的我。 - 所以，请你们相信，当我对Egret说出冒犯的话语时，最受伤的人是我自己。这倒不是因为我心理会很愧疚很难受什么的（那太装逼了），而是因为『当我用恶劣的方式对待爱我的人时，其实我也扼杀了别人继续爱我的可能』。所以我的损失才是最大的。当然，这是我咎由自取。 好了，扯了一堆没用的 进入正题吧。直接点，先抛观点： > - Egret如果能不用TypeScript 而是直接使用JS ，同时抛弃掉对Flash的傻傻痴恋 ，那么Egret会离成功更近一点。 > - 在WebGL面前，Egret runtime的价值有限。 > - Egret的那套开发工具才是一切的关键，也是最大的困难之所在。 我的整篇文章 都将围绕且只围绕上述几点展开。不喜欢 不感兴趣的，可以撤了。 --- ### Egret 与 TypeScript , 是童话还是谎言? 7yue老师的文章里第一个阐述的问题就是 Egret 为什么选择 TypeScript ,总结一下有以下几点: > 1. TypeScript 是 ES6 的超集，将来ES6普及时，可以平滑的过渡到ES6 > 2. TypeScript 弥补了JavaScript 的不足, 可以帮助开发者开发更有规模，更成熟，更有质量的游戏项目 > 3. 更类似于ActionScript3.0的语法，可以用TS基于Canvas来封装跟Flash ActionScript3.0类似的API结构设计。 我觉得这几个观点都有些问题。 **首先**，TypeScript并不是ES6的超集，更不是子集，只是有很多交集而已。TypeScript的代码现在以及未来都不大可能『不借助TS的编译器编译，直接跑在浏览器里』。 虽然它和ES6语法上的确实相像，但是这种相像意义不大，他们就是两种不同的语言。类似的，UnityScript和JS也很像，C#和Java语法也很像一样，但本质上就是不同的东西。 认为『TypeScript 就是 ES6的提前实现，学习TypeScript 就相当于学习ES6，就是提前与未来接轨』的想法是不对的。 TypeScript就是一个借鉴了ES6的语法，但是加入了types，不支持异步yield await的 js transformer 。真想提前与未来接轨，请直接学习真正的ES6，ES6 to ES5 的transformer已经很成熟了。 **其次**，目前的JS确实有很多不足，一个用10天时间写出来用来应付差事的语言能有什么好的(BTW：从语法层面，我最喜欢的语言是 AS3 和 Python2 ，作为有多年Basic + Java + PHP经验的人，喜欢这两种语言一点也不奇怪 ）？ 但是为了弥补这种不足，我更建议选择真正的ES6，而非TypeScript。而且什么module啊、classes啊 ,在ES5时代也早就有成熟的解决方案了，虽然这些方案不够统一，不够完美，但是早已被广大程序员所熟悉和理解，也经过了足够的验证，是可用和好用的。 TypeScript真正带来的价值（标准ES6无法提供的）基本上只有types，编译期的类型检查。给弱类型动态脚本语言加入类型检查，这么多年一直是很有争议的一件事。早在ES4里就尝试加入，结果最后连自己都悲剧了，后来ES6里又想加入，后来又去掉了，计划在ES7里加入…… 不可否认，类型检查是有好处的。但是它的好处大多数也仅仅体现在『有助于减少在编码期因失误造成的拼写错误等低级错误的发生』。也许有人会说，这个好处已经足够了，配合强大的IDE可以更好的开发复杂的企业级项目，尤其那种大型团队，成员众多，水平良莠不齐balabalabalabala…… 他们说的就跟如今PHP Python Ruby 和JS没开发过大型项目似的…… 另外，『TypeScript并不强制要求变量指定类型，并且可以和兼容ES5的传统js代码混用』这点，很多人把它看成是优点。那些有这种想法的朋友，你们确定这是优点吗？是优点吗？是吗？一边说『有了类型检查 再也不怕开发大型 起夜急 项目了』，一边对『可以和兼容ES5的传统js代码混用』持认可态度的人，精分的真是可以了。 说了这么多， 其实我想表达的不是TypeScript一无是处，而是我们没必要把它神话。他就是诸多js transformer里的一个，还不是最好的那个（没有最好 ———— 后半句自己心里默念一下吧，我懒得打字了）。 我觉得7yue老师说的那几点里，让他选择TypeScript最直接的原因只有**第3点**：『更类似于ActionScript3.0的语法，可以用TS基于Canvas来封装跟Flash ActionScript3.0类似的API结构设计』。 我必须强调一下，我不是说Flash那一套不好，更不是觉得AS3不好（但是总有人不信）。而且我对Flash的感情不比任何Flash开发者少，毕竟我们这一代70后80初的人 也是看着Flash动画长大的。当年的闪客帝国给我带来过无数美好时光。而且我很多游戏开发的技术都是从Flash游戏开发的书籍里借鉴学习的。 但是，我特别反感『把HTML5弄成Flash那个样子』的做法。 简单的说：我觉得我们可以借鉴Flash里好的设计思想，更要保留和发扬Flash领域里那些优秀的经验，但没必要在API层面去模仿Flash和AS，而属于HTML5自己的特点和优势。 而且这种模仿甚至会把Flash里的那些坏味道也带进来。典型的就是那个MovieClip，我都无力吐槽了，从名字到内部设计，根本不是为游戏准备的。 引领『模范Flash的API，以便让Flash开发人员更容易上手』这种思潮的框架/引擎 自然是大名鼎鼎的 easelJS 。后来我在盛大也和同事李正林（其实主要是他）搞的QuarkJS也是类似的东西，虽然自己参与其中，但是一点不喜欢。 说句题外话：也许有人会说，哪个社区不都是如此？NodeJS的兴起不也是因为搞JS的人『喜欢JS那一套东西』，所以balabalabala…… 但是这里面有一个本质的区别：NodeJS是充分挖掘了JS本身的特质和功能，让JS可以做更多的事情，而不是用JS去模拟其他某种语言，更不是从JS代码翻译成其他语言代码后再去执行。 好，把话题拉回来。虽然我不喜欢『模仿Flash的HTML5游戏框架』，但是我对『模仿FlashPunk和flixel这类Flash游戏框架』的做法是持肯定态度的。我的这两种态度并不矛盾： > Flash是提供渲染、音频、输入输出、网络等功能的底层架构，HTML5也是提供渲染、音频、输入输入、网络等功能的底层架构。而FlashPunk是构建在Flash上的上层游戏框架。在上层框架范畴内，我觉得可以借鉴Flash领域的任何优秀的产品（思想 算法等）。但是没必要先去用HTML5模拟一套Flash。 > > 这就好像北京和广州都可以到上海，当你在广州时，没必要先飞到北京，再从北京飞上海。 而这种喜欢用HTML5模拟Flash的人，通常有一个常挂在嘴边的理由：这样就可以用那些Flash领域里的成熟的工具来辅助开发了。一个典型的（也是唯一一个有点现实意义的场景）是：在Flash的IDE里导出的动画描述文件（json格式）可以被这类仿Flash的引擎直接使用。但是懂技术的都懂，这根本不需要模仿Flash，这只和json的解析方式有关。 而从集Flash和HTML5技术之大成的Adobe公司所做的Edge系列的品质，我们就能明白其中的真实价值到底几何了。 我们可以梳理一下Egret所做的事情: 1. 用TypeScript来模拟Flash的体系结构 2. 然后生成JS 3. 去做HTML5能做的事情。 这么折腾一圈之后，除了对初级Flash开发人员更友好（中高级的可以轻松驾驭HTML5，不需要折腾，例如Egret团队里的那些Flash程序员）之外，其他的意义并不大。 而7yue老师文章里几句看似一带而过的话，也从一个侧面印在了我的观点。也许这些话才是Egret团队潜意识里选择TypeScript的真正源动力： > 1. Egret使用TS，一方面是为了让JS游戏开发人员更舒服些，另一方面是考虑到Flash AS3这个开发群体，不争取的话，慢慢都流失掉了，很可惜。 > 2. Egret里我带的这帮人以前是做Flash Pro，Flash Builder，Flex GUI和众多工具及框架的技术，很有经验 第一句只看后半句就好，因为『让JS游戏开发人员更舒服些』是个伪命题，大多数我接触到的JS开发者都只是觉得别扭。 而第二句，我是不是可以这么理解：因为Egret团队的人对Flash特别特别了解，所以把HTML5模拟成类似Flash的东西后，才能更快速的展开后面的计划？ 而Egret产品线里有一款叫TS Conversion的工具, 它的存在也让我进一步巩固了我的这一观点： > TS Conversion是一款语法转换工具，能够快速将Flash游戏代码转换成Egret游戏代码。 以我对Egret团队的了解，他们完全有能力针对HTML5技术本身的特点去开发引擎、工具等等，但是他们就是放不下Flash的情结，这就是我前面所提到的『对Flash的傻傻痴恋』。 而这种痴恋其实里外不讨好。知乎上那位一直说『Egret很好，要是把TS换成AS就更好了』的Egret拥护者，似乎也验证了这点。 我们可以很容易的分析出 Egret + TypeScript的组合，对开发人员友好度的排名情况（从最友好，到最不友好）： 1. 熟悉Flash，也熟悉HTML5，但Flash情结严重。 2. 熟悉Flash，但不熟悉HTML5 3. 一张白纸，什么都不熟悉，不管用什么引擎，都要重新学习 4. HTML5游戏开发者 Flash，Flash，Flash …… Egret的一系列选择，一直在向我传递着一个信号：Flash为大。 也许Egret的开发者的初衷并非如此，但是证明你的，不是你的心，而是你的所作所为。 在这里插播一件几个月前我在某群里和一位资深Flash粉之间发生的趣事： 他在群里说Egret好，靠谱，牛逼。我问他，你用过吗？他说没用过。我说那你为什么说他好？他说，因为这是从Flash社区出来的人做的，我相信他们。 这…… 还真是让我感动呢，计算机信息技术专业要变文科了？ 唉 不说了，说多了全是口水，弄得好像我和Flash社区势不两立似的。其实我不喜欢的是JS社区，而flash社区一直是我学习各种游戏开发知识的宝库（有我发过的无数条黑js，夸flash的微博为证）。所以，大家千万别误会。 既然已经聊到了开发工具，那我就顺势离开TypeScript这个的话题，聊聊Egret的开发工具吧。 --- ### Egret 开发工具， 任重而道远 这个其实没什么好说的，我个人很认可7yue老师说的那段Egret对开发工具的观点： > 要想在市场立足，在最短时间内做出来的产品的“核”也就是中心思想很重要，它不必拘泥于是否先要有个IDE来承载这种形态，市场需要的是最有效率的工作流，其次才是一招打遍天下的IDE集成开发环境，工作流的形态可以先出现在最初的若干款产品里，他们之间独立，小巧且专注，之间的数据通用且可以协作，对于研发而言，成本和风险均可控制。而IDE，功能强大且齐全，开发者需要的功能都具备，但是研发成本高，风险大，周期长。 在日常游戏开发中，在选择工具时,我也一直在坚持『若干款开发工具，他们之间独立，小巧且专注，之间的数据通用且可以协作』这样的原则。例如 地图编辑使用TiledMap， 骨骼动画使用Spriter， 图片打压缩和打包使用自己开发的一个小工具…… 可以说，Egret的开发工具是走在正确的路上，所以现在的功能缺失啊、各种小bug什么的都不是事，随着时间的推移，都好说。 但是一个完整的的功能强大和齐全的IDE，是一个躲不开的东西。Unity是也是Egret必须面对的对手。毕竟，早晚都要做，这部分应该是最大的难点，也是Egret和其他基于完全基于代码的引擎的最大差异。 我最担心的是 Egret内部对这个开发工具没什么太大的野心，觉得自己有很多其他优点，IDE上差不多就行了，而不去用Unity的高标准要求自己。 我是希望Egret团队能把重心放在工具这方面，而那个Runtime在我看来，其实是可有可无的东西。 『研发开发工具』这个领域我不是很熟悉，也不说太多了，下面就聊一聊Egret的那个Runtime吧。 --- ### Egret Runtime， 也许只是看起来很美 Egret 一切基于性能的自信，其实都是源于这个Runtime。 在其他方面，无论是Egret Cocos2D-JS 还是我比较推崇的一些国外的同类HTML5引擎，性能其实都差不多的。 『性能』通常不是引擎所要解决的核心问题，而各个引擎所使用的那些优化相关的东西也都是一些通用的、尽人皆知的东西，不存在什么『独门秘笈』。另外在实际场景中，很多优化方法要么有很大的局限性，不具备普遍价值。比如被过度神话的『脏矩形』优化技术。 Egret Runtime做的事情简单说来，就是把 浏览器内置的那个比较慢的HTML5 Canvas，『替换』成一个更高性能的 OpenGL的画布。 原理跟 PhoneGap-FastCanvas 、CocoonJS 以及 Ejecta 有很多相似的地方。 ``` 当在Runtime环境中，运行的逻辑大概是这样： 游戏代码 --> Egret引擎 ---> 通过 Runtime,在一个OpenGL的画布上执行渲染。 而在没有Egret Runtime的情况下，运行的逻辑大概是这样： 游戏代码 --> Egret引擎 ---> 在HTML5 Canvas上执行渲染。 ``` 在没有Runtime时，Egret就是一个选择了TS作为中间语言的HTML5引擎，没啥特别的，暂不细说。 而Egret Runtime可以以两种形式存在。 **第一种**，可以脱离浏览器单独使用，这时候Egret 则变身为『支持TS语言的原生游戏引擎』。它的最直接的竞争对手就是 Cocos2D-JSC 、Unity2D 一类的东西 。此时和这两者比， 它除了用了TS，也没啥特色和优势（相反，由于TS，还带来了些劣势）。这第一种情况我想也不是Egret的主要发力点，只是一个『附加价值』，没什么好说的，重点是第二种。 **第二种**，内嵌在浏览器里，作为一个浏览器底层的插件。这正是Flash插件以前做的事情。不同之处在于你的代码在没有安装这个Runtime的浏览器里也能运行，只是可能会比较卡而已。 第二种方式看起来比较美妙，但现实往往比较残酷： 1. 在iOS上，这条路走不通 2. 在Android，用户无法给自己喜欢的浏览器『安装』这个Runtime，只能期待浏览器内置。 3. Egret Runtime嵌入浏览器的事情，只能靠Egret官方去和浏览器厂商去谈合作，把自己内嵌到浏览器里。 事实上,Egret也确实在 to Business（用2B怕引起误会…）的路上不断的努力着。 - 由于使用了TypeScript，Egret自然成为了微软的战略合作伙伴。 - 他们还与腾讯合作，让Runtime成为腾讯X5浏览器引擎的一部分，这样Android版本的微信、手机QQ、QQ浏览器都会内置Runtime。 - 他们也与小米合作，让小米手机、平板、智能家电的Android系统里的自带浏览器和系统WebView都内置Runtime。 - 由于有了腾讯和小米作为案例，很多小的浏览器厂商以及未来想在HTML5游戏领域布局的App（它们通常是内置个WebView来跑HTML5游戏）也开始主动联系Egret。 Egret的这些努力没什么不对，一个只关注『如何让引擎技术上牛逼，而忽视市场』的引擎厂商是很难生存的。但是这里面也存在着很多的隐患和不确定性： 1. 这些都和iOS没什么关系。 2. 这些合作大多在进行中，未来如何还不确定，风险也未知。举个例子，目前腾讯X5引擎自己的问题都一堆，这时候再加一个Egret进来，会进一步提升引擎自身的不稳定性。未来出了问题，排查起来不轻松。 3. 对于那些主动找Egret合作的中小浏览器以及App而言， Egret对他们的支持力度，以及这些App自身的研发能力都会直接影响到最后的效果。 4. Egret无法敲开真正的浏览器的大门。例如Chrome 和 很多一线厂商的内置浏览器。 5. 类似的事情，在Egret之前也有人尝试过，失败了。 UC 和 欧朋都试过。 6. 使用Egret的开发者要考虑有Egret Runtime 和没有Egret Runtime的两种情况。或者按最差的情况（没有Runtime）来设计自己的游戏，那么此时Runtime的价值自然被大大削弱。 7. 最最重要的： Egret Runtime重点解决的问题是性能，而在未来WebGL在移动端普及之后（这天不远了，iOS 8已经支持，新的Chrome也支持），性能不再是问题，Egret Runtime的价值会被大大削弱。 也许有人会说，WebGL 在移动端的普及还要很久，但是再久也会比ES6的普及来得早，再久也会比Egret成熟的时间要早。（Egret的版本号虽然挺大，到1.x了，但是让我来评价的话，应该还在0.3x的阶段，离一个出色的游戏引擎距离还很远，因为如前所述，我觉得IDE很重要）。 另外，虽然我认可Egret在市场上的努力， 但是最近发生的一些事，让我产生了一些逆反心理。我觉得Egret的本质仍然是技术产品，所以我更希望它能优先考虑从技术和游戏引擎的本职工作上征服我，而不是先在市场营销上取得成功，然后利用市场绑架我（这种事情确实已经发生了）。当然，这些也许是我的技术情结在作祟，对于那些觉得『开发游戏就是赚钱，其他都是扯淡』的人而言，我真的是在扯淡。 --- ### 对 Egret 的一些建议 说了这么多，表达了很多对Egret的不满，和对7yue老师的不敬，但是我必须要说，HTML5游戏领域需要Egret这样的团队，至少他们做了一件很了不起的事情：把HTML5游戏这个领域再次炒的火热起来，而且不是没有营养的虚假炒作，而是真刀真枪的实干。 所以，虽然我前面说了，我写这篇文章不是『为了Egret好』，但我还是『希望Egret好』。 最后提几个充满了我个人喜好，但是可能别人完全不认可的建议吧： 1. 推出纯 JavaScript 版本，如果真的对ES5不满，就搞ES6的。 2. 重点发力开发工具。 3. 那个Runtime只是暂时的权宜之计，别投入太多感情。 4. Egret是一个游戏引擎，一个HTML5/JS游戏引擎，请不要搞成另一个『Flash』。 5. 请先用产品征服我，而不要用市场绑架我。 也许有人会用7yue老师 文章中那最后的几句鸡汤来反驳我，说我的观点是『基于现在去假设未来』,或者说我『没本事创造未来，就知道瞎预测未来』…… 对此，我只想说：这么有人文情话的话题，还是等我们60岁以后（如果我能活到那时候）再来讨论吧。 最后，总结一下我这篇文章，其实就是几个不满： - 对Egret用TypeScript的不满 - 对Egret中处处流露出的以Flash为重的不满 - 对Egret Runtime的过渡宣传不满 - 对用Egret绑架我的人不满(其实这个和Egret没有直接关系,只能说他们的市场营销和对非技术人员的洗脑很成功) 也许这种在不满情绪的驱使下所写出的文章，都是满满的负能量，毫无实际价值，但是它至少让我『输出个人价值观』的欲望得到了充分的满足，所以，感谢每一位读了它的朋友。 谢谢。 ---