Sign in to follow this  
nGamer

Handling Items in RPG

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites

Right, my bias is towards JRPGs so its what I take in when I read or hear 'RPG', usually weapons and items are not upgradable or subtly different there, as they commonly are in western-style RPGs. Prototype is a nice system for western-style RPGs then, and usually counts only make sense for very few kinds of items (e.g. the ones that are always identical) anyways, so my recommendation doesn't make sense under those circumstances.

Edited by Ravyne

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this