那你们还是招一个懂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真的很轻松。
等啥呢
性能这一块能提高还是会考虑，感觉性能真的不友好
我们专做2D游戏，目前正在使用，下个项目肯定使用。
当前项目正在从U3D转成cocos，因为H5！H5！H5！
目前已经碰到几个问题：
1、tiledmap不支持45度角地图，起码js和c++支持度是不一样的。
2、还是tiledmap，层次遮挡的问题。这个我们通过将ObjectGroup里的Object创建出实体的cc.Node解决了，当然可能会引发Node数量导致的性能问题？
3、还是tiledmap，加入 camera，移动的时候，刷新会有问题，这个我们也正在解决。
4、ParticleSystem太弱了，对比一下u3d的，差了不仅仅是一个次元啊！我们正在引入可定制数学公式来引导粒子运行。
哈哈哈，是不是动画文件太多了，或者plist太多了。同款。后来把这些资源都放到动态加载才解决这个问题。
超级flag已收哈哈哈哈
祝creator从2.0这个新起点继续腾飞
在 CCPrefab.js
内部确实是 json
正能量满满 话说现在独立开发者还有活路吗?比较向往自由
没啥活路，好好打工
吐槽下:
1.发布的文件分静态和动态文件夹,且所有js文件合并成一个文件,文件管理没以前那样灵活
2.自己写开发调试工具没有creator内部api难以实现,比如 Editor.Ipc.sendToWins(“scene:reload-on-device”) 这api只能在内部调用 , 外部cmd调用不了
3.creator 写的插件启动速度慢
4.好处就是很ui多东西不用重复造轮子了
总结就是 功能丰富,使用卡顿,自定义不灵活
h5项目还是要用creator , 非h5项目就不用creator了
以上是以lua版作对比
您好
一个好的编辑器都有自己的代码IDE，现在cocoscreator主要是使用chrome进行调试 算是取巧了吧，但是这种方式真的是一个引擎团队长期的使用方式么？
Unity使用mono，好吧不跟untiy比，就算是白鹭这么二流的引擎 人家也是把ide 、编辑场景集成在一起，可以很方便的调试，最基础的查看运行时场景物体 这个功能cocos都没有。
一个没有自己的代码ide 的引擎，无论做的再好 也是一个有重大缺憾的引擎，试想下 如果有一天chrome不支持js调试了，那是不是意味着 这个引擎又进入到打 log的时代？
1赞