专访张路斌：从HTML5到Unity的游戏开发之路
发表于 08:24|
作者单明珠
摘要：社区之星52期采访了非计算机专业出身、热爱游戏的张路斌，为了离梦想近一些，毕业后前往日本，选择在游戏行业发展。在这段时间里，他在CSDN博客里撰写了几十篇技术文章，并著有《HTML5 Canvas游戏开发实战》一书。
张路斌，英文名Lufy（ ），非计算机专业出身，由于本身喜欢玩游戏，毕业后千里迢迢前往日本，从事游戏开发工作。一开始接触Java、.Net和PL/SQL开发工作，由于碰上金融危机公司裁员，便跳槽至一家小公司做了半年手机游戏开发，随后到一家互联网公司工作。现在在一家游戏公司上班，接触最多的是Unity开发。Lufy曾开发《杨家将传奇》、大型网页游戏《アイドルバトル》、《Flash游戏ポイガチャ》、多平台三国记系列游戏，以及数十款手机小游戏。在CSDN博客上撰写了几十篇的技术博文，还著有《HTML 5 Canvas游戏开发实战》一书，并独立开发了HTML5游戏引擎lufylegend。近日Lufy接受CSDN社区之星栏目的专访，让我们一起来看看他在日本游戏发展道路上的点点滴滴。CSDN：请先介绍下自己。Lufy：大学毕业后，我最先接触Java开发，后来到日本做.Net和PL/SQL开发。很不巧的是，我在日本碰到了严重的经济危机，一起出来的小伙伴们都回国了。相比下，我运气较好，找到了一家做手机游戏开发的小公司，后又跳槽至另一家互联网公司，主要接触PHP、JavaScript和Flash。现在在一家游戏公司工作，接触最多的是Unity。CSDN：非计算机专业出身，为什么会选择到日本，在游戏行业发展？Lufy：我做这个行业，主要是因为我喜欢玩游戏。游戏玩多了，自然就会有“游戏中的某个地方要是如何如何设计，或许会更好玩”之类的想法，就会想要自己去做一款游戏。大学时，我做了一款《杨家将传奇》，在同类游戏中，它的人气还算不错，现在也有不少人在玩。这款游戏对我的影响非常大，也更让我坚信游戏开发之路。毕业后来到日本，很大一部分原因是我比较喜欢日本的游戏，到日本发展或许会让自己离梦想更近。实际上，到去年年末之前，我都不算是一个全职的游戏开发者，我之所以一直在坚持，是因为我很喜欢游戏开发。HTML5的游戏开发经验之谈——缩短开发周期，并想办法维护CSDN：我们知道您曾独立开发大型网页游戏《アイドルバトル》、《Flash游戏ポイガチャ》、多平台三国记系列游戏，以及数十款手机小游戏，能和我们分享下经验吗？Lufy：经验谈不上，我就根据自身开发经验简单的说下。之前我开发的有点规模的游戏，现在都已下线了。前几天我听了一个游戏经验的分享，和我的想法不谋而合，我在这里和大家分享下。游戏开发者都知道，一款游戏是否会火，根本就是不可预计的，有的游戏画面特效做得相当绚丽，有的游戏内容非常有意思，有的游戏玩法特别新颖，但最后都被淘汰了。当然，以上这些因素都是一款好游戏应该具备的，但也不是必要的。有时你觉得远不如自己的游戏反而一夜之间火爆了，有些简单的不能再简单的游戏，反而取得了很大成功。所以，经验告诉我们，游戏开发，就是不断的重复再重复，挑战再挑战，没人知道这个游戏是否会让你或者你的团队“一夜暴富”。此外，我认为游戏开发应该尽可能的缩短开发周期，让市场来决定你的游戏是否生存下去，然后再想办法维护。就像很多美剧一样，拍摄几集就开始播，先观察观众的反映和需求，反映不好还可以调整，或者直接放弃。当然，还有一些开发者开发游戏是为了自己的兴趣或者单纯的为了实现自己的某个理想，对他们而言，游戏做出来了，就已经算成功了。CSDN：2013年时，您写了一本名为《HTML5 Canvas游戏开发实战》的书，能介绍下吗？Lufy：这本书有对HTML5
canvas的API的详细介绍，也有对lufylegend.js引擎的使用详解，更重要的是，书中以实例为向导，详细讲述对休闲、射击、物理以及网络游戏等各种类型游戏的开发流程，包括游戏分析、开发过程、代码解析和小结等相关内容，帮助读者了解每种类型游戏开发的详细步骤，让读者彻底掌握各种类型游戏的开发思想。最后，书中通过数据对比分析，指导读者提升程序的性能、写出高效的代码，从而开发出运行流畅的游戏。CSDN：既然您提到了HTML5游戏引擎lufylegend，那么能否介绍下为什么会有自己开发引擎的想法？Lufy：至于我为什么想开发自己的HTML5游戏引擎lufylegend，这里我依然引用《HTML5 Canvas游戏开发实战》一书前言中的一段话来回答我开发HTML5引擎的原由：我是一个喜欢不断学习新知识的人，所以当HTML5作为一种新技术出现的时候，我没有理由不去了解它。由于本身对JavaScript有一定的了解，所以我在学习HTML5的Canvas时，上手非常快。出于对ActionScript的喜爱，我一开始便试着在JavaScript中模仿ActionScript的API来做开发，并且在博客上发表了《用仿ActionScript的语法来编写HTML5》系列文章，这便是最初的lufylegend开源库件的构建过程。当我把自己研究的类库整合到一起后，发现它使用起来十分方便，使用它来开发游戏可以节约大量的开发时间，于是我将其分享到了网上供大家免费使用，希望给相关开发者提供便利。CSDN：lufylegend有哪些优势呢？Lufy：lufylegend的优势在于入门简单、性能高等特点。其实所有的引擎都有一套自己的标准，并在这个标准上进行封装和扩展，所以在渲染过程中必然要增加很多额外的处理和计算等，但这些都会导致引擎效率的降低。而我在这款引擎的设计和维护上，一直坚持以高性能为第一目标，尽量简化渲染流程，以达到接近原生渲染的速度。我之前做过一个测试发现，在Canvas 2D基础上，lufylegend的渲染速度高出其他引擎很大一截。目前，lufylegend正在追加WebGL渲染功能，相信不久后的2.0版本，lufylegend在渲染速度上依然会保持领先。当然一款引擎只比性能是不够的，还要比易用性。在lufylegend交流群里，很多人都说，lufylegend太简单了，用它一天就可以开发出一款简单的小游戏。这个绝不是吹牛，lufylegend在设计上模仿了Flash的API。此外，在lufylegend中还有显示列表、对象、继承、事件等，极大的弥补了JavaScript在开发过程中的不足。lufylegend中还提供了对Box 2D的简易封装，以及Tween，不同屏幕的自动适配等功能。此外，我还引入了一些在Unity开发中自己发现的一些比较实用的小功能，这都让lufylegend更方便使用。CSDN：HTML5浏览器兼容性问题让人很头疼，你怎么看待这样问题？Lufy：说到兼容性，这也是出现许多引擎的原因之一。不同浏览器会有不同的处理，比如不同屏幕大小的自动适配，比如各个浏览器对音频的支持度等。开发者要么自己进行处理，要么就接触第三方工具或者引擎来处理。一款引擎，只有帮助开发者解决问题，才能受到欢迎。我觉得大家可以对兼容性持乐观态度，因为，兼容性的问题不可能会完全消失，但随着一系列标准的完善，这类兼容性问题会越来越小，未来会更小。所以，兼容性、渲染性等问题，应该交给引擎和框架来解决，开发者应该把重心放在自己的产品和开发上。CSDN：你觉得HTML5在开发游戏时有哪些优势？对它未来发展有哪些看法？Lufy：用HTML5开发游戏最大优势在于它的跨平台性，即无需进行下载就可进入游戏。一个链接一个二维码就可以在任何平台上向其他人分享你的游戏，还有比这个更简单的传播方式吗？再一个开发JavaScript人员储备充足，这也是一个很大的优势。HTML5出现的时候，我认为它是未来Web的方向。在移动开发方面，HTML5已经是主流了，这个不用多说。随着移动端和PC端对WebGL等新功能的支持，也让HTML5有了更大的发展空间，我觉得不光是在游戏领域，未来HTML5一定会渗入到各个领域。Unity能够缩短游戏开发周期，但学习成本高CSDN：您最近刚换了工作，现任工作最多接触的是Unity开发，可以说您现在也是一位Unity初学者，请问在学习Unity时，遇到了哪些难题？Lufy：我本身英语比较差，unity的界面是全英文的，所以遇到第一个问题就是打开unity后，眼睛看到的基本都是问号。这个难题我只能自己去查资料、摸索，慢慢学习资料查多了，再多的问号也就变成了文字。我比较喜欢Flash开发，对于Flash的设计理念根深蒂固，所以刚接触Unity时，遇到2D界面的开发，我总是将Flash的思路带入到Unity中，不过经过公司Unity大牛的指点，最终回归正途。此外，Unity还有自己的一套标准，如果只是将以前完全不同领域的思路或做法强加到Unity当中，只会让后期开发变得越来越困难，这也是导致很多Unity开发者失败的原因之一。再一个就是unity太复杂，并不是短时间内就可以掌握的，我接触时间还比较短，现在依然在逐步深入学习当中。CSDN：Unity在3D引擎方面具备卓越的品质和优势，同时也支持2D游戏的开发，您觉得它和HTML5相比，有哪些不同和优劣势？Lufy：其实Unity和HTML5基本没有冲突点，Unity主要是App开发，而HTML5的优势主要是页游开发或者是依赖于WebView的端游开发，这要看公司的产品侧重哪一块了。不过既然问到了，我简单说一下自己对Unity的看法。Unity的优点很多，简单总结的话，主要有以下几个方面：相对于游戏引擎来说，功能非常完善；学习资料丰富，交流社区也很强大，开发案例多；可以在PC端预览，Debug方便；Editor的扩展方便；GUI、以及NGUI等UI组件丰富；多平台支持；可以直接在AssetStore中购买所需素材或组件等。因为以上优点，使用Unity开发，能够有效的缩短游戏的开发周期。当然缺点也有，比如说学习成本比较高，想短时间深入了解Unity是不可能的。CSDN：给我们简单的介绍下日本游戏市场吧？Lufy：这个问题比较大了，我只能简单的说下我对日本手游的一点了解。日本手游中卡牌游戏居多，游戏一般都采取免费下载、内部收费的形势。
日本的手游的发布渠道比较单一，一般只考虑苹果以及谷歌旗下的应用商店就可以了。日本用户消费意识很高，日本人对扭蛋尤其钟爱，其也是日本手游的主要收费方式之一，卡牌类、RPG类、养成类、战略类，无论什么类型，扭蛋几乎无处不在，而且所有人都会大把的往里砸钱。日本手机网速比较快，而且手机上网基本上都是包月形势，所以不用担心游戏流量问题。日本人对手机游戏的狂热程度绝对超出你的想象，路上、电车上、厕所里，任何地方都能看到低头摆弄手机玩游戏的人。这也决定了，能够适应碎片化时间的游戏会比较卖座。CSDN：以后会回国发展吗？怎样看待国内游戏市场的发展？Lufy：这个当然，以后肯定会回到国内发展的。其实我觉得无论国内还是国外，手游开发都将成为未来游戏开发的主流。而且国内有着全世界最大的用户群，很多国外公司都开始进军中国手游市场，把中国当成最大的游戏市场，包括我现在的公司也是。现在智能手机在国内已经很普遍了，而且性能越来越高，再加上微信等各种平台渠道的推广，所以未来国内的游戏市场也就是手游市场，手游市场必将取代PC游戏市场。CSDN：给同样热爱编程游戏的小伙伴们提供一些学习建议吧。Lufy：这是一个老生常谈的问题，之前也有很多人总结过了，我再总结一遍吧。自己多动手，有些东西看一百遍或者听一百遍，也不如自己写一遍理解的透彻。多看代码，现在开源的代码库这么多，这绝对是提高自己编程能力的一个捷径。多跟人交流，有些问题可能自己通过调查解决了，但如果听下其他人的想法，或许会学到更多。尤其在你刚接触到某个新领域的时候，一定要多看书，这个书包括电子书，或者互联网上一些从基础到深入的连载文章。在开发过程中，最忌讳的就是遇到问题不思考就发问，虽然我觉得大家都知道这样不好，但是这类人确实有很多。举个简单的例子，一个对象的某个属性可以设定为两个不同的值，对于会学习的人来说，他会将这两个值分别设定，然后看一下结果有什么不同。而另一部分人，会直接到论坛或者QQ群等地方去问。这就是自学能力差异的体现。若想获悉张路斌更多动态，请关注。
CSDN博客： 新浪微博：
社区之星访谈上期回顾：
更多精彩内容，请点击查看。CSDN社区之星专访栏目，欢迎推荐采访人或自荐，来分享你的成长经历和相关技术，相关信息请发送邮件至：shanmz#csdn.net（#换成@）。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章&&&&原生手游市场已是红海，腾讯、网易等寡头独霸天下，H5游戏市场或将成为下一个风口。据笔者所知，很多H5游戏开发团队由于选择引擎不慎导致项目甚至团队夭折。如何选择适合团队和项目的引擎，笔者通过学习和项目实践，总结微薄经验，供大家参考，非技术人员也可以将本篇内容作为引擎选择的重要关注点。选择H5游戏引擎的思考维度1、开发语言的支持2、2D、3D、VR的支持3、性能4、引擎的应用广度5、设计理念6、工作流支持力度7、商业化成熟案例8、学习资源与技术支持能力&&&&首先，我们要知道，当前主流的游戏引擎有哪些。由于H5引擎有很多，笔者在这里进行了精心的筛选，过滤掉不支持webGL的引擎，以及封装了第三方渲染内核的JS框架，和不能直接在中运行的JS引擎。&&&&为什么要过滤掉这几种呢，首先，没有自己的渲染内核，仅仅是基于第三方的内核作的API封装，笔者很担心可持续的性能优化和维护能力。另外，不能在浏览器中直接运行的JS引擎，将限制H5游戏跨平台的交互能力。还有，&笔者非常看好webGL模式，认为webGL模式才是H5引擎的未来。原因有几点：第一、性能，webGL模式远超Canvas数倍。DOM模式就不适合用于真正的游戏开发，更不用提。第二、3D方向，webGL模式理论上可以制作2D和3D游戏，Canvas和DOM模式下只能制作2D游戏。第三、普及率，webGL的普及率已经非常高了，尤其是支持webGL的腾讯TBS-Blink内核已在4月19日发布，并逐步在、空间、、等APP中采用静默安装方式全面升级。这个普及率在国内带来的影响，;你懂的……1、选择H5游戏开发语言&&&&拥有广泛开发者的H5游戏开发语言共有三种，分别为&AS3、TypeScript、JavaScript。其中Flash&AS3、TypeScript均属于面向对象的高级脚本语言，通过编译器将原项目代码编译成JavaScript代码文件运行于浏览器之中，面向对象的高级语言无论是项目开发管理，还是项目开发的工具环境的成熟度都明显优于JavaScript脚本语言，尤其是中大型项目方面，AS3等高级语言的效率会更高。&&&&从上图看出，支持JavaScript语言的引擎更多，由于AS3语言的编译器为Layabox引擎推出的，因此采用AS3作为开发语言的仅有Layabox引擎。笔者建议在开发中大型游戏项目的时候，采用TypeScript或者是Flash&AS3语言进行开发。如果是小型游戏，任选其一即可。2、引擎的未来延续能力&&&&选择一个引擎，并不是简单的认为，满足眼前够用就可以了，引擎的未来延续能力也是很重要的，这个项目是2D，下个项目想开发3D，如果引擎不支持怎么办？去换个引擎？如果VR的机会来了，再想发布VR版本，这个引擎不支持，需要重新开发吗？等等问题，作为开发者尽可能要提前想好。&&&&通过上图，可以看出，即便是在支持webGL的H5引擎里，有只面向2D游戏的，也有只面向3D游戏的，同时支持2D、3D、VR的H5引擎，从目前看只有Layabox与Egret引擎。3、性能是核心需求&&&&性能是H5游戏面临的核心门槛，也是很多H5游戏不被专业玩家认可的重要原因之一。游戏卡顿，不流畅，这样的产品体验很难在激烈竞争中生存下来。&&&&H5产业早期的普及阶段即将过去，游戏品质在迅速提高，品质中包括精细的美术和炫酷的动画等。在复杂的游戏项目面前，上述种种元素，其流畅体验度对游戏引擎是极大的考验。所以选择性能优秀的引擎是保证品质的最重要基础，一定要谨慎。&&&&在游戏项目研发开始时，一定要先对复杂的模块做DEMO测试，特别是带背景滚动的游戏。比如横屏卷轴游戏，对帧数稳定性要求极高，如果满足不了性能上的需求，可能会带来眩晕、眼花、疲倦等不良体验。&&&&在webGL的2D渲染性能方面，pixi.js的性能处于当前的顶级。在webGL的3D渲染性能方面，Three.js非常优秀。在runtime方面Cocos2d-js也有着原生级的表现，经过对比，笔者认为Layabox性能的综合实力最强，在各个渲染领域都保持在HTML5引擎的顶级水平。当然，上图仅作为参考，对于任何号称某个引擎性能最牛的论调，一定要亲自进行性能DEMO的测试对比，而不要轻易采信。&&&&由于性能是游戏最核心的需求，笔者这里再多说一句，大型项目在系统复杂度、UI复杂度、动画显示数量和种类等方面与小型游戏项目完全不在一个量级。会涉及到比小游戏更复杂的性能优化、内存管理、资源管理等需求，如果选择了小马拉大车的低性能引擎，项目夭折可能性非常大，除非最后项目开发者花大量时间自己优化引擎。所以性能差一点，就会导致结果差很多，不可主观想象。4、与引擎的应用广度&&&&随着H5游戏品质提升，在其他领域也具备一定的竞争力和价值，一次开发可发行各个领域版本，已成为日渐明确的需求，这里面包括发行原生APP手游和PC的flash页游需求，大统一的引擎时代即将来领。目前最火爆的H5游戏《传奇世界H5》据说有40%的收入来自PC网页。&&&&发布PC页游时，由于PC浏览器目前对HTML5兼容性不足70%，用户损耗很大，页游联运平台可能会拒绝或放量很少，只有采用能同时发布Flash版本的引擎，才能解决这个问题。5、设计理念与定位&&&&设计理念是个比较大的话题，也是个很重要的引擎选择因素，比如引擎是要专注移动端，还是要面向全平台多端游戏市场。是注重性能，还是注重工具链等等。深入了解不同引擎的理念与定位，才能更好的与游戏产品进行结合。&&&&上图内容仅作参考，详情建议去各引擎官网深入了解。6、工作流支持力度&&&&作为商业级开源引擎，工具链的提供与支持也是一种选择考量要素，比如UI、粒子编辑器、骨骼编辑器、场景编辑器等等，如果引擎方直接提供或支持，那么将会较大的提升研发效率。本文中提到的7个引擎，只有Egret、Layabox、Cocos2d-JS这三个引擎，在工具链方面提供足够全面的支撑。7、是否有成熟的商业案例&&&&怎么证明引擎是成熟的？一定要有成熟的商业案例，一般引擎的官网上都会有游戏案例介绍，我们在选择引擎之前要进行深入体验，包括：商业案例的数量、商业案例的种类、稳定性、流畅度（要在低端机里体验）、项目复杂度、项目相似度等。如果有一些大型成功案例背书会相对安全可靠些。从目前的行业案例来看，Layabox引擎的MMORPG《醉西游》、重度动作游戏《猎刃2》、大型模拟经营游戏《梦幻家园》等无疑是H5引擎技术的最高水准代表作。但是从卡牌、挂机等类型的付费游戏总体数量来看，Egret引擎明显占优，充分说明该引擎的市场宣传力度更胜一筹。8、学习资源与技术支持能力&&&&能提供什么样的学习资源，以及技术支持，对于开发者也是重要因素，如果你是技术大牛，只想使用轻量的第三方渲染内核。那么2D游戏，pixi.js无疑是首选。3D游戏，笔者推荐Three.js。但是这两种引擎的学习资料都比较稀少。笔者认为学习资料的完善，以及在学习过程中的技术支持力度，将会很大的帮助你解决引擎使用中的问题。所以，API完善，DEMO完善，文档完善，社区的响应速度，交流氛围，以及QQ技术支持等，都可以作为你选择引擎的因素考量之一。9、页游移植产品的引擎选择&&&&目前像《醉西游》等优秀H5产品是Flash页游或手游移植而成，移植类的产品在选用引擎时要注意，代码是否可以直接移植？如果可以，那将节省大量的开发成本。比如Flash&AS3开发的2D或3D页游或手游，可以把逻辑与算法代码直接拷贝移植到Layabox引擎项目中，开发速度提高数倍。&&&&写在最后：最后提醒一下，千万不要相信某些引擎的单方宣传，一定要花一点时间去研究实践，亲自制作DEMO去作一作对比，动手体验到的才是真理。针对DEMO测试笔者有几点建议：&&&&1、采用一个复杂的UI，特别是复杂列表，比如说没有分页的背包列表，背包里放上不同的道具图片，测试滑动时的流畅度，这块比较考验性能，元素越复杂，数据越多，尤其能对比出来性能上的差异。&&&&2、包含最复杂战斗部分，不要写战斗逻辑代码，不然会花的时间太长，只需要把战斗相关的动画和复杂的元素放在场景中模拟即可，因为H5游戏性能瓶颈通常在于画面的显示。&&&&3、&测试主要目的是看项目在引擎中性能，这是最至关重要的，所以，硬件上，我们要选择低端安卓手机（比如红米）进行测试。环境建议使用微信环境测试，首先，因为微信公众号是H5的主要渠道之一，其次，微信当前的H5性能低于，在恶劣的环境下更能测试引擎的优劣。
4￥33495￥6486￥42007￥12608￥14509￥160010￥498业界技术大牛答：html5游戏开发前景如何？_游戏频道_新浪网
业界技术大牛答：html5游戏开发前景如何？
　　编者按：作为2014年游戏业界现象级事件之一，《围住神经猫》的蹿红也为Egret(白鹭)这款游戏引擎博来了关注。Egret(白鹭)是一款可以一次开发，分别部署在Android、IOS和WP原生平台或者Html版本的游戏引擎，最大的优势就是可以直接将Flash网页游戏转换成手机游戏，因性能高效，简单易用而得名。不过，由于HTML5游戏的商业化道路一直不甚明晰，业界对这款引擎前景的看法也是喜忧参半。
　　在这种前提下，有网友在知乎上提出了“如何看待html5开源游戏引擎Egret，html5游戏开发的前景如何？”的问题，作为白鹭时代的联合创始人――马鉴从Egret(白鹭)的技术背景、商业模式、发展前景等多个方面对该问题进行了解答。以下内容为马鉴回复全文，新浪游戏获得授权发布。
　　本来一直都在知乎潜水，但是看到楼上各位华山论剑点到了Egret，而且各持己见。我觉得我作为操盘Egret产品和技术的人，总归要回复几句，但是在诸位看官进入正文前，我先澄清一下，我的回复不会就以下几个问题展开讨论(为什么不讨论，相信各位资深看官都懂)：
　　1. HTML5有没有未来
　　2.开源好还是闭源好
　　3.Web，Hybrid和Native哪家好
　　4.2D没3D牛B
　　我想单就Egret本身而言，给出我关于以下几个问题的想法。
　　1. Egret为何用TypeScript？为何不用Dart,AtScript或者其他？
　　TypeScript(TS)是一个严格意义上JavaScript超集，而且它目前的1.4版本的语言设计更接近于ES6，如果只是单纯认为TypeScript是微软出的一个开源语言的，请认真去http://TypeScriptLang.org深入了解一下这个开源项目，了解以下微软的首席架构师为何会针对JavaScript做了这么个玩意。
　　那么为何Egret会选用TS呢？
　　首先，我们认为Dart的形式针对很多会使用JS或AS3的开发者而言(尤其是初学者这个最大的群体)，学习的成本曲线较陡，而谷歌又是一个在技术上“太过”创新的公司，跟随一个有可能“朝令夕改”的技术去制作一款产品，而且将整个Egret的工具和服务的体系都悬于它之上，实在有些让我坐卧难寝。谷歌的AtScript的目标又过于宏大，瞄准了ES7，但是就目前的H5的技术推进而言，下一个JS的标准是看齐ES6。我们想做一款创新好用的产品，但是首先我考虑的是先要创作一个能用的产品。
　　回到TS，它目前版本是1.4，即将在2015出现2.0，语言的结构设计无限趋近与ES6的标准，有了module，有了Proxy，还会有很多更类似于ActionScript3.0的语法。微软还提供了一个TS的编译器，可以在编译时为开发者提供很多帮助，而且我相信以微软的实力，做个编译器的水平还是很高的。目前的JavaScript恰恰有很多设计层面和开发层面的缺陷，TS都能或多或少的弥补这些问题。选用TS这个开源项目，能再现阶段很好的帮助JS开发者创作更有规模，更成熟，更有质量的游戏项目。
　　其次，我们可以用TS基于Canvas来封装跟Flash ActionScript3.0的API结构设计，而且，我们仅仅封装对于游戏有帮助的部分。我在Adobe的10多年，全部铺在了Flash产品和技术上，Flash是个庞然大物，当初Flash团队之所以放弃AS3到AS4，AVM2到AVM3的项目，很大程度上是Core的部分太复杂了，经历了几代架构师和开发的调整，升级重构的成本已经无法估量。简单的说，就是当时没人改的了，所以，我们也不可能投入研发去自己做一个complier或者virtual machine去让AS3交叉编译为JS。(君不见Adobe曾经宣布的AS3到JS的Falcon交叉编译项目，3年了都没动静，最后随同Flex一起捐给了Apache基金会)。
　　Egret的API设计只是借鉴模仿了Flash AS3里跟游戏有关的API部分，做了减法，因为Egret Engine的定位不是想让开发者拿去既可以做广告，又可以做minisite，又可以做Video，又可以做游戏。我们只想在core上保持精简，如果开发者对不同的游戏类型有需求，比如状态机，物理，粒子等等，都做到了core之外的game library里。我2014年初离开Adobe时候，中国还有接近30万的Flash开发者，其中90%是游戏相关，这是一个宝贵的开发者社区群体，他们对于Web页游的开发和理解远远超过了任何使用其他web前端技术做网页游戏的群体。Egret使用TS，一方面是为了让JS游戏开发人员更舒服些，另一方面是考虑到Flash AS3这个开发群体，不争取的话，慢慢都流失掉了，很可惜。下图是我们Egret Engine在API设计上与Flash AS3 API上的对比。
　　第三，我们使用TS，还有一个想法。将来的JS也是迟早会跟ES6看齐的，等将来所有浏览器都统一支持下一代JS的时候，现在使用Egret的开发者都已经熟悉了ES6那套做法，而Egret几乎可以0成本的直接将TS换为下一代JS的代码，平滑过渡所有开发者，比JS现有体系过渡到下一代的体系成本都低，更顺滑，何乐而不为？
　　2.我们2014年一口气做了一堆工具，而没有一上来就做个集成的开发环境呢？
　　我在这里要回答的有2点。在技术和产品的进化上，第一条真理是：天下武功，唯快不破；第二条是，长鞭理论无处不在；第三条是：工作流是工作效率提升的根本。以上三条重要性依次降低，当一个CTO和CIO做了产品形态和研发的决策时，请倒推。
　　说一说Egret的做法，Egret里我带的这帮人以前是做Flash Pro，Flash Builder，Flex GUI和众多工具及框架的技术，很有经验。但是经验不能完全当做生产力，经验不能当饭吃。经验告诉我们的是，要想在市场立足，在最短时间内做出来的产品的“核”也就是中心思想很重要。它不必拘泥于是否先要有个IDE来承载这种形态，市场需要的是最有效率的工作流，其次才是一招打遍天下的IDE集成开发环境，工作流的形态可以先出现在最初的若干款产品里，他们之间独立，小巧且专注，之间的数据通用且可以协作，对于研发而言，成本和风险均可控制。
　　而IDE，功能强大且齐全，开发者需要的功能都具备，但是研发成本高，风险大，周期长。按照Egret Engine的双周迭代速度，团队潜心于一上来就要打造一个IDE的节奏是不对的。就好像你希望快走，但是又总有一条腿迈不出去的情况一样，这个节奏的结果就是容易扯着蛋。但是2015年，我们也会做出一个第一版的IDE，叫Egret Builder。
　　3.说了引擎和工具，Egret想怎样商业化？
　　商业化的问题其实在这里我不想说太多，我只想说，我们除了引擎，工具，我还让团队做了个运行时。也就是将来Egret的技术体系就是三位一体，Engine，Tools，Runtime。关于Runtime的细节，我也不想多谈，大家可以去http://egret-labs.org上看看Egret Runtime的产品介绍页，就明白我们为啥要针对H5做个Runtime。很多明眼人一看就会说，这不就是个Flash Player么？！答案是Yes，也是No。
　　Yes的部分是我们的团队原来都是做Flash的，受Flash影响颇深。Flash Player里具备很多优秀的Web游戏设计思想都是很赞的，我们就想我们可以用C/C++和OpenGL围绕着这些设计思想，再做一个取代webview的游戏加速器，让开发者基于Egret引擎开发的H5游戏，可以直接通过这个Runtime加速。No的部分是Flash Player是to C的，要让用户去装，而Egret Runtime是to B的，集成到平台app里，作为一个库，当用户在平台里玩游戏时候激活，玩家是不知道Egret Runtime存在的，我们也不打算对玩家去刷什么存在感。Egret Runtime是为了解决H5游戏性能，适配，系统底层调用和碎片化的问题而生的一个产品。
　　在Egret Runtime上，我们跟各大平台的合作关系也很融洽，为什么？因为我们就是他们平台内部的一个组件，生命周期受平台app的控管，你激活我，我就干活，你移除了我，我就进入sleep模式，丝毫不影响人家平台业务，还能提高H5游戏的用户体验，也不骚扰用户，何乐而不为？尤其在Android上，一个activity级别的控件是让平台恐惧的，而一个view模式下的控件，平台是喜欢的。下图是Egret Runtime的HighLevel架构图：
Egret Runtime的HighLevel架构图
　　看了这张架构图，我想诸位看官应该知道商业机会在哪里了。
　　4.Egret现在就是个2D的，木有竞争力啊！
　　近一年内，Egret Engine的确是2D的，但是大伙不都是以进步的眼光看待事物么？Egret也一样，秉着天下武功，唯快不破的思路，我们规划了一下2015年的Egret Next，我们也在预研3D的部分，code name是HummingBird(请原谅我们团队就是喜欢鸟)，更细节一点的计划图在这里：
HummingBird计划图
　　5.说了半天，你们的套路到底是啥？
　　来看这张图，我们想为H5或者叫做使用H5(JS/TS)技术的web游戏开发者打造这么一套环境：
当然，随着时间推移，这图里面的每个环节可能都会过期
　　所以，说H5移动游戏也好，说Web移动游戏也好，说用脚本开发native也好，工作流齐全了，这些还算是问题么？
　　我自己作为Egret的技术管理人，在我10多年的职业生涯里，信奉这么几句话：
　　1. 永远不要基于现在去假设未来。
　　2. 永远不要尝试用一个成功打败另一个成功。
　　3. 预测未来的最好方式就是创造未来。
　　4. 就是干！
&&|&&&&|&&}