哟，难得看见你
毙下给我请安
tgx 核心不是框架
像我都是取各家框架精华为我所用，然后拔D无情
命名方式太多了，之前有做过一个尝试，就是把节点名，美术名，代码变量名都是用下划线分隔单词的命名风格，感觉这样也挺好的，跟常规的英文长句子阅读类似更贴合实际
一个人想咋写咋写 你就算把代码全压在一行里写都行 
作为工具库，还是选择最通用的比较好，这样别人才不会因为不统一而反感(已经有很多人吐槽了)
个人的话就随意的
子弹这种需要用框架的UI来管理吗?
我理解的是框架的UI应该更多的是用来管理游戏中的界面弹窗,而子弹这种应该自己实现一套管理方案.
如果可以创建重复UI,那么打开一个设置界面,在设置界面再打开设置界面,这时候是展示2个设置界面,还是去重只展示一个?
重复弹出ui 还是有 需求空间的, 比如通用提示 之类的
这种走可配置呀
贴脸开大，是个泥人对你都有意见了
任何一个框架，总有不完美，甚至不完善的地方
说实在的，基本老鸟不太会直接拿别人框架直接用，总有自己的心得积累，而且真的是不同的项目适用的框架轻重度也不一样
估计是接手了其他项目用了这框架忍不住开炮了，这还算有框架，有点规范的，对于接手的项目来说，这已经算不错的
个人接手过目过太多项目了，但凡项目组织结构一眼看过去清爽，有点条理章法的，我都谢天谢地，其他的就不苛求了
你可以自己控制，也可以用框架管理，而不是完全不支持，更何况游戏中必然存在打开重复 ui 的情况
在我的设计中，ui 不只是弹窗，而是游戏内的所有 ui。如果你喜欢处处都是限制或者改框架，那说明这一类框架适合你使用
另外自行实现也无非是添加预加载，对象池逻辑。而 mk 的 ui 管理直接支持，无需自行实现
这样的，我认为他说的核心点没什么问题，重复UI确实有很大的需求点，例如那种弹出冒泡提示，或者是界面中重复的子组件等。
不过他的例子不对，不应该举子弹为例子，子弹是属于核心玩法/战斗里面的，应该是另外一套场景渲染物体（或组件）机制（Display Object）来管理，包括绘制，动画等等，抽象基类以便2D与3D都可以适配。场景渲染物体和UI管理在功能着重点上区别还是挺大的。
你是打算出两个版本吗，驼峰和下划线分割我一直都好纠结，驼峰有时候想让部分单词简写看着好不舒服
在学unity的ECS，虽然结构上做到了ECS，但没实现ECS的核心功能-----------性能提升
我草，3000 啊，，
笑屎过去了哈哈哈
去年的项目用的oops，当时用下来感觉一大堆问题，让我严重怀疑这是一个才做出来的框架，结果被告知已经很成熟了。后来，我甚至还给官方更新过一些资源管理上的明显的错误（之前版本的资源还有音效，是不支持非resource以外的bundle管理的，导致我希望拆模块一堆依赖完全做不了）。现在看老哥这么一提，我觉得我大概是被骗了
tgx写的 嘿嘿