【如果让我从头做一个引擎，我会怎么做？】

説真的， creator 又发展了多少年呢（我们不考虑2dx， cocos-js）？10多年前unity 也是被很吐嘈就是个估小游戏的引擎， 到现在可以做出老头环， c#也被吐嘈冷门性能不好(window vista 就是c#搞出来的)， 到现在呢？
未来用cc做大型网页游戏可能存拟， 但中型真不好説。

以前是C# 不支持linux 冷门， unity刚出来的时候那时候游戏引擎都没怎么有，只有flash, unity 利用1两年的时间证明了不是小游戏引擎， 而cocos 都发展10几年了还是没有进步啊 ，这就是差距

又要开始了吗，github上pr 或者issue一个不提，催牛逼头头是道

你这説法不对， unity 初版推出的时间是05年， 我指的是10多年前unity 开始进入天朝视野是14年左右， 也是unity 3至5时期， 那时unity 也是被吐只能做小游戏， 看仙剑当时被吐为啥拿个小游戏引擎做， 所以你把creator 1.0 的时间开始算起， 完全是发展短一方。至于2dx就不别算了， 赛道都不一様了

谁点的

我只是想说大家吐槽归吐槽，有能力的可以多提点优质pr，造福大众 别藏着掖着

好比如打工人，干的多，错的多，骂的多，干的少，错的少，骂的少，不干就不犯错，也不被骂。除了Cocos之外，有很多开源非商业的引擎，这些引擎用的人少自然被骂的少，甚至无从骂起，反正爱用不用。我觉得商业的引擎一定要收费，只有产生收入才能良性循环，收了用户的钱，自然就认真听取用户意见了，有了收入就有动力去改进，如果一款引擎因为收费而没人用的话，那这款引擎就没必要继续存活下去。

那是因为别人C#都可以编译成C++ 你js 还是js 还不支持jit 是一个硬伤

js和c#有着本质的区别，一个是解释型语言 解释型语言就需要频繁的内存交换 ，一个是编译型强类型语言，说白了，你可以unity发布可以把c#全部转换为c++，但是js你却不能把业务代码全部转为wasm，这也是为啥unity 很少有人拿js来写业务逻辑的主要原因。技术路线问题，语言决定了它达不到这个高度，js最大的特性是异步，换强类型编译型语言，在发布到web端的时候转为js 这样才是靠谱的，既能保证原生性能，又能保证平台兼容性。而且游戏大多数时候的瓶颈就是在cpu

还想着强类型语言转为js， 説出这句我都想你是否刚接触程序， 两种语言特性不同的情况只要有一个两边结果不相同， 你是排查js问题还是排查强类言语还是排查转化底层部分？如果你搞过unity 发布web就知道那个坑是有多深？把全部压力都压到开发方身上？我已説过h5做大型游戏可能存拟， 但中型确存在极高可能。 我也提过基于v8的js引擎改为主力服务于webgl的js引擎， 从中去掉一些浏览器通用处理， 类似微信高性能模式下以v8先编译js脚本， 然后在jsc执行达到jit效果， 这性能表现下发展下去你敢保证做不了中型的游戏产品？你要知道现在是微信限制游戏体量， 如果是自家公司独立app呢？
如果你是搞技术的， 有了解过几年软硬件之间的发展， 都不会説出这种完全否定的事。

说话不用带攻击性，因为我现在就在做强类型转js 没有你想的那么复杂 就是两个语法树的转换，处理平台兼容性就行。

语言特性都是可以通过接口适配的 就比如lua的索引是1 js从0 这些都是小问题 可能你没有认真思考过问题

吓死。差点以为又要去学一个新引擎

你可以去了解下语法树ast 做映射就可以转了，泛类型是没法转强类型语言的，只能从强转泛，或者强转强， 你能说出这话 说明工作经验还差点儿意思。

当观点有冲突时，不要试图去说服一个陌生人去接受你的观点，注定是徒劳无功的

也是 不讨论了不划水了 以免引战

编辑器是肯定不能开源的，不然会分裂社区，会多出像quick-cocos2d-x, 之类的，搞得N个人有N+1个Cocos方案。

你真想多了，

下班了，瞎说几句。
cocos 引擎最大的问题是啥？不是语言，不是技术。
是商业模式！Cocos 引擎能赚到钱吗？
赚不到钱怎么能可持续发展?！

请恕我孤陋寡闻，我真没听说哪家游戏公司付引擎费用给 cocos。

用Cocos赚钱了的游戏老板，忙着换车，换房，没有回馈生态系统。