OOP ECS与纯ECS

Question

首先，我知道这个问题与游戏开发相关，但我决定在这里问它，因为它真的归结为一个更普遍的软件工程问题。

在过去的一个月里，我读了很多关于实体组件系统的文章，现在我对这个概念相当满意。然而，似乎缺少一个明确的“定义”，不同的条款提出了截然不同的解决办法：

这就是ECS是否应该破坏封装的问题。换句话说，它是OOP风格的ECS (组件是既具有状态又具有行为的对象，它封装了特定于它们的数据)和纯ECS (组件是c风格的结构，只有公共数据和系统提供功能)。

注意，我正在开发一个Framework / API / Engine。因此，目标是它可以很容易地由谁使用它扩展。这包括添加一种新类型的呈现或冲突组件。

OOP方法的

问题

• 组件必须访问其他组件的数据。例如，呈现组件的绘制方法必须访问转换组件的位置。这将在代码中创建依赖项。
• 组件可以是多态的，这进一步引入了一些复杂性。例如，可能有一个sprite呈现组件覆盖呈现组件的虚拟绘制方法。

带纯方法的

问题

• 由于多态行为(例如，呈现)必须在某个地方实现，所以它只是外包到系统中。(例如，sprite呈现系统创建一个sprite呈现节点，该节点继承呈现节点并将其添加到呈现引擎中)
• 系统之间的通信是很难避免的。例如，碰撞系统可能需要根据存在的任何具体呈现组件计算的边界框。这可以通过让他们通过数据进行交流来解决。但是，这会删除即时更新，因为呈现系统将更新边界框组件，然后碰撞系统将使用它。如果没有定义调用系统更新函数的顺序，这可能会导致出现问题。存在一个事件系统，它允许系统引发其他系统可以订阅其处理程序的事件。然而，这只适用于告诉系统该做什么，即空函数。
• 还需要额外的标志。以一个平铺地图组件为例。它将具有大小、平铺大小和索引列表字段。贴图系统将处理各自的顶点数组，并根据组件的数据分配纹理坐标。然而，重新计算整个提示图每一帧是昂贵的。因此，需要一个列表来跟踪所做的所有更改，然后在系统中更新它们。以OOP的方式，这可以由平铺映射组件封装。例如，无论何时调用SetTile()方法都会更新顶点数组。

虽然我看到了纯方法的美妙之处，但我并不真正理解它比传统的OOP有什么具体的好处。组件之间的依赖关系仍然存在，尽管隐藏在系统中。此外，我还需要更多的类来完成相同的目标。在我看来，这似乎是一种有点过度设计的解决方案，从来都不是一件好事。

此外，我并没有在性能上相互关联，所以这个面向数据的设计和cashe错过的整个想法对我来说并不重要。我只想要一个漂亮的建筑^^

尽管如此，我读到的大多数文章和讨论都提出了第二种方法。为什么？

动画

最后，我想问一个问题，我将如何处理纯ECS中的动画。目前，我已经将动画定义为基于0到1之间的一些进展来操纵实体的函子。动画组件有一个动画列表，其中有一个动画列表。在其更新功能中，它将当前活动的任何动画应用于实体。

注：

我刚刚读到了实体组件体系结构是由定义面向对象的吗？这篇文章，它比我更好地解释了这个问题。虽然基本上是在同一主题上，但as仍然没有给出任何答案，说明为什么纯数据方法更好。

Answer 1