Inventory System Overhaul - High-Level/Design Concepts

[uqrs]

Inventory System Overhaul - High-Level Concepts

This post is part of the Inventory Overhaul, please check the main post for more information.

This issue concerns itself with the general design aspects of the new inventory system: how should it work, and how it should be presented to the player from a theoretical/gameplay perspective. This shan't involve any code or technical aspects: only design.

Please discuss down below- when the discussion reaches (some sort of) conclusion, I'll generate a report outlining the new inventory system in detail based on feedback.

The design goal is to implement an inventory system that:

• Has individual storage items (such as backpacks and duffel bags) instead of a single flat inventory whose volume increases as you equip clothing.
• Is to be presented in a simplified, flattened manner- letting complex micromanagement be an option, rather than the rule.

Inference, Macromanagement, Micromanagement

I present three individual levels of interaction for the inventory, each suiting different kinds of playstyles/players.

• Inference, the topmost level (and the default): the inventory attempts to make smart, informed decisions on where to allocate items and how to manage individual containers. The UI would - for example - attempt to present the inventory in a flattified by-category view that allows ease of understanding, and minimal player involvement in complex inventory management. The inventory would - for example - decide for the player what newly picked-up item to put where.
• Macromanagement, giving player control over the inventory's complex, per-container nature in a broad, easy-to-use manner. The player should be able to make decisions such as "reserve container X for items of category Y", or "these (categories of) items should be labelled 'quick-access', and should not be stashed anywhere slow/hard to access"
• Micromanagement, giving the player absolute 100% control over which item to put in which containers: would provide an inventory view that lets players move items about, back and forth to/from whichever container the player desires, including more complex versions of Macromanagement concepts that might be more esoteric and specialised.
  Note that these three terms refer to design concepts, and will not be explicitly divided up/separated in-game: these provide some kind of foothold for theoretically formulating ideas and functionality for all kinds of players. Do also note that these design concepts are not 100% absolute: the line between Macromanagement and Micromanagement may blur in some areas.

Design Goals

This is the general draft for the way the inventory system should work, this is mostly the result of my own ideas/planning along with a small discussion with kevingranade.

General Overview

Ensure the inventory system is no longer a flat inventory built into the player, whose volume increases with worn clothes. The new inventory system must instead have individual containers that have their own built-in inventory.

Inference: the user can access this inventory in a way that's mostly similar - if not equal to - the current system: a flat inventory view sorted by category, that the player can use/drop/grab items with. The inventory manages most of the behind-the-scenes operations such as deciding which item goes into which container.
Macromanagement: an optional tree view is accessible for the player, that roughly shows which item remains in which container, the player may move items up/around the tree if they so desire.
Micromanagement: another optional view would be a combination of two windows, one displaying the containers the player is wearing, and the other the contents of one container. The player can switch between containers using > and <, move items explicitly to a container, select items in there, move them around, etc. Could substitute/merge with the Advanced Inventory.

Access Speed

The amount of time required to store/access items depends on the container, and where the container is located.

A backpack might take longer to access than someone's pockets, and a backpack within a backpack within a backpack will have the access time of three backpacks (or longer). Moving items from bag to bag takes time too.

Item Pickup

Ensure that the inventory system can infer which picked up item should go where, unless the player chooses to interfere.

Inference: the inventory system makes a couple guesses based on the volume's item and weight, and general importance. For example, it might attempt to put a gun, or grenades in a easy/quick-to-access pocket, while putting items such as iron lumps or empty bottles in less important bags.
Macromanagement: the player may quick-tag or change the broad behaviour of some containers: players may tag/rank certain items as "quick-access" to prioritise certain items being put in certain bags. They may allocate or assign certain categories of item to certain containers, put items in the "last selected container", etc.
Micromanagement: the player will have access to more esoteric, complex forms of item allocation: they may allocate certain items in certain bags, have items be distributed evenly, limit the amount of items in certain bags, etc.

Other Tweaks

Rigs, Pockets

Certain items such as chest_rigs or pants may - for example - only allow X amount of separate items, each with Y maximum volume- kind of a way to emulate separate pockets.

"Quick-stack" & "Quick-stack to surroundings" & "Quick-stack to surroundings by category"

There should be a function that attempts to sort the player's inventory, stacking items whenever possible. There should also be accomodations to instantly empty the players' inventory to nearby tiles, for example by - should the player have 8 plastic bottles - look around the environment to look for a stack of plastic bottles to deposit these to.

[Shoes01]

Has discussion about this been happening elsewhere? It's a shame such a good start to an important issue hasn't been met with more vigor.

Regarding inference, I would the following steps should work:

0. If the inventory is empty, place item in the smallest rigid container. If there are no rigid containers, place item in smallest nonrigid container. If there are no containers, the item is worn/wield (confirmed via prompt). If the item cannot be worn/wielded, inform the player it can't pick up the item.

1. When a container receives an item, it adopts the item's "category" as its own. When the container is emptied, it forgets its "category".

2. When an item is picked up, it is placed in a container with which it shares a "category". If that container is full or there are no containers with that "category", find the next smallest rigid container. If there is no rigid container, etc. (see step 0.).

3. Allow the player to assign a "category" to a container. This is done manually via the UI, or when the player moves an item to a container (the container's "category" becomes the item's "category"). This happens regardless if the container is not empty. When the container is emptied, it does not forget its "category".

Rationale for step 0: we don't want to have a bunch of items with a little bit of space left. Fill up items as much as possible before moving to new ones. Start with rigid containers, as they are already taking up space even when empty.

Rationale for steps 1 and 2: Ensures that similar items are grouped together. What I mean by "category" is detailed below.

Rationale for step 3: Allows the player to "teach" the inference system where it wants what items.

The only issue with this heuristic is the nebulous use of "category". Is there a way to define categories without overthinking the system? Off the top of my head: category by size, category by "crafting tab", category by use. Choose up to one of each.

[uqrs]

"Discussion" has mostly been happening off-screen: the occasional conversation with Kevin or other contributors
on the official Discord server. Aside from that, I've mostly been
accumulating notes and ideas as I continue to try and make sense of the
current inventory system. Progress is occurring, albeit slowly.

Above Points

I'll go down your points one by one:

Inference

0. This would be an adequate default solution given the caveats that:
   • This item isn't set to be ""preferred"" for other containers already.
   • I feel like certain other criteria besides rigidity should be
     considered. Among others:
   • Whether the container is watertight or not; it would be pretty
     dumb if the inventory system filled up all (rigid) small plastic
     bottles with random guff before it begins depositing these things
     into the backpack.
     • The access speed of the container-- bullets for example
       should not be stored inside a plastic bag contained in an eighth-level
       nested fanny pack.
     • Various other considerations that may come up down the road.
1. Is completely adequate for inference.
2. "
3. This very much falls under what I would call macromanagement-- assigning categories is adequate, so is
   tagging a container with "sticky categories" (always adapt category of
   whatever you dump in there, never forget even when emptied).

On the issue of Category

I feel like the current category system would be relatively adequate, given
that:

• The player can manually override a category if they so desire (micromanagement)
• Several sub-distinctions are made: bullets compatible with held firearms should receive quick-access priority over unusable bullets.

I am considering creating a flowchart of sorts to visualise and organise the
inference system and the choices it makes. Updates on this follow.

Several other issues/considerations

Free Correction

Kevin has suggested to allow the player to correct the inference system
manually: if the player picks up an item mid-encounter, they should be able to - for no extra movecost -
manually reallocate the item to a more appropriate container if they feel
the inference system failed them. Of course, the goal is to make sure this
would be needed as little as possible.

Access Speed - Item Size & Item Number

Another tweak suggestion: the access speed for a given item should
correspond to the size of the item (the smaller, the longer), and the number
of items it shares the container with: finding one specific fluoxetine pill
somewhere in a bag filled with LSD should take longer than retrieving a
big, steel bottle in a bag of pills.

Dynamic Encumberance

Non-rigid containers should have a base encumberance and maximum
encumberance, where the actual encumberance increases as the weight and
volume of the container does: an empty backpack isn't as encumbering as one
filled to the brim with pool balls.

[Shoes01]

Has anyone discussed the possible issue of this implementing "realism" at the cost of gameplay/dev sanity? I am thinking about both the First In, Last Out and the "hard to find things in a container full of things". For example, I pack a bag and put my socks at the bottom. I can quickly pull the socks out, messing up everything else, or I can carefully unpack the back, grab the socks, and repack the bag. Will this provide a meaningful gameplay experience? I don't think the effort in coding an Inventory that can do that will be worth it.

[muravey-omsk]

I don't think that order of packaging items is actual now. First of all it is necessary to implement basic interaction with containers. P.s. sorry for my English. пт, 12 окт. 2018 г., 0:28 Jason Gilbert <[email protected]>:

Has anyone discussed the possible issue of this implementing "realism" at the cost of gameplay/dev sanity? I am thinking about both the First In, Last Out and the "hard to find things in a container full of things". For example, I pack a bag and put my socks at the bottom. I can quickly pull the socks out, messing up everything else, or I can carefully unpack the back, grab the socks, and repack the bag. Will this provide a meaningful gameplay experience? I don't think the effort in coding an Inventory that can do that will be worth it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#23978 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACf7Q4uyR5ry3qeaHnGm-Z3rIswqvaHnks5uj3-7gaJpZM4UheCz> .

-- Алексей Смирнов

[Dansiman]

Regarding inference, I would the following steps should work:

0. If the inventory is empty, place item in the smallest rigid container. If there are no rigid containers, place item in smallest nonrigid container.

Rather than "the smallest container", use "the container with the least free space" for greater efficiency. If the player's 10L backpack has 9L of stuff in it, and their cargo shorts (1.75L capacity) are empty, a plastic bottle should be placed into the backpack, before the cargo shorts, when picked up - if the shorts were picked due to being a smaller container, then there'd be no place left to fit the makeshift crowbar they try to pick up next.

See the multiple knapsack problem, and related Wikipedia articles on combinatorics, for more on ways to optimize this kind of thing.

[kevingranade]

No activity for 3 months, closing in favour of #3671