弱弱的问下,你们下个项目还会继续用 Creator 吗?

请问哈 project.js和setting.js怎么拆分?

今天已经是4.24,坐等1.10

什么时候开源 creator 的编辑器

你想多了,这个不会开源

主题有 [missing {{count}} value] 个回复,大约要花 4 分钟阅读。

unity开源了,保证就开源

不改代码也是,你切到别的窗口然后切回ccc,就卡了…

ccc提供了各种便利的功能和工具,作为使用者必须心存感激,虽然现在项目的很多问题还没解决,但是下个项目应该还是会继续用ccc。

功能很方便(除了上面提到的各种卡),性能没有准确用例的横向对比所以就不评论了,反正针对某些特定类型的游戏,引擎的某些实现是不适合我们的(例如微小改动导致重构整个渲染cmd队列的性价比就很低)。当然没有通用的完美实现,所以怎么样支持引擎扩展和修改就很重要了,强烈建议cocos源码用Typescript来写,反正能编译成js,引擎这种规模的代码量,js实在是不合适,相信换成TS你们团队的开发效率也会大大提升。

重点:期望看到内存管理的优化,现在没有看错源码的话,destroy是不会影响纹理释放的,目前的释放机制基于scene,没有引用计数和池,也就是做一些比较持续存在且变化的场景的话,就会崩掉,目前我们就遇到这样的问题,场景随着人物等出现和移除,内存慢慢就爆了。

另外就是现在很多人基于ccc做微信小游戏,小游戏上的gc问题很大,即使解除了纹理引用,并且内存总体占用已达4/500m,仍然没触发full gc,经常游戏就被系统杀进程了,据目前的观察,呆着很久才会发生一次full gc,在游戏内存的正常增长速度下,这个触发条件几乎总是太晚了,避免不了被微信或系统杀掉。希望cocos能针对微信小游戏进行优化。

3赞

得看公司需求了,如果要用3D的话,可能会跳引擎了

项目组从c++过来,js方面生得很。不用的原因很简单,东西太多太复杂,接受不过来,掌控不了。一开始两个方向都尝试了,最终放弃了creator。

那你们还是招一个懂js的人吧,js内容简单方便直接,在逻辑层比C++好用多了,只是你们自己没用好而已

我们之前的项目全部是c++的,包括服务器,17年11月份的时候全部转向Creator,TypeScript+VsCode。从人员的适应性来说,就是最开始的时候有些慢,目前都已经熟练,也没有遇到什么大的解决不了的问题。网络用WebSocket+字节流,服务器仍然是c++。

可能是年龄大了,吃老本,懒得学了

看微信公众号里C姐说计划是把3D内置到creator里面

毕竟不能什么都没摸索的情况下全员都转,对别人对自己都不负责。近两周刚开始。先踩踩坑,让其他后续进来的人能较快适应。

其实,选creator反而简单,一条龙,看看使用说明书就好了。反而从html5开始弄更有难度。年龄大,吃老本,懒得学?呵呵,不存在的。

还早着呢

只所以用cocos creator没有用白鹭,就是因为cocos的native有这么多年的积累了,王哲说白鹭的native性能不行。可是看了上面的帖子,cocos creator的native竟然很多坑,不稳定?

c++转js不要太简单,我只用不到一个星期就开始写项目,如果你c++足够好,理解js真的很轻松。

等啥呢