Inventory System Overhaul: High-Level Proposal

[natsirt721]

I have been giving this a good deal of thought in the last week or so, and decided to get all my thoughts down on paper. This is intended to be a comprehensive proposal for inventory overhaul, and is based on #23978.

Containers and Containing

Containers will see some minor changes, but the underlying mechanics will stay largely the same. Container flags for fluid containment will be expanded for general use with solids.

• SEALS: Container can be sealed. This will now apply to things like boxes, to indicate that they are a valid container for storing dry goods as well as fluids.
• WATERTIGHT: Container can store liquids. If a container does not have SEALS, it can only store liquids when on the ground or wielded (this behaviour is unchanged from the current experimental build).
• COLLAPSIBLE or EXPANDABLE: Inverse of rigid. More items are rigid than not, so rigid should be the norm. Container expands to fit its contents. Container has an empty volume and a storable volume. As contents are added, the volume increases as (empty_volume + contents_volume). When full, the container has a volume of (empty_volume + storable_volume). If the container is a worn container, encumbrance will scale with the volume of the contents.
• OVERLOAD: New flag. Indicates that the container can be filled up to 1.5x its rated volume under certain circumstances, at the expense of significantly increased encumbrance. Overloaded containers will not be considered sealed for purposes of containment, and this flag should not be used with and/or doesn’t apply for fluid containers. See below for details.

Overload Flag

This flag is intended to be used with wearable containers such as backpacks, to allow the transport of singular high-volume items. This is to compensate for the fact that the new inventory system will result in many, low-volume containers which could make transporting high-volume items impossible. The container can only be overloaded if it contains a single item whose volume is at least 0.5x that of the container’s maximum storable volume - you can’t put 10L of marbles in a 7L bag, but you can put a 10L log in if you let it poke out the top. Items can still be added to an overloaded container, as long as the resulting volume does not exceed 1.5x the base volume of the container. This will have to consider stacked items - such as rocks or marbles - ineligible for overloading, as the individual volume of a rock or marble should disqualify the entire stack. Overloaded containers will apply a significant encumbrance penalty, either a flat percent if the container is overloaded, or scaling with the excess volume. Example below:

Consider the following items:

• Backpack, volume 7L, overloaded volume of 7*1.5= 10.5L.
• Log, volume 10L
• Rocks, 0.25L each, stackable

1. Start with 4 rocks in the bag, cannot add the log because the new volume (11L) is greater than the overloaded volume of the bag.
2. Remove 2 rocks, add the log, volume is 10.5L and the bag is overloaded and full, is no longer considered sealed, and incurs a large encumbrance penalty.
3. Remove 2 rocks, bag is still overloaded, but now has 0.5L of space.
4. Add 1 rock, bag is overloaded, still has 0.25L of space
5. Remove the log, bag is no longer overloaded, and can store up to 6.75L of additional items normally, or an additional 6.75L of items PLUS one item of exactly 3.5L overloaded.
6. Can add up to 27 rocks (6.57L for a total of 7L), but no more because each rock’s volume is less than 7*0.5=3.5L.

Food

Food will have to be stored in a sealable container of a suitable size, or else will rot faster than normal. This will take advantage of the recent change which applied a shelf life to most forms of food. Certain tiles, such as a minifridge or root cellar will negate the unsealed rot penalty in addition to extending the shelf life. If the food is in a container with items of a dissimilar material, the penalty will still be applied. This allows for large containers such as backpacks to be considered sealable, but require the player to individually package fruits and meats contained within. OTOH, a backpack full of raw meat is a valid storage solution, and will not apply the rot penalty. The increased rate of rot, and the threshold for considering a container full enough will be an implementation decision, with the penalty itself possibly dependent on the food itself. This solution uses the rotting mechanic as a proxy for ‘dirtying’, which seems acceptable as the outcome of both is inedible food.

Worn Containers

Worn containers will behave much in the same way as other containers, with one major change. Each worn container can have distinct pockets, each with their own volume and flags. For instance, a camelback item would have one pocket with seals, watertight, expandable, and a storable volume of 1.5L to represent the ‘wet’ pouch, and another pocket with seals, expandable, and a storable volume of 1L to represent the ‘dry’ pouch. This removes some ‘special’ pockets such as a magazine pouch, and treats all pockets the same.

‘Special’ Pockets

Certain worn containers will remain as ‘special’ pockets, only able to carry a certain subset of items. These containers include scabbards, holsters, ammo bandoliers, and other wearable containers specifically suited to carry certain items.

Item Accessibility

Item accessibility determines the difficulty for the character to get the item from its container into their hands, in order to wield/wear/throw/reload/eat/use the item. For demonstration purposes, accessibility will be calculated in units of ‘accessibility points’ (APs), where more difficult to access items have more APs - these will be translated into move costs when the specific equations are created. Accessibility is calculated independently for each item, and is broadly dependent on three things.

Base AP of the Container

Base AP measures the ease of getting to the items in the container. Whenever a container is accessed, the container adds its base AP to the cost of access. For nested containers, the base AP for each is added to the pool, perhaps with a stacking penalty for deeply nested containers.

• Simple containers like a box or bottle will have low base AP - to access their contents, open a flap or unscrew a lid. Containers such as a sealed can or vacuum packed food will have higher base AP - they must be unsealed which takes time.
• Worn containers such as ammo pouches or pants pockets will have a moderate base AP - They are easy to access, but some dexterity is required.
• Worn containers such as a backpack will have a high base AP - one must take off the backpack to search through the rear pouches. Using the example of a camelback, the ‘dry’ pouch would have a high base AP, but the ‘wet’ pouch would have a low base AP due to the water hose dangling over the shoulder.
• Overloaded containers will have additional APs added to their base AP, proportional to encumbrance (i.e. flat or scaling with overloaded volume).

Volume of the Item

When selecting an item, the relative volume of the item versus the filled volume of the container will add APs. Additionally, the absolute volume of the item will add APs. This effect accounts for the time costs associated with both finding and removing an item:

• It is harder to find a single small item in a large pool of other items.
  • Finding a single codeine pill in a backpack full of marbles is tough, but finding it in an empty backpack is much easier.
  • Finding a car battery in a backpack full of marbles is easy, because the battery is a larger percent of the filled volume of the container.
• It is (in general) harder to remove a large item from a container, regardless of the size of its container.
  • Removing a single codeine pill in a backpack full of marbles is easy once you have found the pill, just remove your hand.
  • Removing a car battery from a backpack full of marbles is harder, because the large battery is colliding with the marbles as you try to remove it, and you may spill marbles out of the bag if you are not careful.

The 'filled volume' will only consider dissimilar items, so 1 rock in a bag of rocks will be considered 100% volume, and incur no finding cost.

Encumbrance

Encumbrance penalties account for the loss of manual dexterity and flexibility necessary for manual actions.

• Hand encumbrance is the primary driver of this - it is much easier to perform dexterous actions with no gloves than with over mitts. This penalty might scale with the volume of the object being retrieved - grabbing a pill with oven mitts is significantly harder than grabbing a pan. Additionally, encumbrance below a certain point could add negative APs to the pool.
• Arm encumbrance can also affect this to a lesser degree - encumbered arms are harder to move to the worn containers than unencumbered ones. For equally encumbered arms and hands, I would expect this to apply around 30 to 50 percent of the penalty that the hands apply.

Dexterity

Once the total cost in APs is calculated, the character’s dexterity stat would apply a percentage modifier to the APs - the actual percent would be capped with a lower and upper bound to prevent abnormal dexterity from totally negating/insanely inflating APs.

These three factors accounts for the main aspects of finding and removing and item in a container, i.e. effects from the container(s), effects from the item itself, and effects of encumbrance. Whether or not they linearly scale with moves (as this proposal outlines) or not is a design choice for the developers, in the interest of game balance I won’t attempt to determine this.

Storing Items and Inventory Management

The above mechanics detail item removal from containers, and should work adequately well for item insertion. For inventory management, the following modifications should be applied.

1. Base AP is only calculated when an item is removed and inserted into a container.

• Moving an item from a box in a bag into a bottle in the same bag only adds AP for the bag once.
• Moving multiple items to/from a container only applies AP once for each container, per remove/insert.
  • E.g., in rearranging the inventory from bag1>box1>item1 and bag1>box2>item2,item3 to bag1>box1>item2,item3 and bag1>box2>item1, the following base AP costs are applied:
  • Bag1, for accessing its contents
  • Box1, for removing item1
  • Box2, for inserting item1
  • Box2, for removing item2 and item3
  • Box1, for inserting item2 and item3
• Alternatively, each box is only added once for access, rather than twice for insertion and removal.

2. Relative volume penalties are calculated using the volume whenever the operation is applied. If the operations are performed in the order that the player does them, a clever player could potentially minimize volume penalties by moving large items before smaller ones, but this would not be an advertised mechanic, and the benefits will probably be negligible.
3. Encumbrance penalties are applied once for each container access, in the same way as base AP.
4. Dexterity scaling is the same as above.

Inference and Management

This is perhaps the most challenging aspect, designing an system and interface which allows the user exactly enough control over their inventory. The original issue identifies three levels of management; inference, macro, and micro. I think these can be reduced into two concepts, simple and advanced, combining aspects of macro with the other two.

Simple Management Mode

Simple inventory mode lets the game decide where items go when they are added to the inventory. Containers can be tagged with item categories that the game will consider when filling containers, and tagged containers will try to be filled with items that they are tagged with before putting other items there. Certain items (mainly ammunition) will be placed in containers with lower base AP. Food will be placed in sealable containers, and the game will try to fill sealables with food first to negate the rotting penalty. If there are items of the same category in an existing container, try to put matching items there (category autotagging). After these rules, the game will try to minimize the number of moves/AP spent adding items to the inventory. If the accessibility algorithm is constructed well, using AP as the objective function should produce reasonable results. After an inventory operation, the player gets a free inventory sort action, allowing the player to correct the system if they didn’t like where some items went. This action replaces the pickup action’s move costs, allowing for more or less points to be spent, but must be taken immediately following the inventory operation.

Advanced Management Mode

Advanced inventory is similar to simple inventory, except items which do not meet container tags are explicitly placed by the player. Additionally, containers are not auto-tagged when they get something that is contained (could be an options menu option). For full manual control, the player set no tags on any container, and assigns each item to a container by hand. Players using auto-pickup are encouraged to set tags so that auto-pickup doesn't trigger the manual inventory insertion dialog every time.

The Interface

The inventory interface will have two modes, flat and tree, which can be toggled using TAB. Flat mode is essentially the current inventory interface, with items sorted by category on the left and clothing on the right, and is the default view when using simple management mode. This allows for a quick overview of the inventory, and quicker (fewer key presses, not fewer moves) access to specific items. Tree mode is a tree, where the top nodes are worn containers, and the leaves items or sub-containers. Containers with multiple pockets (e.g. backpack) will have one node for the container itself, followed by leaves for each pocket, each with its own contents. Singleton containers (e.g. can, box) will have one node for the container, and leaves for each item within. Worn clothing without storage appears at the bottom by default, but can also be moved around the inventory. If clothing is moved from the root level to a container, it will be take off, and worn if it is moved from a container to the root level.

Advanced uses of this include special nodes at the top of the inventory. In advanced management mode, when items are being manually added to the inventory, a node with the items will appear at the top. The currently wielded weapon will appear as a leaf to a ‘Wielded’ node. If desired, the 9 adjacent tiles can also have their own nodes, which allows for similar functionality to the current advanced inventory. This allows for the player to sort items in containers on adjacent tiles.

Key commands in tree mode are slightly different to accommodate the tree structure. All items can be examined using RETURN/ENTER, and examined pockets will show their parent item. Forward slash (replacing filter, in flat view) will open a mini-menu where containers can be tagged with item categories or specific items, which the game will consider when adding items to the inventory. In addition to manual tagging, the menu will have two auto-tag options which will 1) add a category tag for each item of that category in the container or 2) add an item tag for each item in the container. Containers can be collapsed/expanded to hide/show their contents using Left Arrow, and items are selected for movement using Right Arrow. Items can be moved up and down the inventory after being selected using Up and Down Arrows, and placed using Right Arrow again (a-la armor sort menu). While an item is selected, containers can still be collapsed and expanded to more easily allow for item movement. In the header, the total cost in moves is tabulated as the items are rearranged, so the player can see how expensive their inventory operation is. When the inventory is closed, move points are spent to rearrange the inventory based on the rules defined in Accessibility. The inventory will remember which containers are collapsed and expanded each time it is accessed.

Implementation Decisions

This is a list of all the proposed concepts whose values could be modified for balance, ordered by section.

• Containers and Containing
  • Overloading
    • Maximum overload: Flat percent of base volume, or per item?
    • Overloading encumbrance penalty: Flat if overloaded, or based on extra volume?
    • Overload size: Minimum item size to qualify for overloading
  • Food
    • Spoilage penalty rate: Flat percent of base, or per item?
    • Container packing: How to determine if a container is a food container (and not apply the rot penalty)
• Item Accessibility
  • Mechanics
    • Specific translation between AP and moves (obviously)
    • Exact calculation of AP based on contributing mechanics
    • Extra AP penalty for deeply nested containers?
    • Volume/relative volume AP costs
    • Encumbrance AP costs
    • Dexterity AP modifier
  • Inventory Management
    • Same as above, but for inventory sorting
• Inference and Management
  • Simple Management
    • How hard does the game try to minimize moves/AP for operations?
  • UI
    • Specific UI elements/layout
    • Keybindings

This is quite the text dump, but I think it covers everything to an adequate level of detail.

[CoroNaut]

The finding costs for grabbing an item from a container are nice, but maybe wait until 1 second game increments are implemented? I'm not sure how well it will work either adding increments of 0 or 6 seconds for a 2-4 second finding action.

The tree-level interface for containers sounds really nice, I hope you allow it to be on the ground with stuff inside.

[kevingranade]

I'm not a fan of the overloading concept. The fact that splitting up inventory means the player will have less capacity available is expected and intended.

Food spoilage is currently based on most foods not being stored properly, adding better containers will generally extend it.

In general I'd prefer to avoid adding extra features (overfilling, food spoilage adjustments, ecumbrance changes, access time changes) based on the inventory overhaul until the inventory overhaul is done. Doing everything at once is a recipe for completing nothing. Designing the system is fine, just dont implement it.

In other words, don't implement anything outside of inference and management.

[natsirt721]

I'm not a fan of the overloading concept. The fact that splitting up inventory means the player will have less capacity available is expected and intended.

Fair criticism, this can be something that is implemented later if it is deemed necessary.

Food spoilage can proceed as outlined, just in an inverted fashion (bonuses for proper rather than penalties for improper).

As for implementation, this was intended to be a comprehensive rework of the inventory based on the needs outlined in #23978; whether or not it is implemented all at once is irrelevant, assuming that this establishes an outline for future work. Although, I disagree with implementing just the management system - I would do access time as well, because that the simple inventory uses minimizing access time as an objective function. Doing the inventory inference mechanics without access time would require development of a throwaway algorithm, so I don't think it makes sense to do those asynchronously. However, the rest of the proposal can be implemented as needed.

@CoroNaut I don't see what the problem with implementing access with 6 second turns is, seeing as how (as I understand it) the move points system effectively subdivides the turn already. If my understanding is incorrect, please elaborate further.

[CoroNaut]

When I wrote my previous comment, I was considering the extreme case of storing every unique lowest-volume item inside a single backpack that could fit, and finding it. I think I can say that the finding time will be very high for such a search, meaning your time will be close, if not above the 6-second increment (~100 move points) which is enough for enemies to move closer to you. any search cost below the amount of move points you have remaining would be free (allowing you to grab such an item, and defend yourself with ease). If 1-second increments were enabled, we would see the character have to make a choice on whether to actually grab whatever they wanted or prioritize fighting the enemy because they know that the time for finding such an item would allow the enemy to attack them.

Of course my case is in the extremes, however, it can be applied to any case with a finding cost less than however many move points you have left (to not trigger the next turn). 1-second increments would eliminate this issue(mostly) because you know you would have a high chance of triggering the next turn for longer than average search actions.

It's possible this is not an issue in your eyes, and is just a side affect of the turn system.

[kevingranade]

Not really an issue so much as personal notes, if you return to work on it feel free to reopen.