Stack Size - Overflow (Inventory Management)

[Roguedeus]

Currently, there are a lot of scripts that either limit the items stack size, or the total inventory (based on stack count or item size) but they all seem to suffer from the same issue... Loot overflow, is discarded.

Say you can only have 20 of something, and happen to loot one of that item while already having 20 of it. Say this item is expensive, or rare.

To bad... POOF!

I have a problem with this, and I don't think I'm the only one. However, whats the alternative?

I am thinking that instead of assigning HARD item 'count' limits in party inventory, it should be interpreted instead as SOFT 'purchase' limits. Thus, if you already have 20 (or more) of an item, you simply won't be able to BUY any more of them. You will, however, be able to LOOT as many as you like.

IOW, as long as its a script event not tied to normal merchant purchase, an items stack size can get as large as you wish it to. (a hard limit can be assigned via a script constant).

This shouldn't be hard to support for crafting (or other 3rd party) mechanics. It might be as simple as, a game switch that can be toggled allowing the next gain_item method call to exceed stack size.

This may appear arbitrary, but it manages to both limit hoarding via merchants, AND at the same time encourage searching for LOOT in both encounters and chests. (and even quests)

Thoughts?

Note: As long as only a few methods are aliased, this shouldn't require any fancy GUI changes, or much worry about compatibility.

[HimeWorks]

Depends on what the game supports.

Default RM project has no support for handling item overflow. Overflow? Too bad. What do you want the game to do with it?

Mechanics that you would need include

1. transferring items automatically to a "deposit box"
2. dropping items on the ground (so extra loots are automatically dropped, or cannot even be picked up)
3. prompting the player whether they wish to "free up space" for the item or to drop it

These are just examples that I have seen in games and all make sense. But yes, very little changes are required to default scripts: just some extra logic to gain_item and then everything else is custom code.

[Roguedeus]

I am thinking it can be as simple as a bool check for merchant purchase. No secondary inventory is needed.

Does the party already meet/exceed normal stack size? - Then prevent purchase.

A game switch can be used as a flag for the check. As well as for prevention of stack count increase upon looting. The flag is set when the event starts the merchant command.

When not flagged, gaining an item will simply iterate the count like normal.

Individual items can also be flagged as having HARD count limits, so looting/purchasing functions normally with them.

[Roguedeus]

If I've inspired you to write it yourself don't hesitate. I am still deep in my combat mechanic and likely wont be getting to this any time soon. Ditto with the Alchemical Synthesis plugin we talked about last month.

I am attempting to focus on one part at a time. Keeping it as clean and documented as I can.

[HimeWorks]

By default, you can't purchase an item if it will exceed the item stack size.

[Roguedeus]

Exactly.

I was referring to the flag as a 'use default', while all others use the new script. :)

[Roguedeus]

This mechanic might also allow for the use of special merchants that allow the purchase of more than the standard amount. Or for 'market controls' to be different between points in the game... Say an empire has a law that prevents merchants to sell more than X of an item... So finding a black market merchant is preferable (at greater cost) to exceed the standard purchase limit... etc...

edit: Thinking of it like that, its not much different than having a merchant run out of an item and re-stock after a time... But this soft cap, will actually be more player friendly. And there is no reason why a merchant cant do both. Limit purchase, AND run out of stock...

[HimeWorks]

I think for the most part it's all about how you convey this information to players.

[Roguedeus]

I think I will do it with a small conversation option on merchants. Something like, Merchant License which will have the merchant explain their limits...

It shouldn't take but a few times before the player gets it. As long as it doesn't change often, or for arbitrary reasons.

I Really like the idea of the primary reason to seek out the Black Market is to deal with merchants that will flaunt the laws regarding quantity controls. And its not without a real analogue. Price and purchase controls are common in many countries. Especially during economic/political troubles.

[HimeWorks]

Would these limits reset after a certain period of time? Would the player know when they get reset?

[Roguedeus]

I am thinking, the simplest way to handle it, without a GUI, would be to make is a standard 20 cnt (or similar) limit at the beginning of the game. Talking to a merchant can explain what the laws are in regards to Merchant Licenses, and the black market.

When visiting the black market, the player will be told that they can purchase up to 25 of something in their inventory, because they are 'new' and need to earn the trust/respect of the black market factions before they will allow for more.

Thus the player will make a mental note that If they find the need to carry more than 20 of something, they need to deal with the black market, and the risk that comes with it, OR they need to fight monsters for loot, or open chests for loot, after purchasing the max of 20 of whatever item.

This could also encourage some inventory strategy, with crafting skills... Crafting might allow you to exceed the purchase limits, but then what if the player runs into a patrol and the guards inspect their gear? If they are found breaking the law (hoarding) the guards might ask for a bribe... etc...

Later on, the player might complete quests for the black market, and get there max purchase bumped up to 30. This would happen very deliberately, and intuitively, so that the player shouldn't have trouble knowing that they have a 20/30 count limit (white/black market) for purchase.

And they will never have to worry about running out of room when looting, because they will always gather those items. Its what they do with that overflow later, when entering a patrolled land, that matters... The player might have to dismantle or sell some of there inventory to get there item stacks to meet the Market Limit of 20. Or face possible negative results.

edit: This can also be a good incentive to USE YOUR ITEMS until you have 20 or less, or risk losing them from confiscation at patrols, or what not.

[HimeWorks]

That would be pretty unique. It would go well with whatever story you have going on in that universe.

[Roguedeus]

I can't think of another way to justify the mechanic while preserving a sense of suspension of disbelief.

I attempt to make as much of the games mechanics as intuitive as possible, to minimize the tedium of playing with them.

[HimeWorks]

I think having a visible stock count would be intuitive, but that's cause that's what I've seen in other games.

[Roguedeus]

I would agree if the stack size changed for different items. In which case I might simply add a /20 (or whatever that stack limit is) suffix to each items stack count in the inventory menu.

Ex: 
-------------------------------
Red Poition    3/10
Blue Potion   19/20

-------------------------------

But one of my biggest issues with games today, is the way they assume the player is an idiot and needs to be reminded about everything. Which, to me, is generally due to arbitrary mechanics, that make no intuitive sense, change so often that a reminder becomes necessary, or function as a 'choice illusion' to mask poorly constructed (or repetitive) plot lines.

Maybe I am wrong... :)

[Roguedeus]

Of course, I come from a childhood generation where Zelda and Dragon Warrior for the NES were about as good as RPG's got... Heh.

A few more.. (Ultima) (Final Fantasy)

So, I am likely VERY biased.

[HimeWorks]

The only games that come to mind when it comes to fixed stack size are the star ocean and tales series. For whatever reason, they had a limit of 20 stack for all of their items, whether it's a consumable or an equip. Given that they were developed by the same team or something...it shouldn't be surprising the design decisions.

And so when you're at the shop, you would press left and right to increase or decrease how much of the item you wanted, but it would stop when you have reached the max.

This is more of a visual cue so you don't need to think "oh how many of that did I have?"

Because in those games, item count was not a core focus. It didn't make a difference whether you memorized your supplies or not. It would make a difference if you only had 2 left and you thought you had 10 before you entered a dungeon, but it's not really relevant.

For other games, it may matter.

[Roguedeus]

I may end up not even using the inventory limit after I write it up, if it doesn't accomplish what I hope.

Primarily I am trying to find a way to encourage item use, rather than item hoarding... Currently, I am focusing balance of all consumables (not skills) based on cool downs that persist after battle. Some skills will have similar cool downs, but not many.

[Roguedeus]

I am trying to imagine a way to encourage item use... Its not easy.

Games like Darkest Dungeon do it by wiping all items after the dungeon ends. Of course, they have a very limited selection of items, and their mechanic IMO is way to RNG dominated with fake difficulty. But that's just my opinion. IOW, I do not like the way they handle most of their mechanics.

Other games simply restrict inventory through weight limits... Theo has a really slick script for just that.

I am thinking... I'll write up the stack overflow script first, and if it doesn't feel right, I might simply prevent ALL consumables from being looted, and instead, focus on merchants and crafting to collect them.

That way, it should side step the issue of losing loot outright. I do not expect to need to limit stack sizes of crafting materials, but will limit the 'crafting' of items via cool downs, or what not, when not in a crafting area.

So. Monsters and chests (or whatever) will never drop stack limited consumables. They might drop equips, non-consumable items, and the like. But primarily, they will be a source of gold/exp.

[HimeWorks]

For me, items are rarely necessary because

1. I can run to the inn
2. There are other forms of free restorations that render items useless

Remove those easy restores and players will be forced to use their items.

[Roguedeus]

There are a whole bunch of possible uses for items that don't involve restoring. :)

[Roguedeus]

Hmmmm. Maybe, the issue isn't in scarcity, but in utility.

What if, every item in the game had more than one intrinsic value, and the challenge wasn't in collecting them, but in deciding which utility was most valuable, at the time?

A simple example would be the basic red potion. Intrinsics:

• Consume Restore. (100HP)
• Dismantle Misc. Crafting Elements.
• Craft Base for crafting Red Potion II. (and a few others)
• Craft Research 'craft experience' grinding.
• Key for unlocking potential faction side quests. (supporting the resistance)

etc...

The challenge is in making sure that every item has a finite utility, each with a value that can change drastically based on the play through... With a little roguelike sugar, the player may find themselves starved for items, rather than hoarding them.

[Roguedeus]

Closed to get it off your front ToDo page.

[HimeWorks]

Maybe I should open a forum or something for discussion purposes and idea generation that people don't want to take to one of the more popular communities?

[HimeWorks]

Providing multiple utilities for a single item would definitely increase the chances of it being used, because...well there are two ways to use it so the chances are higher lol

A couple games I've played used that same concept (ok, Final Fantasy 8 and 9), where you take weak items and combine them into a strong item, and then you could take that strong item and combine it into a quest item or an even stronger item.

So you had things like

Potion --> Hi-Potion --> Mega Potion

And the Potion could be used in multiple materials.

Of course that means you need to actually have such a system in your game. If you do, then that would be an easy way to integrate weak items into the mix.

There are definitely a lot of things you could do "with" the item instead of directly consuming them or selling them.

[Roguedeus]

As a general rule, I try not to limit the players capacity to plan ahead. Though I will if I can justify it some way, specifically as an excuse for unlocking that limit later. Progression is best when not limited to simple measures of scale. Advanced mechanics, and constantly expanding freedom, are key IMO.

On the forum note. Your host is extremely slow, and a forum will likely be even slower. :) But if you want to limit conversation here, I understand.

[Roguedeus]

I've just spent the better part of my free time, these last three days, writing an Armor script that adds two new bars to battle status.

The Armor effectively acts like a damage prevention, or 'preemptive healing'. The intention is to make actual healing extremely rare/expensive and not 'normally' done in battle.

Of course, once I had the basics I couldn't leave it alone...

So now its supporting enemy HP bars, and a slew of optional tweaks like auto generating armor, gain rates, and even selective param application based on armor existence... Imagine a suit of armor that only applies its fire resistance to damage taken as long as the actor has armor remaining. No armor, no equip resistances... Of course, actor and class based rates will apply as long as they aren't tagged armor limited.

I am looking to even allow use of the armor as fuel for abilities. Especially for tank classes that focus on defenses.

The more I play with it, the more time I spend adding nuances... Its a curse!!

[Roguedeus]

The screen shows the unrefined indication of actor and enemy armor... Physical and Magical. ;)

I still need to play with the spacing and sizes. Currently, actor states are obscured... :\

[Roguedeus]

Fixed... For now.

I really wish there was a better way to display states... Possibly a sub-window that would show up when actor is selected. Or something. I wish I was more confident with windows.

I'd settle for a way to reduce the displayed icon size. Like a state icon zoom or something.

[Roguedeus]

Semi-Final battle Status...

The new Equip Status... Amor Display (Initial : Maximum / Generated) Initial = The armor you begin battle with. Max = The maximum armor you can accumulate in battle. Generated = The armor auto generated at the beginning of each turn. These stats are primarily gained from equips. Better armor, isn't just DEF anymore. ;)

I really wish I had a flair for 2D graphic design... But I'll settle for clear and functional rather than nothing at all. ;) Time for lunch...

[Roguedeus]

I'm not sure if I like the clutter...

[Roguedeus]

I may not need this inventory script after all... The more I think about it, the more I realize I should probably NOT limit carry capacity, but instead simply limit 'open' availability. In order to have regular access to some materials it will simply require the player to sacrifice other materials to get them. (Dismantling).

In other news... I finely finished the Armor mechanic. Complete with battle popups, equip comparison, and status info. It functions very much like HP or MP, but has a very deep effect/counter-effect mechanism that I am hoping will add that layer of 'simple' complexity to battles that I have been looking for these last few months.

[Roguedeus]

I remember when I attempted to read the code behind windows and menu's and couldn't understand it.

Now, Its actually pretty easy to find and manipulate what I want. Its a really strange feeling. edit: I will admit, that equip change color highlighting was a pain. I can't find any SIMPLE way to color code strings, like I could in Java.

[HimeWorks]

It means you have leveled up. On Feb 28, 2015 12:27 PM, "Roguedeus" notifications@github.com wrote:

I remember when I attempted to read the code behind windows and menu's and couldn't understand it.

Now, Its actually pretty easy to find and manipulate what I want. Its a really strange feeling.

— Reply to this email directly or view it on GitHub https://github.com/Hime-Works/Requests/issues/258#issuecomment-76535776.

[Roguedeus]

lol ;p

[Roguedeus]

I can't stop myself... I am re-writing Yanfly's Skill Restrictions into an ALL useable item restrictions script.

Example of Improvements:

  #-----------------------------------------------------------------------------
  # new: <cooldown_grp: integer, string, string, string...>
  #   Applies the integer cooldown to ALL usable types with all tags.
  #   (Must match all tags to be applied. Multiple note-tags repeat effects.)
  #   (If an item qualifies more than once, the highest cooldown applies.)
  #
  #   !!!IMPORTANT!!!
  #     A note-tag WITHOUT ANY tags to apply itself, will apply to 
  #     ALL LIKE ITEMS.
  #     Ex: <cooldown_grp: 1> 
  #       on a skill, will apply a CD:1 to ALL BATTLER SKILLS.
  # 
  #-----------------------------------------------------------------------------
  def cooldown_groups
    return @cooldown_groups if @cooldown_groups
    @cooldown_groups = []
    temp_group = @note.scan(/<cooldown[-_ ]?grp:\s*(.*)\s*>/i)
    unless temp_group.empty?
      temp_group.each{|group| 
        @cooldown_groups.push(group[0].strip.split(/\s*[, :;-]\s*/)) }
    end
    return @cooldown_groups
  end

Of course, it relies in your tag manager... :)

edit: This may end up being one of my best scripts yet. Its a shame I am scrapping my Fusion mechanic... It was a BEAST to write and pretty damned fun. Parts of it will survive. But I am not sad. I learned a TON writing it.

[Roguedeus]

That was a bit more intense than I expected. But worth it. With my improvements I'll be able to do a TON of tweaks including allow skills to charge up other skills when used (like a skill that charges when a drain attack succeeds), skills to charge up or cool down faster when the battler is struck with specific elements (A fire elemental charges a fire attack faster when struck with fire), and all sorts of stuff.

[HimeWorks]

Sounds interesting. So like if someone is hit with a fire spell, it could potentially have increased fire damage

[Roguedeus]

Not exactly. If someone was hit with a fire spell, they can speed up a 'COOLDOWN' or re-charge a 'USE' for another skill that is either on cool down, or out of uses.

Now that the restrictions are processed directly inside the item_apply method, rather than scattered all over the battlers many methods, the single point of access, is conveniently also right were @result and make_damage_value occur.

The item used can be checked for element type, and if it qualifies, as a @result.success it can fire a uses change for a specific or wide group of usable items.

If I wanted the effect to scale with damage, I just check @result.hp_damage or whatever... etc... (though multi-attack skills may cause complications, especially the way Theo's SBS processes them)

[Roguedeus]

But your interpretation is cool. Maybe you can add a plugin to your attack element modifiers script that adds a state (with an element bonus) when a particular element type of damage is taken. The duration might scale with the damage dealt.

It might even work off absolute value, so negative values (absorbed) by the target count... etc...

[Roguedeus]

Damn that was laborious. My Armor script is bigger and more complex, but I didn't feel as burned out writing it as I did this. Not sure why.

...

Finely... The core is complete. Restrictions apply by use, or by target. On skills or on Items. And uses can be regenerated via feature objects. Or any combination of those.

Restrictions can be targeted by ID or by a combination of TAG & !TAG.

Specific restrictions can be randomized, while group restrictions are still static (feature adjustment will be applied).

Ex: You use a stack of arrows to renew your archery skills to 20 uses. Each archery
 ability used reduces ALL archery abilities uses by one. Three attacks later, all 
archery abilities have 17 uses remaining. Using an arrow item will restore 1 use to 
all archery abilities. Using a stack, will reset them all to max uses. (20)... etc...

Wearing a quiver accessory might double your max uses to (40)... etc...

All restrictions are visible in the selection list. Including uses (Available/Maximum). Similar to item charges.

Restrictions can be reset per battle, by a targeted effect (using another item/skill like healing), or by resting (such as at an inn).

While this system works in and out of battle, I still need to determine how I will keep track of users remaining, for items. Skills are auto linked to actors, but items are party objects, so keeping track of how many party members are on cooldown for an item, or whatever, requires a rolling queue.

Cooldown is rather straight forward, but uses aren't. I may have to tie all item based use restrictions to the entire party, as I can't think of an easy way to link the user of an item to the restriction, while in Scene_Menu.

[Roguedeus]

Unless I have different inventory for each actor... Heh. But that is way to complex a solution for such a small issue.

[Roguedeus]

Maybe if I attempt to make opening the Item scene initially act like Equip or Status scene... But only to open it. That way the last menu actor is selected for item restriction linkage.

edit: That wasn't as difficult as I expected.

#===============================================================================
# 
#===============================================================================
class Scene_Menu < Scene_MenuBase
  #-----------------------------------------------------------------------------
  # overwrite:
  #-----------------------------------------------------------------------------
  def create_command_window
    @command_window = Window_MenuCommand.new
    # @command_window.set_handler(:item,      method(:command_item))
    @command_window.set_handler(:item,      method(:command_personal)) #new

    @command_window.set_handler(:skill,     method(:command_personal))
    @command_window.set_handler(:equip,     method(:command_personal))
    @command_window.set_handler(:status,    method(:command_personal))
    @command_window.set_handler(:formation, method(:command_formation))
    @command_window.set_handler(:save,      method(:command_save))
    @command_window.set_handler(:game_end,  method(:command_game_end))
    @command_window.set_handler(:cancel,    method(:return_scene))
  end

  #-----------------------------------------------------------------------------
  # overwrite:
  #-----------------------------------------------------------------------------
  def on_personal_ok
    case @command_window.current_symbol
    when :item                      #new
      SceneManager.call(Scene_Item) #new
    when :skill
      SceneManager.call(Scene_Skill)
    when :equip
      SceneManager.call(Scene_Equip)
    when :status
      SceneManager.call(Scene_Status)
    end
  end
end

The rest was making sure I had the menu actor correctly selected for enable? and user methods.

[Roguedeus]

I just had a really cool idea regarding Item Uses...

=begin
Items that are NON-CONSUME on use, but are USE restricted, with a chance of breaking that 
increases each time the item is used.

    Each 'use' is an equal fraction of 100% Break Chance'... 
    Thus an item with (5/5) uses has a (100%/5) = 20% chance to break on its first use. 
    At  (4/5):(100%/4) = 25%... 
        (3/5):(100%/3) = 33.3%... 
        (2/5):(100%/2) = 50%... 
        (1/5):(100%/1) = 100%...

        Items can have risk free uses, either normally or applied. 
        (6/5) indicates that the first use has no chance of breakage, leaving a (5/5).
        Risk free uses are most commonly applied to items of greater quality.

    If the item doesn't break, its USES might be reset somehow. (rest, recharge, etc)
    Item Uses indication can be fraction (5/5) or Percent (20%). (Option switch)

Edit: All done. With a few caveats. First, I had to track item USES by party, rather than Actor, as having the same item with different USES remaining until breakage for each actor was odd.

Second, due to 'Free' uses, the Percent indicator option is prohibitive. Players need to know how many free uses remain.

Third, I have not decided if I am going to support adjusting 'Free' uses via feature objects yet. The idea of gaining a perk that allows extra uses of certain items is a appealing, but now that uses are tracked by party, it seems odd that one actors perk would apply to all actors... Maybe I can change how they are applied based on the current scene... hmmm.

edit 2: Nope, I think i found a better solution. Time for sleep.

[Roguedeus]

My solution was to track bonus uses by actor and core item uses by party... Now actors with perks that make them better at using certain items can use those items a lot more before they risk breaking.

An example as a wizard using a wand, vs. a rogue using a wand... (in D&D rogues can use items outside of their class range) So a rogue can manage to figure out how to use the wand, but will risk breaking it (without free uses) while the wizard has a natural amount of free uses for all wands. Such free uses can be reset, or even expanded with new perks... Such as a wizard that learns the 'Efficient Wand Use' ability, doubles their free uses before risk of breaking... etc...

...

I also discovered that the way battlers execute actions, lends itself to interruption AFTER an action is determined, if the restriction for the action prevents it before it occurs... My restriction script allows for an action to change the restriction of a targets skills/items, thus creating the ability to INTERRUPT an action!!

Imagine a counter spell skill that if it manages to land before the target completes its spell, the counterspell causes said action to begin COOLDOWN for 2 turns. So when the targets turn to act comes up, its spell is no longer available, and it skips its turn as a result.

I realize this is somewhat similar to getting stunned by an attack, before you act, but this is more strategic and less heavy handed. The counterspell can be limited to a certain type of magic (by tag) or whatever. So it may prevent a wizards spells, but not a priests!! Etc... It affords TONS of potential depth.