Is there a standard way to create an inventory system with all of the modern ARPG features

This has been the hardest information to nail down. Its not as easy as just use the UI and store inventory in data and represent the visual information in the UI. There is so much to it.

A game like POE. Look at a bullet list of representations
-Items can be viewed in general grids

  • have differing sizes
  • have other items attached to them, and you and drag those items to other grids
  • removing items that are attached to another item
  • can be stackable
  • have stats that don’t apply to every other item
  • have durability and rarity
  • are types of currency
  • can be transferred
  • swapping items
  • finding good positions for new items that are added
  • context menus
  • tool tip content generation

The list can go on and on. I have been breaking this down on my in into smaller problems. It’s quite a nightmare. I didn’t mention saving.

What’s the best resource either to purchase or to learn from? AI struggles to understand these systems. I certainly struggle to understand.

Maybe it requires a team. This is certainly a trivial problem, but it also seems like several full-time efforts to manage.

Inventory systems are deceptively more complicated than you may initially imagine. It does require a pretty SOLID understanding of C#. And not just Unity specific C#, but just regular C# knowledge.

You can definitely write an inventory system that doesn’t use any Unity API’s at all, and still be able to use it in Unity, for reference. But it is easier of course to just code it in Unity, specifically for Unity.

And they do take a lot of code. In my current project, the items and inventory system is definitely the largest in terms of code-base size.

I mean some of your requirements are trivial, some aren’t. An inventory system is only as difficult as your requirements. And we know that in game dev, some things that seem simple turn out not to be.

What you do need to do is sort out the layers of responsibility, and the systems (API’s) you need to put in place to make it happen, and where each thing happens.

It does start with the items, though, and the data and objects (as in the O in object oriented programming) they express. Above that you have the actual inventory management system (purely in code), and above that is the actual user interface itself. But in the end it’s still just data (and objects), and presenting the means to interface with it.

An item’s size and whether they’re stackable: just points of data on the items themselves. Yet it’s the inventory management system that acts on this data.

Transferring items/swapping items: this at the end of the day is just compounding the actions of removing and adding items to containers.

Context menus and tooltips are again, simply data and objects that top-level user interface systems use.

Stats are (generally) immutable data on items. Durability is however a mutable data point. Once you have mutable data, you need a way to handle that in your items. Usually I use scriptable objects for immutable items, and pure C# items that allow for mutable data, with a common interface expressed by both so they can intermingle in together within the same inventory management system.

As you can see it goes on and on and adds up with every requirement. Ideally you try and implement systems that can kill multiple birds in one stone.

I mean if Path of Exile is your reference, they have a team of 100+ people. While probably only a few a handling inventory stuff, they are probably experts at this compared to us solo indies putzing about in our free time.

I don’t know any resources for learning this. I’ve learnt the most by just getting into it and starting to code. Then being critical of my results, thinking of solutions, and refactoring as needed. It does require a degree of creativity, too.

1 Like

Saving is probably the easiest part actually, if set up correctly. Because you’d have a tree of data collections with items (which in itself can be containers as you noted). Then it’s just a matter of recursing into this collection. Think of it as a Collection of Collections of Collections, where “Collection” could be anything, most commonly Dictionary, List, Array, HashSet.

Make a list of requirements for YOUR particular use case, prioritize it and work off of that.

I highly recommend developing the core inventory system solely as C# classes, not MonoBehaviour. And use unit tests to confirm that your collections behave as expected, ie you can’t add more than 3 items to a 3-slotted “insert gem” item.

Also you haven’t yet listed the transition of an inventory item to a world item (drop) and the opposite (pickup).

You can pretty much get any inventory system from the store, preferably several, to disect and learn from them if you want to make the system your own. But you can deduct from their descriptions and manual quite easily whether they will satisfy all your requirements. There are several capable solutions out there but I’m always wary whether the code is any good - there’s just too many popular tools that are just plain awfully architected.