引擎组的人接口api也是吃饱了没啥事天天改。每个版本都有接口名字不一样。
你们CTO吃干饭的吗，允许你们这样乱改。
就不能有点顶层设计，花一个月时间把所有接口名字都给定好了吗？以后接口只加不改不删，这样不就能兼容旧代码了，一点继承也没有。跟过家家一样的，脑袋一拍想一出就改一次名字。
这不是从2DX一直以来的传统吗 哈哈哈
跟我写代码有点像 哪天看着以前的代码命名有点问题就给改了 偶尔会出莫名其妙的bug 
他的意思是只增加不修改 这样久的版本也可以兼容 假如之前叫setPosition 后面想换成 叫 setPos 可以这样setPos 里面去调用setPosition 或者 反过来 假如后面命名的函数更加有意义别人也乐意用老的用一样没有问题 这样别人升级就比较容易
1赞
似乎很长一段时间，原生都不如浏览器跑web的效果，发热明显，真到上线估计要愁死
从年头到年尾，再给半年也不见得有戏
其实我有一点搞不懂为什么原生的会比 web差 按道理来说应该原生肯定比web好的才对
JS<–>C++ 来回传数据和JS端计算量太大导致的；各种渲染逻辑大部分都在JS端写，而且用的是类似unity这样的组合模式。如果是cocos2dx原来那样的设计模式 ，还好搞一点。
以前看到这个设计模式，我就觉得不靠谱，一直没有入坑，一直关注到现在。
如果要彻底解决问题，原生端我建议是重写，用C++，继续JS只写业务逻辑的设计思想。
他们已经开始慢慢在把那一块挪到原生端了 之前应该考虑的一套js代码兼容所有平台 维护成本低
小游戏感觉要凉了，有人能靠广告收入赚到钱吗？？？
cmake 这个真的是考虑欠妥，徒增复杂度而已。
希望以后能征求一下社区反馈，不要再自己拍脑子定了。
不用 CMake 的话，引擎版本升级后，老项目定制好的原生工程如何升级呢？
跨平台项目现在哪个不用CMake？连VS2022都超级强化了CMake的直接支持
1赞
lua都有这些问题，，，，只是可能不太突出你就没注意到。。。。
还有可能我接触的lua项目比较小吧 
我只能理解为你们可能不太清楚使用者的真正使用方式。
两年过去了 