Infrastructure Development Re-examined

This post is part of a series describing the procedural distribution of infrastructure and facilities in a pseudo-medieval TTRPG setting. If the reader hasn't read the prior posts, may I suggest starting here and reading in advancing chronological order?

This is a short one, as I just re-visit earlier work after some experimentation.

In the previous post I mentioned that the population implied by the level of infrastructure development was out of line with the desired population total. Specifically, I wanted the population total to be approximately 800 thousand but the 5,761 infrastructure points distributed by this technique implied, with that of the notable settlements, a population of only about 440 thousand. The solution I settled upon was to normalize the infrastructure points after their distribution amongst the 18-mile hexes based on the target population over the implied population. This had the effect of scaling the infrastructure points up to 12,163, implying a population of about 791 thousand.

Below is an image showing the most highly developed, Type-1, hexes in white, the completely undeveloped are black with no outline, and the shades between indicate intermediate levels of development with the lighter being more developed. The light blue pentagons represent the most populous settlements, those over 4,000, the red diamonds are settlements with 1,000 or more, but fewer than 4,000, and the grey circles are smaller settlements which qualified as "notable."

For reference the terrain is shown below.

I think that this has worked well and the answers have an intuitively correct feel to them. I have found anomalies at the 6-mile hexes on 18-mile hex intersections where they have been allowed to keep higher infrastructure totals than I would have allowed them manually because their higher total clearly should have been attributed to a settlement within one of the 18-mile hexes but was not because the program is operating with the myopic constraint of looking at each 18-mile hex group independently. Conveniently, the anomaly had a counter example nearby illustrating why those intersection hexes are exempt from the infrastructure point swapping step in first place.

The thing is though, this method has produced a picture of civilization that is merely punctuated by small areas of wildness and that's not as dangerous, superstitious, and parochial as I want my world to be. By shortening the "distance half life" from 18 miles to 12 miles I achieved what I think is a categorically different result.

Here humanity and the wild hold more equal sway. Humanity can be seen to have gained and lost ground against the wild. This is the sort of world I want my players to face.

Infrastructure Details at the Six-Mile Hex Scale

This post is part of a series describing the procedural distribution of infrastructure and facilities in a pseudo-medieval TTRPG setting. If the reader hasn't read the prior posts, may I suggest starting here and reading in advancing chronological order?

There's an aspect of Alexis' infrastructure distribution system that has remained a niggling worry for me and following this step I will see whether that concern was justified. The worry is this: infrastructure "points" distributed at 18-mile hex level (or 20-mile, strictly following his technique) are based on population, but only loosely in that the points aren't "conserved." What I mean is that the initial "seeding" of the infrastructure points has a direct correlation to population, but the "spreading influence" part can result in different total numbers depending on the terrain and thereby breaks the correlation with the population total. As long as these are treated as relative numbers rather than absolute, that's no problem either, however they do have an absolute meaning to the 6-miles hexes which thence have specific population meanings when there isn't a settlement within the 6-mile hex. I think that this will end up no jiving with the starting population figure. Maybe it won't be significant, maybe the "play" in the 6-mile hex type population implications is large enough to accommodate a wide range of terrain effects on the infrastructure. That's the disconnect in my understanding of how Alexis intended the system to work and what I think it will end up doing, anyway.

This is the first step where there will be randomization involved in building the data behind these maps, so we could rerun this step several times and get different results each time although I will employ a randomization seed in the program I write to do this so that I can repeat for specific results when desired (typically to troubleshoot misbehavior).

The technique includes mapping steps as well as the data generation part in which I'm interested. I'll skip directly to the "Hex Type" section of the procedure. Hex type is a categorical description of the level of civilized development to be found in the 6-mile hex, where type-8 is complete wilderness and type-1 is highly developed. The infrastructure points of the 18-mile hex are randomly distributed to the 7 hexes entirely contained by it to designate the level of development within each of these smaller hexes. It takes 64 points to make a type-1 hex, 32 to make a type-2, 16 for type-3, 8 for type-4, 4 for type-5, 2 for type-6, and 1 for type-7. Any settlements within the 18-mile hex, however, get the most highly developed designations automatically. The technique leaves undesignated 6-mile hexes at each of the 18-mile hex's vertices where only a third of the area falls within the 18-mile hex. These "gap" hexes are handled handled after their surrounding hexes have all been designated whereupon the average of those surrounding hexes is used to set their value, with fractional results providing a proportional chance of landing at the integral values on either side of the fractional value.

Because I'm doing the entire domain at once automatically, I'll be making a minor modification. I won't leave any gaps. Instead, as each 18-mile hex distributes its points, the fractional hexes will have a 1/3 chance of getting a point as well. Only the 7 hexes entirely contained by it, however, may be used in the type-swapping step to ensure that settlements within the 18-mile hex get the most civilized hex type available there.

I ignored whether or not any landmass actually existed in the 18-mile hexes while propagating the infrastructure points, but at the 6-mile level of detail the numbers have specific meaning and so those hexes without any land to develop will not get any infrastructure points. I had a vague notion that the number in 18-mile sea hexes might lend some sense to port traffic or piracy, and that is still at the back of my mind, but at the 6-mile hex level this doesn't seem helpful. There is a question in my mind as to whether the infrastructure points at the 18-mile scale might be prorated to the number of 6-mile hexes of the 9 within it that have at least some land. On one hand, concentrating infrastructure at the coastline seems like it would happen naturally from this, but on the other some hyper-concentrated development could result. For the first pass, I'll go with my instinct and prorate the 18-mile hexes' points before distributing them.

The end result in the most civilized part of the domain came out like this. Each six-mile hex shows the hex type as a Roman numeral and the specific infrastructure points as a smaller Arabic below it. I'm unsure about the level of civilization. Intuitively it seems high, but I won't make a judgement just on that basis. First I want to analyze what all this civilization adds up to in terms of population totals.

Fortunately I can run this entire process all the way through in under five minutes, so experimentation won't be terribly painful.

At the start of this exercise the 18-mile hexes were "seeded" with 2,831 infrastructure points distributed according to the total population of the notable settlements within each of those hexes. After being propagating points outward from these hexes to influence the development of civilization outside those settlement, there were 36,105 infrastructure points. Many of those were in the ocean however, and after dropping points proportional to the number of non-land 6-mile hexes, the total came back down to 5,761.

At this time Alexis has defined the Type-7 hex, but not the more civilized on his Wiki, so I have had to make assumptions. The Type-7 hex has just 1 infrastructure point and a population of 50 - 80, averaging 65. Using the final infrastructure points as a basis for calculating population, however, the implied population outside the notable settlements is somewhere between 288,050 and 460,880. The notable settlements themselves add 63,583 so that is about half of the population I wanted to end up with.

I think what I'd like to do is normalize the infrastructure points at the 18-mile hex level after the propagation step. Since the final population is intended to be about 735,000 outside the notable settlements, the total number of infrastructure points should be about 11,300, almost double what I have. Scaling the infrastructure after the propagation step will get the right number, but may result in less spread than might otherwise occur. On the other hand, scaling the starting number will likely increase the spread of civilization over a great distance and make a larger final number.

One possibility is to scale the starting points iteratively until the solution converges on the desired final result. While that is probably the best option, I'm going to start smaller and simply scale the final number at the 18-mile level and see what happens. Having the infrastructure more tightly consolidated seems like it might be a good choice in a dangerous world anyway.

This will take some experimentation.

Infrastructure Spread

After "seeding" the 18-mile hex grid with infrastructure numbers according to the amount of, let's say, public works control, exerted by the settlements falling within each hex of the grid, the next step in developing a sense of the region's facilities is calculating the "spread" of that control. As I mentioned in my previous post, Alexis' method is to propagate half the number to adjacent hexes, halving that influence with each hex outward until a border is reached or the number drops to zero. Elevation changes, in increments of 400', between each hex each halve that influence again. For example, a hex with a 100 points would add 50 points to an adjacent hex whose mean elevation was within 400' of its mean elevation. If that adjacent hex was 900' higher, however, it would only get 12 points added. While this system makes a lot of sense, I'm working with different data and using different tools from Alexis, and on this step, I'd like to attempt a refinement over his method.

The image above shows the 18-mile hex containing the settlement of Carlow at the center and the 6 hexes immediately surrounding it. The green numbers in the center of each hex are the "seeded" infrastructure points for each hex and only one of Carlow's neighbors also has a seeded value. The red numbers toward the top right of each hex is the mean elevation for the hex in meters. The elevation change increment which concerns us is 400' which is about 120m and all of Carlow's neighbors are within that range, effectively at the same elevation as Carlow.

One reason I'd like to refine the propagation of the infrastructure number is that, just looking at it, Carlow, on the east side of its hex, has a large hilly area dominating the center of the hex and seems like it ought to influence the development of infrastructure far more in the 2 hexes east of it than the 2 west. I'd like to account for that while still staying "zoomed out" at the 18-mile hex level of detail.

The approach I'll try first is to use the distance and amount of elevation change between each settlement in the hex and the center of the adjacent hexes to calculate how much infrastructure development influence that settlement exerts. Staying close to Alexis' method as a starting point, I'll count each 12 of the 10m contours and 18 miles between the settlement the adjacent hexes' centers as halving. I have the luxury of doing this automatically instead of by hand, so I'll take fractional effects from those impediments to the spread of infrastructure, but I'll round results to the nearest point in the end.

Writing a program to do this was a very fun exercise and results look like this with the small green number below the initial infrastructure score representing the final score.

Carlow's population being 457 generated an initial infrastructure score of 20 (or 20.359, before rounding) which makes its maximum range of influence about 78 miles, that is since we halve the influence every 18 miles, 18 times the base 2 log of our score tells us the furthest hex centers we need to consider possibly influencing. We won't go anywhere near that far without hitting contours, every 12 of which also halve the influence. There are 68 of the 18-mile hexes whose center is within that mileage limit, however the contours limited the spread of Carlow's influence to only 14 of them: 0908, 0909, 0910, 0911, 1007, 1008, 1009, 1011, 1108, 1109, 1110, 1111, 1210, and 1211.

Carlow[3] to center of 18.0908 is 51.958 miles, crossing 21 10m contours, contributing 1 infrastructure.
Carlow[3] to center of 18.0909 is 37.219 miles, crossing 37 10m contours, contributing 1 infrastructure.
Carlow[3] to center of 18.0910 is 26.726 miles, crossing 29 10m contours, contributing 1 infrastructure.
Carlow[3] to center of 18.0911 is 26.203 miles, crossing 40 10m contours, contributing 1 infrastructure.
Carlow[3] to center of 18.1007 is 55.370 miles, crossing 22 10m contours, contributing 1 infrastructure.
Carlow[3] to center of 18.1008 is 37.814 miles, crossing 15 10m contours, contributing 2 infrastructure.
Carlow[3] to center of 18.1009 is 20.911 miles, crossing 9 10m contours, contributing 5 infrastructure.
Carlow[3] to center of 18.1011 is 19.542 miles, crossing 23 10m contours, contributing 3 infrastructure.
Carlow[3] to center of 18.1108 is 46.026 miles, crossing 25 10m contours, contributing 1 infrastructure.
Carlow[3] to center of 18.1109 is 28.359 miles, crossing 16 10m contours, contributing 3 infrastructure.
Carlow[3] to center of 18.1110 is 11.543 miles, crossing 12 10m contours, contributing 5 infrastructure.
Carlow[3] to center of 18.1111 is 10.273 miles, crossing 10 10m contours, contributing 6 infrastructure.
Carlow[3] to center of 18.1210 is 21.749 miles, crossing 47 10m contours, contributing 1 infrastructure.
Carlow[3] to center of 18.1211 is 27.693 miles, crossing 41 10m contours, contributing 1 infrastructure.

On first reading it appears that this method had the desired effect. Carlow only increased the infrastructure score of the adjacent hex to the southwest, through all those hills, by 1 point, but the hex adjacent on the southeast received 6 points from it.

Let's look at the hex to Carlow's northeast. There's no settlement there but it ended up with the same level of infrastructure as Carlow's hex because:

Hex 18.1110 has 0 base infrastructure and 9 outside infrastructure contributors, 13 from Dublin, 5 from Carlow[3], 3 from Newbridge, 2 from Naas, 1 from Mullingar, 1 from Celbridge, 1 from Leixlip, 1 from Tullamore, 1 from Maynooth, for a total of 28.

Looking around more, I continue to be pleased with a superficial review of the results.

I'm going to look around a bit more, find some better river data than what I have so far, and move on to the 6-mile hex work next.

Distributing Infrastructure in a Pseudo-medieval, Fantasy Ireland

I'm experimenting with methods of procedurally generating plausible settings for TTRPGs, and here I'm specifically looking at the distribution of infrastructure. This exercise will follow, pretty closely, my interpretation of a system that Alexis Smolensk has developed for his own setting.

I have as external inputs the SRTM elevation data from the USGS and a list of the 60 largest settlements on the island of Ireland according to the 2011 Northern Ireland Census and 2016 Census of Ireland. Because I'd like to simulate a population somewhat like a 16th century Europe, I will make assumptions about total population of the island and its distribution. Estimates I've found of the island's population in the 1500's is around 800,000 and so I'm taking that figure as the first assumption. My second is that in a medieval, agrarian society, some 8% of the population might reside in urban locations. That might be on the high side, historically, but since I'll be scaling the 60 starting settlements accordingly only one of them will end up with a population over 10,000 and one more over 5,000, representing a little under 4% of the total population which is good enough for me to start.

One convenient thing about this exercise is that I can execute it over and over very quickly using different assumptions. While I'm interested in making reasonable and justifiable assumptions, I needn't fixate on getting them right the first time. Indeed, much of what I hope to gain through this exercise is refinement of these assumptions and procedures.

In order to execute Alexis' infrastructure method, I first need to assign, to each of the 18-mile hexes of which the island is composed, an elevation. I'm starting with data that has 3-second arc precision, about 90m, so going out to 18 miles is going to mean averaging tens of thousands of data points to get one figure for the 280.6 square miles the hex covers.

The image below provides a sense of the number of elevations to be counted. Notice that they have varying area, so some of these points will contribute more or less to the average for the 18-mile hex depending on how large each polygon is.

Up close, the input data looks like this:

 

I had a fair amount of foundational work to build before writing the program to actually do the hex grid calculation, so it was two days later before I was able to actually execute this. For the whole island of Ireland, the program ran for about 14 minutes, which isn't great, but I'll call it good enough since it's I'm not planning to re-execute many times.

There are 272 18-mile hexes in my grid over Ireland, although I could have selected a tighter grid if I had been careful, many of them are water only, but really there's no harm in having the extras; they don't eat much.

Here are the results, zoomed in fairly close, and with the contours turned on, because I'm rethinking the role of elevation, at least at the 18-mile hex scale, as not as helpful to what I want to achieve as what the contours say could be.

The small, black numbers are just my hex labels, the larger, red numbers toward the upper right of each hex are the average elevation figures in meters. I think for infrastructure distribution purposes I might consider counting contours between the centers of each hex, or something like that, instead. For now, though, I'll move on with the next step given the answers I have at the moment.

The population of settlements forms the basis for distributing infrastructure. The population assumptions are 1) total island population 800,000 and 2) 8% of the population resides in settlements (that is, the "urban" population). My input data for the 60 largest settlements on the island indicate the 48% of the contemporary population of the island lives in those settlement. This scales the size of the setting's settlements to about 1.88% of their contemporary population.

Given that infrastructure is driven by settlement, each 18-mile hex containing one or more settlements will start with an infrastructure number equal to the hex's proportion of the total urban population times the island's population divided by the area of an 18-mile hex.

This initial assignment sets a number above 0 in about 20% of the hexes with a very steep drop off from the highest at 1,074 to 468 to 221 and then decreasing with a gradually flattening slope with about half of the 52 hexes with some infrastructure number having between 10 and 20, and after 10 dropping to 0.

The next step of contributing infrastructure points to nearby hexes will take another slug of work, so I'll leave off here for now.

The Map Isn't the World and Why the World Matters

My general intent with this blog is to share the development of my TTRPG game settings in the hope that it some little nugget of information I post will be helpful to someone else; that I'll pay forward some small part of the debt I owe to others who have shared their work. This post is somewhat of a departure from that mission.

After sharing with friends a pretty picture of what I was working on I reflected on their reactions. I made this representation by selectively shading, and then deriving contour lines from, the Shuttle RADAR Topography Mission digital elevation data. I'm not really making a map. This picture is that, but it's not a picture that I really care about. It's the data underneath it, and the data that I wish to add to it, that is important. No picture is necessary.

I'm not sure how widely that is appreciated in the TTRPG community. Let me explain further. While the picture above helps the beholder to appreciate the shape of the earth there, there is much more data that could be here. That is there. That is impossible to show all at once. In an attempt to illustrate my point, I'll focus in on a smaller area and show the same information in a different way.

This spot is about 85 miles southwest of the center of the other image, but it's the same data. Instead of shading, however, I've represented the SRTM data more directly. The pink dotted lines, and numbers within them, are the actual radar height data, clumped by like values, which is why the little bit of the Atlantic in the top left of the image just has one "0" on it instead of one "0" every 3 arc-seconds.

The contours, same as the previous map image, were derived from those boxes. I've created more detailed information, in those contours, from less detailed information. The details were implied by the less detailed data, but nevertheless, and importantly, made up. They are not reality. For my purposes that unreality in no problem. Even if I use it to derive more data, exaggerating the inaccuracies, that's still no problem because I'm using this to run a game, not pilot an aircraft with black-painted windows.

Although it may sound like I'm advocating for one to ignore reality in the one's game setting, that is not my point. The realism is important. The specific match of these contour lines to the shapes of Maumfin and Tully Mountain are not important, but a reasonable, imaginable from common human experience, sort of slope is important.

I want my players to understand what it looks like approaching Maumfin from the west along the shore of Ballynakill Lough even though they would know them only as unnamed features in possible swineman territory. This is what that looked like one day about 5 years ago. Of course, there is no paved road nor even the single utility wire seen here when the characters see it.

It's important that I give my players a believable place where they might encounter swinemen even though encountering swinemen is not part of the common human experience. I have made so few departures from that common human experience in the setting otherwise, that it is easier for my players to incorporate this fantastical element into their imaginations. The swinemen are more real, and more threatening, because the countryside is so recognizable as a place my players might have walked or driven.

As evocative as a map like this is it can't compete with the emotional impact created by the vision the players create in their heads when I describe a dozen swinemen, in wedge formation, coming down the slope above Ballynakill Lough toward the PC's camp where they've spent the last couple of days catching, smoking, and salting fish to provide for the next leg of their expedition after having laid such a tangible countryside before them first.

Moreover, and back to the original point, at the end of the day, the map from the Hobbit, above, is only a picture. Those pink boxes near the beginning of this post, or rather the data they are displaying, will drive the placement of infrastructure expanding outwards from population centers, the course of streams the player's characters depend on for water while trekking as they are, and so much more than pretty pictures.