c++ - C++ 中的实体系统

Question

在游戏开发中，有一个实体系统的概念，旨在通过获得灵活的架构来简化游戏循环。有关详细信息，请参阅以下链接:

http://www.richardlord.net/blog/what-is-an-entity-framework
http://shaun.boyblack.co.za/blog/2012/08/04/games-and-entity-systems/

现在我想知道如何实现自动Node创建时Component添加到 Entity在 C++ 中？请告诉我识别的原理是什么Nodes可以从特定的 Entity 产生，即你应该有 Component 的列表和聚合组件的类。并且您应该了解可以使用数据列表创建哪些类。

例如我有 Components :

class PositionComponent
{
  int m_x;
  int m_y;
  int m_rotation;
};

class VelocityComponent
{
  int m_vX;
  int m_vY;
  int m_vAngular;
};

class RenderableComponent
{
  Sprite m_view;
};

和节点:

class MoveNode
{
  PositionComponent m_position;
  VelocityComponent m_velocity;
};

class RenderNode
{
  RenderableComponent m_rend;
  PositionComponent m_position;
};

现在，如果我创建一个 Entity像这样:

Entity * e = new Entity;
e.add(new PositionComponent);
e.add(new VelocityComponent);

然后我想要一个代码来创建 MoveNode自动，如果我还添加这个:

e.add(new RenderableComponent);

那我也想知道 RenderNode被 build 。因此，当我删除它时:

e.remove(新的RenderableComponent);
RenderNode应该删除。而这个过程当然不应该绑定(bind)到具体的 Nodes和 Components我已经定义了。

如何在 C++ 中实现这一点？

Answer 1

我有点困惑，因为它似乎混合了概念。我将尝试阐明这两个概念。

实体和组件

实体组件系统在游戏引擎中很常见，例如Unity就很明显地实现了它。试图解决简单继承在很多情况下效果不佳的问题，比如混合渲染和碰撞信息；是 Collidable还有一个 Renderable ?而且由于多重继承对许多人来说是一件可怕的事情，而且在许多语言中都不支持，唯一的出路就是实体/组件设计。 (实际上不是唯一的解决方案，但这是一个不同的问题。)

实体组件的设计很简单，你有一个类Entity接受多个 Component 类型的对象.会有多个组件“做”某事，比如 MeshRenderer , TriMeshCollision或 RigidBodyMotion .如文章所述，实际逻辑不需要在组件本身中实现。该组件只是为特定逻辑“标记”实体。将实际工作委派在一个系统的紧密循环中是有意义的，甚至可能在不同的线程中完成，但稍后会更多。

然后组成实际的实体。有两种基本方法可以做到这一点，在代码中或在数据中。

例如，您在代表一个“真实世界”对象的代码中组合对象； Goblin 类型的对象存在并且它派生自类 Entity .来自 Goblin 的构造函数然后将创建所有组件并将它们注册到自己身上。现在只对高级逻辑进行继承，例如 FastGoblin源自 Goblin并且只有不同的 Material 和速度设置。

创建对象的第二种方法是通过数据，即您拥有某种形式的对象描述语言。 (采用 XML 或 JSON 格式)然后这将在工厂方法中创建基于在此对象描述语言中定义的给定模板的内容。

基于节点的工作调度

拥有完全定义的对象但没有执行逻辑可能是有意义的。考虑服务器上或编辑器中的对象。在服务器上，您不希望渲染代码妨碍您。所以基本的方法是创建不包含数据的组件。要解决的问题是，如何在不迭代每一帧的整个场景并对周围的对象进行类型转换的情况下有效地完成任务？

您的第二个链接所描述的基本上是 Designing the Framework of a Parallel Game Engine 的拙劣版本

需要有一种方法来以有效的方式安排工作。建议的解决方案是让每个“节点”都执行特定任务。然后通过将节点提交给工作调度程序或特定系统来调度节点。

以渲染为例。你有一个实体，它有一个 MeshRenderer成分。该组件将创建一个 RenderNode并提交至 RenderSystem .然后当需要渲染帧时 RenderSystem将简单地迭代每个 RenderNode并调用其显示方法。在 display 方法中完成了实际的渲染。

或者，系统、引擎或实体可以基于特定组件配置创建节点。以物理学为例。该实体具有 TriMeshCollision和 RigidBodyMovement成分。 PhysicsSystem看到这个配置会创建一个 RigidBodyNode它将两个分量作为输入，从而实现刚体运动。实体是否应该只有 TriMeshCollision组件PhysicsSystem然后会创建一个 StaticColliderNode来实现行为。

但就像从数据构建组件的机制一样，节点也可以通过工厂函数创建并附加到实体。这可以是对象定义或基于规则的系统的一部分。

将此设计映射到 C++ 应该很简单。相当困难的一点是找出不同位如何连接的方式；例如，如何MeshRenderer可以访问 RenderSystem所以它可以提交它的RenderNode .但这可以通过单例(颤抖)或传递 Game 来解决。/Engine周围的对象 Entity或 Component .

这是好的设计吗？

但我想在这里解决的问题是:这是好的设计吗？

我对你的第二个链接(游戏和实体系统)有问题，因为我认为设计很快就会落空。对于物理等其他方面也是如此，但在考虑现代 3D 渲染时，这将变得非常低效。

当您需要在空间上组织场景以有效地剔除隐藏对象，将对象组织成批次进行照明并减少资源切换时，整个“节点列表”概念就没有实际意义，因为无论如何您都需要一个单独的组织结构。

此时，您可以让组件直接与系统“对话”，并且每个系统都有适合其特定用途的独特的特定 API。渲染、声音和输入的要求各不相同，将它们塞进 API 是徒劳的。

也可以看看

Entity/Component based engine rendering separation from logic