游戏的继承/界面设计

Question

我正在设计一款游戏，但我不能完全理解继承结构。我通常相当擅长它，但这个只有太多的重叠，我无法决定这一切。

我正在寻求模拟帆船 - 想想帆船时代。因此，据推测，一切都延伸到船只类。

有几种类型的船只风格：划船（厨房，独木舟），方形钻机，前后钻机，具有不同的行为。其中每一个都进一步细分为其他几种类型。我无法确定这应该是Vessel的一系列接口还是扩展。还要注意，可能会有一些交叉（船只可以划船和方形装配），这让我想到界面？

船舶也有不同的行为：商船，战争人员，私人船员，海盗。我真的无法确定这应该是一个接口还是另一个类的扩展。但是，在这种情况下没有类型的交叉。

最后，个别船只可以有几种行为。商人可能在车队（自卫）或独立（逃跑）。战争中的人几乎总是攻击，除非严重失控......但可能在舰队，中队或独立工作。私人和海盗只会在较弱的情况下进行攻击 - 通常是独立但偶尔成对出现。我假设这也应该是一个界面？

我的大问题是，每种风格的船（护卫舰，战列舰等）几乎都可以履行这些角色，因此我无法构建简单的实体继承结构。护卫舰不能延长战争，因为有些人是私人战士。 Sloop不能伸展方形装备，因为有些装备是前后装配​​的。 etcetc。

任何想法都会受到赞赏，我有点松散的结局。 感谢

Answer 1

将“行为”部分作为接口。这将帮助您毫无问题地为不同的船舶分配不同的行为。 Strategy Pattern在这里很有帮助。简而言之，它指出应该改变可变属性和常量属性。

对于不同的动作方式，合成听起来像是目前最合适的答案。

关于“但可能在舰队，中队或独立工作。私人和海盗只会在较弱的情况下进攻 - 通常是独立但偶尔成对出现。”部分，我想这与继承树无关。您可以根据自己的需要制作课程“小组”。

这可能会对您有所帮助：

“然后有几种类型的血管样式：......”指定了不同的可能行为。所以“Movable”接口及其子类就是为了这个。在“Vessel”类中，您可以拥有“Movable”类型的成员。由于“Movable”是一个接口，任何实现它的类都可以赋予该成员。所以Vessel的任何子类都可以有任何可能的行为，我们也可以在运行时更改它们。您也可以将其设为ArrayList。 （不确定你是否真的想要这样做）。但是如果你需要为同一艘船提供多种不同的行为，你就可以做到。

当你说“船舶也有不同的行为：......”时，感觉就像扩展船只的单独类别将满足这一要求。然而，句子“在这种情况下没有类型的交叉”。让生活更轻松。

对于巢段“最后有几种行为，个别船只可以......”，你应该为不同的可能行为添加一个成员。它主要是一个ArrayList，因为一个容器将具有多种攻击模式。

最后一段，如果你能提供更多细节，我可以提供一些更多的想法。

Answer 2

好的，这里有一些想法：

• 船只有一种或多种推进装置（桨，帆等），您可以通过组合建模（例如，有一系列推进方法）。
• 船只使用各种策略中的一种（使用策略模式 - 请参阅http://en.wikipedia.org/wiki/Strategy_pattern - 为此）
• 依赖于附近其他船只存在的策略将需要某种方式来查询其他船只 - 因此您需要某种数据结构，以便您可以找到哪些物体靠近哪些其他物体（查看用于广角碰撞检测的数据结构类型）

作为策略模式的替代方案，您可以切换到使用基于组件的设计。在此设置中，船只将由一个或多个推进组件，策略组件等组成。然后，您可以根据需要组合各个组件以制作不同的容器。

作为额外的奖励，如果您希望您的游戏是数据驱动的，那么基于组件的设计非常有用，因为您可以为每种不同类型的组件编写保护程序/加载程序，而不是为每种可能类型的容器编写

如果你对这种方法感兴趣，你可能想看看这里：

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Answer 3

我想根据Bhusan答案的第二段提供一些建议，我在此完整引用：

“关于”但可能在舰队，中队或独立工作。私人和海盗只会在较弱的情况下进行攻击 - 通常是独立的，但偶尔会成对攻击。“部分，我想这与继承树无关。你可以根据你的需要制作”团体“类。”

这让我相信你还可能想要考虑某些船舶组的复合模式，至少那些由同样具有相同行为的船只组成的模式。请参阅http://en.wikipedia.org/wiki/Composite_pattern所写的内容“复合模式描述了一组对象的处理方式与对象的单个实例相同。”

例如，你说“商人可能在一个车队（为自己辩护）”，但可能他们也可以单独为自己辩护？当然，这说起来容易做起来难，而且我对你的建议是不要过度思考它，并从你想要做的原型的一小部分开始

Answer 4

您应该分类并使用strategy模式。
不可变属性应该绑定到继承树（例如，护卫舰不会变成独木舟，这些是精确的，非行为类型，从船只继承），并且可以改变的一切都应该存储为可内部行为类型的参考。 （Man-o-war是一种行为类型）
AI应该单独处理，例如使用状态，但这也必须在您的体系结构中的不同模块中。

Answer 5

我认为你需要考虑对象Composition以及它如何帮助简化事情，而不是将其视为严格的继承。

例如：发货具有行为。 （组成......船代表行为以确定如何对X情况作出反应）

盗版是行为（从行为界面继承）...

Answer 6

你不应该扩展船只类。相反，Vessel对象应该包含描述它的其他对象。 （这被称为依赖注入，令人讨厌迂腐 - 忘了我说过。）你有一个推进类，有方形帆，前后和桨的实例。对于大型和小型船体，您可能需要特殊的实例。你有一个行为类来处理他们的态度。有时一个简单的整数和一个类一样有效。相反，你的武器舱可能只是一些枪支。 （或两个数字，一个用于手续费。）如果你想要撞击，或者装满火箭的船只，或者需要区分长枪和卡罗纳德，你可能需要回到使用该级别。

如果您愿意，可以随时切换特性 - 尽管您可能没有。尽管如此，你仍然可以从风帆转向使用扫描，或者通过商船的保存货物行为切换大胆的船舶行为，以实现失去神经的船长。无论如何，如果你需要它就在那里。