When any item is being added to the player’s inventory, the “AddItem” method is called, passing in the item object, and the amount which is being added to the player’s inventory.

With the “AddItem” method an inventory slot that already contains an item with the same ID as the item passed into the method, which hasn’t reached the maximum stack size can be found. As much items can be put in that inventory slot as possible. If the limit is reached, and still there is more to add, or if there isn’t a partially-filled slot with that item type, the remaining quantity can be added to the another slot. [4]

Another very similar example implemented with an array was found.

The base class “Item” that all of the item types are descended from is created (see Figure 4.) Then the created child classes e.g., Armor, “Item” variable can be used to store any of the derived classes.

The “Items” is an array, where any Item-derived object can be stored, e.g., Armor or Weapon (see Figure 5.). “FirstAvail” method adds items to the array, where there is a space for it. When one of the items is in use in the Inventory system, the way how to deal with them has to be determined.

The code snippet above (see Figure 6) shows how to behave with collected items. The operation “as” checks the true type of the object and returns null if it doesn't match. So if you store a “Weapon” item in slot 0 of the inventory, it will not try to use it as an “Armor” item.

According to the wiki book “Learning C With Game Concepts/Designing A Roleplaying Game.” [5]  an inventory system should contain list of items (e.g., objects). Inventory should also be able to do such processes as insertion, deletion, and finding of specific or similar items. When same item is added, number of such items increases and not the instance. Each of the created items should be inserted in an item node. Each node can be linked to other nodes to form a data structure, e.g., linked lists or trees. [5], [6] In this book’s example, inventory is implemented as double linked list, where node points to its own item, forward and backward. [5]

Another similar approach is to create inventory system using dictionary data structure. Data is read into the dictionary form the item class, where all the properties of items, like type, name, etc are initialized. Item type is used as a key in the dictionary. [7] In other cases developers use item itself as the key and then set the value as amount of the items that players are carrying. [8]

Purpose of this work is to demonstrate and create useful implementation for organizing objects. On top of that, organized objects could be showed to the player in the video-game scenarios.  

The last few months we were developing a video-game, where basic implementation of using associative array was used when storing player-held objects. The system was called backpack, and it was a core for an inventory. This backpack was able to input or find specific elements held inside. It could also hold special items, for example required by the quest, that could not be dropped out by the player. Items that player wanted to store, were picked up or stored directly from where they lay, parented to the backpack game object and reflected in predefined array. Predefined array size, was the size of the backpack capacity, which is a very common and realistic in-game practice.

This backpack system had few limitations, therefore more advanced structure was needed. First of all, all objects that were stored initially by the system or picked up by the player were just parented to backpack’s gameobject. This meant, that all game objects would be stored in both the array and the backpack transform. That, theoretically leads to a longer object reitrieval time, in case where object id for the retrieval is not known. So for every not known object retrieval, the complexity is O(n). Furthermore, backpack system was not organizing objects in any way, they were just added to an empty array slot (which was also needed to be found) in the array. Object types were also not recognized nor set in the objects themselves. This meant that they could not be grouped to groups as food, weapons, clothes etc, but also that a single item from the specific group could not be retrieved. Backpack system was also not able to visualize objects that are currently stored inside, therefore player could not know what and how many of the items are currently inside. Lastly, backpack system was not a separate class and implemented together with the player class, which is in general not the best practice.

Inspired that backpack objects could be displayed through the inventory in an organized fashion to the player, we have decided to redo the backpack system completely. 3.2 Previous work limitations showed that:

To fulfill the first requirement, new object should be checked among same type of objects in the backpack, and compared if it has exactly the same parameters. If for example, two objects are similar, although the size is slightly different, they can be overwritten and counted as exactly the same.

System should also be very dynamic. Considering that previous work used a simple array, the first improvement should be to create a dynamic structure, theoretically allowing to store as many different objects as possible. This would also give another improvement - the upgrade of backpack capacity without any restructuring of already existing data.

New system should be able to do at least the minimum of what previous system was able to do:

Lastly, to demonstrate how the new system works, inventory GUI should display what object types and how many of them backpack is storing.

This chapter will cover how and why specific decisions were made while implementing backpack - inventory system. All other elements as prefabs, models, code, icons, textures, and some sounds were also created by us. However, only the backpack system and GUI will be covered in this part.

We have started by implementing the switch between the use of the new backpack and the old backpack systems. The new backpack system was created in a separate class, called Backpack, instead of keeping the code in the Player class. Firstly, to use dynamic data structure type, instead of associative array we have chosen to use Dictionary to store game objects. Dictionary as the List is a dynamic structure, which does not need predefined size to be known before adding new objects. After, it was decided to use the ObjectType (apple, rock, bottle etc.) as the Key (string) and GameObject (Unity GameObject) as the value in that dictionary. The purpose of that was to be able to find object according to the type. Therefore, all objects that can be picked up and stored by the player, received new property of ObjectType. Later, to add new feature and fulfill the second requirement (knowing object type amounts), another dictionary was created to store object amounts, where Key was again ObjectType, and the value was the amount of it.