如果你已经用 Creator 做过项目，你们下个项目还会继续用 Creator 吗？如果不会，最主要的原因是？
请看题，为了不歪楼，不要在本帖回复你们想要什么，也不要长篇大论，有需要欢迎另外发帖。
下个项目正在考虑用呢·～
如果是2d游戏的话还是会考虑的
会啊…从0.7开始就入坑了…
目前最希望的是在运行效率和内存管理方面提供一些更稳健和有效的机制。
1赞
H5必选，原生还是会用cocos-js，小团队更专注产品本身，填坑担心花费太多精力
这一块的工作已经开始了，不过工作量很大，没那么快加强。目前已经完成的工作是，从 1.6.1 开始，用户可以启用所有场景的资源自动释放，一般不会出问题。（不过还只能释放场景载入的资源）
恩，目前我们用的是1.5.1正式版，内存管理资源释放什么的表现不如意，手动释放也挺胆战心惊的。等1.6正式版出来了换1.6试试。
1赞
2D类项目肯定会用，主要考虑：
- 之前使用cocos2d-js, 最大问题是UI的组织会浪费大量时间，Creator解决了这个问题；
- Creator目前已支持TypeScript，开发体验很好，大型项目也不怕；
- 后续版本性能优化正在进行时；
- 支持很到位，引擎组在论坛中很活跃。
之前一直在用cocos2d-js ,creator观望了蛮久了，现在正准备用1.6，要朝h5靠拢，编辑器不错，想想cocos studio的泪都还没擦干…
typeScript用起来，支持够好的话，对大型项目也是一大助力
如果前后端都是从0开始，我首选creator
不过由于历史原因，应该很多公司和我公司一样，服务器不支持websocket，客户端又有部分或全部代码是c++写的
creator对c++不友好，c++的项目，creator只能当编辑器，所以用不了
希望更多的公司用creator，我们也可以用creator做项目了
我说的对吗
这个可以通过其他途径解决，比如客户端心跳/服务器端心跳判断进行重连。
从cocos2dx 3.5开始使用JS开发我们公司的产品，目前的架构和自动化工具都是完善的，不太可能迁移到creator.
creator使用JS来做模块组合，感觉效率上面会比cocos2dx 低很多，个人觉得这样做不是正确的方式.
模块化当然很好，但是没有必要每个零件都是模块化出来。感觉是为了模块化而模块化。
（个人之见，勿喷）
除非,Creator能比cocos2dx 效率高很多，稳定很多，并且有本质上革命性的变化，才有可能去使用creator.
目前，一直关注，但不入坑。继续用cocos2dx JSB方式开发。
继续使用的几率更大, 毕竟开发了这么久, 有了一些积累. 目前正在攻坚内存管理部分, 如果这部分可以顺利解决的话, 那后面开发2D游戏应该会继续使用了.
个人感觉目前引擎的短板:
内存管理机制.
自动合并drawcall的机制.
Native非阻塞的预加载.
我觉得这两项是用creator做中大型项目必然会收到掣肘的部分.目前引擎提供的机制还是不够的, 大型项目必须自己想办法解决.
2赞
希望下个版本支持和提升下面的东西
- 对ECT2格式的支持
- 对WebAssembly的支持
建议专精2D方面的，做到极致！
我们会继续使用 Creator ，除非对高品质的游戏支撑无力（内存管理，性能问题等），希望能够像你们之前说的增加部分 3D 功能就会吸引更多游戏厂商选择使用 Creator 的，话说 @jare 你这么问不会是公司管理要解散这个项目了吧。。。
你想太多了…… 怎么可能？我只是在找痛点。
建议抢占2D和H5市场，不要盲目做3D支持，首先做3D会花费大量精力，2D自然就搞不好，其次再次强调，做3D真的只会选择U3D，等Creator把2D和H5市场吃稳，再支持3D吧。
7赞
Creator 不会做 3D 的，别担心。我们是有人在研究新的 3D 引擎，不过那和 Creator 没有关系。
1赞
表示用了很久，ws没什么问题。后端nodejs。基本做到了重连无感知
我觉得creator最大的问题还是性能上，现在的加载方式，在加载场景的时候，消耗了太多的时间，让人诟病