I can try to give some rough details here. So, I had actually solved the inventory back in January of this year. That version mostly used the same idea and principle from the grid based inventory video I referenced in my initial post. Since then though I have been reworking the inventory.
I say that to say that video is still relevant to how I achieved it but its become less relevant with my current rework of the inventory.
In the new inventory Data for each object type is stored in a Data Asset. It could be stored in a Data table as well, but for the game I made the inventory system for Data Assets was the better option. The corresponding data is pulled and used by an “InventoryItem” class that is the physical representation of the item in your inventory. (It also holds user-changed/dynamic data as well since data assets cannot). In the old inventory it used child classes of a master item class to store the data for each item.
The new system adds items based on grid size availability and the grid size requirement of the given item. This is stored in the data asset corresponding to that item. If there is room available the given inventory. Removing the item is done by clicking on the physical representation of the item (InventoryItem class) and moving the item outside of the inventory grid. This spawns in the item and removes it from the inventory.
Saving the data is pretty easy to do. Each InventoryItem class has a custom Ustruct that holds all relevant information to that item (Data Asset to use, customizable/dynamic data, position in grid, etc.) When saving the game it creates an array and adds that struct data to the array for each item. When loading it does have to spawn in the inventoryItems and assign the appropriate struct information for each item. The spawning was significantly slower in the older system I did. Tahnks to the new system using data assets its much faster to get the required data and display the objects appropriately.
Sorting was not something needed for the game I developed this system for, but it could be added in fairly easily. Essentially whatever sort order you are trying to perform (Name, Type, etc) you would create a temporary array of all items and rearrange them to match that order. Then you use that array to remove and re-add those items into the inventory grid. Another option could be to go through the grid size and grid requirements of each item and calculate the correct grid positions for each of the existing items and just change those values in the original inventory. Most likely that method would be more performative, but take some careful math considerations. In my opinion the performance gain from that method would be negligible enough it likely isn’t worth it for most games.
I apologize I don’t know quite what you mean by constraints? If you mean limitations of this system then I think the biggest limitation is performance. Because each inventoryitem has to have a physical mesh to represent it, it will always be more resource intensive than a lot of inventory systems. Because of that I wouldn’t recommend this for a game where you may be collecting hundreds or even thousands of items. I experimented simply adding in static mesh components rather than a new actor to the inventory system but in my case this only slowed performance. You could possibly reconstruct one solid static mesh to represent the full inventory grid and then remove and add to that mesh as needed. However, after a lot of my own experimentation with procedural meshes and procedural skeletal meshes I wouldn’t recommend that.
I hope that helps and I’ll try to get something together to go into more detail at some point.