I had a question regarding the best way to have items in my RPG game.
Currently I have a class structure in which everything inherits from GameObject. Item inherits GameObject. Armour Inherits Item. Helmet inherits Armour. Etc.
I am wondering whether I should have a class for each specific piece of armour, weapon, item, etc. in the game, or whether I should have generic "Helmet", "Shield" etc. classes and then use a factory instead to fill in the constructor arguments. I am unsure of whether the number of classes will become too much and if this is bad.
Classes:
Item* firstHelmet = new LeatherHelmet();
Item* otherHelmet = new SteelHelmet();
Factory:
Item* firstHelmet = Armour::Create(ArmourType.Helmet, Tier.Leather);
Item* secondHelmet = Armour::Create(ArmourType.Helmet, Tier.Steel);
The first example will result in a large number of classes. However, the second example is going to result in a lot of if statements or switch cases to query the type and tier of armour being created and then setting the appropriate variables.
Which is best, or is there another better solution I am missing?
Answer
The rule of thumb about whether to subclass or to create multiple instances of the same class is: Do these objects need different program logic or just different values?
When the steel helmet and leather helmet use the exact same programming and only differ by the values of attributes like name
, defense
, price
and sprite
, they should all be instances of the class Helmet
.
When all types of armor use the same programming and differ only by which equipment slot they occupy, then they should all be instances of the class Armor
with an attribute slot
.
But if any armors have unique game mechanics, then it might make sense to implement these as individual sub-classes. When all helmets have values for hearing-impairment and vision-impairment but all other types of armor have not, then a class Helmet
inheriting from Armor
which has these additional attributes might make sense. When you have an unique helmet with a very gimmicky game mechanic, like a helmet which turns the character into a chicken if equipped on a Thursday, it might make sense to create an unique class just for this helmet which overrides the equip
method. On the other hand, if you have many items with unique mechanics, it might be worth it to add a scripting engine to your game and allow items to contain scripts.
the second example is going to result in a lot of if statements or switch cases to query the type and tier of armour being created and then setting the appropriate variables.
Instead of hardcoding your item creation you might want to consider to move your items and all of their values to an external file. You will still have a switch
to convert strings from the file to the correct enumerations, but all the numeric values should come directly from the input file.
This keeps your item initialization code clearer and also gives you the advantage that your can change your item values without having to recompile the game.
No comments:
Post a Comment