Explore and repair a massive alien ship and travel to planets as you try to survive your journey through an unknown universe. Scavenge what you can and try to find a way home, if it's even possible.
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.
Posted by JaseDeacon on Mar 7th, 2014
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.
The inventory system does the basic features for what I would consider a “usable” inventory in a game like Adrift:
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).
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..
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.
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.
(The next two are animated, click to view)