我是怎么使用oops的?

这个帖子说oops有一些不好的地方,我看了一下,确实有一些有问题比如音频,这里也不引战,可能我没有那么严重的代码洁癖。
我们也是重度游戏,我个人觉得oops挺好用的,不过我也做了一些魔改,下面介绍一下:

  • 场景:单场景不好用,改成多场景
  • mvvm:做一个功能要建这么多文件,不好用,做app还行,游戏开发不适合,删除
  • ecs:我们项目也是重度战斗,自己另写了ecs,没有用到,删除;感觉框架的这套ecs不太好理解
  • 网络:我们也自己写了,删除,原版的没看,应该是实现了比较简单的网络功能
  • 声音:原版的功能比较少,用了原版的框架,但是加了一些功能
  • 屏幕适配:增加了对折叠屏的适配

其他还有很多小修小补,总得来说还是比较好用的,特别是比较重要的资源和UI模块
给作者点赞!

@dgflash

oops 我也参考过,一些模块的设计值得借鉴。

但是这里的点在于:【你觉得好】和【马赛克觉得设计有问题,建议别人不用】是两个不同角度的人的两点观点(就像我们的歼十C感觉已经落后,但是小国都觉得牛逼一样的,这是不同级别的人的看法)。主要他的言辞比较尖锐,写的东西别人看了不高兴。

请教下折叠屏适配咋弄

为什么单场景不好用

如果我全部说完,你们会知道每个系统没一个是成熟的,其中我认为最差的就是 UI 管理,音频只是其次

这才是一个正常的交流贴

这个官方文档有写,主要是监听window-resize

单场景明显不行,主界面场景和战斗场景,逻辑上就不合适,
还有引擎代码有一些清理,是在切场景的时候才清的

可以展开讲讲吗,比如主界面场景和战斗场景逻辑是什么角度考虑不合适哇,引擎代码哪些清理会有问题呢?

清理你可以看一下源码切场景时候做了些什么吧。
分场景的话,一般会分启动、登录、主场景、战斗,等等,然后在不同的场景上加载各种prefab。
我们是重度游戏,希望游戏逻辑简单,清晰好维护,不要把一个东西搞的太复杂

说单场景不好用的肯定是没设计好场景逻辑模型,我的多个项目使用单场景模式:主界面和战斗场景(核心玩法由战斗逻辑模型基类实现,派生不同战斗玩法类,代码简洁,扩展性强,维护起来很丝滑)

中重度玩法
我也是单场景,很丝滑

这个纯看如何设计了
单还是多其实都行

每个人设计思路不一样,做东西也不只有一种办法。只要游戏做出来稳定就是好的设计,单、多场景都行。

是的,关键看设计了

我基本都用单场景,主场景预先设置好场景树骨架与全局节点,其他场景以prefab的形式存在,加载时依附骨架。以业务逻辑(什么战斗,界面切换之类的)来说,这套结构完全满足,而且更灵活。

除非像Unity里面,必须依赖场景文件的一些光照设置,烘焙等,才会使用叠加式来做场景,否则基本上都用单场景。

作为框架,都应该支持吧,不应该提供一种选择

哈哈是的,场景树骨架说的很精确,丝滑灵活~

其实还是godot设计好,场景和prefab就是一个概念,那管你单场景还是多场景,本质上就都一样了。

这不一定,框架不是为了适应各种情况
框架的目的一般是做一些限制,规范开发

引擎才需要能适应各种情况

如果有人认为批评差代码不对,请你先去喷 Linux 创始人 Linus Torvalds