我一直在阅读很多关于实体框架的内容，现在我想在我的游戏中实现它。实体框架基于使游戏实体成为组件的简单容器，其中组件包含实体的特定特征（以及描述该特征的所有变量/访问器）。 然后通过创建系统来模块化游戏逻辑。每个系统实现并运行游戏逻辑的某个方面（例如，碰撞，渲染，动画）。每个系统必须能够访问具有某些组件组合的每个实体（例如，RenderSystem必须获得 具有PositionComponent和AnimationComponent的实体）。
我的问题是关于实现此类功能的最佳数据结构。
我目前的想法是创建一个实体列表的Vector（具有N个单元格，其中N是可能的组件的数量）。因此，每当我创建（实例化并添加某些组件）实体时，我也会从每个列表中为它包含的每个组件引用该实体。 “杀死”实体需要从每个列表中删除每个引用。问题在于查询某个系统必须处理哪些实体，因为搜索键是组件的组合，而不是单个组件，从而增加了操作的开销（许多搜索和必须进行比较。
我的想法好吗？我可以使用更好的数据结构吗？请注意，游戏中的所有内容都应该是一个实体，在一个级别上总计成千上万的Entite（我可以使用一些空间分区）。
答案 0 :(得分：0)
他们有两种方式，
纯粹面向数据的系统会导致您不拥有实体类，而只会拥有共享ID的组件。在这种情况下，每个系统的矢量或散列映射都不会成为问题，因为这些数据结构中的搜索速度很快。如果每个实体每个系统需要多个组件，则可以在一个适合每个系统的数据结构中聚合组件。
问题在于，纯数据导向系统的可用性低于更实用的方法，在这种方法中，您保留了前面描述的系统的所有功能，但是您保留了一个实体类，该实体类保存对其组件（或聚合组件结构）的引用每个系统。处理实体（删除或检查实体）变得更加容易，因为您仍然可以在一个地方找到有关实体是什么的所有信息，即它是由什么组成的，而不是它所处的状态，而不是查询每个系统。
在你的情况下，最好的办法是尝试......以两种方式实现粗略引擎非常容易和快速，一旦你玩了两个，你就可以决定哪一个套件你更好。
答案 1 :(得分：0)
This article是有价值的，因为它建议对数据结构进行4次迭代，但在我看来，没有人是一个好的解决方案。但我建议阅读它，因为有一个详细的问题分析，很好的估计内存和其他好的材料。