临近2022还有人选cocos2dx、cocos2d-lua、cocos2d-js吗？

Cocos2d-x
#41

我想creator 也是在努力的过程中，最终会把这块整合起来的。 从发展历程上看，creator 把 2.x 和 creator3D 整合成 creator 3.x来看， 他们已经完成了cocos引擎最重要的第一个历程，后面的路越走越顺的。个人觉得， creator3.x 才是 cocos creator 游戏引擎的真正开始。

#42

冥冥之中自有天意cocos2dx也是发布了3.x版本开始起飞的当然巅峰也终止在3.x版本，希望这次能飞的起来飞的久点:laughing:

#43

赞同这个看法，感觉3.4版是一道坎，这个版本功能上基本能满足轻度中度游戏产品的开发需求，我看引擎一般都是对着具体的产品，这个产品那个产品里的这个效果那个效果如果要做大致怎么样能做出来。

比如《斯派罗传说：龙之黎明》这个08年的产品，Creator 3.4在画面渲染，物理，粒子特效，后效等方面已经具备开发这种产品的潜力了，问题是能不能让引擎功能稳定下来，性能优化到相同大小的场景不卡顿。虽然参考的产品是08年的，但如果能在手机上能实现相同的效果，那还是很顶级的产品。

越过了3.4这道坎后面Creator只要整体使用稳定，性能给力，功能上就算弱一点也能自己造轮子解决部分需求，甚至可以在早期妥协一些效果来迁就引擎，引擎不具备的效果在创意和题材上可以进行一些避让，毕竟不是谁都开发什么高大上的产品，玩法好有创意的产品比如最近TGA最佳独立游戏提名里的《12分钟》并不需要高大上的功能特性。

如果3.4版之后引擎良性循环生态一旦培养起来，别的高大上的都是方案整合的事情。

2赞
#44

有志者事竟成，只要是真正的努力过程中，时间会证明一切的。

1赞
#45

这两天遇到的一个坑，0.1+0.2 == 0.3. ==> false，js这点可靠性都保证不了，真的不知道为什么要选择js
后来引入了decimal，但是拿出来的new Decimal(this.node.y)本身在动画中精度就丢失了，这里精度也是没法保证的，现在只能在decimal的基础上再自己写了个判断大小的方法，自己再处理一次精度，真的难受，当年用lua，各种基本的小数就算是判断相等都没得这些问题，js为什么就不能学习一下呢

1赞
#46

这是直钩钓鱼？

#47

CCC和unity相比，少了两个基本的东西，一个是地形寻路系统，一个是角色控制器。所以大型游戏根本做不了。

unity的地形数据可以直接对场景进行Bake,生成地图数据，寻路可以用NavMeshAgent，或者第三方的AStar Pathfinding插件，角色控制器有CharacterController。

ccc3.x这两个基本功能都没有，怎么做大型游戏。没有寻路系统，单有地形系统Terrain有什么用，摆设看的。没有CharacterController组件，玩家站30度的小斜坡都站不住，会受重力而自动下滑。

目前很多unity能轻易实现的东西，ccc都做不了，所以很多公司只要不是做h5游戏，基本都选u3d和ue。

6赞
#48

我不钓鱼，我喜欢直接拿炸药炸鱼

#49

最近几年跑了几个unity项目，加上一些朋友的反馈

  1. 国内unity大都是跑lua的，国外c#

  2. unity用c#，burst，navmesh，compressed texture一套下来，editor极其卡，米忽悠最近fps open world转ue了，不建议用unity跑大项目，原神是把unity改得连unity开发自己都不认识了，跟重写一个引擎区别不大

  3. 不要太指望unity的editor，这个editor的设计只适合小游戏，可以试试让它加载open world的主世界，应该能卡到精神崩溃

2赞
#50

你这个要求的标准就不一样了。。只能说你这些需求，不管啥引擎都难搞，都需要定制。

#51

比方说地编，如果到了一种地步就是editor完全跑不起来，要定制到只能用imgui做一个游戏运行时地编，上lod，运行时多线程加载，那用unity的价值就不大了

而且unity不知道为什么就很卡，也有可能是我们开发理解不透彻没用对。我这边上有一个700g的项目包括一个私有引擎，正常开发不卡。一个unity项目30g，一般一天有一半时间它在import，compile，不知道它到底在干吗

#52

这个问题跟Editor对资源的组织方式有关系，我也用过一些内部引擎，跟你放多少资源进去完全没关系，引用资源都靠路径，自然就不用import做啥事情。

#53

creator 重心放在H5 这就是弊病的根源
一个游戏引擎，底层的渲染代码重点就要放在原生（比如c/c++）上,这样才能最大限度发挥机器的性能。
至于跨平台（或者说是多语言的支持），那都在底层核心的基础上去拓展。

1赞
#54

把自动光照烘焙关掉就好了

#55

这是历史原因吧，以前都是搞页游，卡牌。以后都是元宇宙游戏，就算不是3D PBR渲染也要能支撑大场景，就会逐渐向原生上迁移。其实如果有钱经得起折腾了，后面可以成立一个团队直接搞typescript编译到原生代码的编译器，类似Unity的IL2CPP那样，性能就非常接近cpp了。

我之前在golang weekly中看到一个超屌的思路搞定golang2cpp转换，实现产品移植到Switch上。他先编译成wasm，然后把编译好的wasm binary转换成cpp代码(估计很像IL2CPP)，最后移植一个wasm runtime，虽然多线程能力不行，但产品至少无障碍移植成了原生的。

Typescript也能编译成wasm，顺着这个思路的话是有可能换一个角度解决原生代码问题。

https://blog.bitsrc.io/typescript-to-webassembly-the-what-the-how-and-the-why-3916a2561d37
https://javascript.plainenglish.io/from-typescript-to-webassembly-in-few-steps-c76f98f00632
https://www.assemblyscript.org/
https://developers.google.com/web/updates/2018/10/wasm-threads

5赞
#56

现在新项目用2dx lua cpp版本, 而不用creator egret laya的只有一个原因, 2dx lua cpp 版本无法被反编译, 代码很安全.

#57

如果你只是用cocos自带的话。。。能的哦，亲～ :upside_down_face:
52pk上面一堆教程，甚至还有一键破解工具，以前我也玩过这玩意。。。
以前有次我备份的代码被同事删了， 我就是直接反编译的更新包出来用的

#58

lua好像一堆反编译的

#59

别问，问就是开发者自己实现，
不会就是你菜，都开源免费的东西，还不满足 :innocent:

#60

你这是在钓鱼吧