Dri*_*riv 5 game-engine entity-system
当存在共享或依赖的组件时,我一直试图围绕 ECS 的工作方式进行思考。我已经阅读了大量关于 ECS 的文章,但似乎无法找到明确的答案。
假设以下场景:
我有一个实体,它有一个 ModelComponent(或 MeshComponent)、一个 PositionComponent 和一个 ParticlesComponent(或 EmitterComponent)。
ModelRenderSystem 需要 ModelComponent 和 PositionComponent。
ParticleRenderSystem 需要 ParticlesComponent 和 PositionComponent。
在 ModelRenderSystem 中,为了缓存效率/局部性,我想遍历所有位于紧凑数组中的 ModelComponents 并渲染它们,但是对于每个模型,我需要提取 PositionComponent。我什至还没有开始考虑如何处理每个模型的纹理、着色器等(这肯定会破坏缓存)。
与 ParticleRenderSystem 类似的问题。我需要 ParticlesComponent 和 PositionComponent,我希望能够以高效/友好的缓存方式运行所有 ParticlesComponent。
我考虑让 ModelComponent 和 ParticlesComponent 每个都有自己的位置,但是每次模型位置改变时它们都需要同步(想象一下对角色的粒子效果)。这会添加另一个需要跟踪和同步组件或值的实体或组件(并且可能会否定任何缓存效率)。
其他人如何处理这些依赖问题?
降低复杂性的一种方法是反转数据流。
考虑您ModelRenderSystem
有一个侦听器回调,该回调允许实体框架通知它一个实体已添加到包含位置和模型组件的模拟中。在此回调期间,系统可以在位置组件或拥有该组件的系统上注册回调,从而允许ModelRenderSystem
在该位置对象发生更改时收到通知。
当来自位置更改的更改事件进入时,ModelRenderSystem
可以将其必须在更新阶段复制的修改列表排队,然后在更新期间,这实际上是一个简单的查找每个修改模型并将位置设置为事件中的值。
好处是,在每一帧中,您只复制该帧期间实际更改的位置更改,并且可以最大限度地减少复制数据所需的查找。虽然位置的更新传播到各种感兴趣的系统可能不太适合缓存,但您观察到的收益却超过了这一点。
最后,不要忘记系统不一定需要正确地迭代组件。实体系统中的组件允许您轻松切换可插入行为。系统始终可以管理更加缓存友好的数据结构,并使用上述回调方法,允许您以最小的耦合轻松做到这一点并管理数据复制。