organized or overkill?
Author
Recently I''ve been pondering how I should handle items in my app. Does it make sense to have a base ITEM class and then have beaucoups of subclasses (ITEM : public SHIELD, PISTOL, BOTTLE, ARROW, etc) or would it make more sense to define ID''s for each item and whatnot. I ask because it seems to me as though the subclasses may be overkill but it also seems that ID''s are a little unorganized, and it''d be a pain to define them so much. Also, I used the subclasses, however, I would be able to eliminate a lot of parameters, as well as a lot of calculations (because I could store the path names to the meshes, and then also store things like bounding sphere radii, etc). Anyone have any advice as to how to handle a class that will have to be used for say, anywhere between 25 and 200 different types of things?
i''d combine the two ideas. have an ITEM class, and derive several subclasses (i.e. WEAPON, COLLECTABLE, POTION) based on functionality. for example, WEAPON subclass would be for any item that can be equipped and used to kill things; POTION would be for any item that can be drunk for some effect. within those subclasses, you can use the IDs to differentiate the types of weapons, potions, etc...
that''s how i''d do it anyway...
that''s how i''d do it anyway...
I like krez''s idea. It''s overkill to have a different class say a short sword and a long sword if the only difference is stats.
---------------------
Ryan Bujnowicz
[ vangelis ]
---------------------
Ryan Bujnowicz
[ vangelis ]
Incidentally, Half-Life uses a new class for every weapon, item, etc. regardless of any similarities. It uses sort of a string ID based system.
I personally think that having classes for each ''class'' of items/weapons is a good idea, then using class factories or something to create them if necessary.
I personally think that having classes for each ''class'' of items/weapons is a good idea, then using class factories or something to create them if necessary.
i would have a item base class, with subclasses for different categories (like what''s been said so far), and then use your favourite scripting language to define the unique behaviour of each object.
Author
Thank you for your help! I''m starting development on my few subclasses just now. For starters I''ve decided on the following:
EQUIPABLEITEM(shield, weapon, armor, etc)
USABLEITEM(Potions, etc)
MAGICITEM(Spell Scrolls, etc)
MISCITEM(Jewels, etc)
Sounds good. Thanks alot
EQUIPABLEITEM(shield, weapon, armor, etc)
USABLEITEM(Potions, etc)
MAGICITEM(Spell Scrolls, etc)
MISCITEM(Jewels, etc)
Sounds good. Thanks alot
Make subclasses for things which differ in fundamental behaviour.
If you can describe all the differences between X and Y in terms of numerical statistics, then they go in the same class (and those statistics are members).
If there are differences which include ways that they can be used, or the types of calculations needed to support the actions, then make different classes.
Don''t be afraid of getting your breakdown wrong the first time. Make what looks right, on your gut instinct. You can change it later.
If you can describe all the differences between X and Y in terms of numerical statistics, then they go in the same class (and those statistics are members).
If there are differences which include ways that they can be used, or the types of calculations needed to support the actions, then make different classes.
Don''t be afraid of getting your breakdown wrong the first time. Make what looks right, on your gut instinct. You can change it later.
Although I am usually a proponent of very conservative object orientation, I have to step in and defend the "class for each type of item" rather than each category of item.
Imagine you have in your game a bow and a sword. Both are weapons, yes, but they both attack in different manners. The bow may be fired for a distance, and must somehow throw an arrow (or more, triple crossbow in Ultima VI, anyone?) at the target. The sword can only be swung (or possibly thrown) at close range. And yet both are perfectly valid attacks. I think a virtual Attack() or something function would be nice here; inherited from CWeapon (or whatever) into CBow and CSword. Each type of weapon has its own unique procedure for performing the attack, however.
Imagine you have in your game a bow and a sword. Both are weapons, yes, but they both attack in different manners. The bow may be fired for a distance, and must somehow throw an arrow (or more, triple crossbow in Ultima VI, anyone?) at the target. The sword can only be swung (or possibly thrown) at close range. And yet both are perfectly valid attacks. I think a virtual Attack() or something function would be nice here; inherited from CWeapon (or whatever) into CBow and CSword. Each type of weapon has its own unique procedure for performing the attack, however.
Content vs. Code
Content is the stuff in the game, code is the driving force behind the content. So, is an item object a content object or is it a code object?
If the difference between two "objects" can be described using a set of easy rules, you might declare them as content. Think of the weapons in Diablo & Diablo II. Those objects HAD to be content objects, there is no way they wrote seperate code for every possible weapon. They instead probably had a class for each weapon type. On the other hand consider any popular FPS like Quake I, II, III. Those weapons demand different code for every item. You''ve got to call ''em based on your needs.
-----------
VenDrake
"My stupid jar is full. I can''t talk to you anymore."
Content is the stuff in the game, code is the driving force behind the content. So, is an item object a content object or is it a code object?
If the difference between two "objects" can be described using a set of easy rules, you might declare them as content. Think of the weapons in Diablo & Diablo II. Those objects HAD to be content objects, there is no way they wrote seperate code for every possible weapon. They instead probably had a class for each weapon type. On the other hand consider any popular FPS like Quake I, II, III. Those weapons demand different code for every item. You''ve got to call ''em based on your needs.
-----------
VenDrake
"My stupid jar is full. I can''t talk to you anymore."
Omaha: well, you could further derive a "Sword" and "Bow" class from the "Weapon" class; this is actually what i would do, i just didn''t give a full dissertation on it
for example, from CWeapon, derive CSword, CBow, and CSpear. the different swords, however, could be differentiated by name, damage, weight, graphic to use, etc; they don''t need their own class. in an FPS where there are like 10 weapons which are all radically different it would be worth it, but for an RPG there would have to be hundreds of classes to do it that way, and most will be the same except for minor differences.
i am not trying to be argumentative, i guess it just depends on what type of game you are making
for example, from CWeapon, derive CSword, CBow, and CSpear. the different swords, however, could be differentiated by name, damage, weight, graphic to use, etc; they don''t need their own class. in an FPS where there are like 10 weapons which are all radically different it would be worth it, but for an RPG there would have to be hundreds of classes to do it that way, and most will be the same except for minor differences.
i am not trying to be argumentative, i guess it just depends on what type of game you are making
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
