Blesmol / pfscf

Pathfinder Society Chronicle Filler
https://blesmol.github.io/pfscf/
MIT License
7 stars 3 forks source link

Automatically calculate things like gold from treasure bundles and char level #36

Open Blesmol opened 4 years ago

Blesmol commented 4 years ago

A proposal was made that it would be good to have functionality that would automatically calculate the gold a character receives based on the characters level and the number of treasure bundles that the character received.

This should not replace the current option to provide a gold value directly, but merely be an alternative option. It would require that also the char level is provided, which is currently not done, as it does not appear anywhere on the chronicle sheets. And it would also require to keep the table somehow in the game-specific template.

tdhsmith commented 3 years ago

I was thinking the easiest way to do this would be defining some way to do an indirection via a lookup table in YAML. Something like a block of "computations" or "conversions". So a quest could have:

parameters:
  "Player Info:"
    level:
      type: text
      description: Character's level
      example: 2

conversions:
  gold_by_level:
    source: param:level
    target: param:gp
    lookup_table:
      1: 3.5 gp
      2: 5.5 gp
      3: 9.5 gp
      # etc...

However that's not going to fly for scenarios, whose rewards are parameterized by both level and the number of treasure bundles recovered.

One could set up a whole math parser and then define the computations as arithmetic expressions, but that seems like a lot of work for this feature, especially when this is about the only use case.

tdhsmith commented 3 years ago

If there was a computation system, it could also be used to automatically determine reputation/XP in scenarios with partial success metrics.

And if it was super expressive it could perhaps be applied to earn income calculations, but that strikes me as too complex to bother with anytime soon, since there are so many exceptions to account for.

Blesmol commented 3 years ago

Yes, it would require two additional parameters, level and treasure_bundles or so, then some lookup table with the gold value per treasure bundle per level, and then support for some basic math, beginning perhaps with only multiplication and adding more only as required.

For the calculation we would have to see whether it's some special conversion node as shown above or some inline value expression like, e.g, value: "${table:treasure[param:level] * param:treasure_bundles}gp". Not really sure whether I would be comfortable with having a node that overwrites a user-provided parameter value like shown above. Should then either have semantics of "overwrite if not set by user" or accessible via a separate arg identifier. BTW, the societyid parameter already creates additional argument store entries to be able to access only parts of the society id, like player number or char number.

I would currently strongly vote against doing automatic calculation of rep / xp, as I do not (yet?) see the benefit. Unlike gold, XP/rep should be identical for all players and should be somewhere between 1-4. If GMs have to provide additional input values somehow just to calculate "yup, you've got 4xp", then I would assume this would scare of GMs instead of really supporting them.

tdhsmith commented 3 years ago

Not really sure whether I would be comfortable with having a node that overwrites a user-provided parameter value like shown above.

I'm not happy with it either. Some node needs to allow data to come from 2 possible sources. I erred towards the side of having the computation push data onto a target, because then it is an additive feature that doesn't change the syntax of the base case. I targeted the parameter just because there wasn't a precedent for referencing a content entry as far as I could tell. But neither of those are strong arguments. It would probably be cleaner simply to define it with the value either on the content or on the "receiving" node.

Should then either have semantics of "overwrite if not set by user" or accessible via a separate arg identifier.

My assumption was the GM providing gp would always be a stronger and override any calculation. I guess you could emit a warning when content got a value from 2 "sources".

I would assume this would scare of GMs instead of really supporting them.

Agreed. My brainstorming was a bit of a hammer in search of a nail.

Blesmol commented 3 years ago

Some node needs to allow data to come from 2 possible sources.

True. One open question here is whether the node that combines two values is the same node that also does the calculation. In every case, it should be (more or less) clear to people reading the yml file what is happening at a specific node, even if that means having more nodes to reach the goal or very speaking names.

My assumption was the GM providing gp would always be a stronger and override any calculation. I guess you could emit a warning when content got a value from 2 "sources".

Yes, explicit content should always have priority over automatically derived content.