0
\$\begingroup\$

I'm wandering what would be a suitable way of storing items in inventory. Many games have an inventory that stores different items with its quantity. For example, [ "Herbs" x5, "Torch" x2, ..].

so I came up with a data structure like this in Java;

HashMap> inventory // where Integer -> item id, ArrayList -> there are same items stored in the list

but I thought Is this a good way to store items even if the number of items in each list becomes larger (x99 items) ?

or should I just store the quantity of items instead of storing objects in list? in this case, is using tuple going to be ok? like HashMap>

\$\endgroup\$

2 Answers 2

Reset to default
2
\$\begingroup\$

Store quantities, not instances. There is zero value in having 99 instantiated torches in an inventory. All you need to know is that you have torches and how many of them.

A HashMap works, but it's not ideal; if it's the easiest thing for you, though, I would go with that for now. Another option that might be even easier to just keep a single array of quantities, where each item has a unique small integer ID. For instance, torch might be #17. Then you can just set array index 17 to 0 if you have no torches, and a positive number when you have some quantity.

The advantage of the array is that since the list is ordered, you can generate an index of items in the inventory (items with quantity > 0) quite easily, which will mesh well with the UI in most of these kinds of games.

\$\endgroup\$
5
  • \$\begingroup\$ somehow the HashMap<Intger, Arraylist<Item>>> is missing. well, the reason I'm planing to use HashMap or even TreeMap is that it would be easier to find index(itemID) for addtion or deletion of corresponding items when a player gets or sells them. so in hashMap, keys and items would be stored like HashMap<01, Pair<("Tourch", 80), 99>> inventory; // where Pair has an object comprising of Touch and it's cost 80G, and the quantity 99. or is it better to separate objects from its quantity as different arraylists? \$\endgroup\$
    – neko
    Commented Oct 2, 2013 at 8:50
  • \$\begingroup\$ All the inventory needs is quantity. All other data like cost, name, etc. can and should be stored in a separate data structure. A store, for instance, needs to know how much an item costs but the store does not have quantity in these kinds of games generally. \$\endgroup\$
    – Sean Middleditch
    Commented Oct 2, 2013 at 15:31
  • \$\begingroup\$ I see.yes in Item class, I'm planning to have attributes like id, name, cost etc. thinking of which, how will the array of item quantity be also sorted when the items in the hashmap are sorted on the basis of cost? \$\endgroup\$
    – neko
    Commented Oct 3, 2013 at 13:11
  • \$\begingroup\$ It won't. Sort outside of the inventory and item structures, not inside them. Your core data structures should be fast (you can't sort a hash table anyway, by definition). \$\endgroup\$
    – Sean Middleditch
    Commented Oct 3, 2013 at 16:26
  • \$\begingroup\$ I meant "be consistent/static" rather than "be fast" and thinko'd that one, but of course being fast is good, too. :) \$\endgroup\$
    – Sean Middleditch
    Commented Oct 3, 2013 at 21:02
0
\$\begingroup\$

In previous games, the solution I've used is similar to this:

How should I handle collectable/droppable/stackable items in an inventory?

class ItemStack {
  Item item;
  int count;

  // ...public methods here...
}

Stacks are very easy to work with and also allow you to have instances of the items

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .