• 12
• 12
• 9
• 10
• 13

# Handling Items in RPG

This topic is 582 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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


Edited by nGamer

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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.

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.

Whether and how much an item can stack, or however many packable items fit inside something fits nicely in the item description.

I prefer to keep item descriptions/properties in a sort of dictionary of their own, read-only. Then I have an inventory of X 'slots', which are quantities of an item (up to that item's stacking limit).

##### Share on other sites

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).

Ah, right. Well, sometimes it's quicker and easier to just use the prototype pattern for this sort of thing, i.e. just clone objects to instantiate them rather than split them into Instance and Type objects. The per-instance properties get duplicated, but it means you don't have to implement a potentially complex system of overrides if it's possible to change those properties later on.