我在 iOS 9 中使用 GameplayKit 的实体/组件概念设计我的游戏，对于 ShootComponent，应该将子弹/导弹定义为实体吗？
是的原因：
将逻辑与其父级分开，例如playerTank 或enemyTank；
如果不是，TankEntity需要区分它的子弹是撞到其他实体还是撞到自己。
拒绝的原因：
它不是逻辑世界中的真实实体，由我的坦克或敌方炮塔发射；
子弹总是会被射击并消失，所以游戏需要不时添加/删除它；
请为您的cmets。
【问题讨论】：
标签： iso gameplay-kit
最终决定将子弹/导弹定义为实体，因此在接触测试、渲染等组件中充当实体。
【讨论】：
我会将它添加为使用它的实体的组件。 因此，您将能够使任何实体发射子弹或导弹。 请记住，您的实体应仅充当简单的引用，其中不包含任何逻辑。
【讨论】：
首先让我们阅读 Adam Martins 对他的条款的原始描述。 Apple 似乎从 Martin 那里得到了实体和组件的想法：
实体：实体是通用对象。通常，它只包含一个唯一的 id。
组件：对象某一方面的原始数据，以及它与世界的交互方式。
系统：“每个系统连续运行（就好像每个系统都有自己的私有线程一样）并对每个拥有一个或多个与系统查询匹配的组件的实体执行全局操作。 "
Martin 只是定义了组合设计的术语，它是一种更可重组和更灵活的继承替代方案。 所以实体是你可能认为是类的实例，但是类已经被剥离了所有的数据和方法，这些数据和方法已经被移出到组件中——实体只是委托给组件。
所以你的导弹......它会是一个普通的面向对象术语中的类的实例——一个对象，对吧？导弹可以有多种行为方式……它可以寻找敌人，可以直线飞行，可以加速等。它还具有指示是否击中敌人的属性，以及其总伤害的属性、健康等。
所以导弹是一个实体，而这些不同的方法/数据将是导弹实体的组成部分。
Martins 的方法很有趣，并且没有像 OO 那样关注组合设计（我真的不知道是什么原因），所以我明白为什么 Apple 会在游戏框架中采用它像这样。
但他的想法似乎并没有得到很好的充实。例如，通常在组合设计中有一个委托层次结构，其中对象将继续委托一个链，直到找到一些数据或方法。在顶部有一个元对象，一切都委托给它。通过这种方式，对象既是组件又是实体——它们既是委托对象又是被委托对象。但 Martins 的术语不支持这一点……他的模型是扁平的——只有实体，然后是可以添加到其中的组件，但实体之间没有委托，也没有元对象。
也许他觉得这种扁平化设计适合游戏开发。我有我的怀疑......你似乎想要某种对象的层次结构。我会寻找一种混合继承的方法，或者设置某种自定义委托层次结构，其中对象可以充当实体和组件。您可能会看看这是否可以在该框架内实现，或者它是否不仅仅是您自己编写的。
【讨论】：