0

我使用 ecs 有一段时间了，但有一个问题我找不到一个很好的、主要是通用的解决方案。有一组类型，其中最多一个应该与一个实体相关联。前任。有一些触发逻辑。可以在通常的并行迭代中一次评估所有触发器（具有相同类型）。一切正常，但在单个实体上设置多个触发器是没有意义的。现在，我有各种清理和健全性检查系统（任务），在创建新触发器类型时必须始终更新这些系统（任务）。(编辑在更新时，我指的是源代码而不是运行时。）在传统的 oop 中，这将是微不足道的：将每个实体的单个指针存储到基本类型，派生并实现新的绑定器，仅此而已。在 ecs 中，它们存储在不同的存储中，我没有一个好的解决方案来确保对它们进行某种互斥。

感谢您的任何建议。

4

1 回答 1

1

我有各种清理和健全性检查系统（任务），在创建新触发器类型时必须始终更新这些系统（任务）。

...

在 ecs 中，它们存储在不同的存储中，我没有一个好的解决方案来确保对它们进行某种互斥。

我个人喜欢让实体系统在实体的组件列表因任何特定原因发生更改时通知组件系统。这样做的好处是，它允许系统随后能够构建并保留最适合其需求的内部数据结构，以跟踪游戏循环更新阶段快速高效处理所需的任何组件状态。

有了这个，我将创建一个TriggerSanityCheckSystem维护一些数据结构，以跟踪实体是否具有现有的触发关系。如果是这样，该系统要么抛出异常，要么以某种方式禁止向实体添加新的触发器组件。如果系统检测到实体没有现有的触发器，它将注册正在添加的新触发器，可能是它的类型，然后继续前进。

这TriggerSanityCheckSystem将在任何其他触发器系统之前运行，以保证您在允许组件逻辑执行触发器之前需要的互斥性要求。

更新

这里可能有更好的方法，我只是不确定它是否适合您的设计。在您最初的问题中，您提到了以下内容：

在传统的 oop 中，这很简单：为每个实体存储一个指向基本类型的指针，派生并实现新的绑定器，仅此而已。

如果你能做到这一点呢？这里的第一个问题是这些触发器有多个实现，但每个实体应该只允许其中一个实现。如果互斥性是由实际的组件实现本身驱动的呢？

struct TriggerDelegatingComponent 
{
  BaseTrigger *delegate_;
}

这里的目标是您拥有一个管理此组件类型的单一系统，并且它限制只有一个组件实例的实体，并且该组件将逻辑限制为单个触发器实现，从而消除了对这些健全性检查的全部需求。

在这种方法中，您可以将 ECS 和 OOP 两全其美。

于 2019-05-11T18:53:22.323 回答