Finally, Holdridge

The Holdridge system is probably a bit more useful than the Koppen system for figuring out what things look like on the ground. At least, it's a start.

• After redoing some of the temperatures, the ice-cap has been knocked down to a reasonable area. I still need to redo the rain so that the lines aren't quite so sharp. The number of ice-capped peaks has also been reduced, which is good. Those should be rarer than they were.
• It's hard to remember that the continent on the right is not so much tall as it is wide/long. I tend to think of the interior as an inaccessible desert, but it's really only a month's journey from the sea. Of course, since its horizontally oriented, winds aren't as likely to blow directly inland.
• Possibly because of the rain, there's not as much desert as I'd like to see. Deserts are thematically fun, and only two of them seems a bit sparse.
• One thing I will look into soon: right now I use January and July as my summer and winter maps (and of course it's opposite seasons in each hemisphere). Going forward I'll be tinkering to see if I can use the "hottest" and "coldest" month each year to do the relevant annual sinusoidal approximations instead. For example, in the high latitudes, the hottest month will tend towards January; and in the lower, July. But I need a better understanding of how this works on Earth, first.

Rivers II: Big Fun on the Bayou

Not only are swamps thematically interesting, wetlands are important sources of early iron (and peat or coal). So it's useful to know where they might form. This is not as easy as it sounds - although there are reams of scientific literature on wetlands, they almost always focus on description rather than prediction (because we observe wetlands after they've formed), and even those definitions can be fuzzy.

There are four overarching types:

• Swamps. They are forested, and the other types are not. They often form on the banks of large rivers or lakes.
• Bogs. These form in the highlands, with a high precipitation which exceeds the evapotranspiration (generally this is the same as PET, or at least for my purposes). Bogs are the best source of bog iron, as well as peat, bog oak, and many types of berries. Occasionally they can form in glacial valleys or at high headwaters. Bogs specifically show up in cold temperature and boreal climates.
• Marshes. These form on the coasts of seas, lakes, and streams in temperature or high latitudes.
• Fens. These form on slopes, plains, or depressions (as opposed to bogs). Both bogs and fens are mires (containing peat), but bogs are acidic and fens are alkaline.

From this, I need to establish selection rules. In each case below, I'll select a random number of the locations which meet the criteria. In addition, the aridity ratio ($P/PET$) must be above 1.

• If the Holdridge type includes forest, and a river with a drainage above a certain threshold flows through the hex, and the hex is a plain surrounded by at least 3 other plains, the type is swamp.
• If the Holdridge type does not include forest, and a river with a drainage above a certain threshold flows through the hex, and the hex is a plain surrounded by at least 3 other plains, the type is marsh.
• If a coastal hex has an elevation lower than 50 feet, and is a plain, it is a marsh.
• If a hex is a highland or valley, and the annual precipitation is higher than a threshold, it is a bog.
• If the hex is a depression, and the annual precipitation is higher than a threshold, it is a fen.
• If there is a headwater in the hex (defined as the absence of any other hexes which drain into it) and the drainage is higher than some threshold (indicating a high amount of rainfall), and the hex is a plain, it is a bog.

I may revisit the bog/fen distinction if I ever dip into soil determination.

These are some pretty strict requirements. However, fiddling with knobs like this is the best way to get a world map with reasonable variety.

This classification scheme is not perfect but my hope is that it has the ghost of scientific backing, and provides enough distinction that I can convey to my players the difference between the bayous of Louisiana to the bogs of Siberia.

Finally, Koppen

The final fruits of my labors so far (key and comparison here):

Koppen map

A few things to note.

• I think I need to revisit how I match up the seams. For example, for the continent on the left that wraps from the top up around to the bottom, the orange area (BSh, semi-arid desert) transitions abruptly to blue Af (tropical rainforest). This happens in a few other places as well, but I'd like more gradual seams around the edges to make it apparent that the map is continuous. In addition, I need to revisit the precursor maps to make sure there is enough of a transition in these areas.
• Not all climate groups are represented. In fact, only 18 of the 32 possible climates are present. That's very interesting.
• I still have a massive ice cap. I think some of this is due to various bugs in the code - the nature of the classification means that it's just a bunch of nested ifs. I also had a typo when calculating the lapse rate, causing altitudes drop the temperatures a lot more than they should.
• All in all, this should be a good start to determining where certain resources (especially agricultural ones) are located.

Resources II: Iron Mining

Iron is a must have resource for a D&D civilization. I want to explore how iron can be found, and what other elements are found with it. I'm particularly interested in what kinds of things generally appear together. This will help me design a system for generating consistent placement of resources.

Iron has been mined for a long time. I found this article, about a Nasca ore mine, fascinating.

There are five major types of ore containing iron. There are some general trends that can help place them.

• Hematite. This is probably the most common form. It usually occurs in banded iron formations in sedimentary rock. You can also use hematite to produce various ochres, specifically in the colors of yellow, red, purple, sienna, and umber, depending on the concentration of impurities.
• Magnetite. Sometimes found in sands, but largely igneous and metamorphic rocks. It's also a good source of magnesium.
• Siderite. A poor source of iron, so I'll pretend it doesnt exist.
• Limonite. This is found in a class of soils called laterite soils. They are often found on plateaus, and contain large amounts of clay, aluminum (unknown to ancient peoples), and sometimes nickel. It's also useful for yellow ochre. More importantly, gold is often found in limonite deposits. It's generally formed in areas with alternating wet and dry seasons.
• Goethite. Commonly found in bogs, an early source of iron for the Welsh and Norse. The generation of bogs is something I'm still trying to figure out. While most of the other ores must be dug up, goethite can literally be picked up by hand out of the muck. In addition, a bog that's been picked clean generally replenishes every 50 years or so as the iron from deposits continues to coalesce. Yields brown ochre.

There is also meteoric iron, but it is so rare that any weapon made from it would certainly be an artifact and therefore priceless in any game.

Goethite and limonite are the lowest-tech and lowest-yield sources. When the limonite is worked, it actually turns into hematite. So these will be the first available in the tech system. Hematite and magnetite are harder to get and require more infrastructure and technology to extract iron from the raw ore. I need to do more thinking about what levels to assign to each of these resources. Of course, it requires additional knowledge to extract nickel and magnesium.

I'm thinking that to get a good idea of the distribution of some of these ores, I need a better system for figuring out the distribution of the different types of rock.

Resources discussed: hematite, magnetite, limonite, bog iron, clay, nickel, yellow ochre, red ochre, purple ochre, sienna ochre, umber ochre, magnesium, gold, 

Desirability I

Where do people live?

My plan is to set rules to determine a value of desirability. Cities will then be placed at the most desirable locations first, and then less desirable. When I get around to the history simulator, this rating will be used to guide the spread of civilizations. Azgaar has a very nice demonstration of this process here.

The base desirability will be 0.

+1	Coastal hex
+1	Natural harbor (if only one of the hex touches the ocean). I need to think about how I can check for this, since I currently use hex centers and not edges
+1	Per point of river drainage. This might be a little much, since these rivers can get fairly large. The Amazon would, by this system, have a drainage value of about 6800 at its mouth. Predictably then, the city of Belém was the first European settlement on the Amazon
+1	Per number of rivers joining at this point ($n-1$).
+1	Per raw (Stage 0) resource. Some will naturally be worth more than others (gold is better than copper), but overall this will be a good start.
+1	Within a favorable biome. This will capture temperature ranges as well as roughly approximating agricultural potential. It's pretty difficult to find information on specific biome suitability, since mankind is incredibly adaptable. For now, I'll just add this if temperature is between 60 F and 90 F, and if the biome is not E (tundra) or B (desert)
-2	In fact, E or B biomes are likely to be extremely unfavorable to settlement
-1	Mountainous terrain isn't great either

Applying those simple rules yields this:

Desirability map

A few thoughts. First, the rivers are looking very nice. There are some which drain uncermonially into the sea after a few dozen miles, and some which arc across the landscape. This map is set to have no endorheic basins but I'll be changing that, maybe even to the 17% Earth value. Second, the ideal bands are still pretty sharp, and I don't really like that. I have my doubts that wind could push enough moisture to form a rainforest across nearly 6000 miles (bottom right). I might need to further reduce the penalty for the tundra.

However, I just had a thought that if different races prefer different climates, perhaps I could create a different map for each. Everyone likes river trade, but halflings are particularly suited to the cold and so have penalties in warmer climates, whereas orcs are desert dwellers and build their cities in heat that would make an elf weary. Food for thought. The system is extendable and takes very little time to solve - I've vastly improved the brute force algorithms of a few months ago and now changes are easy to make.

Resources I: Resource Symbols

On my smaller scale maps (such as Demoland), I'd like to place icons denoting the available resources (at least, the exploited ones). It's always a challenge to come up with a new icon set, so I'm going to be stealing liberally and redrawing everything to fit my style.

Raw elemental resources (gold, iron, etc) I've taken from here. Alchemy has already derived many useful icons, so no sense in reinventing the wheel.

I also think I'll end up stealing from Atlas Elyden, which is an absolutely beautiful project (the icons are under a CC BY-NC license, but I'll probably use them to stimulate my own imagination rather than outright copying).

These will only be for the small maps; for one, they will be reduced to clutter at the large scale. For another, a giant dictionary of symbols I have to look up can be tedious for anyone not familiar with the system already.

I'll update this list as I create more. Eventually, each should have its own post.

	Copper. Mined primarily as chalcopyrite and malachite. ~28% chance to find.
	Iron. Found primarily as hematite. ~32% chance to find.
	Gold. Found with copper or in alluvial deposits. ~0.004% chance to find.
	Clay
	Wood
	Silver. Found as galena, but I'm going to consider it a raw metal instead. ~16% chance to find.
	Umber. The raw form of manganese. ~2% chance to find.

Temperature I: Turn Up the Heat

I'm using the guidelines here, but I'm still looking for better ways to formulate the temperature. There is a lot of cold on my world, and a lot of hot, and not a lot of in-between. This has the potential to be pretty interesting, so I'm going to leave it for now. In such a world, control of the habitable zone would be very important.

However, most of the land is already in the southern hemisphere. I have a very deliberate north-south orientation. Many maps I see have a bias to show a vast sea to the west, no doubt tapping into cultural memories of the medieval period, or Cantre'r Gwaelod-type legends. Of course, Tolkien did us no favors with Lost Númenor.

I'd post more of these maps, but opening in Inkscape gives my computer a heart attack, since Inkscape refuses to render using the GPU. WHY? (I hear it's a planned feature...).

Summer temperatures

Black is cold, grey is warmer. Yes, it's confusing, but I map the value of the pixel to the temperature. So 0 (black) is -47 F, all the way up to ~147 (grey) for 100 F. That makes the programming a little easier.

I do work on the rough map in color to make it easier to parse in my head.

Summer temperatures

I Couldn't Think of a Pun about Potential Evapotranspiration

Hmmm. Maybe "PETs Allowed" would have worked.

Potential evapotranspiration is an important part of the Holdridge equation. Now that I have the temperature of the surface (suitably adjusted for lapse rate), I can derive the amount of water that's vaporizing from the surface. The easiest (and most inaccurate) way to figure that out is to use the Thornwaithe Equation:
\[PET = 32 \left({10 T_a \over I}\right)^\alpha,\]
where $T_a$ is the average temperature, $I$ is the heat index, and $\alpha$ is a factor derived from the heat index. All these are easily derived.

July PET map (black is lower evaporation)

Man. I really need to fix the temperature maps - right now the map thinks it's got a massive ice cap that coats nearly the entire bottom fourth of the planet. That could make for some cool Clan of the Cave Bear type adventures. But it's not what I'm looking for.

Rain, Rain, Go Away

I totally redid the pressure maps (several times) and figured out a way to discretize the values (so, getting the pressure at each hex) in a much more efficient manner (essentially, I used Pixelize instead of Hexify in Gimp and I discard any pairs that don't overlap bounding boxes when doing the comparison). From there, I redid the wind maps and finally was able to move on to the precipitation. A little behind schedule but that's ok.

I want to say a bit about orographic precipitation. As mountains rise, water bearing air is forced up the pressure column, and also undergoes cooling. This means that all the water in the air will drop out (so, rain). I've modeled this as an increase in the monthly precipitation based on the elevations (where $\Delta P$ is the change in rainfall and $z$ is the altitude):
\[\Delta P = \textrm{max}\left(0, 0.005 \cdot z - 7.6\right)\]
For the life of me I can't remember where I got these numbers so I may just play around with them until I get something I like. Most of the scientific literature on the subject deals with absolute pressures and precipitation rates, not necessarily easy to translate into additional millimeters per foot of altitude.

Rain also does not fall in months with an average temperature less than freezing (technically, it could fall as snow, but for the purposes of climate determination, only liquid is considered). I still have to redo the temperature maps, so that cutoff, like everything else here, is subject to change.

Winter season rain

Demoland Infrastructure

This is largely based on the process here. I recommend reading through that first, to get a grasp on the basic concept.

The total number of people in the towns (all less than 1,500, seems inappropriate to call them cities) is 3,539. The total number of people is 52,044. Therefore, each urban dweller influences about 14.7 people (or the inverse of 6.8%, the urbanization rate). Taking Andox as the first example: it has a base infrastructure of $1208 \times 14.7 / 347 = 51$.

Here I've given 1 extra point of division per 2000 ft of elevation. This is less than I will probably use in the future, but I wanted things to spread out a bit here. I've changed all the terrain to initial woodland, which is 3 points of division. Those numbers can change, and once I get this system working in the code I'll play around with them a bit more. I did this one by hand to get the system in my fingers, and that's too much work to play around with.

The woods here really constrain the spread of the people. Fascinating. The elevation penalty tends to push the infrastructure down the same paths as the river, which makes sense.

Interestingly, there are two hexes with no infrastructure at all, between Betryn and Ffith. I want them to still count towards the whole population density, so I gave them 0.1 points of infrastructure each (all other numbers are integers).

To figure out how the rural population shifts (discussed here), I considered where the infrastructure points were concentrated. For example, the main Andox hex has 56 points. The total is 486.2, and hence that hex contains ${56 \over 486.2} = 11.52\%$ of the total infrastructure, and thus the total population. This works out to $(52044 - 3539) \times 11.52\% = 5587$. If we look at the local urbanization rates, Andox has about 21%. All the numbers work out and I'm happy.

Demoland Population

Continuing from here.

I want to base my system on Alexis's tech/dev system, which in turn is inspired by the Civilization games. I'll tweak as necessary.

I wanted an equation (surprise!) to determine the population and tech level of a hex. Plugging Alexis's thresholds into Excel yields the following, where $\rho$ is the population density of a hex, and $t$ is the tech level:
\[\rho = 3.03\exp\left(0.69 t\right)\]
I have to give some consideration to the difference between a hex population and a hex density. Density, of course, is dependent on how large the area in question is. Since the hex itself, which is the discrete unit of area, is very large (about 346 sq.mi), a low density can still yield a large population only if the entire hex is assumed to be occupied. This is usually not the case, depending on the topography.

However, for now I will be treating them as the same. The local perceived density, then, is how many people you can travel to see in one day (1 hex).

To keep things more simple, I'll pick a tech level of 8, which has a hex density of 765. That gives a total population of 52,020 for the 68 hexes (at around 2 people per sq.mi, that's practically deserted depending on how spread out they are).

So how many of those live in cities? I really like Lyman Stone's work on this, in lieu of the oft-quoted Medieval Demographics Made Easy. He suggests an urbanization rate of about 5.1% in Europe. I've tried to find some estimates of that number for earlier eras (specifically the Roman era, my go-to), but apparently Roman demographics is a battleground of academic contention, with some estimates as high as 30%. To that end, I think it's most useful to randomly select a rate between 5-15%.

Rolling for a rate: 6.8%. That puts 3537 people in the 10 cities. Seems a little low. Perhaps some of the cities (well, towns, really) will disappear, or be little more than tiny hamlets.

Now, obviously not every city has 353.7 people. So where are they all distributed? Zipf''s Law! Generally speaking, this states that the largest city is twice as large as the second largest city, and so on all the way down. Formally stated, the equation is as follows, where $P_i$ is the $i$-th largest city, $K$ is a constant, and $R_i$ is the rank of the $i$-th largest city:
\[P_i = K R_i^{-1}, \log(P_i) = \log(K) - log(R_i)\]
What we need to find is $K$, once we decide which cities are the largest, in order.

1. Andox
2. Malis
3. Gerlin
4. Derl
5. Ffith
6. Cadewin
7. Betryn
8. Llen
9. Norys
10. Kenor

So we know that the following equation will hold true:

\[\sum_{i=1}^{10} P_i = \sum_{i=1}^{10} {K \over 11-i} = 3537\]

Huh. That was easier than I thought. $K \approx 1207.6$, so the population of each city is $P_i = {1207.6 \over i}$:

Andox	1208
Malis	604
Gerlin	403
Derl	302
Ffith	242
Cadewin	201
Betryn	173
Llen	151
Norys	134
Kenor	121

That adds up to 3539, which is close enough. Interesting. So most of these are barely hamlets. This is in keeping with the low tech of the area though - remember that most people will be scattered across the countryside.

Another problem arises: Andox has more people than the average density (765), and Malis isn't far behind. Does this mean that everyone in the Andox hex lives in the city proper? That doesn't make any sense, given the earlier discussion of urbanization rates. The easiest thing to do is work backwards from the rate to find the number of people who have moved in to crowd around the city. That maintains the overall total. However, I foresee several problems with this.

1. Does the local tech level increase/decrease?
2. Not all hexes have settlements. There are 58 "empty" hexes now, each of which should have about 765 people.
3. With larger numbers at a higher tech level, you could easily have millions of people crammed into a single hex. That works out to thousands per sq.mi - almost a city in its own right!

What is needed, then, is a more robust system for determining the remaining urban population. I suspect my answer lies in the infrastructure system. And hence, a problem for a new post.

Stars and Bars

I have been thinking way too far ahead about dividing my large hexes into much smaller ones. Normally, these would be 6 miles or so - perhaps 2 mph if the mood strikes. But I have the potential to examine 1 mph...that is no simple task. Each 20 mile hex becomes 400 subhexes. How do I determine what's here? The real danger is that once that is done, I'm still not satisfied...but I should really stick to things I can accomplish right away.

Alexis has laid some excellent groundwork tying the effects of civilization to wilderness plotting. There are three posts here I'm standing on here: Groups, Features & Groups, and World Plotting. These posts deal with the generation of random subgroups of the 7 subhexes possible in a 20 mile hex. In particular, he presents a table with the odds of generating different combinations (I won't copy it here - if you want it, go there instead). A comment caught my eye, where someone considered whether this would be extendable (as I am now attempting) into larger numbers of subhexes, and hence greater detail.

I can now answer that question, a mere seven years later. This type of problem is dealt with by the combinatorics branch of mathematics, and specifically is called the Stars and Bars. The question asks, given $n$ objects, how many ways can I choose $k$ multisets? A multiset here refers to the fact that you can choose a sequence of objects that is distinct but looks the same - in Alexis's system, this is why there are only 2 distinct Type II hexes despite 7 total choices. The language here is very similar to the binomial coefficient $n\choose k$, and they are mathematically related:

\[\left(\!\!{n\choose k}\!\!\right) = {n + k - 1 \choose k} = {(n + k - 1)! \over {k! (n - 1)!}}\]

So: if we have $n = 7$ total hexes, and $k = 1$ is wilderness, then:

\[\left(\!\!{7\choose 1}\!\!\right) = 7\textrm{ total options}\]

Now that we have an abstracted model, let's return to the original equation. Fortunately, you can skip all the fancy math and just use Excel's COMBIN function. Boring (understanding the fundamentals helps with design). Here is where we encounter problems. In the 7 subhex example, the number of categories and the total number (128) of combinations are both manageable numbers. The cumulative sum is a nice, gentle slope.

Not so with 400 subhexes. There are only (let me grab my calculator) 2,582,249,878,086,908,589,655,919,172,003,011,874,329,705,792,829,223,512,830,659,356,540,647,622,016,841,194,629,645,353,280,137,831,435,903,171,972,747,493,376 total combinations. That curve is much steeper:

Hmm.

On the bright side, that pretty much guarantees that each hex will be unique (my ultimate goal), since the odds of the same layout occurring twice in 108,000 hexes (a laughably small number now) is astronomically small.

So what now?

The x-axis is tied to the infrastructure number. 7 is less than a typical infrastructure number. In the original post, the bell curve is scaled to 100. For 400 hexes, we have to compress it (assuming 100 is the max). For now, the easiest thing to do is just divide 400 by 100 and say that each point of infrastructure is worth between 1 and 4 extra hexes of not-wilderness.

These thoughts are still a bit incoherent, so I apologize. I'm trying to wrap my brain around the rule-defined system. Nobody tell Jeremy Crawford that someone is trying to use rules in D&D.

Demoland

While I work on the big map, inching towards perfection, I want to create a test case to work through the trade system. This will keep my creative juice flowing. Demoland is such a test case.

The names come from a Markov chain generator I'm working on, based here on a selection of Welsh names. Once I like the results more, I'll put up a full post about it.

These are 20-mile hexes (nominally a day's travel), with an area of ~346 square miles. The total map has 68 hexes (~23,562 square miles). That's roughly the size of West Virginia: a lot of land for people to live in, if they pack right. West Virginia has a population of about 1.8 million, at a density of roughly 77 per square mile. If they were evenly spread out over this area, that'd be around 27 thousand people per hex.

The dashed/light rivers are impassable for trade, either because they are too shallow, or because they drop too quickly, rendering them difficult to safely navigate (such as the segment meeting the main river at Andox). This has the effect of isolating Cadewin, Norys, and Kenor a bit more than the other cities. It's possible that, if trade were thick enough here, that villages could spring up at the point where the rivers become navigable. The river width is only representative of the area it drains, not necessarily its size.

Dark green is largely forested, light green is either cultivated or grassland. That's as specific as I'll get for now. Increasing lightness is higher elevation. The landscape doesn't change terribly dramatically until the river begins to carve a valley in the Malis area.

The drainage basin here gets fairly low, around 500 feet above sea level at the bottom right. However, for ease of calculation, we'll consider it as a closed trade system. If Malis has connections outside the other nine cities here, they aren't interested in trade or travel.

Now, the placement of these settlements might not be ideal, but I've yet to codify the algorithm to pick better locations. So here they are, through freak acts of nature or perhaps oddly placed resources.

The travel network is defined based on modifiers for terrain. This captures the effect of how long it takes to travel through each hex, based on a initial value of 1 day. Grassland is no modifier, through forest is 1.25, upriver is 0.707, and downriver is 0.5. Multiple routes can be defined between each set of points; this is most relevant when traveling upriver, but in more complex networks can capture the effect of, say, a frozen river in winter forcing land travel. Elevation is also accounted for: a change of 4000 feet requires an entire extra day to surmount. Thanks to this, Andox is equidistant from Gerlin and Derl in terms of travel time.

The network has 20 unique connections, but only 9 total point-to-point routes. I feel that very often, heart and soul is poured into world maps, and the ultimate use is as the simple network above: "We travel from Andox to Derl. It takes about a day. The end." Not that we should be spending a crushing amount of time on travel descriptions - but come on! There's an insane amount of gameability. Not only that, but if we as DMs and players treat beautiful maps as mere webs of nodes, then there's no point to spending the time to make them! On the other hand, if the time has been spent, we should think about how we can utilize the new detail set before us (Sunk Cost Fallacy be damned).

I haven't decided who gets what yet. It's an opportunity to tweak the randomized resource generation. Similarly, no population numbers. All will be made clear in time.