Over the past few days I’ve been adding an inventory system to the Adrift prototype. The inventory is pretty standard at the moment but I thought I’d go into the base ideas that I’m using to construct the system.

Over the past few days I’ve been adding an inventory system to Adrift. The inventory is pretty standard at the moment but I thought I’d go into the base ideas that I’m using to construct the system.

Basic features

The inventory system does the basic features for what I would consider a “usable” inventory in a game like Adrift:

You can drag items around the inventory slots

Item types have a maximum stack size

When items are dragged onto items of the same type, the stacks combine up to the max stack size

When you drag and drop items outside the inventory area they are removed from your inventory

Collecting items from other inventories (like storage lockers) shows the other inventory on the right, allowing players to just drag from the other inventory to theirs easily

Splitting a stack is just a matter of right-clicking and selecting the size of the stack to create. Doesn’t limit the player to just halving the stack.

In addition to this, when items are consumed from the inventory (player eats food, uses cable to repair power system) the items are deducted from the smallest stack first which maximises inventory space usage in the long run (unlike games like Rust which consume from the biggest stack first, meaning you could end up with 5 stacks of 2 arrows, which is wasteful of inventory space).

Inventory layout

For the moment I’ve decided that an inventory container is just a grid of inventory slots (size depending on the inventory template). This is very common approach used by many, many games and therefore has the least amount of effort required to understand it for players.

Player inventories do have six hotbar slots however, and that’s where I want to play with alternate ideas. One idea is that I want players to select which item they want to equip from their actual belt, so if they press a key, they look down, click on the visible item on their belt, and then they equip it. This would hopefully remove the need for a hotbar UI and make it feel a bit more “real” as well as adding consequences to walking into a situation without the right tool equipped.

How does this affect inventory layout? Well when players drag an item from their inventory to their “hotbar”, I want them to actually drag it to their belt (rendered in proper 3d) and see it attach, reenforcing the idea that their inventory is not just magical boxes, but they’re real items. Later, I’d like to explore using a backpack as the inventory and render each item in 3D inside the grid. But that’s later on..

Inventory should not just be for the player

When I think of an inventory, I think about the base concept of “a collection of items in one place”. When you think about it, many types of things have an inventory.. players, backpacks, storage lockers, machines and so on. So why treat each one differently?

In my approach, an Inventory Container can be attached to any entity and the UI to display & interact with the Inventory just works off an InventoryContainer with no knowledge of what it’s for (player, locker, etc).

Using this approach, inventory items can be exchanged, consumed or credited the same way for everything and that makes it extremely simple and effective. Just how I like it.

Machines use inventories, too

Following on from the previous section, machines will use inventories for their operation as well. Fabricators will consume items in their inventories to fabricate items for players, Life Support modules will consume raw materials in their inventories in order to scrub CO2 from the atmosphere, etc.

The potential of the inventory system enables very interesting scenarios for the future and I’m glad to have it up and running so quickly.