ccc ide只是看起来现代吧。
比如现代前端，也很少使用可视化的进行编辑。
并不能证明ide强大就好吧。
何况ide设计的感觉对程序猿也不友好。
拖拖拽拽，对资源管理感觉不是很友好。
如果资源管理完全依赖ide，又会造成ide越来越笨。
本身人家不适合做，你们强行来做的，一般用这个都是web套壳的exe，这个不能怪electron
你想错了，项目用unity，策划，美术必须安装。
啥时候iOS和web性能一样，就已经达到要求
为啥？
字数字数
没有为啥，因为需要。就像做tiledmap一类的需要装一样
这也是客户端技术决定的。
比如地图并不需要装unity而只需要装tiledmap。
我可不想美术、策划能直接通过unity动客户端的项目仓库，鬼知道他们会搞出什么事情
我也觉得奇怪，为什么觉得creator需要嵌入tiledmap呢，作为一个外部工具不是挺好的么，
用unity做游戏，所有得工具链，都基于他扩展，你估计不是用unity开发，不懂
策划，美术，都要用unity去调试数据，或者效果，你不安装，你当老板啊？
美术能不能动仓库，是可以设置权限得，不会用得，只开只读权限
1、我是cocos、unity、windows开发，你猜错了。
2、策划调试数据用excel导表给客户端包（exe/apk）调试。
3、美术用ps、spine editor、3dmax等工具，或者用专门的特效工具开发，当然可以安装unity来辅助看具体效果。或者用具体项目组开发的工具查看更好，不一定是unity。
美术只有美术svn，策划只有策划svn。程序有自己的git，各自没有对方仓库的任何的读写权限。
美术产出png、模型文件，策划产出表格、文档，客户端程序产出具体的包（apk、exe等）。
只有这些产物才能相互交流查看。
首先嘛，我觉得现在是讨论，不是谈论怪罪人，而是我们希望更多的是优化编辑器，不说其他3D问题，3d可以慢慢来，但是迫在眉睫的是编辑器卡顿问题，别说大项目了，非常非常小的幼儿教育游戏小项目都一天卡死30+次，真的没有夸张，甚至说低了、。。。。可想而知，你们应该把工作重心放在这里。。。期待下
1赞
你们这种做法，策划每次做一点点调整都需要重新打包？
你们并没有将unity融入开发流程中去，用了unity写几句代码，真不算用unity开发（个人观点）
自动化，重新打包有啥问题？
另外策划能调整的是配置表，还能调整代码不成？
美术资源又不是策划调整的。。。
确实，才用unity做了4，5年，确实没有几百万行的代码的项目。（具体也没数多少行）
我们只是尽力不要去深度依赖具体某个引擎的开发流程。
尽量去将开发流程可以同时应用于unity和cocos
尽量去积累两边都可以使用的工具。
1赞
可以吐槽编辑器卡，支持的不完善。。但是搞不懂为啥要急着需求把tilemap 骨骼动画集成到编辑器里，用现成的不香么，集合进去让你少下载打开几个软件？
工作流不同吧。我们也做过重度游戏，策划需要重度使用unity，毕竟改个数值，测一下战斗平衡就要重新打包，这个效率还是太低了
对CCC的愿景就是重回2dx时代的手游份额