Inventory System Overhaul

[uqrs]

Inventory System Overhaul

1.) General

This Issue serves as a general discussion point for the Inventory Overhaul.

The Inventory Overhaul is a project/undertaking that concerns itself with both

• The underlying inventory code that manages the players' items, mostly inventory.cpp and inventory_ui.cpp, which shall be subject to massive cleanup, simplification, and documentation: making it something that is not a pain to work/interact with.
• The actual gameplay element of the Inventory, and how the player interacts with it. This relates to the inventory system as it is presented in-game: this concerns itself with moving away from a singular flat inventory, and more towards individual containers and bags that the player carries.

This post will address both of these issues in the broadest of general terms, so that it may serve as an outline for more in-depth and detailed undertakings, which will be sequestered into their own separate issues.

This post acts as an overview/hub for this undertaking, and only contains broad strokes/a game plan. Actual in-depth discussions can be found in their own respective issues (found underneath each individual header).

Every single part of this post is up for debate and modification: most of the initial post is just me ad-libbing what "sounds" and "looks" good to me after a conversation with kevingranade: this Issue post serves as a central location for debate and discussion on the central design of this undertaking: as such. This issue post may be edited/receive updates whenever people bring forth good points/ideas/criticisms.

1.1.) Definitions

Within the scope of this Issue, some terms like 'high level' and 'low level' may be thrown around- these will be elaborated upon here so that we are all on the same page:

• high level refers to the abstract theory of how the inventory system shall function, and how it will be presented to the player. It involves gameplay concepts like containers, encumberance, turns, etc. It more focuses on the actual design aspect of this issue.
• low level refers to code: the C++ (and JSON) source code, the structure of the program, classes, functions, everything and all code-related.

2.) The Goal Of The New Inventory System

2.1.) High-Level Concepts

The new inventory system must - ideally - attempt to move away from the concept of one flat inventory for the player, and more towards a collection of smaller inventories bound to storage items (e.g. backpacks) that the player carries with them.

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.

I present here a broad, general overview of ideas/concepts for a new inventory implementation. Discussion on the specifics shall be held/can be found in this Github issue, along with an overview of (possible) In/Ma/Mi aspects of each individual piece of functionality.

• Ensure the inventory system is - internally - no longer a flat inventory built into the player, whose volume increases with worn clothes.
• The new inventory system must - internally - instead have individual containers that have their own built-in inventory.
• The new inventory system must be able to be presented both in a flat, by-category display, a tree-view, or a per-container view.
• Allocation/retrieval of items should be "smart" by default: minimal player interaction until the player chooses to intervene (make Inference the default design standard).
• A bag/container's volume and weight are affected by its contents:
  • Its weight is dictated by the cumulative weight of the contents.
  • Its volume is dictated by:
    • If rigid, the volume is constantly equal to its max storage capacity
    • If nonrigid, the volume is dictated by the cumulative volume of its contents
• The speed of accessing a container should be dictated by the container itself (grabbing something from pockets is quicker than taking something from a backpack)
  • Nested containers add up speed-wise: a backpack in a backpack in a backpack is slow to access.
  • Moving items from container to container takes time.

2.2.) Low-Level Concepts

While I have my general ideas about implementation approach, I feel like I'd be getting ahead of myself by elaborating upon these now, especially considering step 3 urges everyone to take this one step at a time: I'll post/edit in my own ideas after Step 3.1 and 3.2 have been taken care of.

3.) The Plan

I urge myself (and everyone willing to assist) to - for the love of god - take this one step at a time. This is a big undertaking, and getting ahead of ourselves (programming/implementing before we've agreed on general design) should be avoided, as it can cause miscommunication and bumps in the road. Step 3.1 and 3.2 listed below can be done simultaneously, as they are mostly separate in nature and concern themselves mostly with general planning. But every subsequent step should be done sequentially.

3.1) The current inventory system must be documented

I'm not talking about in-depth function-wise documentation, but the general broad overview of how the current inventory works should be written up and made available: this is to ensure that everyone intending to tackle the inventory rewrite is on the same page about how it works, and what we're replacing.

3.2.) High-Level design

See individual issue post for this topic
The actual design of the new inventory should be sorted out: general agreement on how it works, how it's presented, etc. should be generally agreed upon before any kind of programming should be done. The end design of the inventory system shall be presented in a report, published for everyone to access.

3.3.) Low-Level design - Planning

How are we implementing this in code? This refers to the act of both cleaning up and rewriting parts of the inventory system in the source. This should be discussed, and a general approach on code structure and general implementation should be agreed upon completely in order to maximise the chances of clean code emerging. A report shall be generated with the general structure and pragmatic approach for implementing in code.

3.4.) Low-Level Design - Implementation

Using the agreed-upon approach from step 3.3, the general broad strokes (the general inventory code, organisation, and classes) should be implemented, tested, and made sure that they are clean and stable.

Only then should the actual new inventory system be implemented/constructed from these building blocks. Ideally, the Inference and Macromanagement aspects of the inventory system should be implemented, stable, and usable. Then, Micromanagement aspects should be implemented (perhaps under a separate aspect of Advanced Inventory).

3.5.) Testing & Bugsquashing

Should the new system prove to be overly bug-riddled and gross, then _qrs shall stinkbomb himself and shave his head in shame.

3.6.) Pull Request

The new system must be extensively tested, tested, tested, tested, tested and tested beforehand, making 100% sure that it's stable, and can be merged into the main branch without causing any possible issues. To this project, there is no "ill clean up/check for bugs afterwards". It must be (close to) release-level standards before a PR shall be made.

4.) Documentation

The actual newly written code shall be painstakingly documented and elaborated upon- a report shall be written (on top of individual comments) that outlines how the new inventory system functions: it must contain enough details that the average programmer who knows nothing about the inventory code could read through it, and be ready to start making modifications and additions to the code by the end of it. This bears no actual effect on the rest of the overhaul process, though, and serves only to make further additions in the future easier.

[Night-Pryanik]

#3671 is for the reference.

[kevingranade]

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