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

Question

I'm making a very simple 2D RPG in Java. My goal is to do this in as simple code as possible. Stripped down to basics, my class structure at the moment is like this:

• Physical objects have an x and y dimension.
  • Roaming objects are physical objects that can move().
    • Humanoid objects are roaming objects that have inventories of GameItems.
      • The Player is a singleton humanoid object that can hire up to 4 NPC Humanoids to join his or her party, and do other actions, such as fight non-humanoid objects.
      • NPC Humanoids can be hired by the Player object to join his or her party, and once hired can fight for the Player.

So far I have given the Player class a "party" ArrayList of NPC Humanoids, and the NPC Humanoids class a "hired" Boolean.

However, my fight method is clunky, using an if to check the party size before implementing combat, eg

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. 

My question is, thinking in object oriented design, am I on the right track to do this in as simple code as possible? Is there a better way?

Answer 1

" My question is, thinking in object oriented design, am I on the right track to do this in as simple code as possible? "

No, and your description uses the essential verbs that describe how your design is built on too much inheritance.

Physical Objects have an x and y dimension (position).
[A Roaming Object is a Physical object that has a changeable position]
Humanoid objects are roaming objects that have inventories.
The Player is a singleton humanoid object that can have a party
[A party has a player and] has up to 4 NPC Humanoids

Composition, although too rarely stressed in object-oriented design has a role to play in code. This is why the has-a / is-a distinction is so often used in analysis.

By declaring a player as a singleton, you've added type complexity and possibly limited your design. What if you'd like to have two players at some future point? How about more? This is not an unreasonable extension but would require that you break the singleton anti-pattern used. If you only want one player, only instantiate one; coding the singleness assumption into the class is unnecessarily limiting. Remember that the coder has to affirmatively call a constructor and need not worry about Players spontaneously appearing.

An object has a position, great: give it one through composition. A position can be changed, so define position::move(). A Player may have a human controller which distinguishes it from an NPC, but - by definition - a non-player character indeed is a character, one which has control that doesn't come from a player. Might you want to give an NPC player control? Many games do, but if you have already encoded the player-character dependency inside a class, an NPC will always be an NPC.

Also, how certain are you that 4 (or 5) is a good number for a party? The Zero, One, Infinity principle says that if you will allow more than one, allow an arbitrary number. If you don't hard code "five-ness" into your design, you limit flexibility.

I generally recommend that designers consider inheritance a method of last resort because of a history of overzealous use. A design can be OOP with no inheritance at all. Polymorphism is cool, but so are encapsulation and abstraction, perhaps even more so.

Answer 2

Well, forgetting the overall design, from a basic programming point of view, instead of having that if structure, you should have a method that takes the party size as an argument. That way, you can just pass in this.getParty().size() and get rid of the if s.

ie

  combatManager.fight(this.getParty().size(), eneObj);

Where combatManager is an object (or class, if you want a static version) that knows how to make things fight .

As I said though, this is not a solution for your design, simply a nicer way to avoid the if s.

The Player class should not be responsible for making things fight, so perhaps you could change your fightEnemy method to engageEnemy or something, and simply have it go to the combatManager with the correct parameters.

Answer 3

Perhaps this would be a nice opportunity to use the Strategy Design Pattern . This way you can change the fighting strategy which will be used when party members are added or removed, rather than every fight.

Answer 4

The player is part of the party. The NPCs are part of the party too. Why would the player handle NPC combat? I think you should add that logic into the NPC class (extends Humanoid) and let add some AI so that NPCs will act with the player and other NPCs when they are grouped together.