java - Java游戏的面向对象设计: How to handle a party of NPCs?

Question

我正在用 Java 制作一个非常简单的 2D RPG。我的目标是用尽可能简单的代码来做到这一点。归根结底，我目前的类(class)结构是这样的:

• 物理对象有 x 和 y方面。
  • 漫游对象是物理对象可以移动()。
    • 人形物体是漫游物体有 GameItems 的库存。
      • 玩家是一个单人类人动物最多可以雇用 4 个 NPC 类人动物的对象加入他或她的队伍，并执行其他操作，例如与非人形物体战斗。
      • NPC 类人生物可以被雇佣玩家反对加入他或她派对，一旦被雇佣就可以为玩家而战。

到目前为止，我已经为 Player 类提供了一个 NPC Humanoids 的“派对”ArrayList，为 NPC Humanoids 类提供了一个“hired” boolean 值。

但是，我的战斗方法很笨拙，在实现战斗之前使用 if 检查队伍规模，例如

public class Player extends Humanoids {
   private ArrayList<Humanoids> party;
   // GETTERS AND SETTERS for party here
   //...

   public void fightEnemy(Enemy eneObj) {
      if (this.getParty().size() == 0)
        // Do combat without party issues
      else if (this.getParty().size() == 1)
        // Do combat with party of 1
      else if (this.getParty().size() == 2)
        // Do combat with party of 2
      // etc. 

我的问题是，在面向对象的设计中思考，我是否在正确的轨道上用尽可能简单的代码来做到这一点？有没有更好的办法？

Answer 1

“我的问题是，在面向对象的设计中思考，我是否在正确的轨道上用尽可能简单的代码来做到这一点？”

不，您的描述使用了描述您的设计如何建立在过多继承之上的基本动词。

物理对象具有 x 和 y 维度(位置)。
[漫游对象是具有可变位置的物理对象]
人形物体是具有库存的漫游物体。
玩家是一个单例人形对象，可以拥有派对
[一个派对有一个玩家并且]有最多4个NPC类人生物

虽然在面向对象设计中很少强调组合，但它在代码中发挥着重要作用。这就是为什么在分析中经常使用 has-a/is-a 区别。

通过将播放器声明为单例，您增加了类型的复杂性并可能限制了您的设计。如果你想在未来某个时候有两名球员怎么办？更多怎么样？这不是一个不合理的扩展，但需要您打破所使用的单例反模式。如果你只想要一个玩家，只实例化一个；将单例假设编码到类中是不必要的限制。请记住，编码人员必须肯定地调用构造函数，而不必担心玩家会自发出现。

一个对象有一个位置，很好:通过合成给它一个位置。位置可以改变，所以定义 position::move()。一个玩家可能有一个人类 Controller ，这将它与 NPC 区分开来，但是 - 根据定义 - 一个非玩家角色确实是一个角色，一个有控制的角色不是来自玩家。你可能想给 NPC 玩家控制权吗？许多游戏都这样做，但如果您已经在类中编码了玩家角色依赖关系，则 NPC 将始终是 NPC。

此外，您有多确定 4(或 5)是聚会的合适人数？ Zero, One, Infinity原则说，如果您允许多个，则允许任意数量。如果您不将“五性”硬编码到您的设计中，就会限制灵 active 。

我通常建议设计人员将继承视为万不得已的方法，因为继承曾被过度使用。设计可以是完全没有继承的 OOP。多态很酷，但封装和抽象也很酷，甚至更酷。