是的，最开始用ccc的时候脚本里所有的属性我都在编辑器拖，那时候个人游戏结构设计又差，最多一个脚本可能要拖几十个元素。编辑动画的时候很容易崩溃导致依赖的丢失，然后得重新拖，直接崩溃。现在我基本不用动画编辑器，能美术完成就美术完成，不能我就用缓动写，获取一些节点或者组件也是用代码，已经养成习惯了。
两种都是正途，只是适用的场合不同。
我们都不是小孩子了，不需要做选择。
全，都，要。
A：依赖编辑器
优点：通过可视化编辑，对于组件绑定和节点绑定的效率提升是非常大的，可以极大的提高生产效率。
缺点：多人协同时容易冲突，代码关系不直观
适用场合：
1、UI界面
2、不需要动态加载的对象
3、规模不大的项目
B：不依赖编辑器
优点：代码逻辑与资源分离的模式，可以使我们最小程度控制资源的加载粒度。特别是当一些资源需要动态加载卸载，但逻辑始终运行的时候。
缺点：需要自己构建一套代码+资源的驱动机制，许多地方需要自行做代码与资源的连接。
适用场合：
1、大型项目，多人协同较多的情况
2、需要显示与逻辑分离的对象
3、需要与服务器通信的对象
4、需要资源异步加载的对象（逻辑代码在资源未加载时就得运行起来）
8赞
大佬总结的很全面啊，
伸手白嫖党：大佬来个B cup的demo 
请教下这里是指的哪部分？
我个人开发大部分是用A，小部分代码用的B
一般UI用A游戏逻辑用B
实际还是看具体需求，如果未来改动不大的话游戏逻辑也会用A，毕竟小型项目用B开发起来实在太麻烦了
1赞
两个人同时修改一个场景，就冲突了
但是一般是一个人一个功能或者模块,动同一个场景的还是不多
难道用B方案就不会冲突了吗？
我入行时的主程跟我讲：脚本语言的可读性大于性能考虑。所以我是一直要求自己用b方案
这里应该是指冲突后不容易处理，但是b方案冲突后处理相对恢复容易一些
这个我赞同，我在公司项目里面在自定义组件里面加静态的 创建 和 回收 函数，和 new 差不多的意思，所以可读性除了不与 上层组件交互的组件外（例如 碰撞销毁物体的组件，或者listView工具组件等），基本是可以直接读懂的
同时修改一个场景就是前期规划的问题，如果只有一个基础场景，其他功能通过预制体来加载，完全没有这个问题；如果真的有增加，只要另一些人同步一下就行完成不会冲突。如果每个功能都放在场景上这个不是冲突问题了，这是设计上的问题了
接触到的项目基本都是混用的。
目前看来，基本上做好业务逻辑和数据处理分离，开发到同一个场景内容时和同事商量下处理顺序，及时更新svn或者git就没什么问题了。
而且现在技术选型选择用ccc的大部分都是中小游戏，工期都比较赶，资本都希望能快速上架（游戏爆火了再讨论更新维护），这种情况下A的可视化编辑就是唯一选择。（公司有钱能支撑整个项目开发周期内的支出当我没说）
ps.ccc的2.x还是很香的，至少我接触到的项目里遇到的问题大部分都能解决或者绕过。（原生忽略，项目基本是web或者包壳）
已经讨论这么热烈了，还要置顶干嘛呢？我想各方观点已经都很充分表达了，但未出现特别一致的结论，让子弹再飞一会。
我作为产品也肯定有自己的想法的，不过以官方立场说出来只会压抑大家充分表达的欲望。
实际上论坛里有多大量经过项目充分锻炼的研发，他们的意见其实站在用户立场是更权威的。
1赞
单一场景，功能全部怼成预制件，谁做某个功能在自己的预制件里随便造， 基本就不会冲突了
1赞
你们有没有像我一样的，连预制都没有，直接new出所有节点组件，包括下级节点，
我觉得预制每次还得再界面上面拖一下，有点麻烦，有时候默认的属性还需要在界面上面改一下，我都是在代码里面写好
完全抛弃可视化开发，只使用引擎 
牛逼坏了啊。