Devlog 3: Inventory/Item System

Inventory/Item system was quite interesting to implement. From developing it I learned the many ways synchronization can happen between clients for the map items. For example, to place blocks I can use a RPC to place a block on all clients, whereas for picking up an item (where the item pickup object will be destroyed and transferred into the players inventory), I get the current player colliding with the pickup object and check if I can access the inventory. 

- If I can access it, I add the item to the inventory and destroy the pickup object,
 -If I cannot access the inventory, means it is another player and so I only destroy the pickup object for them without adding it to their inventory.

This is an interesting workaround as by right, the solution should be to instantiate and destroy gameobjects on the network. However in my case, instead of the gameobjects exisitng on the network, they exist on every single client locally. Which I presume would be a good thing as it would take up less resources on the network. However I am yet to find out the drawbacks, so it may not be the best solution.

For the placing and destruction of blocks, it is using the aid of the unity tilemap system, where it essentially splits the map into a grid, where I can spawn objects in the individual cells. This is helpful as the blocks will fit perfectly on the grid system, therefore there would not be worry about spawning blocks overlapping one another.

Originally, I had planned to take more advantage of the tilemap system, where for placing blocks, I would simple assign a sprite to the cell on the tilemap. This is very cheap as there would be no instantiating new gameobjects, just modifying the tilemap data. However, I soon found out that it was very limiting. Simply changing the sprite on the cell meant that if I wanted to destroy the block, the only point of data I can get would be the sprite name, so in order to destroy the block and spawn a pickup for it, I would have to trace to the block's item data using "dirtSprite.png" for example. This is possible but would be extremely troublesome. Another thing is if I want the blocks to have extra features, like a block that spins for example, it would not be possible as the block is represented through a sprite on the grid. There would be no way to spin it as all the sprites/blocks on the grids are connected. Hence, I had to change up the system to just instantiate new gameobjects to place blocks. With this I can assign the item data to the gameobject's script "Block.cs", and so I would have all the points of data I need, and I would also be able to add unique features to each block by just adding scripts to it. For example, for the spinning block earlier, I can just make and assign a script that spins the block.

Making the inventory system was interesting too. Mine is quite unique in the sense that the inventory slots were dynamic as each inventory slot is assigned a slotIndex. For example, a List<InventorySlot> can contain:

• InventorySlot(itemName = dirt, quantity = 2, slotIndex = 1)
• InventorySlot(itemName = dirt, quantity = 2, slotIndex = 5)
• InventorySlot(itemName = dirt, quantity = 2, slotIndex = 0)

Making the logic for the adding of items to the inventory was also quite interesting. The function for it is one of the longest functions I have written so far, where there are many layers of checks that have to be done to decide where to put the item. For example, finding existing item lots, checking for excess qty, then calling the function recursively to add the excess qty. There are just a lot of scenarios to consider and handle.

All in all, there was a lot of good progress made this run and this is getting closer and closer to looking like a real game. Whats next would be just to continue expanding on the inventory/item system. Maybe adding consumables or weapons.