遵循了ECS的基本规则，E就是纯ID，啥也没有，C就是纯基础数据，啥也没有，S就是纯业务逻辑处理，啥数据也没有。除了E/C/S 之外，还有 EM/CM/SM 三个脚本负责 实体管理、组件管理、系统管理，基本上都是实现一些实例创建、销毁、查询和实例间关系映射的功能（映射还是为了方便查询）
于是就有了一个很尴尬的情况，就是 entity 类作为一个中间桥梁，其实并没有太大的意义，entity 类实例一端关联着真实数据，也就是 component ，另一端关联着界面元素，也就是 Node，当需要通过修改真实数据去触发渲染系统更新界面时，总会需要多次查询，例如：
step1.改变了记录实体当前所在位置的 component 的值；
step2.发送属性值改变的信号；
step3.负责渲染的 system 收到信号后，先要去查一遍是哪些组件改变了值（当然也可以直接用事件参数传递过来），但总需要遍历这些组件，从组件找到实体，再从实体找到界面元素，再去改变界面元素的位置，这一步过于繁琐，至少需要遍历两遍，即使使用稀疏集或者链式调用都改变不了至少需要查询两遍的情况。
我就感觉很丑陋，非常丑陋，请问大家有更好的办法吗？

我也在godot用esc，但是用法和你不太一样。 感觉用ecs后，就不应该用观察者模式了，而应该每帧去遍历每个system，把每个entity都在system里执行一次。当然了，里面需要有各种不同的component，有的存数据，有的代表某个状态

godex好像是个ecs的框架？之前用过。ecs效率的本质是数据连续存储，遍历效率非常高，如果离了这一点那么ecs就是单纯的一种抽象思想了。而且ecs不适合ui，不要用来做界面。

我理解，E是最重要的怎么能说没啥意义呢？E里用字典存component，改值的时候，根据key获取改变的component，不需要遍历。
而且ESC是为了拆分数据和逻辑，系统一定会更复杂。这是不可避免的（总要有取舍）
拆分后更灵活，模块化符合单一指责，迭代优化的时候也更方便（都写一起改逻辑的时候很麻烦）

没有银弹。

我没看过这些规范。按照我个人的开发体验来看，就是需要实体字典。godot对象只有一个实体其它都是引用，可以很方便的用数据记录对象。

数据主要还是加载与保存的时候最重要，重要的是理清需要静态保存的数据在运行时的逻辑关系。

总之根据引擎特性，godot允许实例数组的存在且可以通过自带的查询查找实例。如果你将每一类对象单独保存到数组也可以快速搜索到目标对象。

需要模数分离的地方应该是需要严格监管数据的。可能伴随有复杂的权限记录与回档机制。

喜欢ecs用bevy