C++ 在游戏子系统中注册游戏对象组件？（基于组件的游戏对象设计）

我正在创造一个新的世界。一些提示：

GameObject

只是

组件的列表

有

游戏子系统

。例如，渲染、物理等。每个

游戏子系统

都包含指向某些

组件

的指针

GameSubsystem

是一个非常强大和灵活的抽象：它代表游戏世界的任何部分（或方面）

需要在

游戏子系统

中注册

组件

（当创建和组合

游戏对象

时）的机制。共有4种方法：

---

• 1：模式。每个

  组件

  都提供给每个

  游戏子系统

  <代码>游戏子系统决定注册哪些

  组件

  （以及如何组织它们）。例如，GameSubsystemRender可以注册可渲染组件

职业选手<代码>组件对它们的使用方式一无所知。低耦合A.我们可以添加新的

游戏子系统
。例如，让我们添加GameSubsystemTitles，它注册所有ComponentTitle并保证每个标题都是唯一的，并提供按标题查询对象的接口。当然，在这种情况下不应重写或继承ComponentTitleB.我们可以重组现有的
游戏子系统。例如，GameSubsystemAudio、GameSubsystemRender、GameSubsystemParticleEmmiter可以合并到GameSubSystems空间中（将所有音频、emmiter、render
组件
放在同一层次结构中，并使用父相对变换）

骗局。每一张支票。效率很高

骗局<代码>子系统
了解
组件



2：每个
子系统
搜索特定类型的
组件

职业选手。性能优于
方法1

骗局<代码>子系统
仍然了解
组件



3:
组件
在
游戏子系统
中注册自身。我们在编译时知道有一个GameSubsystemRenderer，所以让我们来调用类似GameSubsystemRenderer:：register（ComponentRenderBase*）的东西
模式<代码>组件订阅“更新”事件（由游戏子系统发送）

职业选手。演出没有不必要的检查，如

方法1

和

方法2

骗局<代码>组件与

游戏子系统

耦合不良

---

• 4：模式<代码>游戏状态（包含

  游戏子系统

  ）可以实现registerComponent（组件*）

职业选手<代码>组件和

游戏子系统

彼此一无所知

骗局。在C++中，它看起来像是丑陋而迟钝的Type ID开关。

---

问题： 哪种方法更好，并且主要用于基于组件的设计？惯例怎么说？对方法4（数据驱动）的实施有何建议

---

谢谢。

投票支持第三种方法

我目前正在开发基于组件的游戏对象系统，我清楚地看到这种方法的一些附加优势：

• 组件是越来越多的自给自足子实体，因为它只依赖于一组可用的子系统（我假设这组子系统在您的项目中是固定的）

• 数据驱动设计更适用。理想情况下，这样可以设计一个系统，其中组件完全由数据定义，而不是C++。

---

---

编辑：我在使用CBGOS时想到的一个特性。有时，能够设计和构造无子系统无源元件是很方便的。当您想到这一点时，第四种方法是唯一的方法。

我的方法是在每个子系统中实现代理模式。由于每个子系统只对每个实体可能包含的总组件的子集感兴趣，代理仅存储指向系统关心的组件的指针，例如，运动系统只关心位置和速度，因此它需要一个代理，该代理存储指向这些组件的两个指针。如果实体缺少其中一个或多个，则子系统将忽略它。如果两个组件都存在，则将创建代理节点并将其添加到内部集合中。代理还可以存储实体的唯一标识符值，以便在必要时可以在固定时间内从每个子系统添加/删除代理

---

这样，如果需要从引擎中删除实体，则可以向每个子系统发送包含实体id的单个消息。然后可以独立地从每个子系统集合中删除代理。

我同意您的看法，这些优势非常宝贵。但是第一种方法有另一面：项目之间没有组件可重用性（使用不同的

子系统集）。在单个项目中重新组合子系统也成为一个问题。可以有数百个
组件
，重写它们是一项繁琐的任务。我相信第二个优势也可以通过其他途径实现。同意你的观点。有一段时间，我被介绍使用CBGOS设计，但没有我希望的那么多。但我在处理这件事时遇到的工作让我考虑了以下几点：1。以最抽象的方式设计子系统接口，使子系统集在不同的项目中略有变化。2.最重要的是通过组件之间的消息交互，并在可能的情况下切断接口依赖关系。这可以解决问题。我在gamedev.net论坛上也遇到过使用这种方法的人。我发现将
组件划分为3个不同的hi非常有用