实体-组件-系统框架的最佳数据结构

Question

我已经阅读了很多关于实体框架的内容，现在我想在我的游戏中实现它。实体框架基于使游戏实体成为组件的简单容器，其中组件包含实体的特定特征（以及描述该特征的所有变量/访问器）。 然后通过创建系统将游戏逻辑模块化。每个系统都实现并运行游戏逻辑的某个方面（例如碰撞、渲染、动画）。每个系统必须能够访问具有某些特定组件组合的每个实体（例如，RenderSystem 必须仅获取具有 PositionComponent 和 AnimationComponent 的实体）。

我的问题是关于实现此类功能的最佳数据结构。

我目前的想法是创建一个实体列表的向量（包含 N 个单元，其中 N 是可能组件的数量）。所以每当我创建（实例化和添加某些组件）一个实体时，我也会从每个列表中为它包含的每个组件引用这个实体。 “杀死”一个实体需要从每个列表中删除每个引用。问题将是查询哪些实体必须由某个系统处理，因为搜索键将是组件的组合，而不是单个组件，这增加了操作的开销（许多搜索和必须进行比较）。

我的想法好吗？我可以使用更好的数据结构吗？请注意，游戏中的所有内容都应该是一个实体，在一个关卡上总计有数千个实体（我可能会使用一些空间分区）。

Answer 1

它们是两种方式，

纯粹的面向数据的系统将导致您没有实体类，而只是共享一个 ID 的组件。在这种情况下，每个系统的向量或哈希图都不会成为问题，因为在这些数据结构中的搜索速度很快。如果您希望每个实体的每个系统有多个组件，您可以将组件聚合到一个适用于每个系统的数据结构中。

问题在于，与更实用的方法相比，纯面向数据的系统的可用性更低，在这种方法中，您保留了前面描述的系统的所有功能，但保留了一个实体类，该实体类包含对其组件（或聚合组件结构）的引用每个系统的。处理一个实体（删除或检查它）变得更加容易，因为您仍然有一个地方可以在一个地方找到关于实体是什么的所有信息，即它是由什么组成的，而不是它处于什么状态，可以在一个地方找到而不是查询每个系统。

在您的情况下，最好的办法是尝试...以两种方式实现粗略引擎非常简单快捷，一旦您使用了这两种方式，您就可以决定哪一种套件你更好。

Answer 2

This article 很有价值，因为它建议对数据结构进行 4 次迭代，但在我看来，没有一个是好的解决方案。但我建议阅读它，因为它对问题进行了详细的分析，对内存进行了很好的估计以及其他很好的材料。