CleverRaven / Cataclysm-DDA

Cataclysm - Dark Days Ahead. A turn-based survival game set in a post-apocalyptic world.
http://cataclysmdda.org
Other
10.7k stars 4.2k forks source link

Render PALS webbing as a separate type of pockets, and list their contents among items worn #76272

Open Hyperseeker opened 2 months ago

Hyperseeker commented 2 months ago

Is your feature request related to a problem? Please describe.

Problem 1: Intangible Pockets

Currently, PALS/MOLLE pouches are rendered as a quasi-part of the item they're attached. This works well for calculations of available weight, volume, and number of holsters, as it provides the player with a clear view of their overall carrying capacity.

However, in this configuration, issues arise when it comes to user experience.

Problem 1.1: "But I don't want to hide everything!"

When multiple pockets with different purposes are attached to the same item, hiding the contents of said item could also hide items which the player may want to keep track of. For example, if having a flashlight in a flashlight pouch, and a dump pouch with high priority attached to a webbing belt. While the contents of the dump pouch may be irrelevant in the moment (its purpose is to collect magazines or other equipment for later sorting), the player may want to keep the flashlight visible in the inventory if its battery is running low, or because that's an easier way for the player to turn the flashlight on and off. Hiding the contents of the belt will hide both the dump pouch (irrelevant) and the flashlight pouch (relevant).

This issue can be navigated around in multiple ways. However, forcing the player to adjust their item-management strategies for reasons which aren't strictly-necessary (like if it would be detrimental to their character's encumbrance) results in a negative experience due to externally-imposed friction. In other words, users of any software would feel upset about having to worry about "avoiding" a "mistake", despite never making a mistake and having a reasonable idea that their way should work. In this case, the "mistake" would be placing both pouches on the same webbing which would then be either hidden entirely or shown entirely, with no middle ground.

Problem 1.2: "How do I insert this item in that pocket?"

With attached pouches not being directly accessible, players have to fumble with the (admittedly, powerful otherwise) pocket managament system in order to get the item into the right pouch. For example, getting that flashlight (now moved to the ballistic vest's webbing, which wouldn't ordinarily be hidden) into the flashlight pouch, rather than the preceding magazine pouch, canteen pouch, gas mask pouch... etc., until the space on the webbing runs out.

This, too, can be prevented through pocket management. Setting a higher priority on the pouch's pocket, whitelisting the flashlight on the dedicated pouch or blacklisting it from all others... Just like with the "all or nothing" issue above, however, this creates avoidable, unproductive friction for the player, with no pay-off or benefit.

Problem 1.3: "Can I detach this pouch directly?"

Lastly for pouches themselves, the player cannot remove a particular pouch directly from their inventory. They can do so with every other wearable item, including the one the webbing for which holds the pouch they want to get rid of.

Much like the rest of this problem, this part is about player convenience. Being able to directly interact with the pouch from one's inventory, and in particular to remove it from the webbing, would save on key presses every time. Over multiple playthroughs, this time and friction add up.

Problem 2: Unrealistic Webbing Capacity

At the moment, all webbing of a given item is rendered as a uniform shared grid, with every slot accessible to any pouch. An item may have 3 slots of PALS webbing available, and a PALS_LARGE pouch (like the triple stacker) can take up all three.

This runs against how PALS webbing is often distributed on real-life equipment. While there are rigs, belts, and backpacks where the webbing is uniform and consolidated, many "spread out" their webbing in order to maximize available pouch space while minimizing the encumbrance all the pouches (and their contents) would bring. This is particularly-noticable while browsing the aftermarket, but even the US military can provide us with a few example to review.

This is the MOLLE assault pack:

Side view of the MOLLE assault pack

It's an official part of the MOLLE II equipment program, aimed at providing US soldiers with sets of modular equipment which could be adjusted for each mission and circumstance.

In-game, it provides 6 slots for pouches[^1]. That's enough for 6 separate magazine pouches, three holsters, or two triple stackers, with each combination of pouch being able to rest on the pack comfortably.

However, from looking at the pack's appearance, it's apparent that the grid is nowhere near uniform. There are separate (though perhaps joinable) pairs of 1-slot webbing on each side, plus what may or may not be usable single-row webbing on the back. It would be impossible to attach two triple stackers, or anything else that takes up three columns, to this grid. A real-life triple stacker require 6 slots immediately-adjacent to one another, as you can see from this back view of it:

Back view of the Condor Triple Stacker magazine pouch

Problem 2.1: "How come I can reach over my back just as well as over my chest?"

In addition to the problem of capacity, PALS webbing doesn't account of the placement of self relative to the character's body. That is, a pouch placed on a chest rig (easily within immediate reach) will have the exact same move cost to remove its contents as one placed on the MOLLE assault pack.

Wield cost of the magazine inside a pouch on the pack...

...and on the load bearing vest

This is obviously unrealistic[^2]. Reaching for same pockets would be easier than others, depending on their placement relative to your arm's reach. However, there is currently no way to address this: as mentioned, PALS webbing is treated as uniform, with no separation to their placement or limitations.

[^1]: While balancing webbing capacity for PALS-capable items in Armory, I'm operating under the assumption that 1 in-game slot equals to 6 cells, usually in a 3-row by 2-column formation. This makes the most sense for larger pouches, such as the triple stacker; since nothing larger than that seems to be easily-available, I'd chosen this to be the starting point, and calculated all the other pouches in Armory based on this measurement.

[^2]: In case you need proof (welcome to Earth!), scratch your pec with your dominant hand, then scratch the same relative point on your back.

Solution you would like.

Webbing as Pockets

TL;DR: Allow defining PALS webbing as pockets within the carrying item. Such pockets would only accept compatible items. Each such item could describe how many slots it takes inside the pocket. Display such items among items worn by the character in the inventory when they're attached.

Proposal

Instead of an attach/detach action, PALS (and potentially other attachments systems[^3]) could be defined as pockets inside the item. For each separate attachment point (in the case of PALS: for each distinct grid), a separate pocket would be defined. For these pockets, most properties of generic pockets should be available; this would allow common restrictions (such as weight, volume, length, materials, flags...) to be applicable, without altering the pocket definition schema too much.

Each such "attachment system" pocket would fill up based on its slots value and the slots value of its contents (see below), with dimension-based restriction being optional. Each pocket defines how many slots of a particular attachment system it has. If no slots value is provided for the pocket, assume "slots": 1 for that pocket.

Items attaching to these pockets would define how many slots they take up. For PALS, one slot could be one cell, which would allow rendering realistic pouch capacity: a single grenade pouch would take up 2 cells, a MOLLE-compatible knife sheath – 3, while a rifle-magazine pouch – 6. If no slots value is provided for the item, assume "slots": 1 for that item.

A pocket would fill up on the "largest value" basis, much like pockets already do between weight and volume. For example, if one such pocket has a limit of 3 slots and 2 kg, and already has 1 slot and 1.7 kg occupied, another compatible pouch weighing 0.6 kg won't be able to attach even if it takes up 2 slots or less.

When attached, the pouches should be displayed underneath the item they're attached to in the "Items worn" section of the inventory. In this respect, they should be treated as if the pocket they're in has the ablative property[^4]. When navigating the inventory, the attached pouches should be selectable and interactable just like any other worn item. Each pocket could optionally disable the display of attached items: e.g. belt and items clipped to it are probably not quite as important as MOLLE pouches.

Advantages

Why This Should Be in the Game

Dark Days Ahead has been steadily moving away from its arcade-y sci-fi roots and towards a simulationist, realistic gameplay for a long time now. This proposal describes a feature that fits well into the increasing realism of the game.

This pocket-based solution to managing attachment systems should also provide an improvement to user experience of inventory management with modular equipment.

Examples

Example attachment-system pocket definitions:

{
  "pocket_data": [
    {
      "pocket_type": "ATTACHMENT_SYSTEM",
      "attachment_system": "PALS",
      "description": "Side webbing",
      "slots": 4,
      "max_contains_weight": "4 kg",
      "max_contains_volume": "750 ml",
      "volume_encumber_modifier": 0.66,
      "//moves": "both for attaching a pouch and for wield-cost penalty",
      "moves": 130
    }
  ]
}
{
  "pocket_data": [
    {
      "pocket_type": "ATTACHMENT_SYSTEM",
      "attachment_system": "PALS",
      "holster": true,
      "description": "Back pouch slot",
      "//slots": "effectively as permissive a slot as one can find, because it spans the entire back of the ballistic vest",
      "slots": 20,
      "max_contains_weight": "16 kg",
      "moves": 400
    }
  ]
}
{
  "pocket_data": [
    {
      "pocket_type": "ATTACHMENT_SYSTEM",
      "attachment_system": "velcro",
      "holster": true,
      "description": "Lower back hanging pouch slot",
      "//slots": "for Velcro, slots can be defined as a square area taken up by the hook-and-loop attachment point itself",
      "slots": 4,
      "max_contains_weight": "4 kg",
      "max_contains_volume": "2 L",
      "moves": 70,
      "flag_restriction": ["VELCRO_HANGING_POUCH"]
    }
  ]
}
{
  "pocket_data": [
    {
      "pocket_type": "ATTACHMENT_SYSTEM",
      "attachment_system": "belt",
      "description": "Length of belt",
      "display_contents": false,
      "slots": 16,
      "max_contains_weight": "6 kg",
      "max_item_volume": "200 ml",
      "moves": 10
    }
  ]
}

Example item's attachment definition:

{
  "attachment_data": {
    "attaches_to": "PALS",
    "slots": 2
  }
}
{
  "attachment_data": [
    { "attaches_to": "PALS" },
    { "attaches_to": "belt" }
  ]
}

[^3]: Existing systems include Velcro (aka hook-and-loop; for pouches, inserts, and decorative elements), QASM (for modular panels), ALICE (the predecessor for MOLLE), conventional belt clips (currently handled via the BELT_CLIP flag). Potential options include historical European military systems (e.g. Koppeltragesystem, aka KTS), proprietary ones from Exodii or Hub 01 etc..

[^4]: This is currently the case with ballistic plates.

Describe alternatives you have considered.

  1. Allow holster-based pockets to "merge" in order to emulate "slots" (1 merged pocket = 1 slot)
  2. Same as above, but bringing back the pre-pockets multi property
  3. A whole lot of holster pockets, each emulating a large slot, but only being able to take one pouch, regardless of how large it is

The initial implementation of MOLLE pouches in the reworked (current) version of Armory relied on a volume-based approach, where each pouch would be "put into" the webbing pocket. This resulted in terrible user experience if approached without careful management on the player's end: if overflowing with newly-picked-up contents, pouches would simply plop out of the webbing. This meant either frustration from having to manage your volume carefully, or frustration from losing a pouch with potentially-valuable contents (like a magazine full of ammo, a stuffed medical pouch, or a holster with a gun in it).

I'd initially posted a similar feature suggestion to Armory's desired-features doc. That proposal contains an alternative/complementary subfeature which uses area-based slots. Calculating capacity based on surface area would be useful for Velcro and similar flat-surface attachment systems. Providing two out of three physical dimensions (width and length, aka X and Y axes) wasn't difficult for me because I have been using dimensions to calculate volume since the very first mod I'd made for this game; referencing the comment with the dimensions would then make it easy to come up with the surface area the pouch/panel would take up.

Additional context

The previous proposal I mentioned in the other section also came with JSON-based attachment-system definition examples. I'm not including those here because I'm not positive they would be useful. Pocket systems like these would probably be implemented on the engine end anyway.

A good baseline for PALS cells per slot would be important: it would lead to rebalancing which would allow smaller pouches (like the hand-grenade one) to be relevant. Right now, they take up exactly as much space as other useful ones (like the single-mag pouch), while failing to provide as much utility. Being able to put two grenade pouches in the same amount of slots as a magazine pouch would make those pouches much more viable.

This proposed system could shine even more when separate move costs for storing item in and taking item out get implemented.

What an attached pouch might look like in the inventory (see Direct Action H-harness and its chassis; taken from an Armory implementation which uses ablative):

2024-09-08 00_35_17-Cataclysm_ Dark Days Ahead - 907998a

CoroNaut commented 2 months ago

Each pouch's contents could be hidden independently Each pouch can be immediately and directly inserted into

I love the idea so much that I'd like to suggest this be the case for anything with more than one pocket (backpack, rucksack, duffel bag, cargo pants, etc). Making this the default for all pockets would be even more amazing than just using it for molle attachable pouches. A pocket option per-pocket to hide or show that pocket from the inventory view would help keep clutter down and give the user even more quality of life.

Pockets define their own move-cost penalties, providing a semi-realistic simulation of reaching for a particular pocket

57679 may be fixed if each pocket were considered separately for determining move cost.

IdleSol commented 2 months ago

My personal opinion.

Problems 1.1, 1.2, 1.3 are not problems. In most cases, proper priority setting and whitelisting is enough.

Problems occur when you have “useful” and “useless” things in the same pocket. But this refers to improper or no prioritization.

1.1 and 1.3 can be seen as a positive side. I don't need a separate list of pockets, each of which needs to be hidden (not hard) and which takes up half the screen (which is important). And if selected incorrectly, will detach the pocket from its attachment point.

For example, I choose all the things to undress. I select all of them at once, not one at a time. If each pocket is displayed in the list of worn items, they will be selected and removed (separated from the base item).

Problem 2.1. I'm in favor of being able to specify where the pocket is attached, with sub body part accuracy.

I'm not sure about the penalty. No, it's realistic. And it's quite realistic to remove the backpack to put the thing away. But it is not convenient from the game point of view. And to make a penalty for the pouch on the back and not make a penalty for the backpack, just not logical.

IdleSol commented 2 months ago

Let's create a “tetris” in cataclysm.

{
  "pocket_data": [
    {
    "pocket_type": "ATTACHMENT_SYSTEM",
    "slots": "6 x 2",
    "covers": [ "torso" ],
    "specifically_covers": [ "torso_upper" ],
    },
    {
    "pocket_type": "ATTACHMENT_SYSTEM",
    "slots": "3 x 1",
    "covers": [ "torso" ],
    "specifically_covers": [ "torso_lower" ],
    }
  ]
}

    "torso_upper"             "torso_lower"
*********************          **********
*##*##*##***##*##*##*          *##*##*##*
*##*##*##***##*##*##*          *##*##*##*
*********************          **********
*##*##*##***##*##*##*
*##*##*##***##*##*##*
*********************

"//": "item K"
    {
    "type": "ATTACHMENT_POCKET",
    "slots": "1 x 2",
    }

"//": "item L"
    {
    "type": "ATTACHMENT_POCKET",
    "slots": "2 x 1",
    }

"//": "item M"
    {
    "type": "ATTACHMENT_POCKET",
    "slots": "2 x 2",
    }

"//": "item N"
    {
    "type": "ATTACHMENT_POCKET",
    "slots": "1 x 1",
    }

    "torso_upper"             "torso_lower"
*********************          **********
*KK*##*LL***LL*MM*MM*          *NN*##*##*
*KK*##*LL***LL*MM*MM*          *NN*##*##*
*********************          **********
*KK*##*##***##*MM*MM*
*KK*##*##***##*MM*MM*
*********************

When you select attach. It opens a grid based on the description of the slots. In the example above, the item has a 6x2 grid at the top of the torso and a 3x1 grid at the bottom. Overlaid on this grid is the size of the pocket to be attached. For example 1 x 2. The player must then indicate the location by using the arrows or mouse. And click attach.

For the next pocket, the floor grid opens, but part of the slots is highlighted with a color/sign as occupied. To unattach a pocket, you can leave it as it is: choose from the list of pinned pockets.

UPD. And if you use centimeters instead of slots, you can simply set the width of the system and the number of rows in the system. Additionally dividing it into conditionally independent parts.

For example. A pistol clip holster, takes X centimeters and one row. Rifle holster takes Y centimeters and two rows.

Build the grid at the rate of 1 centimeter equals one slot horizontally. The maximum length, specify in the description. And we already have fewer restrictions.

Hyperseeker commented 2 months ago

Problems 1.1, 1.2, 1.3 are not problems. In most cases, proper priority setting and whitelisting is enough.

That's what I meant when I said it can be avoided. There are ways to navigate these issues with the tools currently available (and some thinking). I don't believe players have to, ultimately. Explicit is better than implicit: the less brain power it takes to perform an action, the easier it is to perform, and thus the more-likely it is to be performed. I can certainly appreciate the powerful framework of pocket management, and I'm using it extensively myself, but that doesn't mean the design has reached its ultimate shape with regards to UX.

I don't need a separate list of pockets, each of which needs to be hidden (not hard)

In an ideal situation, your survivor would have plenty of platform to latch MOLLE pouches onto, with a clear differentiation of their purpose and their place on the urgency hierarchy. In an ideal situation, you'd already have all the gear you need to achieve your goal, and the know-how to do so efficiently.

What if that isn't the case? What if all you have is that tiny chest rig you found? No belt, no MOLLE-compatible backpack, no extra space on your chest, your belly, your legs, or your back. Would you still carry your medical supplies in the backpack, even if you have a relevant pouch? (The importance of which I'll address later in this comment.) That might take a while to reach.

Besides, improving pocket management by giving players more control over the inventory is a positive change.

I don't need a separate list of pockets <...> which takes up half the screen (which is important)

I agree. It's important to figure out how to manage that list without overburdening the Items Worn section. Suggestions are welcome.

For example, I choose all the things to undress. I select all of them at once, not one at a time. If each pocket is displayed in the list of worn items, they will be selected and removed (separated from the base item).

This is not true even now, and that won't change if this feature is adopted. Selecting an item's container for dropping prevents you from dropping the item separately. This also applies to the subparts of your worn items. Ballistic plates don't drop separately from your ballistic vests, nor do guns drop from single-point slings.

Here's a screenshot from a live playtest I'm running, with me trying to drop everything from my character's Items Worn list:

Subparts are automatically deselected from dropping and cannot be dropped individually

Notice how subparts refuse to be dropped:

  1. The chassis inside an ablative pocket of the harness
  2. The ballistic plates inside ablative pockets of the vest (aka plate carrier)
  3. The rifle hanging from a sling strapped to the harness (non-ablative)

This is part of the inventory management that is powerful but requires an understanding of the system to use correctly. You may refer to it as having a high skill floor and a high skill ceiling, if you're familiar with game-design jargon. In a way, this is still part of Problem 1 (the UX), though I'm not raising it within this proposal because it's out-of-scope.

And to make a penalty for the pouch on the back and not make a penalty for the backpack, just not logical.

This is out-of-scope for this proposal, but I do agree: backpacks, and many pockets along with it, ought to be rebalanced as to their move costs.

IdleSol commented 2 months ago

Perhaps this will help you.

Pay attention to the behavior of the pockets when attaching them to the “system”. 1

I took two identical pouches. I concealed the contents of one of them. Then I attached both to my vest. 2

As you can see, the vest remembers their state. The “problem” is that it cannot control their state individually. The only thing left to do is to modify the pockets settings menu by adding a show/hide contents option.

I think this is what you need?

What if that isn't the case?

I don't really understand what you're talking about. You have to set up priorities and whitelists anyway. Or put up with the inventory clutter.

Hyperseeker commented 2 months ago

The only thing left to do is to modify the pockets settings menu by adding a show/hide contents option.

If you can make a case for it as a feature suggestion, I'd be happy to support it. It would be a big improvement for the current pockets system.

You have to set up priorities and whitelists anyway.

Yes, you have to work the pocket management regardless of what you do it for. This becomes easier with per-pocket show/hide.

If we were to go with your original example, of showing/hiding entire items, you'd not be able to make a choice to strap "unimportant"/non-urgent pouches to one location and "important"/urgent ones to another. In situations where your PALS webbing is limited, you can hardly afford to hide only the "unimportant" pouches' contents.