ScrollView为啥不加一个addItem()的接口呢?

现在要ScrollView.content!.addChild(item),用起来太费解了,新手都不一定能正确找到地方,从直觉来说,应该在ScrollView上加上addItem(item),把上述代码包装起来,本来这个组件就叫ScrollView,不应该去操作组件里面的content

引擎只提供积木,如何搭建是用户的事

1赞

我这个问题是提给官方的,以一个使用者的使用体验提出的建议。
另外,你这句是万能的废话,同理引擎应该删掉ScrollView组件,毕竟引擎提供的积木已经够玩家自己搭建一个ScrollView出来了

我觉得 content.addChild 挺好的, 意图明确.

addItem 一方面不一定适用, 毕竟 content 一定是装 item 么? 很多组件并不添加 child (比如 content 可能只是一张简单图片 或者 其它自行渲染和改变尺寸的组件)

另一方面, 额外的 api 增加维护成本, 用户可能对这个接口产生错误假设, 以为里面有什么 magic 发生.

赞同!很多cc writer都是经常说fei话的

有一定道理,但游戏用ScrollView主要是用来做背包类的列表吧,通过ScrollView.content.addChild()还是有点反直觉,主要是我用Creator这么多年,最近开了个空工程想写个背包,获得了ScrollView一时竟忘了怎么添加item了,直接的接口没有,百度和论坛都没有解释,文档也没有使用的例子,最后只能翻以前的项目和捋一捋逻辑才搞定
作为一个做了很多Creator项目的老用户,一下子卡壳了说明这个接口也许有一定必要性,至少很不直观,可能官方出一个专门做背包类的ScrollView组件更好吧,毕竟这是个游戏引擎,而且github上有非常厉害的开源的ScrollView组件,可惜到3.x维护跟不上了,不如官方收编

我想你指的是缺少 ListView 啥的, 提供虚拟化支持的列表. ScrollView 更多是作为基础设施吧.

如果多说废话就能成为 Writer,我想论坛人均都是 Writer 了吧?

但写背包类的游戏常见UI,基本都是直接拿ScrollView在content上套个Layout来实现吧,性能差还不直观,这种组件应该作为一个游戏引擎的基础设施存在会好点

那么为什么 ScrollView 不直接配齐循环列表,只加一个 addItem?

诸如此类,为什么node上的size放在了uiTransform,node的opacity为什么放在了uiOpacity,我想都是同类型的问题,为了简化接口,让用户不难理解,addItem可行,但是保不齐后面有类似情况的组件,难道每个都封装个快捷api而不使用通用接口,这会造成什么问题我想大家都明白吧

你这个就是面向接口编程,而不是面向需求编程,任何的实现最终都是面向需求编程,而不是无意义的一开局就整10个接口,为了接口而接口真的很恶心

表面上是精简,其实说白了,就是cc经验不足导致考虑不到位,没用过自己的引擎api来实践中大型的游戏开发,难道你没听说过开发游戏引擎的人很少用自己的引擎开发商业级别游戏吗?unity就前几天才用来开发了属于自己团队的第一个游戏。。。你以为。。。

引擎接口设计都是有自己的一套规范,而且接口肯定是越少越容易理解对新用户越好,但是接口少也会导致像楼主这样的问题,所以在接口定义上,肯定会选择付出少量代价就可以省去一个接口的操作

通用是相对的,游戏引擎就是为了游戏业务特化的,为了设计而设计显然是舍本逐末,UITransform和UIOpacity抽出来就是没有以前方便,这是为了设计而弱化开发便利性,但凡能不分离出来就不应该分离出来,我相信这是引擎组的无奈之举而不是有意为之。
而如果是本来可以不分离而故意分离已配合某种设计理念,作为开发者我只能感到遗憾,确实没有以前方便,同样的理论也可以把rotation分离出来成UIRotation,scale分离出来成UIScale,甚至position分离出来成为UIPosition

1赞

这个我相信不久的未来就会去除,目前应该是无奈之举,不信你翘首以盼

这个我也不喜欢,至于会不会就看引擎组的人,我们都说不上话

1赞

同意你的看法

至于你句话我不太赞同,你可能没明白官方为什么这样做,我个人觉得就是因为 node 属性太多太杂乱,1不利于后续维护,2对新用户不友好,一个点出来一大堆提示。划分标准我觉得是按照大体分类进行划分,而不是你说的一个属性划一个组件,这样划分有什么意义?uiOpacity之所以只有一个opacity,我觉得这才是无奈之举,label 有 color,sprite 有color,但是空节点不需要color,只需要 opacity,可能就是因为这个才如此划分

你这话说得没道理,点出一大推属性根本不是问题,反而更方便,新人不等于傻子。
node有哪些属性唯一需要考虑的就是node是什么,如果是gameObject或者抽象的对应物质,那么位置,尺寸,颜色,旋转四个属性就能定义。
node是什么,就该有哪些属性,加加减减的核心问题在于说不清node是什么
另外我只是依照你的逻辑给出极端的例子,毕竟你也没给出拆分的标准
对象的设计肯定是先有对象的定义,然后才有属性,并不是根据“大体分类”,定义不严格,后期肯定变得混乱