Rumah > hujung hadapan web > Tutorial H5 > egret 和cocos2d-x-js哪个目前更稳定更好用? ?

egret 和cocos2d-x-js哪个目前更稳定更好用? ?

WBOY
Lepaskan: 2016-06-07 08:42:28
asal
4500 orang telah melayarinya

貌似cocos名气大一些?因为神经猫的大火才知道egret,玩了一下他们的demo,貌似性能一般,不过对flash开发者特别亲切。有人对比过这两个引擎吗?分析下

回复内容:

曾经cocos的脑残粉,从1.x开始用,2.x后的每出一个版本,我都会激动地第一时间下载下来编译看看多了什么新内容。

然而很多时候正式版都编译不了,beta版就更是惨不忍睹了,至于引擎内部的坑,那就更列举不完了。
每次发布新版本,总是引入一堆BUG,之前能用的又不能用了。

cocos最坑的地方是许多官方吹上天的功能也就骗骗新手入坑,根本不能用,一堆BUG,比如cocostudio, cocoside,给我的感觉是引擎官方的态度问题,未来也不会有好转。

目前在做的游戏不用cocos了,以后也不会选择用cocos的项目,多了些思考游戏该怎么做的时间,少了些和引擎勾心斗角的时间,生活美好了许多~

PS:最近看到某位开发者升级最新版本3.8的经历,你们感受下~
Cocos2d-x 3.8正式版出了, 我要升级过去,... 来自杨世玲 我用过egret,用了一段时间不习惯又用回cocos2d-js了,最大的原因是cocos2d-x可以通过jsb实现native版本,而egret只能靠他家的runtime。虽然jsb的native版本有许多坑,但是小修小补就可以用的很流畅,还可以出windows版,mac版。配合webstorm也很快,更重要的是直接用js而不是ts,还可以用babel来个es6,比ts用着要爽。
所以我的建议是如果没有native的需求,只是做html5的游戏,以前没有用过cocos2d-x的话就直接上egret。
如果用过cocos2d-x,还是建议用cocos2d-x js。
我当时用的是egret1.5,编辑器是比较强,但是多而杂,并不是宣传的那么好用。可能是我用的姿势不对吧。 引用【王哲】的评论
只能说你的内幕太不值钱了。我这边的内幕是,cocos2d-html5核心人员之一离职,再带走我引擎组两个骨干,用cocos2d-js做刀塔like的游戏,后面由于代理的原因被强制改成egret引擎,白鹭对此游戏寄托无比厚望希望称为切入重度游戏的标杆,结果7月发布,8月公司解散,现在这波人又用回cocos了,原因不明。

首先,我个人不太愿意介入Egret和Cocos的斗争中,王哲大神是我非常尊敬的前辈,但涉及到公司名誉,作为当事人,我不得不澄清几点:
1,前半段说的基本属实
2,我们公司没有解散,还扩张了
3,我们也没有用回cocos(毕竟cocostudio太难用了,抱歉了)
4,Egret和Cocos都是非常好的引擎,各有优点,选谁就看团队的技术基因和积累和项目特点

最后,现在撕逼无益,大家还是好好做产品吧 我站在玩家立场来答一下这事. 希望搞前端引擎的兄弟们都冷静下.
游戏,最主要还是玩家喜欢,然后买单,这是根本. 所以题主的问题改为"玩家会为什么引擎买单?" 才符合你问题的原始意义. 然而这个问题的正解却无论如何都无法在这里获得, 每个搞引擎的人或者公司都会真诚的告诉你, 用我的吧! 我有一百个理由和证据让你相信,你的选择是正确的.

然而我是玩家,我其实并不关心你用什么工具,我在乎的无非是:我首先能看到你,其次你做的菜是不是合我口味(合口味不代表美味噢! 这点很重要). 所以我引用到实际市场中来反问, 排行榜前5的东西美味吗? 和排行榜本身美味吗? 两个延伸问题(感谢1楼提供的素材截图:) ). 通过解释这两个问题, 我想或许你自己就能得到答案了.
1:排行榜本身美味吗? 在某年, 被国内大鳄们的刷榜垄断后, 对我而言,已经不再那么美味了,菜品名字依然不断在换, 不过味道呢? 不过菜单上我也看不到其他的菜,姑且就吃吧,没法子, 老板买单吧.
2:前5的手游美味吗, 上面的问题已经给出答案了. 前5的菜名可都是杠杠的吸金利器啊,(味道虽然....) 但是前5的手游玩家买单了, 无论主动被动,都买单了,这是在商业意义上的结果.

所以, 你发现没, 这个问题和你用啥锅炒菜关系并不大,我根本看不到. 换言之,手游本身不需要太强的引擎来做支撑, 在当前的环境中, 菜名和饭店本身才是国内市场的本质. 菜好吃不好吃,已经没有我们玩家说话的余地了,因为我只能吃到菜单上有的 :) . 在玩家这个层面,我其实挺诧异老外, 他只吃他想吃的,你塞给他的, 他闻都不闻, 还丢一句 holy shiiiiiiiii T_T!

最后极其负责的解答你,这两个都足以胜任你的菜品.
egret生态链比较完善(战略层面,实际上还需要把工具链再打磨打磨), 如果HTML5真的起飞,那他会飞的更高更轻盈.
coco 年纪大些, 踩得坑更多,填掉的坑也已经很多了,这是优势.如果HTML5起不来, 那他也给你买了一份保险, 自己想.

(ps: 仅在手游的领域中,你别故意抬杠,拿去搞端游或主机 :) , 不过你的菜名和饭店才是你关键啊) 题主的问题是稳定和好用。

从稳定上来说,这两个目前都相对上稳定,绝对上不稳定。
而好用大多数情况下是个人喜好吧?有些人以为 PHP 好用,而有些人以为 C++ 好用。

我做了2年 cocos2d-x 开发,主要基于 lua 和 cpp,没有研究过 js。触控目前对 lua 绑定的支持并不大,两年前是这样(Cocos2dx+lua合适还是Cocos2dx+js合适? - JavaScript),现在好像依然是这样。

所以,触控应该是花了很多精力来做 cocos2d-x js 支持。

我没有研究过 cocos2d-x js ,所以没有权利评判它,但评价一下 cocos2d-x 应该还是可以的。

cocos2d-x 2.x 的代码质量一般,但 3.x 有了很大的改善,问题是工具链这部分,cocos studio 不但没有给引擎添彩,反而是拖了后腿。

cocos studio 的问题上面已经有同学提到了,虽然夸张了点,但毕竟是事实。我从0.3一直看到1.0,发现还真的没办法用在工作流中。遂彻底失望。

例如骨骼动画这东西,本来 cocos studio 中的 Armature 就是移植 dragonbones 2.2 来实现的(在cocos2d-x中使用CCArmature实现骨骼动画
cocos2d-x专用的DragonBones2.2),最后却完全改成了自己的东西,和 dragonbones 不兼容,而且提供的编辑器也很难用。

egret 我用了1个月,所以还是个菜鸟。

egret 提供的工具虽然也有这样或那样的问题,但看得出来很多地方是用心了的,跨平台一开始就选了 AIR,这也是能快速推出这么多工具的原因之一吧。

虽然我不用 egret 的工具链(仅仅使用引擎),但从团队中的其他人看来,他们愿意去用 egret wing 而不用 vs 的 ts 插件(有些还是c++程序员),这就说明了这工具做得还是蛮好用的。不过有些工具也是有问题的,例如 texture merger 的实现就不是很完善。

总之,对于有 ActionScript 基础的同学来说,选择 egret 的确是可以快速上手。而没有这方面基础的同学,如果觉得使用 cocos studio 没有什么困难,或者根本不使用 cocos studio ,那么用 cocos2d-x js 也挺好。

的确如 @陈升想 所说,撕逼无义,还是好好做好产品再说。 推荐phaser.js成熟靠谱,框架全面基本无坑,性能不错底层是pixi.js。
其次cocos2d-js,jbs有小坑,hybird性能可以接受,但文档非常狗屎(js这一块,基本是要看c++的对比js来开发的)。。
egret没做过项目,似乎案例也极少,看了一下,api基本是原封不动照抄as3(这点对原来flash开发人员有是吸引力的,但照抄说明框架设计者设计思维的匮乏),功能有限,基本只能看做是一个renderer引擎,离pixi.js似乎更近一些。 题主, 去京东 淘宝买东西, 千万别看差评, 看完你啥都不敢买了. cocos2d 经历过那么多产品的锤炼, 现在仍然有那么多的用户, 它的质量是靠得住的. 白鹭也是类似的情况(但历史底蕴确实比cocos2d差, 但是历史包袱也轻) . 其实说到底 引擎的选择往往都是由团队大多数人员的喜好和团队大多数人员习惯决定的. 而不是引擎本身的素质. 可能是我见识短, 我还真没见过哪个游戏项目要靠引擎来决胜负的. 换句话说 , 能用cocos2d做成事的, 用白鹭也成, 做不成的, 用赤橙黄绿青蓝紫, 啥鹭都做不成. egret对于flash开发者比较亲切?我其他不说了,光一个movieClip就真不亲切了。egret喜欢闭门造车,都是自己重写一些世界已经有默认规范和用法的东西。关于这个的牢骚,我也在GameRes上吐槽过[深入思考]从使用Egret的不爽中提炼的2个产品设计要点
cocos2d在做UI等方面的确是有欠缺的,但是相比egret还是好很多,毕竟成熟太多了,egret在很多方面没法给人一种做引擎的感觉,前一阵子还透出了想转型做编辑器的味道,但是一看那个飞机游戏编辑器,我就觉得太多太多的不靠谱了。
虽然我不是一个CTO,甚至不是一个程序员,但是让我一定从这俩里面选一个,我一定选cocos2d。 如果大型游戏,强烈建议不要使用cocos2d-js
我们目前的几个项目都是cocos2d-js开发的,我打算把这几个项目转egret。有如下几个理由:
1、cocos ide有BUG:断点会崩溃、代码提示很差、内存太高、虚拟机的菜单栏会影响事件(迭代了很多版本,这菜单栏BUG都没修复)
2、studio的工作流在几个引擎中是最差的,而且有BUG。经常和实际表现不一致。而且内存占用大,会崩溃。不能继承(这个问题最严重,不能继承按钮,那么按下缩放等高级功能就很蛋疼)。
3、架构太差。写点小功能没事,如果想写大型游戏,这套架构会让你抓狂!比如最简单的按钮事件,我必须在事件方法里面加个触摸类型判断。一个很简单的点击,就多出很多这种相似的代码!4、UI有好几套,然而每一套都有BUG。CCUI的设计也是很糟糕的!同时也是崩溃的罪魁祸首。
5、引擎BUG问题,很多BUG会让你欲哭无泪,比如坐标会出现undefined。再比如热更新的BUG,XCODE编出的包默认是js而不是jsc,当这个包发布商店就会出现不能热更新的问题,同时也进不去游戏,卡在了热更新界面。(这个问题导致我们流失了3个月的用户,知道苹果商店通过审核位置),再比如java/objectc和js的交互,这个都有问题!再比如:ios第三方输入法会导致崩溃!
6、工作流问题,IDE的断点的观察变量很不友好、studio导出的配置很大、studio扩展性很差。在IDE 1.2版本出来之前,我们团队甚至无法断点,只能打印日志来debug。
7、工作效率问题,代码提示先不谈。我实现一个简单的列表都能折腾很久,那ccui的list真是太不好用!除此之外,裁剪、遮罩这些只需要一行的代码,在cocos下面需要无数行!
8、引擎升级问题:cocos大概一个月1个升级,egret是2周。然而cocos升级会带来大量的新BUG,而且兼容性很差。导致我们现在还用3.0版本。最蛋疼的是,官方的3.6版本又不能断点了!3.0升级到3.6还会导致布局混乱、九宫失效、崩溃闪退(绝对不是代码问题这个解释了)!基本上cocos每加个新功能都会带来无数新BUG,老BUG修复量也少,我论坛反馈的问题经常需要迭代2到3个版本才修复,下个版本修复兼职是不可能。而egret不仅迭代快,BUG修复也勤快!也很少有一些导致产品质量的验证BUG。
9、官方人员态度问题:我在cocos论坛发的BUG反馈,过了7天才有人来回复。地址(从3.0到3.1和3.2的BUG,官方帮忙看下),再看下egret我发的BUG反馈,当时是下班时间,然而第二天一早就回复我了。地址(Egret社区-BUG列表
10、API问题:cocos经历了3个大版本,官方API文档也有的API,实际尽然是没有的,官方回复是还没加入js绑定。
11、跨平台问题:cocos2d-js经常是HTML5和JSB表现不一致。导致我们现在只能专注JSB而放弃HTML5版本。egret很少有这个问题。
12、性能问题:先抛开runtime。如果你用了ccui,那么我100%保证你的cocos2d-js的性能会被egret秒杀。再来说下native下面的性能对比,cocos的人说egret是js写的逻辑,而他们是绑定。那么问题来了,在现在,js的逻辑产生的性能压力一点都不是问题(参考node.js,能用js写服务器了都)。主要的性能压力其实是在渲染上面,而他们2个都是opengl作为渲染的。如果用了ccui,那么还是被egret秒杀。那ccui带来的drawCall真是太!!再来谈runtime,egret现在很多浏览器都集成了runtime(可以opengl渲染代替canvas渲染),而cocos-js只是说在合作,已经慢了一步。
13、产品路线图问题:cocos的几个产品一心在弄3D,egret都已经自己搞了一个IDE了。开发基本的生活cocos都没保障好,就去想和u3d打架!
14、内部问题:cocos估计内部很不和谐,ide据说是1个人在开发,studio是30个人(30个人整出这东西),而且studio是用的.NET搞的,跨平台最呵呵的技术!QT、AIR那些那么多高效率,扩展性强的技术不用,选了个.NET。。。。
---------------------------------------------------------------------------------------------------------------------------------
题外话:说了那么多cocos的不是,我也曾试着爱过它,我甚至开发了一个和egret wing一样的UI编辑器,写了个和Flash/Flex一样的API(egret用的这套,这种架构很好用,简单明了)。其中UI编辑器还加上了unity3d那种绑定脚本的功能。然而因为cocos底层的一些令人发狂的BUG,我最终是放弃了。有egret这个车子在,我还造什么轮子?我打算把手里头的这套cocos的东西开源。然后去整egret去!
---------------------------------------------------------------------------------------------------------------------------------
再来个题外话:
游戏引擎cocos2d-js和egret 对比
这个是百度搜索第一的对比,里面说cocos2d的工具比egret多,我不否认,但是能用的基本没有。而egret的工具很稳定。就拿最简单的骨骼动画,cocos连龙骨都不支持,studio里面的骨骼设计也是坑的不行,egret的骨骼设计工具从界面和实用性都已经完爆studio了!
再来说上面的地址里面的成功产品:捕鱼达人、DOTA传奇、我叫MT那都是cocos2dx写的,和js版本一点关系都没有!请问你有见过网页版的刀塔传奇么?
上面的开发语言对比,大项目来说,ts真的是完爆js!js那不小心就会出错真心不适合大项目,不然微软不会造这个轮子。
上面的参考资料对比,cocos2d-js的文档连参数的注释都没,和c++文档作参考也不行,很多参数是不一致的!而egret在开发工具里面就继承了中文的帮助。

从目前状况看,今年绝对是egret产品井喷的一年,不信走着瞧!cocos真是把我坑惨了!
---------------------------------------------------------------------------------------------------------------------------------
再次申明,请拿cocos2d-js或者JSB的大作出来,不用拿2dx的东西。说到2dx,你们再去了解下,榜单上,有几个人是没改过引擎源码的,有几个游戏能随着cocos引擎升级而升级。用studio的又有几个。并不想和王哲斯逼,只是希望你们能正视BUG,提高体验。如果好,我们团队会考虑cocos技术的,否则只能用egret和unity3d了。我说cocos这么多不是,也是希望他成长,能给开发者带来更多利益,带来更多方便,而不是各种无厘头的问题,各种蹩脚的手段去开发。还有,我说的这几点,@王哲 你接招,如果我不说出这些BUG,这些问题,那么估计还不一定改。egret同样有个人叫王泽,然而他的理念完全当我们开发者是用户,提高开发体验,这个很重要的。 引用1楼袁浩的第一句话:如果大型游戏,强烈建议不要使用cocos2d-js或者cocos2d-x。

这张截图是我现在泡知乎立刻截的AppStore中国畅销榜前五名,清一色基于cocos2d-x引擎开发。不知道只在知乎上发过一个贴子的袁浩同学是如何定义「大型游戏」的?
egret 和cocos2d-x-js哪个目前更稳定更好用? ?
抛开榜首游戏不谈,我手里最近3个月国内上线的手机游戏情况。
egret 和cocos2d-x-js哪个目前更稳定更好用? ?

事实胜于雄辩。

另外,袁浩说的所有技术问题大约70%我接招。回头安排技术人员改去。

引用有一层楼匿名人士的评论:有些内幕如果知晓的话,一般人评判起来会毫不犹豫地选择Egret,至少安心~


只能说你的内幕太不值钱了。我这边的内幕是,cocos2d-html5核心人员之一离职,再带走我引擎组两个骨干,用cocos2d-js做刀塔like的游戏,后面由于代理的原因被强制改成egret引擎,白鹭对此游戏寄托无比厚望希望称为切入重度游戏的标杆,结果7月发布,8月公司解散,现在这波人又用回cocos了,原因不明。

其实我根本不想和白鹭撕逼,在原生游戏时代cocos和unity火拼的最后结果是谁都没得到好处。至于说cocos不适合开发大型游戏,抱歉了我只好piapia打脸了。
Label berkaitan:
sumber:php.cn
Kenyataan Laman Web ini
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn
Tutorial Popular
Lagi>
Muat turun terkini
Lagi>
kesan web
Kod sumber laman web
Bahan laman web
Templat hujung hadapan