crnormand / gurps

Implementing a GURPS 4e game aid for Foundry VTT
MIT License
105 stars 49 forks source link

[Feature Request] Support shopkeeper module #286

Closed mjeffw closed 3 years ago

mjeffw commented 3 years ago

Discord user Martin Ph DK asked a question on the Foundry server about support for players picking up items in-game or interacting with a shopkeeper to purchase or sell things they possess. He says there is a module in Foundry that does that sort of thing but needs to be supported per game system. Is there any plan for you to either, use another method to support this activity, support it within your game aid or connect with the module developer to add your game aid to his list of supported systems?

mjeffw commented 3 years ago

https://github.com/jopeek/fvtt-loot-sheet-npc-5e I think it was this one.

I thought it was so cool because it helps to create merchant shops or lootable enemies, but I think those are Item bound, which is disabled for Gurps, right? Unless it can be as simple as a more GCS library type interface. But that would create an issue with automatic weight calculation and that the players would need to have the ability to export our their sheet in between the games if they acquired something new. But it would make the game so much more convenient for everyone.

crnormand commented 3 years ago

This is a big discussion... grab a seat and a coffee (or beer), and let me pontificate.

Items per Foundry (capital I) are a separate, well defined class (the other being Actors). You can ask an Actor for all of its Items (and then you can sort based on subtype of Item to find the things you need). Items don't need to be physical. An Item can be a Spell, or an Attribute, etc., as some systems use Foundry to build characters. In fact, JamesH's new system builds characters completely from Items (and I don't want to go in that direction for our characters).

So for our purposes, we really only need to think of Items as Equipment. Of course, our equipment comes from an external source (GCA/GCS), and can come in two flavors: simple or complex.

Simple equipment has no other effect on the charactersheet. Things like rope, coins or healing potions, etc. These kinds of items provide no additional attacks, modifiers or features (to use GCS speak). BTW, equipment created in the Mook Generator are all "simple".

Complex equipment is just the opposite. It has attacks, modifiers or features attached to it. For example, a sword (melee attack) or a gun (ranged attack), or a magical sword (melee attack and modifier (+1 to hit, +1 dmg)), or a ring of protection (feature (+1 DR, +1 Dodge)).

So the two big issues (in my mind): 1. How do we map Foundry Items into our system? 2. How can we model complex equipment to be able to support attacks, modifiers or features?

  1. We would need to create a "wrapper" Equipment object that points to the Foundry Item. Besides all of the Item information (name, weight), our Equipment structure also maintains the hierarchy ("contains" and "collapsed") and Quantity. This will allow all of our code to work unmodified. I thought about maintaining separate lists of Foundry "things" and external source "things", and there really is no benefit, and a huge downside. So for now, I am going forward with the idea that a Foundry Item will point to one (or more) "wrapper" items (e.g. equipment, melee attack, etc.) that will exist in our current lists (actor.data.data. + melee/equipment/skills, etc). NOTE; Assuming the Equipment has the correct cost, qty and individual weight, the character sheet will calculate the sums (cost/weight), and if they have "Automatic Encumbrance" turned on, it will even adjust their Encumbrance level (which will change move and dodge).

2a. Attacks are pretty straight forward. We could model an Item to include values for melee and ranged attacks, and if the Item is added to an actor, it would create a "wrapper" Melee/Ranged object with the correct information and add it to the list of attacks.

2b. Modifiers and features are harder. Basically, any of these is going to require some "logic". We don't have to recreate the whole character creation system (and I wouldn't want to), but we could support a few things, like "+/-N to a Skill/Attack" or "+/-N to an Attribute" or "+/-DR to a hitlocation", etc. BUT, whatever we support, we will have to be able to re-apply it as the GM re-imports an actor.

2d. Which brings up 'syncing'. What happens when the GM gets around to creating the item in GCA/GCS and the Foundry Item is redundant? Either they will just have to manually delete the Foundry Item, or we could try to do a name match and give the GM an option to delete.

2e. How do we handle it when a Foundry Item is removed from an Actor (either because the GM has deleted it, or a character picks up a sword and uses it for a while, and then gives it to someone else in the party)? We will have to remove all of the "wrapper" objects that it created, and rollback any "+/-" we did to other things. Here is where I get a bit apprehensive. Any modifier/feature that we support (e.g. +1 to hit, +1 damage, +1 Skill, etc.) will have to know how to roll itself back. Obviously, simple addition and subtraction is no problem. But could there be weirder ones? Just something to think about.

2f. Would we just have the GM manually edit the Item's info to include what we need, or do facilitate some kind of import from a "shopkeeper" NPC? The GM creates a "shopkeeper" NPC containing all of the things they want to transfer, and then we build some kind of "Item Builder" sheet that allows the GM to create Foundry Items from bits and pieces of the imported items. If you think of our current character sheet, making a sword or a gun would be simple. The GM selects the Equipment and then drags the melee/ranged attack on top of it.

But how would we do a +1 to Skill? That kind of information doesn't exist in the character exports (it is already calculated by GCS/GCA). Which means they would manually have to enter that kind of data. We would have to build a UI that lets them type in various values/formulas (maybe with selections from lists.... maybe the GM could include the Attributes and Skills/Spells that it want to "merge" in the "shopkeeper" NPC, so it would be available in a list to drag/drop from) or just EFF-it, make them type in the damn name and forget about it. But this still requires that we create an editing system for all of the modifiers/features that we want to support (2b).

2g. Or we could try to import something from a GCS library. Not my favorite, since that is yet another import to build, and not guaranteed to remain the same. Yes, it is currently JSON, so it wouldn't be near as hard. And we could parse various modifiers and features directly from the library file, but it would force GCA users to have to use GCS for Items. Using a dummy NPC at least gives us equipment names (cost, weight, etc) and if they include Advantages, Skills, etc, it would give us those names as well, for free.

But either way, 2f manual entry or 2g import GCS library, the biggest problem IMHO is that it would still require that we build the logic to handle the modifiers and features (2b).

Sorry I rambled... I'm waiting for this dang report to finish so I can complete the rest of the reload (work stuff) and normally I would be doing this in front of a white-board or a plate of wings.

Now that I have typed it all out... I am only really worried about 2b. Which of the modifiers/features can we support? Would a simple +/- be various things be enough for 80% of the players?

All that being said... the NPC Loot module isn't as useful to us because of the focus on money (and how to split it). GURPS doesn't really know about money. Yes, it has the cost of things in "$", which you can modify to your tech level and world. But none of the character sheets really deal with money. Fantasy worlds can use coins (which can show up as equipment), but how do you model futuristic "credits"? As far as I can see, the Loot Module (and shop keeper) are just publicly accessible lists of Items with some controls on interaction. Assuming we figure out the stuff above, we could build a simple UI that allows the GM to transfer Items from Item lists, or control which player/players can do it for themselves.

trev-dev commented 3 years ago

Respectfully, I don't understand why this needs to be a thing. Yes it would be cool/neat to have, but it makes "sheets are managed in GCS/GCA and imported into the game" convoluted/confusing. Using GCS/GCA is the premise upon how our whole system works. Re-working to support Foundry Items requires a fairly large paradigm shift, as evidenced by @crnormand's long reply.

We have handouts if we want to show people what's available and then manage the sheets on our end. By putting automated systems in place we relinquish a degree of agency over what happens to these sheets.

Is the feature of being able to click on things and have automated shops worth the cognitive overhead of having to figure out what any player did with their sheet? I track my player's wallets in a special item called a "credstick", how would deductions work with that? Would it be simpler to just have a conversation and update GCS/GCA as we make decisions together?

The majority of my tabletop experience over the last year has been in roll20 where players can freely edit their sheets and one of the best aspects of moving to Foundry is that they may still do that, but everything needs looking at/review before re-importing. My PC's sheets were an absolute mess when we migrated and now they're nice, uniform and accurate. This seems like a feature that will cause more unintended kludge. I personally don't want to manage an equipment library in two places and I enjoy how GCS works for me.

But this isn't about me, now is it? :grimacing:

If this were a feature I want to use, I feel like 2B (Import the data from GCS) is the best bet toward lining things up with GCS/GCA for sheet management. And I would expect to re-import over-top of it anyway unless we plan on managing sheet data within Foundry in the long run.

crnormand commented 3 years ago

I agree with everything you said... we have a process that will work. 'Nuff said. However, once we got dice rolls working, just about everything else has been an optional enhancement anyway ;-) And I am fine with that. This is a hobby project for all of us, and if we can't make it work, then so be it.

Like everything else... this will probably grow organically. Because I also agree with Jeff's point: "I thought it was so cool"!

I just wanted to point out (amongst us devs), the issues involved.

mjeffw commented 3 years ago

I also agree with trev-dev's points. This is a huge can of worms and not anything we want to deal with in any near term.

If we have two-way sync with GCS we might be able to automate this by updating the actual GCS sheet from the game and triggering a reimport of the character, but unless and until that works it means replicating GCS/GCA functionality.

gtludwig commented 3 years ago

Yeah! I also agree that it's a "it would be cool" feature and I believe it would be a very time consuming task in the short term.

gtludwig commented 3 years ago

This morning, as I was getting ready for the day, this shopkeeper idea came back. As I took my girls (two Bernese Mountain Dogs) for a walk, I started to think more about this and this is what I arrived at.

Disclaimer 1: I am assuming simple or complex pieces of equipment are converted to some type of Foundry object in the import process. Disclaimer 2: I am assuming pieces of equipment can be exchanged between actors.

  1. Shopkeepers are actors created in GCA/GCS and imported/updated, while they can be as detailed as the GM wants them to be, they have some basic attributes (IQ, Per, Will), some advantages like Charisma, Voice, etc (hold this thought! [1]), some Skills like Merchant, History, Connoisseur (type), Fast-talk, Jewelry, etc. (hold this thought! [2]), some equipment and some money.
  2. We would have some sort of Shopkeeper Exchange Dialog (SED) where the GM would select a shopkeeper actor and one or more player actors - each player would have a SED box showing only to him/her self.
  3. Upon accepting the SED invitation, a shopkeeper logic would kick in secretly and make the following rolls visible to the GM:
    • Shopkeeper mood roll [A]. Who knows how the shopkeeper life is at the moment? Maybe he lost a beloved one or he inherited some unexpected money? This would add a bonus or penalty to the reaction of others towards the shopkeeper.
    • Reaction roll [B]. based on the player and shopkeeper actors (remember "hold this thought! [1]" above?) advantages.
    • Scarcity roll [C]. Did a war just break in the region? Did a new trade deal just come into play?
    • Perception-based Merchant roll [D]. When Shopkeeper sees the players he quietly tries to gauge whether the players should get a fair-deal or he can drive the knife in a bit, according to his own ethos (remember "hold this thought! [2]" above?)
    • Example: Bill, the local brewer is a dwarf, normally sells a gallon of ale to adventurers at a flat price of 20 cp. Bill's son was just born, so he's feeling charitable and will offer 10% off for that day [A]. Bill has some levels in Charisma that would make things go in his favour some 10%, but the adventurer that walks in is an Elf and Bill does not like Elves and will only sell his quality ale to the Elf for another 10% above asking price. This is [B]. Bill has been hearing rumours of a war brewing in the region he gets his barley from and decides to stock up and needs to have some more cash, so in order to keep brewing, he'll charge another 10% [C]. Finally, though he does not cares much for Elves, this one looks well cared for, so judging by his appearance, he thinks the Elf would not spare some extra 5% for Bill's most exquisite ale. That is [D]. A + B + C + D = -10 + 20 + 10 + 5 = 25% Before any deal is struck, the SED automatically adjusts Bill's Exquisite Ale prices to 20 + 25% = 25cp.
  4. Haggling - GM and player roleplay the transaction and active "hold this thought! [2]" rolls can be made to influence the final price
  5. Transaction summary. Once terms are accepted by both parties a window with a summary of the transaction appears. Accept and cancel buttons will conclude the exchange.
  6. Items are transferred to/from the actor equipment and it affects encumbrance. Money is exchanged.
  7. Once the exchange is completed, a summary of it appears in the chat. GM can allow players to see all the shopkeepers price modifiers.
crnormand commented 3 years ago

That sounds like a cool scenario. Although "logic would kick in secretly and make the following rolls" smacks of automation... and we can't have that now, can we? ;-)

You do mention a process that we don't do at the moment, direct character to character interactions (and I don't mean by whispering in chat). WarHammer has this concept of an opposed roll (sort of like GURPS quick contest), and they built a realtime dialog system that pops up for both players to make their rolls privately, and then compare them. I could see something like that being used here (for private haggling, etc.)... but I digress.

But in essence, we are talking about two different sides of a "shopkeeper". You are discussing the NPC side, and I was using the shopkeeper solely as a place to hold inventory. Since we don't have a "shop" object, or in fact, any other "object" besides Actor, I was going to create a dummy NPC (and I called it "shopkeeper") and use its Equipment list as the inventory for the whole shop.

So, if we do go down this route, we can combine the two into the same NPC... the actual "character" side that you discuss, and the "inventory holding object" that I discussed.

mjeffw commented 3 years ago

You could use OtF formulas in the description of the items to get around the lack of GCS synchronization. That would work for a lot of items. Armor/DR is the one that I can't see how it works but you could do almost anything else.

crnormand commented 3 years ago

I think armor would just be a note describing DR and maybe hit locations. And the GM would just have to be aware of this when they apply the damage dialog to that character. If the character bought new armor that gave them DR4, the GM will just have to enter that in the ADD if that character ever takes damage. Not the most automated solution :-), but until they can sync back up with GCS, the only one I can think of. 

Boifuba commented 3 years ago

This theme is complicated to my campaign due to may player changes his gear each game session. My solution was create a module with a bunch of macros and/or teach my players how to use it. So you got a specific rifle you dont need to change your character sheet, you only open a new macro and tyou roll 4d6+2

crnormand commented 3 years ago

I am closing this. I think the Item support is good enough for these features.