我是程序,对creator比较熟悉.
在以往的工作中,大部分都是使用creator进行UI拼接.
最近项目要求使用FGUI进行UI拼接.
可能是因为熟悉creator,对FGUI不太熟悉,所以过程比较痛苦.
FGUI痛点:
1 官网教程文档不详细
2 论坛不活跃,遇到BUG或者问题得不到反馈和建议,而且谷主的回复通常相当的傲慢
3 居然要收费,比如spine的属性需要会员,用是给他面子,居然要收费.
4 只专注于界面,不能与代码绑定,不像creator那样可以绑定代码组件默认执行一些奇葩的行为.
5 如果我需要一个空节点来作为容器动态挂载其他节点,在FGUI上需要很奇葩的操作
6 组件嵌套逻辑，反祖.比如做个按钮你得先建“组件”，再往里塞“控制器”，改个状态还得切七八个面板
7 布局系统，堪称时间黑洞.Creator的自动布局多香啊，一行代码动态增删节点，自适应美滋滋。
8 动画编辑器，梦回Flash 2004
9 代码生成，脱裤子放O. Creator的UI预制体挂脚本，this.xxx直接访问节点. FGUI得寻找到节点,在as XXX 再xxx
10 资源管理，薛定谔的包体.你删了图，它不报错,打包时候突然暴毙.
11 如果做多语言,得用分支,而且多语言的资源全打在一起,多语言文本不复用.不像creator做多语言完全可以做成多语言的bundle,而且还可以动态切换默认语言的资源引用.
还有很多逆天设计,不再赘述
用了FGUI再回头看Creator的UI编辑器，简直像痛失初恋。
所以我一边用FGUI,一边在想为什么很多公司都在用FGUI
想来想去大概只有一点,想把拼UI的苦力活扔给美术.
但是我见过的很多团队,即使使用了FGUI,依然是程序在拼UI.
所以我就在想,美术拼UI到底有哪些问题
1 UI的层级,结构,复杂一点的表现,不是简单的controller能做到的,通常跟层级,结构关联比较大.但是美术在拼UI的时候往往只注意效果,不会去理解执行,也就不会注意层级和结果.
2 命名,美术命名通常乱七八糟,或者不命名
3 动态加载,完全交给美术,基本上不太可能
4 沟通,很容易相互扯皮,互相埋怨
5 性能问题
所以我又在想,如果交给程序来拼UI,会有哪些问题
1 人力浪费,通常程序的工资比较高,让高工资的人来做UI被认为是浪费人力.
2 审美偏差,程序通常注重运行,美术效果次之,能用就行.而美术对视觉和节奏更敏感.
3 效率,因为叠加了运行逻辑,所以拼UI需要话更多时间去考虑UI
所以我又想,能不能请一个人即懂美术又懂程序的人来拼UI
谁? 谁愿意? 既懂美术又懂程序的人就只为了拼UI?
我之前有家公司,是让美术在creator里拼UI,程序再代码绑定,遇到一些问题
1 沟通
2 层级/结构
3 文件冲突
由于creator的组件化,天然的适合程序来拼UI.
所以,我认为creator应该着重解决团队合作问题,解决如何让美术/不懂程序的人来拼UI.
或者我想问问大家,有没有什么好一点的办法解决拼UI的问题?
如果creator能解决团队合作问题,FGUI赶紧死!
