C++中的实体系统

Entity Systems in C++

本文关键字：系统 实体 C++      更新时间：2023-10-16

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

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

现在我想知道当Component添加到C++Entity时，如何实现自动Node创建？请告诉我识别可以从特定Entity生成哪些Nodes的原则，即您应该有聚合组件的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也被创建。因此，当我删除它时：

e.remove(new RenderableComponent);

应删除RenderNode。当然，这个过程不应该绑定到我定义的特定Nodes和Components。

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

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

实体和组件

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

实体组件的设计非常简单，您有一个类Entity，它接受多个类型为Component的对象。将有多个组件"执行"某些操作，例如MeshRenderer，TriMeshCollision或RigidBodyMotion。如文章中所述，实际逻辑不需要在组件本身中实现。该组件只是针对特定逻辑"标记"实体。将实际工作委派给系统中的紧密循环中完成是有意义的，甚至可能在不同的线程中，但稍后会更多。

然后组成实际实体。有两种基本方法可以在代码或数据中执行此操作。

例如，您在代码中组合表示一个"真实世界"对象的对象;类型为Goblin的对象存在，并且它派生自类Entity。然后，来自Goblin的构造函数将创建所有组件并自行注册它们。继承现在只对高级逻辑进行，例如，FastGoblin是从Goblin派生的，只有不同的材料和速度设置。

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

基于节点的工作调度

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

你的第二个链接描述的基本上是设计并行游戏引擎框架的拙劣版本

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

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

或者，系统、引擎或实体可以根据特定的组件配置创建节点。以物理学为例。实体具有TriMeshCollision和RigidBodyMovement组件。看到这种配置PhysicsSystem会创建一个RigidBodyNode，它将两个组件作为输入，从而实现刚体运动。如果实体只有一个TriMeshCollision组件，则PhysicsSystem将创建一个StaticColliderNode来实现该行为。

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

将此设计映射到C++应该是直截了当的。相当困难的一点是找出一种如何连接不同位的方法;例如，MeshRenderer如何访问RenderSystem以便提交其RenderNode。但这可以通过单例(颤抖)或在Entity或Component的构造中传递Game/Engine物体来解决。

这是好的设计吗？

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

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

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

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

参见

  • 基于实体/组件的引擎渲染与逻辑分离
相关文章：