Need some advice on two classes

[mcleano]

I have two classes, one called character - derived, and one called weapon - base, but the weapon class doesn't have a constructor. Is this wrong? Should I have a constructor for weapon that will be called when the derived class constructor is called that sets everything to null, or equivalent, or can I just leave it as it is?

[helios]

character derives from weapon? Where's the logic in that?

[mcleano]

Whoops, I meant to say character is the base, and weapon is the derived. Except that weapon never has an object made from it, which obviously seems a bit illogical. I'm only really using it to hold values. Am I being a twat? Is there a better way to do this.

[Return 0]

You should consider creating an Item base class and derive Weapon from it. This way you can derive Armor, Consumable, etc... off the base and not rewrite some of the commonalities.

Except that weapon never has an object made from it

So what is the purpose of the Weapon class then? Do you plan to derive additional classes from it? The way I have this handled in my engine right now is I have an Item base class of which the classes Armor, Weapon, Consumable, and a few others derive. I think have one more layer of derived classes to further specialize my objects. So under the Weapon class I have the Axe class or One Handed Sword class.

Item -> Weapon -> Axe
Item -> Weapon -> One Handed Sword
Item -> Armor -> Shield
Item -> Armor -> Helm

[jsmith]

And to give a general answer the original question, classes should always be constructed into a
well-known usable state, so yes, unless the default constructor of all the data members of the
class does the right thing, you should create a default constructor to initialize them properly.

eg,

class Foo {
  int x;  // default constructor of int does not initialize x, so...
  public:
     Foo() : x( 0 ) {}  // set to reasonable default
};

class Bar {
  std::string s;  // default constructor of string() initializes to empty string, so if this is good enough,
                        // then no default constructor needed here.
};

[mcleano]

What's in the item class then?

The weapon calss holds the name and will hold the attacks for two weapons, although I suppose having attacks within the weapon class is a bit illogical. This is the unfinished weapon class:

class weapon {
	  bool rifle;
	  bool sword;
	  std::string weaponName;
	public:
		void wepChoice() {
			int choice = 0;
			std::cout << "Available weapons:\n\n";
			std::cout << "\t1. Rifle\n";
			std::cout << "\t2. Sword\n";
			std::cout << "\nWhich do you wish to use: ";
			std::cin >> choice;
			std::cin.ignore();
			while(!std::cin && !(choice == 1 || choice == 2)) {
				std::cout << "--Invalid input--\n\n";
				std::cout << "Which do you wish to use: ";
				std::cin.clear();
				std::cin.sync();
				std::cin >> choice;
				std::cin.ignore();
			}
			if(choice==1)
			{
				rifle = true;
				weaponName.assign("rifle");
				sword = false;
			}
			else
			{
				sword = true;
				weaponName.assign("sword");
				rifle = false;
			}
			std::cout << "\n\n";
			return;
		}
		std::string get_weaponName() const { return weaponName; }

};

[Return 0]

What's in the item class then?

ItemBase class includes general data that is common to all items. For example the name of the item, the player stats that can be altered, etc...:

unsigned int itemID;
string itemName;
string itemDescription;
double baseItemPrice;
// stats
short int itemStrength;
short int itemIntellect;
short int itemStamina;
short int itemAgility;
short int itemSpirit;
short int itemDurability;
short int itemDurabilityMax;

As far as the methods available. There should be a member function that modifies the players stats based on the item equipped, unequipped or use. For example lets say the item had +4 strength. When it's equipped the function will add 4 to the players base strength. I won't post my class interface, it is now propriertary info :)

As far as attacks, unless the attack is directly dependant on a specific item, you should break attacks, spells, or whatever into their own class. The weapon class shouldn't really contain any sort of input handling. Choosing a weapon, equipping, using, etc... should be handled by your key bind/input handling interface. For example I have a KeyBinding class that associates each key with specific actions dependant on the game state. Every frame I grab an event and pass it along to handle input if its appropriate, for example equipping items, using items, opening menus, etc... its complicated as hell... Handle input processes the input correclty based on the KeyBindings that are set (which can be changed by the player), the object type, game state, etc... This is probably a bit overboard for what your trying to do, but hopefully you get my point.

[chrisname]

The game engine shouldn't handle input from the user, it should handle input from the game interface, is what I think he's trying to say.

[Return 0]

Yes, exactly. Not sure why I didn't say it that way lol.

[chrisname]

Lol.

[mcleano]

Thats one thing i'm not completely clear on, what actually is the "interface"'

[chrisname]

"Interface generally refers to an abstraction that an entity provides of itself to the outside. This separates the methods of external communication from internal operation (for example two different functions written in C language have the same interface if they have the same arrangements of arguments and the same type of return value, but the function body may be implemented in different way), and allows it to be internally modified without affecting the way outside entities interact with it, as well as provide multiple abstractions of itself. It may also provide a means of translation between entities which do not speak the same language, such as between a human and a computer. Because interfaces are a form of indirection, some additional overhead is incurred versus direct communication.

The interface between a human and a computer is called a user interface. Interfaces between hardware components are physical interfaces. This article deals with software interfaces, which exist between separate software components and provide a programmatic mechanism by which these components can communicate."