如何模块化地实现相关对象？

Question

我试着使题目尽可能地普遍适用，但我不确定我写得这么好。这是由我遇到的一个非常具体的问题引起的，在剩下的问题中，我只想描述一下。

我试图用图形、物理和碰撞编写一个小游戏引擎。我试图分别实现每一件事情；完全可以想象，我有一个图形显示的，物理移动的物体，不能碰撞(火灾效果？)或者不是由物理呈现或控制的碰撞物体(无形的屏障)。然而，大量的对象将需要这三个。

我非常确信，我可以把这三个部分完全隔离在它们自己的类中，但有一个例外，它们都需要引用它们的对象的相同位置和角度。

一开始，我认为我应该把每件事都放在自己的类中，只需要用多重继承构建每个实际的游戏对象，但是考虑到他们都需要共享数据，我不太确定这是否可行。

下一个选项是用指向适当位置和方位数据的指针初始化每个对象，但我觉得像对待特殊成员一样对待这些对象很奇怪。。。我希望每一堂课都尽可能地不了解其他班级，如果我是独立设计每一节课，我永远不会做指点。

我还可以让每个类都使用自己的位置数据，并让组合类(通过友谊或getter/setter)强制它们一致，但这也不太正确。

我试着搜索谷歌的信息，了解什么是典型的工作，但我发现的大多数信息都集中在系统的某个特定部分，并没有说太多关于集成所有东西的信息。我只是太有哲理了，还是有更好的方法来做到这一点？

如果这很重要，我正在使用C++。

谢谢。

*我知道自己实施它是没有意义的，但这都是为了好玩。

Answer 1

服务，而不是超类

这些东西不是相关的对象，它们是游戏对象的行为方面，随着游戏对象状态的变化，它们可能会来来去去；把它们看作是服务，而不是超类。它们也不太适合纯粹的组合元素，因为游戏中的行为可能会随着时间的推移强烈地依赖于游戏对象的状态。

示例

一个‘鬼’物体可能是可见的和运动的，但可以通过固体物体，但可能无法通过一个神奇的屏障，也可能造成损害，当它与活的组织碰撞。它只能被魔法武器破坏。

，对不起，

游戏编程是困难的，在这个层次上主要是由于建模的复杂性。黑客来获得你自己的想法(如果只是好玩的话)和/或研究现有的游戏引擎，看看其他人做了什么(例如虚幻引擎源代码)

Answer 2

你自然会朝着实体组件系统的方向努力。

如果您多年来一直在应用OOP思想，最后一步是将这些共享组件转换为原始数据，但只有这样，您才能真正体会到ECS的真正灵活性。实际上，我顽固地拒绝这样做，直到第二次迭代时，我才将组件变成原始数据。

要消除这种感觉，即这似乎是错误的，而且完全违反了封装和信息隐藏，方法是记住，通常只有一两个系统将访问任何给定的组件，而通常只是一个实际转换(变异)该数据的系统。因此，保持组内不变量实际上并不难，如果有的话。它还使维护更广的、组件间的不变量变得更容易，而粗系统处理一切。

实体只是组件的容器(每个实体最多有一个组件类型实例)。组件只是原始数据。系统处理实体/组件，是这三者之间唯一的功能提供者。系统通常也是相互解耦的，通常不调用函数。大多数系统也类似于以下几种混乱的模式：

for each entity with these specific components:
    do something with the components

例如，上面的呈现系统可能如下所示：

for each entity with pos/velocity and sprite components:
    render sprite component at pos

而移动系统看起来可能是这样的：

for each entity with pos/velocity components:
    pos += velocity * time_elapsed