面向数据的设计 - 数据依赖性是如何解决的？

Question

我看到了"Data-Oriented Design and C++" by Mike Acton，我发现它非常有趣。我不明白数据依赖性是如何解决的。

想象一下，我有一个简单的2d引擎：*物理数据 - 处理物理*图形数据 - 渲染精灵*声音数据 - 播放声音

图形数据和声音数据取决于存储在物理数据中的位置。位置可以从物理数据中引用，但在我看来，这会杀死DOD的全部要点 - 在相同的内存位置中拥有所需的数据。

在面向数据的设计中如何处理这种情况？

Answer 1

DOD更像是设计架构的一般方式，侧重于如何有效地首先表示数据。没有单一的方式来做到这一点。 Linus Torvalds展示了对Linux内核和Git等的思维方式，但它与游戏有着截然不同的领域。最重要的是他专注于如何有效地首先表达数据。

作为一个基本的例子，如果你正在设计一个图像处理应用程序，那么如果你没有考虑以数据为导向的方式，而是专注于如何最容易地支持最广泛的像素格式，并提出最简单的接口使用，你可能会想出一个抽象的Pixel，甚至可能是每个像素的堆分配。此时，您需要支付虚拟指针的成本（通常大于像素本身），每像素动态调度，可能是另一层间接，并且可能完全丧失空间局部性。相反，如果您考虑如何有效地首先表示数据，那么您可能会在较粗糙的Image级别（抽象的像素集合，对于给定图像可能为数百万像素）进行抽象，如果您在所有地方抽象的话t按每像素级别支付此类开销。

也就是说，对于游戏来说，接近你所谈论的内容的常用方法通常是使数据集中可访问。这似乎违反了SE原则，但通常如果您使用类似实体组件系统的东西，任何给定类型的组件通常只能由少量系统访问。因此，该数据的范围往往足够小，可以有效地维护不变量。

至于游戏中可能发生的事件，比如两个实体在物理系统中相互碰撞，声音系统可能想要播放声音，有许多方法可以保持物理和声音系统与每个物理和声音系统分离。其他。一种是使用事件队列。

至于一个系统的所需数据也被另一个系统共享，这通常非常实用。如果您希望彼此并行运行这些系统，他们仍然必须复制共享数据，可能会更新它，并以某种方式协调其结果。也就是说，在我看来，避免摆弄它并且只是并行化系统正在做什么（例如：使用并行for循环）是非常有效的，因为ECS中通常只有少数几个系统是热点并且确实非常繁重，您可以轻松地跨线程分发这些特定系统的工作，而无需同时运行多个系统并打开可能的蠕虫。

Answer 2

不确定DOD是否完美，但如果您的物理和图形子系统共享您的ID或句柄，您可以让物理子系统生成所有更新对象的位置和ID /句柄数组，并将其用作图形子系统的输入。