通用游戏UI管理框架的设计与实现

对于ui管理这一块,我一般这么处理:
ModuleInfo{
funcId:1001,
className: BagView,
resUrl:“xxxxxx/xxxx/bagView”//ui资源,
isModel:true,//是否弹窗
releaseType:1/2/3 //释放内存规则
rejectViews:[] //相互排斥的UI
}

UiManger
showWindow(funcId, data, isCloseOther)
closeWindow(funcId)

1赞

UI模块之间的关系就是普通的 M(model), V(view) 再加上事件机制刷新

我再说句公道话哈!我认为小项目也可以用框架,不管什么样的框架,也不管什么模式的框架,做框架的目的是为了让搬砖的底层程序员提升开发效率,我说白了能写框架的人,代码怎么写都基本上是有效率的,做框架是为了让小白能轻松上手做工。有人提到cocos自己的框架结构,我也就cocos举例说下,像我也是个小白,基本上coco的所有接口用cc.XXX就可以轻松使用了,基本上不用自己再去实现什么接口,做工的程序员也不需要去了解框架的结构和逻辑。如果一个框架被设计出来,提供了一些接口,但这些接口还要自己去实现,那就等于:我开了家店,货品清单价格都贴好了,客户来买东西时,对不起,我没货,你先帮我进点货再卖给你行吗?
所以,简单来说,能让小白轻松使用的,并且达到了项目规范的目的那才是好框架。不能让小白顺利做工的框架那不是框架,那是毒,那是坑!

2赞

我觉得CCC只需要良好的工具集,不需要框架,比如你写个全局单例AudioManager,内部把加载,释放,缓存全做了,小白要调用的时候直接AudioManager.play就完事了。UI也是一样,所有的UI其实都可以处理成弹窗,只不过有没有动画,是不是全屏,在哪个层级,能不能穿透,封装那么多有鸡儿用,为了用你的框架,还要去看你的规范,还要看设计文档,能做一个框架啥文档没有,让小白也能用,我就觉得框架是有用的。
已经是组件式开发了,就把组件发挥到极致。把网络,存储也组件化,提供几个便利的全局单例,NetworkHelper,StorageManager,AudioManager,AssetsManager,DialogManager,PoolManager,完事。不用插入任何新规范新模式,小白看名字就知道干嘛的,函数拿出来就能用,这样不香吗,文档都不用写,简单写几个注释就完事了

7赞

楼主开场说的,他想做得应该不是单纯的一个ccc的ui框架,想的是这套框架拿到其他引擎如u3d也能用。我感觉这确实跟ccc的设计思想相违背了。ccc最初的设计思想就是开源、自由、轻量化、组件化,这个框架确实整复杂了,感觉是要搭一个大中型游戏,然后后期可能还要换引擎?这种项目想想都可怕

跨引擎的框架,怕不是这么容易的。驾驭一个引擎都不容易,何况跨引擎。

项目换引擎是不可能的,除非是个人项目。
但在项目立项的时候,或者不同引擎的使用者,在考虑用框架的时候,可以多个选择。

跨引擎,是指不同引擎的开发者,或者开发不同项目的时候可以选择这个框架,并做定制然后,拥有一致的编码体验。

全局单例,好处是简单粗暴
但有考虑过
在分包中使用吗?体验如何?

昨天搞了一下分包
体验舒适,可以试一下
通用渐进式游戏客户端开发框架:EasyGameFramework持续更新贴

不复杂啊 其实就是整合数据不用全部放view里面

是我层次低了。。。或许理解是什么场景情况了。我感觉这种的东西一般小公司没什么用的,多用于大公司跨项目合作统一代码规范的样子。不知道大佬是不是这种想法

  • 说得挺好旳,我也曾经是小白。我也崇尚简单至上。拿来就用。

  • 但人不可能永远是小白啊。人总会长大的,会更深入了解。然后变成大白,尝试创作创造。

  • 我在尝试的时候,我也是出于需求,以及提高效率,提高能力的。但在H5游戏圈这类文章很少,Unity的更多。所以我就想将自己的经验和成果分享出来,给大家参考,交流。

  • 变成大白的小白们创作创造的东西,封装好了,给下一代小白。

  • 而我的框架,就是作为小白的我成长的成果,也可以给大家一个参考。

  • 大家都可以用我的框架简单封装一下或者参考我的思路自己造个轮子。

个人技术积累,个人技术中台。
公司技术积累,公司技术中台搭建。
这是我的设想。
小公司,也可以做积累,积累多了,不就成长了吗?

神仙打架……,那像我这种毕业到现在两年多都是自己写的,没接触过任何公司用的所谓的“框架”的,请问还有救吗????

道理是这个道理,但是小公司敢于搭建维护自己的框架的还是少,老板家里肯定有矿的那种。以前进过一个小公司,自己花三个月搭了个框架,后续也没人维护,都只拿来用。因为框架这玩意必然掌握在公司核心人物手上,而小公司,这种核心人物几乎没有。除非老板就是技术自己来搭来维护还差不多。

所以来一起交流学习啊,等积累到一定程度,有底气了。就可以拿出来用

同是菜鸟请多关照:laughing:

2.4以后都已经支持AB包了,写好了AssetsManager,一样解决问题,跟框架没啥关系。我觉得通用框架设计本身就是个悖论,最适合的还是工具集,脚手架,颗粒度足够细,足够灵活。

1赞

我回复错人了 哈哈哈

关于ABundle不能使用主包单例那个,是我说错了。抱歉哈:joy:
用工具集好还是用框架好,是个人的喜好和需求。

工具集更加确定,拿来就用,可定制性弱些。

而通用框架,使用前需要做些定制,但可定制性高,适应更多不确定情况,不同项目。

其实工具集也是框架,只不过是更确定的框架,带着约定和规范

好吧,希望你这个能做的更好吧,不要像之前的几个框架,都无疾而终了