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.

Weather Engine

Way back when I first started coding up this project (several years ago now), one of the first things I implemented was Alexis' weather generator.

It works pretty well. Working with real-world data as the seed input is easy. I've extended the system a little bit to make it more versatile throughout the year.

The only bits of data I need are: minimum and maximum monthly temperature in Fahrenheit (high and low), and the months in which the high occurs. I also collect high and lows for the precipitation (in mm) and the month in which that high occurs.

"climate": {
	"temperature": {
		"minimum": {
			"high": 77,
			"low": 47,
			"highMonth": 7
		},
		"maximum": {
			"high": 89,
			"low": 62,
			"highMonth": 7
		}
	},
	"precipitation": {
		"high": 126,
		"low": 70,
		"highMonth": 7
	}
}

With these numbers, it's a simple enough matter to fit a sinusoidal curve to give me the monthly average high and low for any given month. Admittedly, very few places on earth have a perfectly balanced summer/winter cycle, but this can be forgiven, and the players are unlikely to notice in any case (particularly across such a relatively small area).

A whole year of temperatures

I've incorporated a few extra bits into my version of the weather engine. The first is apparent temperature. At higher temperatures (80F+), high humidity makes the air seem hotter. This is usually reported as Heat Index. Conversely, when the air is cold, wind can make it feel even colder (Wind Chill).

Next, I used a IDW algorithm (my go-to) to spoof data for all hexes based on just a few inputs. I grabbed a few stations from around the State, but with this method, I don't need to worry about researching all 170+ points.

On one of the original weather posts, Vlad made a comment about how much rain it generates. These are some good thoughts for possible mods. I don't see that problem cropping up at the moment, but it's something I'll keep an eye on.

As another potential update, I could use a Gaussian distribution to generate the temperature for each day, or calculate the daily drift differently. But for now this works well.

Preparing a Setting

I have been working hard on a setting of my home state in another universe. It's been way too long since I've run a game and I'm getting itchy. So far, this has been a good test of things I've learned and things I'm learning, and its given me an opportunity to re-write a lot of the market code in particular. That's helped clean things up and hopefully erased some hidden errors.

I've divided up the region into nine "regions." Not kingdoms, exactly. But distinct culturally (in the real world) and thus a good proxy for translation into a fantasy version. Some populations get swapped over to halfling, elven, orc, dwarf, etc.

The main challenge now is to apply these principles to the regions. There are some differences in tech level here, ranging from a T-8 chiefdom all the way up to T-12. The danger is that I will not be clever enough to avoid "sameness" in the relatively small areas in question (around twenty 20mile hexes). Of course, sameness is not necessarily a bad thing - these regions will share trade routes as well as language - but we want the variety to mean something. Otherwise, there is no reason for them to be separate autonomous regions.

My familiarity with the real-world terrain is also a crutch. Because the farmland is so fertile, nearly every square inch of land that can be farmed is being farmed, a development only in the last 100 or so years. Reconstructing the "original" terrain for a much less populous society has been an interesting challenge.

I will no doubt continue to refine the descriptions of and relationships between the regions, and my next task will be to seed the commodity list with enough stuff to satisfy a party starting out. A work like this is never done, but I want to get it into a playable state. I also have 1mile maps ready for many of the hexes, particularly in the northern part of the state.

Trade VI: Simplifying to Complexity

I've been working on my algorithms to generate trade networks and manufactured goods. Although probably several years out of date now, Tao's Trade System remains required reading for anyone wanting to do something similar.

This iteration was a much-needed rework of the way a lot of the prices were generated. I had gone through Alexis' work linked above and simplified it to my needs. He is using references based in the real world, whereas I am trying to generate from scratch.

I found that of all the equations, the final price of an object simplified to just a few variables. The first is the local value of a unit (oz) of gold (in cp, all prices are expressed in cp and can then be abstracted back up to sp or gp as needed). I'll call this $g$. To find this number, we need the local availability $g_\ell$ and the total availability $g_t$. $g_t$ is the total number of references reachable from the point in question. This is easy to do with network algorithms. Local availability is a weighted distance calculation over all locations $i$ reachable from $\ell$: \[g_\ell = \sum_i \frac{g_i}{\textrm{dist}\left(\ell, i\right) + 1}\] By this calculation, if $i$ has 2 gold references, but is 4 days away, it contributes $\frac{2}{4+1} = 0.4$ references to $g_\ell$.

Right now, I am treating each hex as a node in the graph, but if there is no defined settlement there, all its resources are given to the closest city hex for pricing purposes.

We need a rarity factor $r$ that scales with the size of the network. As the network grows larger, a smaller $r$ is needed to balance things out. I'm trying this out for now: \[r = -\frac{1}{n}\] where $n$ is the number of nodes in the network.

The last two constants are the number of gold pieces per oz ($p = \frac{1\textrm{ gp}}{0.48\textrm{ oz}}$) and ratio of cp to gp ($c = \frac{100}{1}$). These are easy to change. A half-ounce gold piece is somewhat hefty; many coins in history would have been much smaller amounts. Gold is valuable enough that a small bit is worth a lot, and hence a great deal of value can be expressed in quite tiny coins. I like the idea of a gp being a weightier coin. I also try to base the sizes of my coins on current analogs that I can actually show to my players.

A thousand of these is no joke

So the final equation comes together: \[g = \left(r \cdot \frac{g_t}{g_\ell} + 1\right) \cdot p \cdot c \]

For an individual resource $q$, the equation is similar. First, we have to define the base cost $b$ of a unit of $q$. I found that this was the most important factor; it essentially represents the ideal economy where everything is in perfect supply. Whether a board-foot of wood is defined as 1 cp or 18 cp will have approximately a 18x effect on the final price of wood no matter where you are in the world. This becomes the key object of research when sketching out the system. It is then an easy matter to determine how many units of $q$ are equivalent to one reference of gold (assuming a gold ref = 1500 oz): \[\mathit{ref}_q = \frac{b}{\mathit{ref}_g = 1500\textrm{ oz}}\]

We obtain the rarity $r_q$ in a similar way as above with gold, using the distance weighted availability. The final price (in cp) of an item at location $\ell$ is then: \[\$_q = \frac{g}{\mathit{ref}_q} \cdot \left(r \cdot \frac{q_t}{q_\ell} + 1\right) \mathit{ref}_g\]

There are some other ways to view this equation. It can simplify again to: \[\$_q = \frac{g}{b} \cdot \left(r \cdot \frac{q_t}{q_\ell} + 1\right)\]

The next step is to determine the availability of labor references. I haven't quite decided how to assign these so I'll save that for a future post. We obtain the available references by once again iterating on the network: \[L_\ell = \sum_i \frac{L_i}{\textrm{dist}\left(\ell, i\right) + 1}\]

The cost of a material $m$ at a given stage (eg, hematite $\to$ iron ore) is then the cost of the raw materials (the unit cost $\$_m$ times the number of units $n_m$) plus the labor cost, which is raw material cost divided by the labor references: \[\$_m = \$_q \cdot n_m + \frac{\$_q \cdot n_m}{\mathit{ref}_L}\]

This step is repeated for each stage of the process, which can be quite complex. I developed a JSON schema to represent each manufactured material. To raise an auroch from a calf to weaned, you require the following.

{
  "item": "auroch (weaned)",
  "unit": "hd",
  "stage": 1,
  "tech": 7,
  "weight": 200,
  "recipe": {
    "materials": {
      "auroch (calf)": 1,
      "min": [
        {
          "maize": 483,
          "oats": 483,
          "barley": 483,
          "cassava": 483,
          "rice": 483,
          "wheat": 483
        }
      ]
    },
    "labor": "herdsman"
  }
}

Our raw materials are 1 auroch calf + whichever is cheaper between 483 lbs of feed, plus the labor of a herdsman. As long as every manufactured item "downstream" exists, this "item" will be available for purchase.

Resources XXIII: Crops and Climates

I've recently completed a little side project that will help resource placement significantly.

I cross-referenced the crop yields from EarthStat with Koppen climate data to get the prevalence for 175 different categories. The data isn't perfect - it doesn't take politics or demographics into account, for example - but I think it will be useful either in automation (as I plan to use it) or in beginning to think about where crops should be placed on a world map.

More details and the data itself can be found here in its own git repo.

Detail XIV: Benefits

I have put the world project on hold for a bit to get refreshed with other work.

Over at the Tao, Alexis has been reworking his hammers/coins/food system. It's a brilliant system with endless opportunity.

My own use of programmatic aids lets me break a 20-mile hex down into not just 6 6-mile hexes, but 400 1-mile hexes. This is a lot of detail; not something to be done by hand. And I do think the 20$\to$6$\to$2 system generates very beautiful results. I want to consider working on this for a while to see where it leads. By saving the random seeds that the model is built from, I can replicate a nice result without storing too much data.

This was the result from last year:

Last year's detailed hex

My latest version has some upgrades with color, but also additions of hex-type and benefits (hammers/coins/food). One major change is that the scale will be much different than the Higher Path: with many more discrete points, the number of benefits will be correspondingly higher.

An example (not of the same hex as above, I couldn't find the old version of this one) of a 20hex with an infrastructure of only 20. Yet, due to its presence in a forest, with some substantial clustering of hexes (producing a large number of high hex types), it generates a total of 134 hammers, 168 food, and 78 coins, calculated for each 1hex according to a binary system such that $B = 2 ^ {b - 1} + 1$, then added for the whole 20hex. This doesn't yet consider any benefits that would be added for the presence of a trade reference.

Updated hex

There are two paths forward. The first is to adjust the benefits conferred by each hex type such that the numbers become more reasonable. The 20hex total may not be as important as the individual 1hex number: eg, the settlement hex generates {'hammers': 5, 'food': 5, 'coins': 4} in the binary system, or {'hammers': 15, 'food': 5, 'coins': 4} in the decimal system. Without context, it is impossible to determine what constitutes a "reasonable" number. The second is to adjust the results of those benefits.

If a system is to work properly, it has to generate desirable and consistent results. The advantage of doing this programmatically is that I can implement totally different systems at the drop of a hat. The design loop is much tighter than hand calculation (although I am trying to avoid something that is so opaque it can't be replicated by hand).

Ex Nihilo VIII: Pressure

Pressure is easily defined based on latitude and the presence of landforms. The rules are defined based on posts from here.

July

January

These parts aren't very exciting. But they're helpful as a public log of my progress.

Ex Nihilo VII: Currents

Once the coastline is clearly defined, currents can be determined. I've detailed that process elsewhere, and these are the results for the map we're working with. The blue-white scale indicates the angle of the current in each cell from 0 to 360. There's probably a better way I can show this but for now this'll do.

This algorithm takes a really long time to run, so I think I'll accept these results as is, unless some hidden issue rears its head along the line.

Ex Nihilo VI: Tectonics III

Continuing on with the work of generating terrain from the tectonics. My first fresh crack uses both tectonic uplift and droplet erosion. These processes are cycled over and over until some condition is met. In this case, I start from a flat plane and stop when at least one cell is at its maximum height (25599 ft). The sea level is determined such that 29% of the total surface is land. I also apply a hypsometric curve to the land area so that higher elevations appear in roughly the same proportions that they do on our earth.

However, this algorithm generates a pretty boring topography. The mountains slope up uniformly from the coast, and the tectonic uniquenesses are not presevered. Usable, but disappointing.

The problem is that the erosion cycle is too powerful as the terrain grows from zero, and only the center of the continents (that is, the areas with the least erosion) have any chance of growing at all. To fix this, I began with a terrain generated directly from the relative uplift scaled to max height. The warping effects are clearly visible here but these will be smoothed out by the erosion algorithm.

Next, I again cycle through the erosion, but this time I rescale the height at the end of each cycle and apply the same hypsometric distribution. This yields a much more interesting topography.

The grayscale map is a bit hard to parse, so I threw the map into GIMP and applied a simple colormap. where 10,000 ft begins to turn into gray/white.

There are still some issues I can see, or improvements that can be made. Coastal areas are pretty uniformly low for many hexes inland (no Chilean Andes). Most areas do not have significant mountain ranges, although there is one range similar in size to the Tibetian plateau.

But this is the process. Design, test, repeat. This will be good for now and I'll move on to some other elements of the climate system.

Ex Nihilo V: Tectonics II

In the previous iteration, the tectonic plates were generated from a Voronoi algorithm, and thus had very straight edges. Here, I've made those more jagged, which should result in a more interesting coastal topography.

And it does! There is still a good deal of far-too-straight lines, but we can live with some of that. The ripple algorithm, which I'll tackle next, should help.

A bit of Gaussian blur:

Next, to closer approximate real-world distributions, I'll apply my hypsometric scaling.

Lastly, to get a feel for how this will shake out, I use the uplift values to generate a quick and dirty initial altitude map. The coastlines are a bit blobby, but I'm happy with this part of the process.

Getting the ripple algorithm to work will be my next order of business.