Opinions on inventory design

Kilgore__Trout

Hi,

Hoping to get opinions on possible approaches to designing an inventory system, in particular, whether it might be best to consolidate all item types into a single class and keep track of the item type, or define separate classes for each key item type.

This inventory system would need to accommodate multiple item types: crafting components, weapons, armour, and consumables. The item classes themselves are mainly used to store the attributes of the items, and probably won't contain many (if any methods).

The advantages of a single, consolidated class would seem to include:

• Simpler solution in general
• Considerably less coding to manage casting between types
• Simpler interactions with lists

The disadvantages could include:

• Objects will contain redundant data / Unwieldy constructors (this could be reduced by having several constructors within the Item class, one for each type.
• Potentially greater chance of error

Thanks for reading!

RedXIV

If it was me, I'd go with having a single "item" class. I can see enough advantages in having consistent attributes across all the items, for ease of display to the user, for interaction between other items and for mass processing.

That's my thoughts on it, but I will confess to never having implemented one

oisincar

The way I would do it would be have an Item class, with some bools which would determine if the item was equipable, consumable, has health, ect. Then have a separate database which would take care of the transitions between items. I.e. Potion -> glass bottle or 6 sticks -> ladder. I'm not really sure how well that would scale though.

The way minecraft seems to do it is through items which each get a block ID. The crafting table then recognises if a specific arrangement of block ids is there, and will output the correct block.

Again obviously i have no idea what i'm talking about, but that's what I'd try to do.

Kilgore__Trout

Thanks for the suggestions! Started off with one class for each main item type. Seemed good on paper (it might even have aligned with my vague notions of "best practice"), and the basics were easy to put in place, but on getting into the implementation, it feels like it's a lot more complex and requires several times more code to set up this way. Starting to lean toward the single class now. Will probably stick it out for another day or two, and then revert to older version of code if it seems like a better option.

Kilgore__Trout

Thought I'd post back to give an update on how the inventory system panned out.

Consolidated all the item classes into one, and found it much, much simpler and quicker to work this way. Managed to get most of the features (item display, transfer, equippable item slots, shop, crafting) working at a basic level, before moving on. There are a few more inventory related features to add (enemy loot drops, containers) and will hopefully get these up and running soon.

It's possible that I was missing some techniques that would have made working with multiple classes easier, but in this case the single class worked a treat. Cheers!

Torakx

Thats some great progress
Does that mean the single class is just the one big script?
I have often wondered exactly how to organise an inventory system with looting. I figure you need at least a couple of lists or arrays in an inventory manager and possibly a few global variables for saving progress.

Is it mostly strings and ints interacting with lists?
I hear it's a lot of work, so I'm wondering what is the challenging part when writing code?

I found this with a quick search.It gives me a familiar pain in the head
http://codereview.stackexchange.com/questions/39475/inventory-script-rpg-in-c

Kilgore__Trout

Yeah, things actually went fairly smoothly for a change : )

The way it was set up was to have several classes which don't extend monobehaviour, one for each type of item: weapon, armour, equipment, craftable component, sellable item. These classes just store the item's attributes, such as range, weight, cost, damage, etc, and don't have any methods.

The base class would hold all the attributes that are common to all items (things like weight, cost), and could be used for simple items like sellable items and crafting components. The other classes, like weapon, would extend the base class with the extra fields it needs (like range, damage). It sounded good at the time, but I found progress really slow, as you can't process information for multiple classes as easily, and a lot of casting and checking is needed, along with it generally being more complex.

Using just one class for items meant that all items have all attributes (so an armour has a range field, even though it isn't used). A more complex item might have 30 or so fields, whereas a simple one might have 10. To get around passing 30 parameters to create a simple item, I used multiple constructors, which only take the parameters needed to create that item.

Beyond that there's a persistent gamedata object, with a list of items for each item type for each inventory, and each of these lists is loaded into a list of list <Item> for filtering item type and quickly being able to return a specific list of items in a specific inventory. This script handles moving, sorting, and storage. Another linked script serves as a database for the items, and can create and return new items. There are a few UI scripts for displaying and interacting with the items also. Still a lot of work to do in this area, but it's going a lot better with a single class.

Fuzzytrooper

Not sure what language/environment you are using but would it be an option to have a base inventory object with common attributes and methods and then inherit this for specialisations e.g. weapons. The subsequent classes could just add on the required extra attributes.

Kilgore__Trout

That's how I started out. Made okay progress like this up to a point, but ended up having to write a lot of extra code to handle and process multiple child classes, so I switched to using a single class for all items. Was quite a lot quicker and easier to implement.