The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Inventory Management in Video Games

How inventories work in games and some modest suggestions to improve them.

Crafting and inventory systems provide a good time-sink to have players pick up items, spend a bunch of time figuring out what to do with all that junk, and then craft some of it into even more junk they also have to deal with. The UI is often clunky and needlessly repetitive, making it more of a chore than it needs to be.

Most game inventories are one of two kinds, depending on how carry-weight works. Some games assign each item a weight and add up the cumulative weight of the inventory, and above some value the player is encumbered or overburdened. Other games simply have a finite number of item slots and stack limits on how many of the same kind of item can be in one slot, and once filled, the player cannot pick up more items.

The carry-weight game is somewhat more realistic, but it also tends to be more tedious to manage than slot-based games. For example, a common problem is storing items. How it currently works:

  1. Open a container and select the item to store.
  2. If the number of that item is below some threshold, you can only transfer one at a time. (A side problem of this system is they don’t explicitly say the UI works this way. You just find out through use.)
  3. If the number of that item is higher, you’re given a clunky way to select how many to transfer. (Either a scrollbar or up and down arrows to increment/decrement to select an arbitrary number.)

There are several improvements possible:

  1. Provide a grid of all choices. This is easier than getting to the right number by incrementing or decrementing or a slider.
  2. Allow the player to specify a retain value: the number of the item to not store. In systems that use carry-weight rather than slot-space, the user doesn’t want to carry 1000 units of even light items because that adds up. Let them specify how many to keep once and they don’t have to bother choosing.
  3. Temporarily create an escrow column to list the items changing places. This makes it easier to undo mistakes because the items haven’t vanished into the long list of items in a container.
On the left, a pair of arrows above and below a number shows a normal selector. On the right, rows of ten shows an improved alternative.
Example of picking the specific number of items by displaying full rows of values.

Another issue with carry-weight tends to arise in sorting. They either sort by stack-weight or individual item weight. In the stack-weight case, the problem arises when you start transferring from the stack and its collective weight drops enough to reposition it in the list. Suddenly you’ve lost that item and have to go find where it was. That would be fixed by ensuring, even for a low stack-count, that you can transfer exactly the number you want. The retain value would do that.

But sorting by the weight of the individual item is worse. You could be carrying a billion pocket lints and yet the sort does not put it at top, so you have a much harder task of figuring out what’s weighing you down.


One of the things games could consider doing is providing configuration files for these kinds of things. It would be fairly trivial to implement and players could easily write their configs offline and reuse them across playthroughs, share them, etc.

Inventory management isn’t supposed to be a chore, and making it more universal and do more work for the player is something that developers should think about.

More Spatial UIs

Computers don’t present to humans in the most natural ways, but VR may give us the opportunity to change that.

If you’ve ever played the kid’s game Memory, you would probably cringe playing it on a computer desktop, with each card being its own window, non-tiled, overlapping. Or what if you played it by picking a card, choosing a filename, then having to remember the filename to remember the card.

Studies have shown taking pad-and-paper notes beats typed notes for memory recall. Part of the reason for that is likely the spatiality of the notebook. If you had students write or type the same material, then ask them where something was in their notes, I bet the writers would beat the typers on anything that wasn’t on the first screen/page of notes or the last.

That’s because in a long text document the middle becomes a blur. There are no signposts. That’s why programmers use line numbers, to give them back signposts, but even these are somewhat cumbersome, the longer the document gets.

When you’re writing and hit the end of the page, you move to a whole new page. When typing (depending on the editor), you may just get stuck at the bottom of the file. So-called word processors do better, usually putting you on a new logical page at the top, but most text editors and IDEs I’ve seen simply keep you on the last line of the file, at the bottom of the screen.

When you’re reviewing a dead tree document, handwritten or not, you can flip pages and again get something akin to landmarks. With a digital document, you have this endless scroll, where everything in the middle is middle. It would be like drinking out of a straw in a wall, not knowing how full the reservoir of drink behind it was. After the first dozen-or-so sips, you sort of assume you’re in the middle, until you hit the gurgle at the end.

Some books even have chapter styles that have printing on the margin edge of the page, making it easy to see where chapters begin. You can see if you’re about to start a long chapter, and postpone until you have time. With a computer, it could mark the scroll positions of the chapter breaks, but as scrollbars vary by the length of content it would still not be as calibrated as a book.

The same goes for notecards. You can fan them out on a table, shuffle them, stick them on a wall. They are great spatially. But try to recreate those options with a computer and you usually either shrink their size or distort them. You lose their spatialness.

That is the real promise of Virtual Reality: bringing enhanced spatial awareness to computer interfaces. It’s not clear whether or not we could have the same enhancements without VR, but it’s at least likely that we could. The difference with VR is that it more-naturally fits that sort of interface, and it also provides a reset of expectations and aspirations for design, allowing people to experiment and find the spatial uses.

Canonical and GNOME

Canonical Limited (the main driver for Ubuntu Linux) and the GNOME project couldn’t work together so they are each moving forward with their own, reinvented desktop interfaces. GNOME is going for gnome-shell and Canonical/Ubuntu will get Unity.

Removing the minimize button?  Not giving a preference to turn off the display and not suspend when you close your laptop?  Moving the window controls to the other side of the window? Making the tabs square instead of round? Not allowing the editbox to be manually resized? Hiding the RSS icon? Moving the link preview to the URL bar? Removing the status bar?

And those are just the ones I can recall at the moment.

The computer is so central to peoples’ activities, that there is a certain fear that someone will break it for them.  That’s one of the major motivations behind Free Software in the first place: if I can build it myself, then you can’t force me to use the broken one.  If I can’t, then MicrosoftAppleSonyPaypalMastercard can up and decide to force their will upon me, and my recourse is simply to stop using them.  No stabbing big corporations with a fork.

Canonical Limited (the main driver for Ubuntu Linux) and the GNOME project couldn’t work together so they are each moving forward with their own, reinvented desktop interfaces. GNOME is going for gnome-shell and Canonical/Ubuntu will get Unity.

I don’t think this is a bad thing, excepting the bickering.  The larger community of desktop Linux users will get to see two different approaches in the wild for at least a year, which will inform the next iteration of the Linux desktop landscape.  There’s also an open-ended possibility for reunion later.

The dispute is territorial, which is not uncommon in open source.  The uncommon part of this is simply that it’s between two big players rather than between one big player and the users.  Though, the latter has occurred for both reinventions as well (see a few of the questions posed in the first paragraph).

Project governance is hard.  Cooperation is hard.  Finding the best way is hard.

If it weren’t for the bickering, nothing would be wrong.  There’s too much distrust and fear, because that’s what we’ve been taught by the proprietary realm.  When we used proprietary software, we could be stuck with a bug indefinitely.  Or things could change with no warning.

So we’re edgy.  But when the source is open, we shouldn’t be.  And if we weren’t, it would make project governance easier, it would make progress easier.  We should be willing to give the code an honest run.

At the end of the day any shift in any system will require a new equilibrium to be reached.  In open source that means some users will switch, forks might be created, etc.  But it also means that most users will find a slightly better workflow, will be a little (or a lot) happier and more productive.

I just wish that the developers weren’t so quick to assign blame, because they’re both building the foundation for the future, and they should be proud of their efforts even if they fail.