通过脚手架初始化好的项目,带了一个简单的 demo
框架升级很正常吧,就算不喜欢也没必要这样说吧,用自己喜欢的就好了。尊重每一个coder好吧,写出来的东西必定有其设计思想等值得学习的东西。
无缝切换我是不信的,除非引擎本身没有改动很大,说大话谁都会好吧。
你说这话我就笑了,自己看吧,不要用自己的能力对标所有人,而且3.7到3.8改动大吗??
https://github.com/1226085293/MKFramework
https://muzzik.gitee.io/mk-framework/
另外我框架一直没发布的原因是因为我自己还没用它做一款商业游戏,不想让用户踩坑
其中的大部分模块我都是在公司商业项目用过的,我不知道其他框架开发者怎么做,但是我绝对不会让用户承担风险
还是有的,Bundle的配置改了,你可以无缝的原因是,你在这块没有形成规范与自动化
所以你的意思是你自己针对 Bundle 做了额外的配置和工具脚本?那么你这个配置有什么额外的好处呢?
另外如果我本来能无缝切换,加了你说的规范与自动化之后就不能无缝切换了,那么我为什么要加你说的规范与自动化
淡定淡定,不要争论好坏,实现就在那里,根据需求选用。
精确到 3.8 也有好处。
不看好坏看什么?
大佬 你那个视频没声音 看不懂 能不能来个详细点的文档 或者有声音的视频
加群
所以这是设计哲学问题,在你眼里,无法达到你哲学的,你都不加,所以可以无缝链接,但在别人眼里不一定好。比如,walk方法,每个引擎版本实现都不一致,如果认为不加渲染自定义排序没问题或者你觉得这个破坏了你的无缝切换,所以不加,这没问题。但别人的框架,对这个又比较看重,就要加怎么办?要么if要么分版本呗。
除非是个极简架构或纯代码层架构,否则没办法不分版本。而这个作者,连创建文件夹都有要求,说明是一个限制较大的框架而且面向的是更偏向应用层的(即非API调用层面的),这种不分版本,要么框架搞得很臃肿,要么就是分版本。
看了你的框架,显然,你的设计是偏向通用性,所以是API调用型的框架(我个人发明的术语)
Bundle 还对它做操作了啊,这么复杂,,
在看。
- 没有License。
- 一上来task 就扔4个 类到脸上,看的懵懵 。
框架的内部实现会复杂些,实际使用上会一定程度的弱化你对Bundle的感知
这样连创建文件夹都严格规范的使用起来一点不方便
在团队开发中,我这边的感受是省了很多事。
你可以说出你的需求,ui音频限制路径对你产生了什么影响吗?
为大佬点赞
备注:目前已经废弃,使用BaseController(从代码看是规范化处理)
管理器位于assets/app-builtin/app-controller中。
比起一大堆个人《框架》
工作流、对引擎的理解还有正确的编码思维方式 才是最重要的