请问网页游戏需要游戏引擎吗？大家的引擎是买的还是自己写的？_游戏策划吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0可签7级以上的吧50个
本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：34,183贴子：
请问网页游戏需要游戏引擎吗？大家的引擎是买的还是自己写的？
请各位大神赐教。
有基佬玩吗？
我想请教问什么刚刚买的...
楼主美术生，动漫专业，...
要，公司有好几个，好像不是买的，反正上次问了下，好像用的很过时的那种。
网页游戏，简单点的，用Flash就能做……
自己写的.不建议去买.买来的基本都坑爹
现在很多公司都开始用Unity在做了啊，所以页游慢慢的还是会提高品质，等明年估计页游就远远不比现在这么好糊弄玩家了
贴吧热议榜
使用签名档&&
保存至快速回贴专访张路斌：从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
相关热门文章HTML5游戏引擎深度测评 - 简书
<div class="fixed-btn note-fixed-download" data-toggle="popover" data-placement="left" data-html="true" data-trigger="hover" data-content=''>
写了7523字，被17人关注，获得了24个喜欢
HTML5游戏引擎深度测评
最近看到网上一篇文章，标题叫做《》。目前针对HTML5游戏的解决方案已经非常多，但谁好谁差却没有对比性资料。特意花了几天时间，针对文章中出现的12款免费开源引擎做了一次相对完整的对比分析，希望能对大家有所帮助。
针对技术类产品对比，通常有多个维度进行对比，不仅仅是技术层面，还有许多非技术层面的内容会影响我们的使用结果。本文从如下几个维度进行多重对比。
设计理念&功能
2D与3D、编程语言对比
游戏领域中，最直白的一种分类方法便是2D与3D的区分。通常我们都会认为它们是游戏引擎领域两类不同的产品。原文中提及的引擎确实是当下最为流行的HTML5游戏引擎。很多引擎属于2D、3D通吃类型，我们通过一个表格进行对比。
基于HTML5技术的游戏引擎，所需要的脚本必定是JavaScript，只有JavaScript脚本语言才能运行于浏览器中。但目前市场上，出现了很多JavaScript代替品，例如TypeScript、CoffeeScript、LiveScript等等。不同语言直接的定位不同，语言哲学也不尽相同。一些游戏引擎在语言选择上也颇有意思。
JavaScript
TypeScript
enchant.js
cocos2d-js
PlayCanvas
可以从表格中看出，下面三个引擎属于2D和3D通吃类型。
PlayCanvas
在Web游戏领域胜出的编程语言是JavaScript和TypeScript。但绝大部分HTML5游戏引擎还是采用JavaScript语言。只有4款引擎选择支持TypeScript。
从当前前端技术圈环境分析，未来可能很多前端框架或者引擎会推出响应的TypeScript语言分支，从AngularJS宣布将使用TypeScript开发开始，TypeScript在很大程度上被前端认可。不得不说微软在开源圈这一仗打得漂亮。
设计理念&功能
架构设计是一门大学问，对于开源引擎架构的设计模式主要取决于作者的程序哲学观点和产品定位。将设计思路和功能放在一起对比讨论，比单独功能讨论更有参考意义。一个引擎的功能并非越多越好，功能应围绕引擎定位而定，这样的思路在一些引擎中体现尤为明显，下面我们针对每个引擎一一分析。
Three.js项目创建时间是在2010年的4月24日，到目前位置，应该算是比较老牌的开源项目了。事实上Three.js定义并非一个游戏引擎。在Github主页中，作者很明确的定义了Three.js的定位，叫做“JavaScript 3D library”。它仅仅是一个基于JavaScript语言的3D库而已。当然，你可以用它来做任何事情，无论是游戏，还是炫酷的3D展示。
Three.js在设计之处希望创建一个非常轻量级的3D库，能够帮助开发者快速搭建基于HTML5的3D内容。同时，通过暴露简单的API，将3D内容的开发复杂性降至最低。
渲染环境上，Three.js支持WebGL和CCS3D两种渲染模式。从当前使用量和标准普及程度来做分析看，开发者更加倾向于WebGL渲染方式。
文本主要想对2D游戏引擎做深入分析，所有没有对Three.js的功能与那些流行的3D引擎加以对比。
很多人第一眼看到Pixi.js官网，都会不自觉的认为这是一款游戏引擎。但在主页中作者对于Pixi.js的定义为“2D WebGL renderer with canvas fallback”，翻译为中文是一款依赖于canvas的WebGL渲染器。所以当你看到Pixi.js提供了为数不多的功能时，请不要惊讶，因为它只是一款渲染器。
Pixi.js的设计理念很多程度来源于它的定位，只做渲染器，要把渲染功能做到最强。而这样的定位，则会让Pixi.js成为其他引擎的渲染内核。你经常能看到一些游戏引擎，或者产品都基于Pixi.js而开发。
最求极致的渲染性能是Pixi.js的首要任务，为了让Pixi.js更加易于使用，作者在API设计上更加参考非常成熟的2D渲染架构 —— Flash，并且提供的API也尽量参考了ActionScript。
例如创建一个显示对象，在Pixi.js中被封装为 PIXI.Sprite。如果需要显示图像，借助 PIXI.PIXI.Texture纹理进行渲染数据填充。最终设置显示对象的坐标，代码看起来就像下面这样。
var stage = new PIXI.Container();
var texture = PIXI.Texture.fromImage('bunny.jpg');
var bunny = new PIXI.Sprite(texture);
bunny.position.x = 80;
bunny.position.y = 60;
stage.addChild(bunny);
Pixi.js中的显示架构完全参考Flash设计，所有显示对象组合为一个树状数据结构，但内部已针对WebGL渲染方式进行过优化，上层使用起来和Flash并无太大差别。
游戏引擎中的功能，我们可以细分非常多分类，一篇文章无法讲解所有分类细节讲解明白。我将所有功能做了一个二级分类，方便分析。
刻意将Pixi.js放在前面分析，因为Phaser本身并没有自己的渲染核心。就像Pixi.js的定位不一样，Phaser的定位是 "Desktop and Mobile HTML5 game framework"，中为称之为“桌面与移动端的HTML5游戏框架”。Phaser并不把自己定义为Engine，而是框架。所以，当你看到Phaser的功能设计和它的渲染内核时就不会经验了。
因为将自己定位为游戏框架，所以Phaser在游戏功能方面显得相当全面，你能想得到的绝大部分功能Phaser已经替你实现了。在渲染方面，Phaser并没有自己的渲染内核，而是直接引用了Pixi.js。这确实是个明智之举，因为Pixi.js在渲染性能方面非常强悍。前面已经提及编程语言，游戏开发本身逻辑复杂，算法较多，Phaser提供对TypeScript的支持也是非常明知的。
架构方面，Phaser进行非常多的高度封装。就显示部分而言，如果你使用过Pixi.js就是发现，设计思路本身差别不大，但API使用起来则方便很多。Phaser为一准备好了游戏所需要的一切。当我们像创建一个游戏界面时，可以在Phaser初始化时针对不同阶段进行定制。
var game = new Phaser.Game(800, 600, Phaser.AUTO, 'phaser-example', { preload: preload, create: create, update: update });
正向上面这行代码，Phaser为我们定义了 preload 、 create 、 update 等方法，使用时只需要填写callback函数即可。在资源加载时，Phaser会为你调用 preload 回调。 当画面刷新时，可以调用 update 回调。
其他方面，信号和插件系统算是Phaser的最大特色了。
Phaser功能众多，但绝大部分应用其他第三方作为实现。
Egret算是HTML5游戏引擎中的新起之秀，其定位已不单纯为HTML5游戏引擎。官方将其定位为“游戏解决方案”，同时也并未过多提及HTML5。究其原因在于Egret不仅仅提供了一个基于HTML5技术的游戏引擎，更是提供了原生打包工具和众多周边产品，使其成为“解决方案”。
这里单独分析Egret Engine这个产品，其语言使用TypeScript，有2D和3D版本。在架构设计上，同Pixi.js一样，参考了Flash成熟的2D架构体系。API方面，也参考了ActionScript。不仅如此，由于TypeScript的缘故，在事件系统中，也仿照ActionScript实现了 addEventListener 这样的事件注册机制。
内核方面，Egret Engine采用了模块化的设计。这样可以将不同的功能进行解耦。更加有趣的是，Flash中引以为傲的自动脏矩形技术在Egret Engine中也被实现。在canvas模式下，脏矩形会是渲染性能得到提升，比其他引擎更加有优势。
如果你会Flash，那么Egret Engine对你来说不需要过多的学习即可上手。
Egret Engine由于模块化设计的原因，将不同功能放到了不同模块中。这些模块以库的形式提供，下面表中是所有支持模块的总和，但不含平台API部分，例如微信API的封装。
enchant.js
enchant.js并非一个引擎，而是一个框架。同时，enchant.js也不仅仅用于游戏，还可以用于app。
鉴于支持游戏开发和APP开发，这个框架必定会顾全一些东西，不能在游戏方面放开手脚。架构设计上，没讲所有的元素全部按照OOP方式设计，内部使用实践驱动，并有效的结合了异步处理。游戏方面则仅仅对动画相关功能做了支持。enchant.js框架提供了一套插件机制，你可以将使用到的功能模块作为插件注入到enchant.js框架中。
enchant.js还特意提供了一个在线的图像库，方便开发者免费使用其中的素材。当从游戏效果来看，以小游戏居多。
enchant.js框架自身提供的功能非常有限，如果需要其他功能，必须自己扩展或者寻找响应的插件。
craftyJS将自己定义为针对JavaScript游戏的框架。
由于框架的定位，craftyJS在设计上提供了一些系统级别支持，例如将canvas和Dom两种渲染方式封装为同一套API，尽量小的文件体积，实体组件系统，显示对象封装，碰撞检测，事件系统，还有很多功能组件模块。所有的模块都依赖于实体组件系统的设计。
在实际测试中，craftyJS在API上的设计思路也是使用起来最为不舒服的一个。
Turbulenz引擎实际上是为自己的游戏渠道中的游戏提供的游戏引擎。因为和自身渠道绑定，所以在引擎中提供了很多low level API。借助这些底层API，可以呼叫Turbulenz游戏渠道中的一些系统级别功能。
由于Turbulenz引擎更多的为自己设计，更多的提供runtime支持，从严格意义上将，Turbulenz引擎不算是纯正的HTML5游戏引擎。为了满足其自身渠道的需求，Turbulenz引擎力求增加更加完整的功能，同时提高其运行性能。
由于Turbulenz对很多功能做了扩展，同时推出Low Level API和 High Level API。这里不再对其中庞杂的系统进行功能分析，大家如果有兴趣可以到其官网查看。
cocos2d-js
cocos2d-js是喊着Cocos2D-X的金钥匙出身的，它仅仅是Cocos2D-X的一个HTML5实现的分支。
cocos2d-js和Cocos2D-X的设计理念相同，你能够看到所有的API以及语法都完全参考Cocos2D-X。国内对于Cocos2D-X已经非常了解，这里就不做过多介绍。
cocos2d-js的功能提供的相当完整，你在游戏中需要的功能几乎都能够找到。
PlayCanvas
PlayCanvas主要用于3D渲染，本文还是以2D讨论为主，对PlayCanvas的分析就不做过多分析。
melonJS是一个轻量级的HTML5游戏框架，并且通过插件机制扩展其功能。
melonJS在所有的功能设计上都是轻量级的，你可以看到很多功能，并且在此基础之上搭建你自己所需要的功能模块。melonJS对于Tiled Map支持非常好，在兼容性方面也是melonJS关注的重点。
Quintus将自己定位为简单好用的JavaScript游戏引擎，同时支持移动和PC端。
Quintus设计为模块化和轻量化，尽量使用简洁友好的JavaScript语法。在JavaScript的API结构设计中，尽量使用标准的OOP模式。Quintus还借助了jQuery，并通过jQuery插件实现事件和一个选择器的语法。语言设计层面上Quintus没有设计限制使用传统的继承，这使得其中得组件模型更加容易被复用。
Quintus自身并不支持WebGL，同时提供的功能也较少，在Github中排名也很靠后。
Hilo这个引擎来源于阿里前端团队，从官网的主页上看，这个引擎的定位比较模糊。Hilo作为一个跨终端的互动小游戏解决方案，同时有称综合解决方案。从它的演变来看，Hilo属于阿里前端在实践总总结出来的一套工具库。整体引擎并非最初有计划设计构想。
从Hilo支持的特性上看，Hilo的设计思路更加偏向与前端开发者，而非游戏开发者。Hilo提供了多种模块范式的包装版本，实际上在满足不同前端开发者习惯。这些特性完全是前端工程师所偏好的内容，对于游戏来讲，这些内容可能优先级并非最高，作为阿里内部团队的常用引擎，对于阿里来说应该非常合适，应用场景做简单营销互动小游戏足以。
Hilo功能相对比较简单，对于游戏开发来说，缺失功能较多。
对团队开发来讲，工作流搭建是非常重要的，我个人比较看重这点。如果是小型团队或者个人开发者可能对此需求并不大。当项目规模变大时，一个好的工作流会事半功倍。
因为引擎的功能不同，所以涉及的工具也会有所差异，这里就不再做表对比了。
3D并不在本篇文章的讨论范围之内，同时Three.js也并非游戏引擎，不存在游戏开发工作流一说。这里简单介绍一下Three.js所提供的在线编辑器。
Three.js提供的在线编辑器应该是基于Three.js开发的，功能不多，但相当小巧。
Pixi.js作为一个渲染器，其工具支持也是相当清爽，除了一个程序库之外，没有提供任何工具。
Phaser和Pixi.js一样，没有提供任何工具支持，在其官网上只是推荐了两个代码编辑器。还提供了一个简单的在线代码编辑器。
Egret提供的工具非常多，也复合其解决方案的定位。在Egret整个体系下你可以看到如下工具支撑。
Egret Wing：Egret出品的一个IDE编辑器。在提供代码编辑功能的同时，还内置可视化的UI编辑器。与Egret Engine中的GUI、EUI框架配合使用。
ResDepot：这是个小工具，用来配置游戏资源加载表。如果游戏资源多的话，用这个小工具拖拽一下就完成了。
TextureMerger：一个纹理合并的小工具，功能有点像TexturePacker。
DragonBones Pro：针对Egret中骨骼动画解决方案提供的DragonBones动画编辑器。
Egret Inspector：一个基于Chrome浏览器的插件，可以针对Egret游戏进行调试。
Egret iOS & Android Support：这两个东西可以将你的HTML5游戏打包成原生APP。
还有一些其他的工具，但定位与游戏开发不同，有兴趣可以去它的官网看。
从上面的分析看出，Egret在工作流的支持上做的还是非常完成的，从Wing的代码编写，到ResDepot和TextureMerger的资源整合，再到Inspector调试，和原生打包。游戏开发过程中的每个环节基本都有工具支撑。
enchant.js
enchant.js 没有提供任何工具支撑，在官网中也没有任何相关支持工具的介绍。
craftyJS也没有提供任何工具支撑，仅仅是一个开源代码库。
Turbulenz在你下载的目录中包含了很多工具，大部分与格式转换相关。所有工具均为命令含小工具，没有提供任何可视化操作软件支持。
cocos2d-js
Cocos2d-js近年来变化很大，但对于JS这个分支的支持却少之又少。前一段时间新出了一个工具叫做Cocos Creator。我没有具体使用过，但看截图仿佛有Unity3D的影子。从介绍中看，应该对游戏支持还是不错的，编辑方面目前还欠缺。
PlayCanvas
PlayCanvas也提供了一个在线编辑器，不过是针对它的3D功能。编辑器看上去和Three.js提供的在线编辑器份很相似。这里直接借用官方文档中的截图给大家看一下。
melonJS除了源码库以外，也没有提供任何工具支持。但在其官方主页中，包含几个其他编辑器的连接。比如著名的Tiled地图编辑器等。
Quintus没有提供任何工具支撑。
Hilo没有提供任何工具支撑。
结果并不出乎意料，对于开源游戏引擎来讲，维护库就是耗费作者很大一部分精力，更何况去制作编辑器之类的软件产品。很多引擎都会依赖一些比较流行的第三方工具，例如Tiled、TexturePacker等等。虽然可以实现功能，但整个工作流搭配起来还是多多少少会有一些问题。只有Egret和Cocos2D-js提供了相关可视化编辑工具。而这两对于工作流的理解则完全不同。从产品中不难看出，Cocos2D-JS更像Unity3D，提供一个大而全的软件给开发者用。Egret则是什么角色用什么工具，将产品按照角色划分，针对不同角色和开发流程中的各个环节进行产品设计。
相对来说，Egret的这种方式使得每个工具更加垂直，能够做的功能也更加深入，不会让工具显得臃肿。而Cocos Creator则力求完整，一个软件解决所有事情。
性能测试上，我只针对2D游戏引擎做了一个渲染压力测试。
测试内容为同屏渲染对象数量相同的情况下进行帧频数据对比，为了保证测试的公平性，我使用同一台电脑，相同版本的Chrome浏览器进行测试，游戏场景尺寸均为800*600，显示的图片也为同一张。每个引擎进行同屏、20000个显示对象渲染。
其中craftyjs引擎渲染出现问题，这里不作数据对比。Quintus引擎不支持WebGL渲染模式，因此这里页不作数据对比。Phaser渲染内核使用Pixi.js，因此Phaser渲染数据参考Pixi.js结果。
所有引擎编写的代码大致相同，开始做for循环，创建定量显示对象，然后在循环中对每个显示对象做旋转操作。
测试代码如下：
var renderer = PIXI.autoDetectRenderer(800, 600,{backgroundColor : 0x1099bb});
document.body.appendChild(renderer.view);
var stage = new PIXI.Container();
var texture = PIXI.Texture.fromImage('bunny.jpg');
var tnum = 5000;
console.log("render Object Number:",tnum);
var bunnys = [];
for(var i=0;i&i++)
var bunny = new PIXI.Sprite(texture);
bunny.position.x = Math.random()*800;
bunny.position.y = Math.random()*600;
stage.addChild(bunny);
bunnys.push(bunny);
animate();
function animate() {
requestAnimationFrame(animate);
for(var i=0;i&i++)
bunnys[i].rotation += 0.1;
renderer.render(stage);
class Main extends egret.DisplayObjectContainer {
public constructor() {
this.addEventListener(egret.Event.ADDED_TO_STAGE, this.onAddToStage, this);
private tnum:number = 100000;
private bunnys:egret.Bitmap[] = [];
private onAddToStage(event:egret.Event)
console.log("render Object Number:",this.tnum);
this.stage.dirtyRegionPolicy = egret.DirtyRegionPolicy.OFF;
RES.getResByUrl('resource/bunny.jpg',this.onComplete,this,RES.ResourceItem.TYPE_IMAGE);
private onComplete(event:any)
var img:egret.Texture = &egret.Texture&
for(var i:number=0;i&this.i++)
var bunny = new egret.Bitmap(img);
bunny.x = Math.random()*800;
bunny.y = Math.random()*600;
this.addChild(bunny);
this.bunnys.push(bunny);
this.addEventListener(egret.Event.ENTER_FRAME, this.animate,this);
private animate(evt:egret.Event)
for(var i:number=0;i&this.i++)
this.bunnys[i].rotation += 1;
enchant.js
enchant();
window.onload = function () {
var game = new Game(800, 600);
game.fps = 60;
game.preload('bunny.jpg');
game.onload = function() {
var tnum = 100000;
console.log("render Object Number:",tnum);
var bunnys = [];
var scene = new Scene();
game.pushScene(scene);
for(var i=0;i&i++)
var sprite = new Sprite(50, 50);
sprite.image = game.assets['bunny.jpg'];
sprite.x = Math.random()*800;
sprite.y = Math.random()*600;
scene.addChild(sprite);
bunnys.push(sprite);
game.addEventListener('enterframe', function() {
for(var i=0;i&i++)
bunnys[i].rotation += 1;
game.start();
TurbulenzEngine = WebGLTurbulenzEngine.create({
canvas: document.getElementById("canvas")
var graphicsDevice = TurbulenzEngine.createGraphicsDevice({});
var draw2D = Draw2D.create({
graphicsDevice: graphicsDevice
var bgColor = [1.0, 1.0, 0.0, 1.0];
var tnum = 50000;
console.log("render Object Number:", tnum);
var bunnys = [];
for (var i = 0; i & i++) {
var sprite = Draw2DSprite.create({
width: 50,
height: 50,
x: Math.random() * 800,
y: Math.random() * 600,
color: [1.0, 1.0, 1.0, 1.0],
rotation: Math.PI / 4
bunnys.push(sprite);
var texture = graphicsDevice.createTexture({
src: "bunny2.jpg",
mipmaps: true,
onload: function (texture) {
if (texture) {
for (var i = 0; i & i++) {
var sprite = bunnys[i];
sprite.setTexture(texture);
sprite.setTextureRectangle([0, 0, texture.width, texture.height]);
var PI2 = Math.PI * 2;
var rotateAngle = PI2 / 360; // 1 deg per frame
function update() {
if (graphicsDevice.beginFrame()) {
graphicsDevice.clear(bgColor, 1.0);
draw2D.begin();
for (var i = 0; i & i++) {
var sprite = bunnys[i];
sprite.rotation += rotateA
sprite.rotation %= PI2; // Wrap rotation at PI * 2
draw2D.drawSprite(sprite);
draw2D.end();
graphicsDevice.endFrame();
function render() {
var tnum = 5000;
console.log("render Object Number:", tnum);
for (var i = 0; i & i++) {
sprite.position.x = Math.random() * 800;
sprite.position.y = Math.random() * 600;
cocos2d-js
window.onload = function(){
cc.game.onStart = function(){
//load resources
cc.LoaderScene.preload(["bunny.jpg"], function () {
var tnum = 100000;
console.log("render Object Number:",tnum);
var bunnys = [];
var MyScene = cc.Scene.extend({
onEnter:function () {
this._super();
var batchNode = cc.SpriteBatchNode.create("bunny.jpg");
this.addChild(batchNode);
for(var i=0;i&i++)
var sprite = cc.Sprite.create("bunny.jpg");
sprite.setPosition((Math.random()*800), (Math.random()*600));
batchNode.addChild(sprite);
bunnys.push(sprite);
this.scheduleUpdate();
update:function () {
for(var i=0;i&i++)
bunnys[i].setRotation(bunnys[i].getRotation()+1);
this.scheduleUpdate();
cc.director.runScene(new MyScene());
cc.game.run("gameCanvas");
var PlayScreen = me.ScreenObject.extend( {
onResetEvent: function() {
me.game.world.addChild(new me.ColorLayer("background", "#5E3F66", 0), 0);
for (var i = 0; i & 5000; i++) {
me.game.world.addChild(new Smilie(i), 3);
var Smilie = me.Sprite.extend({
init : function (i) {
this._super(
me.Sprite,
(-15).random(800),
(-15).random(600),
image: me.loader.getImage(game.assets[0].name)
,width : 50
,height : 50
this.rotation = 0;
this.alwaysUpdate =
update : function () {
this.rotation += 3/180*Math.PI;
this.angle = this.
function init(){
var stage = new Hilo.Stage({
renderType:'canvas',
container: gameContainer,
width: 800,
height: 600
var sum = 5000;
var bitmaps = [];
var ticker = new Hilo.Ticker();
ticker.addTick(stage);
ticker.start(true);
for(var i = 0; i & i++) {
var bmp = new Hilo.Bitmap({
image: 'images/hero.jpg',
rect: [0, 0, 50, 50],
x: Math.random()*800,
y: Math.random()*600
}).addTo(stage);
bitmaps.push(bmp);
function animate() {
requestAnimationFrame(animate);
for(var i = 0; i & i++) {
bitmaps[i].rotation += 0.1;
animate();
我的电脑配置如下：
最终测试结果
5000 Display
10000 Display
20000 Display
enchant.js
cocos2d-js
按照上述测试方法，我们可以对引擎性能排名做一个大致排列：
第一名：Pixi.js 和 Turbulenz第二名：Egret第三名：Cocos2d-js第四名：Hilo第五名：enchant.js第六名：melonJS
最后放出一张测试时效果图
通常情况下，我们都会选择一个资料较全的产品进行学习使用，毕竟使用过程中会遇到各种各样的问题。现在游戏引擎的文档，讨论组等都已经成为了产品标配。下面这个表格就对各个引擎的这些“标配”做一个对比。
API Document
enchant.js
cocos2d-js
PlayCanvas
从上面对比表格可以看出，绝大部分引擎在文档教程方面做的还是比较深入的，但完成程度不同。大部分都为英文文档，对于国内的开发者来说可能学习起来成本略高。其中两个支持中文的引擎Egret、Hilo均为国人产品，这两款引擎在文档方面，Egret做的相当优秀，开发者可以从它的中查阅大量中文资料。
在学习难度上，Egret算是最为简单的，无论从完整度还是中文普及度上。
这部分对比是在商业产品应用中的占比情况。一个引擎被商业产品应用广泛的情况下，足以证明此引擎具备商业产品使用价值。通俗的讲，别人能用这玩意做出游戏，你也能。所以针对这两方面进行一下粗略的分析。
我对国外的HTML5游戏市场完全不了解，这个市场分析的东西太大，不好做评价。就分析一下国内的，简单看一下到底哪个引擎用的多。
我用了国内比较火的HTML5游戏平台新浪微博作为数据采样基础，一个人实在精力有限，不可能做的完整。由于客户端对游戏地址进行了加密，无法直接获取。所以用了一些调试工具来看游戏网页的标记，以此判断游戏到底使用什么引擎制作。
最终统计结果如下：
CEO养成计划
边锋斗地主
上吧主公（萌喵闯三国）
呆呆忍者村
全民穿越之宫
召唤师学院
我欲封天H5
全民魔魔哒
我们的萌萌
全员加速中
悟空归来 – 西游神传
深海保卫战
大大大掌门
泡泡奥特曼
德州扑克H5
暴走大乱斗
经典玛丽h5
小鸟情人OL
少年，好功夫
秘密魔法花园
少女H计划2
一共找了50款游戏，如上面表格。50款引擎，使用纯HTML5开发的6款，使用Egret开发的30款，Cocos2d-js的14款，laya的1款，createjs的1款。
统计结果如下：
不难看出，Egret 和 Cocos2D-js联合瓜分了大部分市场。而Egret占比居然过半，达到58%。看来Egret在国内HTML5游戏市场还是非常强悍的。
Three.js：作为老牌的3D库，它已经有众多案例，在PC多网页3D中是目前不错的选择。
Phaser：文档教程，和案例方面都很不错，功能也算的上丰富。非常适合独立游戏开发和小团队使用。
Pixi.js：作为渲染器，其渲染性能绝对是非常优秀的，游戏功能方面支持很差，适合极客程序员把玩。
Egret：性能不错，在工作流方面支持非常优秀，适应中度和重度HTML5游戏开发，有较多商业项目验证，非常适合商业团队使用。
enchant.js：性能偏差，不太推荐。
craftyJS：文档教程等方面不太完善，很难找到对应技术支持，不推荐。
Turbulenz：性能极佳，但捆绑其自身业务，不太适合国内市场。
cocos2d-js：老牌引擎，其性能在排名中居中，工作流支持相对完整，推荐。
PlayCanvas：重度3D游戏开发引擎，本文不对3D做推荐。
melonJS：性能不理想，不推荐。
Quintus：不支持WebGL模式，性能较差，不推荐。
Hilo：阿里前端团队作品，偏向于前端开发工程师，与游戏专业开发距离较大，推荐做HTML5营销小交互的使用。
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
被以下专题收入，发现更多相似内容：
如果你是程序员，或者有一颗喜欢写程序的心，喜欢分享技术干货、项目经验、程序员日常囧事等等，欢迎投稿《程序员》专题。
专题主编：小...
· 212315人关注
@IT 专题 由 IT大分类，转定位于IT·互联网行业观察与思考，数码产品极客体验。
主编：向右奔跑 http://www.ji...
· 188647人关注
玩转简书的第一步，从这个专题开始。
想上首页热门榜么？好内容想被更多人看到么？来投稿吧！如果被拒也不要灰心哦～入选文章会进一个队...
· 138450人关注
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
选择支付方式：