Hey guys,

I'm writing an RPG, and I've gotten around to item management. Right now, my definition of an item is simple and I've taken the data-driven approach, but the thing that I'm not sure about now is how to implement item effects. One solution that comes to mind is to have a member that is a pointer to some function that does the item action according to the item code. The other solution was have the client perform the action since it already knows what type of item that is being used.

Below are the contents of my item declaration. Clearly, the item class is derived from a base class, and there is one important inherited member: std::string id. id holds the unique identifier for each item.

# ifndef ITEM_H
# define ITEM_H

# include <string>

class ITEM : public D_OBJECT
{
    public :
        ITEM () ;
        ITEM (const char* id) ;

        std::string description ;
        int quantity ;
        bool usable ;
        bool sellable ;
        int value ;
        bool showQuantity ;
} ;

# endif

Here is a discussion from two weeks ago, with several different examples of ways to do it.

Side note.

Why is item concerned about it's quantity? The item is not a container, it's an item in the world that serves a function. It's primary concern should only be data about it's self, and then doing said function. A container like a player's inventory, a chest, or the world proxy, should only be concerned with the number of same items present.

Sometimes it's easier just to have a quantity field, especially if you know you're going to be displaying the item as a single inventory object, and if you know each instance will be otherwise identical, and that there might be a lot of duplicate items in a player's inventory.

Quantity works well for many types of objects when they are all identical or generic.

Some examples are stackable objects or items with a number of uses.

A quiver of arrows may have some number, perhaps 20, 17, 3, or 0 arrows in it. A system might make a magic wand with a specific number of charges. A system might allow for stacks of food, stacks of potions, or other objects; perhaps you have 7 apples, or you have 34 healing potions.

I think what Tangletail is asking is why an object that represents the properties of an item should be concerned with how many of them the player is holding -- it seems that some kind of inventory object would be better positioned to track quantities, doesn't it? In particular, if the player is holding N potions on their person, M of the same potion in some storage chest, then it seems silly to duplicate the items properties in all of those places.uantities of an item (up to that item's stacking limit).