Jump to content
  • Advertisement
Sign in to follow this  
EmrldDrgn

RPG Inventory System

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm working on a tactical RPG (in the vein of Fire Emblem), and I'm ready to work on an inventory/item system. I'd thought to have an Inventory item which maintains a std::vector of pointers to an Item base class, but I'm having second thoughts. I was going to have the items maintain pointers to their possessors and update them, but what about items for use on enemies? It seems like the kinds of items I'm likely are too varied to have a convenient and unified interface to access them with. So I'm looking for other ideas. Anyone have any? I've never done this before, so any previous experience would be the most helpful, I think...

Share this post


Link to post
Share on other sites
Advertisement
I've created a couple of different RPG inventory systems. I'd recommend that you have an ItemSlot class that holds one item. You can subclass this ItemSlot if you want an ItemSlot to have specific behaviour. You can also make it so an ItemSlot only accepts Items of certain types.

Then in your Item class you can hold a pointer to ItemSlot that owns the Item. This is particularly useful when you want to mount weapons or armour. When you attach an Item to an ItemSlot the ItemSlot can call one or more callback methods that update the inventory interface as well as the visibly displayed 3D models.

Share this post


Link to post
Share on other sites
I'm also struggling with this a bit, but then I always seem to run into trouble when I try and use polymorphism.

I'm thinking about an approach that uses composition instead. So I would have a class called Item which contains stuff generic to all items like string resource ID, description, icon and in game renderable info and so on, it would also need an enum indicating where it can be equipped. The Item class would also have pointers to various components. For a D&D type game these would be:

WeaponProperties
ArmourProperties
EquippedEffect
UsablePower

The constructor for item would take as argument various template classes based on the items blueprint and this initialises the sub-components. So if I pass in a weapon template then I initialise my weapon properties and set the type enum correctly, whereas if I pass in an armour template the weapon properties remain null, and vice-versa. Then if the user tries to eqip the item in an armour slot I check the type enum and send the player a helpful message. If he correctly puts it in a weapon slot the I can pass the weapon properties to where they need to be to update the active weapon.

When any item is equipped I can go through the list of Equipped effects and apply them.

"UsablePower" here refers to any item that has a power or ability the player can use. So the component would need to store whether the ability is self only, as for potions, or targetable as for wands. This also means that weapons and armour can have powers as well, indeed they could have more than one component of this type if you want to have this.

Actually specifying how the power works is more complicated. In practice I think modern games allow designers to associate items with custom scripts for using their powers.

I think this approach allows me to have a container of a generic item class for the purpose of organsing and displaying them and so on, but also lets you easily get at the range of properties you'd need. I haven't implemented it yet though, so there might well be problems I haven't thought of.



Share this post


Link to post
Share on other sites
Quote:
Original post by BoReDoM_Inc

Then in your Item class you can hold a pointer to ItemSlot that owns the Item.


I don't see why it should be this way around? As in I don't see why items need to know about their possesors, as opposed to possesors knowing about their items.

Share this post


Link to post
Share on other sites
Quote:
Original post by Somnia
I don't see why it should be this way around? As in I don't see why items need to know about their possesors, as opposed to possesors knowing about their items.


It is pretty common with items that fire projectiles, since projectiles often have a reference to what game entity fired them. Other common uses would be for items that require certain preconditions on their owner to use (specific levels or skills to use the item) or items that scale with the powers of their owner.

Share this post


Link to post
Share on other sites
Quote:
Original post by Somnia
Quote:
Original post by BoReDoM_Inc

Then in your Item class you can hold a pointer to ItemSlot that owns the Item.


I don't see why it should be this way around? As in I don't see why items need to know about their possesors, as opposed to possesors knowing about their items.

Item's should know about there possessors for several reasons. The most obvious being when you delete an Item you don't want the ItemSlot pointing to deleted memory. However, when you want to attach an Item to a different ItemSlot it must obviously be removed from the previous ItemSlot. If you really want you could search every ItemSlot in existence (assuming some system somewhere knows about them all) for the ItemSlot that holds an Item that is being moved, however this would be a terribly inefficient design.

EDIT: Just to make it clear, the ItemSlot and the Item should each hold pointers to each other, it is not a one-way relationship.

Share this post


Link to post
Share on other sites
Somnia, perhaps you're getting confused with an ItemSlot and the way an ItemSlot is displayed, these would be different. For instance suppose you have an ItemSlotWidget which displays an ItemSlot. The ItemSlot (and the Item itself) certainly would not need to know about the ItemSlotWidget. However, the ItemSlotWidget would probably register a call-back method with the ItemSlot so that when the Item stored in the ItemSlot changes the ItemSlotWidget updates the icon being displayed. Of course you could have multiple ItemSlotWidgets representing a single ItemSlot.

Share this post


Link to post
Share on other sites
I hadn't considered those posibilities. In particular I suppose I thought that if an item was being moved or removed it would only happen in a context where it would already be known what the ItemSlot was, i.e because the player was manipulating that ItemSlot through the UI, but I suppose there could be situations in which that wasn't true.

Share this post


Link to post
Share on other sites
Somnia, that's reasonable. The system that I have described certainly does work so if you need any more details feel free to ask.

I thought I might also share two more advantages of the system. Items that occupy multiple slots i.e. Double handed weapons occupying both the left and right hand weapon slot. These can be implemented by adding a separate list of ItemSlots to the Item class, I tend to refer to these as referenced slots. Then when an Item is removed from its owning slot it is also removed from all the slots that reference it. ItemSlot can then have an additional boolean variable that determines whether they reference the item as opposed to owning it. An ItemSlotWidget can then check whether the corresponding ItemSlot owns an Item, display the icon normally, or whether the ItemSlot simply references the Item, display the icon but make it translucent.

I also mentioned that you could sub-class the ItemSlot class to add specialised behaviour. An example of this would be a CharacterItemSlot, this a specific type of slot that in addition to the standard ItemSlot functionality also holds a pointer to the character that owns the ItemSlot as well as a unique slot identifier i.e. kItemSlotLeftHand.

If you're sub-classing ItemSlot the ItemSlot class would then need to contain some kind of sub-class/type identifier (usually some sort of enum). Then when it is necessary an Item can check what type of ItemSlot owns it. If the owning ItemSlot is a CharacterItemSlot then you can safely typecast the pointer and find out specifically which character owns the Item, and therefore any information about the character.

Another specific type of ItemSlot that I've commonly use is a BagItemSlot, the BagItemSlot would have an integer identifier so that the BagItemSlot itself knows what position it occupies in a Bag. This is particularly useful when you're implementing networking and you need to inform clients which Item was moved from a source slot to a destination slot.

Share this post


Link to post
Share on other sites
I guess what I'm more confused about is how to make the items do whatever it is they're supposed to do, not so much how to hold onto it. How to heal people with healing potions, or whatever. The only thing I thought of was to give the Item interface a DoThing method that takes a character as an argument, and have it just apply whatever its effect is to that character. Does that sound like a good idea? Or are there better ways?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!