需要意见我的基于组件的devise

我有一个实体类和一个组件类。 实体类有一个附加组件的列表,每个组件也有一个成员variables,该variables是对它所连接的实体(循环devise)的引用。

然后,有EntityManager类,它有一个(你猜对了!)实体的列表,每个实体也有一个对其封装实体管理器的引用。

这种周期性devise的原因是由于数据依赖。 为了进一步解释,我的实体类实质上只是一个巨大的数据桶:实例化时,任何types的实体需要的任何数据已经存在于这个类中。 但是,为了使用这些数据,实体需要附加相关的组件。 例如,我的渲染组件将实体的spriteData成员和绘制到后台缓冲区。 没有渲染组件,spriteData不被使用。 由于我的组件需要访问实体的成员variables,所以每个组件都需要对它所连接的实体的引用。

例如,为什么我的实体需要引用实体管理器,这是因为某些组件(例如碰撞)需要访问其他实体的数据桶才能运行(对于碰撞,这将检查附近实体的位置向量并将其与组件的引用实体进行比较)。

除此之外还有更多的东西,但是我只想强调我正在做的事情的核心思想,并且想要一个像这样的周期性方法(只有很less的数据封装)是一个好主意。 也许我只是在过度嘲笑/耸耸肩。 关于如何引导devise的意见也将受到极大的赞赏。

实体系统确实存在多年,您的devise决定并不新鲜。 例如,看一下Artemis框架 ,或者我自己的实现 。

为了给你的系统提供一些反馈,我换一种方式来包装它。 你目前的做法是有一个实体类和附加属性。

class Property { }; class Entity { std::vector<Property*> properties; }; std::vector<Entity*> entities; 

相反,您可以删除实体基类,通过整数ID表示实体,并将相同types的属性组合在一起。

 std::unordered_map<int, SpriteProperty> sprites; std::unordered_map<int, PositionProperty> positions; 

哪个精灵对应于由id给出哪个位置,因此是整数键。 这种devise的优点是它导致了更多面向数据的代码。 要遍历所有的PositionProperties并更新它们(甚至可以并行地完成)比循环遍历所有实体并且每个更新其所有不同的属性要快得多。

使用ID来表示实体也有一个好处,就是你可以轻松地将它们存储到磁盘上,并将它们加载到系统中,而不会丢失它们的身份。