September 15, 2022

Trade VII: Why Can't I Find What I'm Looking For?

The market system is based on rarity, a calculation derived from the local availability of a good and the total available amount of that good (or at least, the amount that is reachable). Goods are arranged hierarchically into stages, from "raw" materials all the way up to complex goods which require many precursors which themselves are often manufactured.

The system I've written to handle these complex goods works great. I can add "recipes" to a master file and calculate a price for any good I can dream up (and properly research).

A core concept of the system is that of a reference, which represents the amount of a good which can be purchased by 1500 oz of gold (approximately 3,125 gp). For small goods, like crops, a single reference can represent tons of material.

The question I am currently working through is: how to take the bits of information I have and translate them into an availability metric.

The market and price list provide two important functions to the party: they generate striving (to aspire towards a piece of equipment they can't yet afford) and scarcity (equipment that is not available for any cost).

We can, of course, allow the price itself to perform both of these functions. However, all equipment should not be available at all times simply because it exists somewhere in the system. The question is then how to determine how often a good will appear in a given market.

My initial thought is to use the local number of references to determine this rarity. If less than a single reference exists in the local market, then there is a good chance it'll not be available that week (or similar period of time). This means that we can recursively build up a local reference amount for manufactured goods based on the local references of its components.

Once I have this number, I can either use it as a probability straight up, or mitigate it a bit by comparing it to the rarity constant (itself a function of the size of the market). For now, I'm simplifying the final product by taking the log of that number and using that to determine a "rarity score."

\[\mathit{rarity} = \left\lceil-\log_{10}\left(\mathit{ref}_\ell\right)\right\rceil\]

Example: for a good with a 0.002 local references ($\mathit{ref}_\ell=0.002$), the rarity score is 3. That can be further used for a roll as needed. We could say that an item with a rarity of 3 will be available in a market on a 1 in 1d30, for example. This makes rare items difficult to find, but not impossible. The party could either hang around until some were available, or travel to another (and perhaps more favorable) market.

The simplest method to determine local references is to use the minimum of all constituent components, without regard to the amounts needed. I'm not super comfortable with this, because my conception of references is tied more tightly to actual production numbers (which I generate from the working population availability). But it has led to some bizarre cascades. Fodder, for example, is very cheap, but a lot of it is needed to raise a foal into an adult horse. This also means that the number of fodder references needed per horse is very very low. Both of these can quickly get out of hand as very small or large numbers are passed through several iterations of the recipe parser.

I tried dividing local references by the amounts needed, or comparing the local references available to the number needed. Neither are really satisfactory. I think I will use the simple method described above, and if I get a lot of complaints in play then I will revisit it.

The recipe system is built and effective. There are a lot of recipes to write, however.

8 comments:

  1. glad you're back posting. we've both been all over Alexis' issues with scarcity. And I've used a few log functions for some of my production as well. Trying to figure out which problem you're trying to solve here: too much production or not enough? Too high a price or too low? Or just overthinking potential outcomes? Would love to join the discussion of how to approach the solution, as I might then incorporate it myself!

    ReplyDelete
    Replies
    1. I think I'm overthinking. GIGO (garbage in, garbage out) as they say. If we get a bizarre price for something that ought to be common, it's not always obvious if that is the system working as intended, or if its a bug somewhere in how we've defined things.

      I've certainly used odd pricing to pick out more than a few bugs in the actual code, or used it to rethink how I assign resources, etc.

      On the other hand, I might be trying to rush perfection. These oddities might just take years of refinement and beating against the rocks of player expectation.

      Have you implemented any of the trade process in your setting?

      Delete
    2. I have! Unlike your effort I'm using a couple linked spreadsheets instead of writing code - since I CAN'T write code and much as I'd LIKE to earn it ain't gonna happen. Sheet 1 is each of the references for each city. No production formulas. Sheet 2 collects the local references (which of course changes from locale to locale,) on the first page with about 40 subsequent sheets which represent/incorporate the recipes and resulting prices. Had a BLAST putting it together and I sleep soundly knowing that wherever my parties go I can give them an accurate price for any item they might wanna purchase. Had a player wanting to buy 50' of silk rope. Never SEEN a mulberry tree! It woulda cost over 3k gp if it existed, which it did NOT in this small 3k population village.

      The presence of all elements does not necessarily mean the presence of the finished product as folks still need to process it. There's no weaponsmith in most small towns but there may be an outfitter, who charges quite a bit more for transporting the weapon from where it WAS made to the frontier where the party is.

      Delete
    3. Very nice! How do you assign the references to the cities and determine if an item is actually available?

      Delete
    4. I stole liberally from you and Alexis of course. Short version? There can BE no short version!
      1. Wood. Based on biome, elevation and population with a ceiling.
      2. Ores and minerals. Much of it based on geographic features. Everything else randomized. Nobodt gets more than 1 reference.
      3. Livestock. formula based on population, infrastructure, biome, elevation and latitude, with a few "personality" twists. ex: Horse production is limited. Mongol-like people however produce a LOT. And they're good!
      4. Crops. Remember all of that Climate work we did about a year ago? That. And biome, population, infrastructure.
      5. Stones. Similar to ores and minerals.
      6. Wildlife. Similar to livestock above.

      This tells me how much of anything a city produces for resale. If the village doesn't have a skilled tradesman to change a resource into a product, it's shipped out in return for finished goods so it's more expensive because it's bought from a peddler or an outfitter.

      My spreadsheet has a page for each “shop” with products listed. I've used conditional formatting to “disappear” items over a certain price (based on population of the village) or under a certain level of occurrence for raw materials.

      You keep askin', I'll keep answerin'.

      Delete
    5. Presence of a skilled tradesman for a particular raw good makes a lot of sense. Currently, I distribute raw goods, then tradesmen, but a second redistribution step could be very interesting.

      What's your formula for max price based on population? As I type, seems it could also be affected by infrastructure.

      Delete
    6. IIRC you're designing more of a "simulation" than a game-able location, so that might be a difference in our approaches.

      Population effects infrastructure so it's interrelated. But I generally use 10% of the pop in gp for availability as well as purchasing power (when the party wants to unload some treasure.)

      Delete
    7. At least for this project, the simulation aspects are siloed off, in large part to make this more gameable.

      That sounds like a pretty good rule of thumb.

      Delete