Java中面向对象的游戏设计:如何处理NPC派对？

Question

我正在用Java制作一个非常简单的2D RPG.我的目标是尽可能简单地执行此操作.根据基础知识,我的班级结构目前是这样的:

• 物理对象具有x和y维度.
  • 漫游对象是可以移动()的物理对象.
    • Humanoid对象是具有GameItems库存的漫游对象.
      • 玩家是一个单人类人体对象,可以雇用最多4名NPC Humanoids加入他或她的队伍,并做其他行动,例如打击非人形物体.
      • NPC Humanoids可以被玩家对象雇用加入他或她的派对,一旦被雇用就可以为玩家而战.

到目前为止,我已经给了Player类一个NPC Humanoids的"派对"ArrayList,而NPC Humanoids类是一个"雇佣"的布尔值.

但是,我的战斗方法很笨重,在执行战斗之前使用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维度(位置).
[漫游对象是具有可变位置的物理对象]
人形对象是具有库存的漫游对象.
玩家是一个单人形对象,可以有一方
[A方有球员和] 有多达4 NPC人型生物

虽然组合虽然在面向对象设计中太少强调,但在代码中起着重要作用.这就是为什么a-a/is-a区别经常用于分析.

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

一个物体有一个位置,很棒:通过构图给它一个.可以更改位置,因此定义position :: move().玩家可以有一个人的控制器,它从一个NPC的区别,但-顾名思义-一个非玩家角色的确是一个人物,其中一个有控制的,它不是来自一个球员.你想给NPC玩家控制吗？很多游戏都有,但如果你已经在一个类中编写了玩家角色依赖,那么NPC将永远是一个NPC.

另外,你有多确定4(或5)对于派对来说是个好人数？该零,一个无限的原则说,如果你允许不止一个,允许任意数量.如果您没有在设计中硬编码"五个",则会限制灵活性.

我通常建议设计师认为继承是一种最后的方法,因为它有过度使用的历史.设计可以是OOP而根本没有继承.多态性很酷,但封装和抽象也是如此,甚至更多.