Sometimes something hits your brain like a pile of bricks. I lurk on mastodon far more often than I ought to, but this post actually paid dividends.
Now, thanks to ACOUP I was already familiar with the idea of cities needing hinterlands (and those being often omitted in modern media), but I was struggling to understand how to arrange those cities on, say, a hex map.
Enter central place theory, a theory on the distribution of cities. After watching some YouTube videos to get my head around the idea, here’s how I was able to use it.
My starting point was already having geography in place, as well as the location of the largest city I wanted. I already had some loose modifiers for travel time in mind. These are 3-mile hexes so entering a flat hex takes one hour at walking speed. So I made hills take 2 and rivers take 0.5. These probably aren’t the travel time I’ll use in play for players but they’re simple enough demonstration purposes, and it isn’t yet clear to me whether they need to match up exactly or not.
Now, we start by finding the travel time to each hex from the main city. We start by finding the distance to each hex adjacent to the city, then find the distance to each hex with the lowest distance, and continue until we’ve filled the area. This is a simple pathfinding algorithm and isn’t too tedious to do by hand (though this example quickly got bigger than I expected). For this example I’m not tracking the distance more than four hours for reasons I’ll explain shortly.
Now I’m going to draw an outline containing all the hexes which are four or less from the center city. What this represents, according to the central place theory, is all the hexes containing settlements which will go to the main city for whatever things they cannot get in a more local market. I’m also using it to define a border between settled and “wild” lands – a dubious concept but one which the fantasy of the OSR is usually built on.
According to our theory, the main city also contains all the services of a smaller level town as well. If we assume that the reach of a smaller settlement is two hexes, we can draw a second outline inside the first to represent all those settlements which will also go to the main city to get less rare goods.
So far this is pretty uninspiring. But the real magic happens when we consider the following. All the settlements between these two outlines *also* need a market for local goods. Or another way to look at it is for each given service it takes a certain amount of settlements within a certain range to be able to exist, so if a region can support these services they will crop up. Some, usually more specialized, services require more people to be profitable, so they are scattered sparsely, whereas more common services require less people so they’re scattered more densely.
We can prevent overlap by placing these towns twice their reach from one another. We’ve already calculated distances from our city, so we can start putting towns on hexes that are four hours from the city.
So I’ve placed a town up north and calculated the borders of its reach.
Now, central place theory says that regions of the same level shouldn’t overlap, which is something I failed to do for this map. Four hours was actually a miscalculation not accounting for the quantized nature of the hexes. It should have been five hours, and in general twice the distance plus one hour should produce results with no overlap. There’s also going to be artefacts due to the way I’m calculating distance not being the same in both directions (I’m only counting the cost for “entering” a hex and ignoring the type of hex I’m leaving. This is what I do during games) and the fact that unlike the central place theory I’m not putting smaller settlements on smaller grids.
In any case the next step is to repeat this process until all the settlements inside the outer outline of the main city are served by towns.
In case it isn’t clear, I want to point out that I’m assuming every “empty” hex inside these boundaries contains a village. I just didn’t want to draw them in.
Again you’ll see more overlap than the theory predicts in the ideal case. That’s; it’s close enough for our purposes. But you’ll also notice that I’ve extended the outline of these towns outside the red outline for the city’s market. This stems from central place theory assuming all land evenly contains settlements and not allowing for borderlands. This is an example of what settlements might look like in a “points of light” setting – hand-placed cities with smaller towns and villages scattered a short distance around them.
This leaves the question of what to do with these “empty” hexes still within the. I’ve elected to put settlements in them, deciding that they’re smaller due to their more limited access to the city’s markets, creating a new level on the settlement hierarchy below our basic settlement. We can call these hamlets as opposed to the baseline settlement of villages. I’m tempted to speculate as to what a more realistic solution might be, but it would be fairly baseless. These artifacts can be left in to create a bigger variety of region sizes, as I could see things getting a little too simple on a flat plain.
So it might be fair to say that this technique is really more inspired by central place theory than truly based on it. It’s close enough for my purposes of having a process deciding the placement of settlements smaller than cities.
But the main takeaways of central place theory are directly useful:
- Settlements contain the goods and services of all the settlements further down the hierarchy
- Settlements of the same size are roughly evenly spaced by travel time, which gets smaller as you go down the settlement hierarchy.
Wait, why bother randomizing where the settlements are?
I have a lot to say on how procedural generation can be used in ttrpgs, but for now the reason I’m using proc gen is because this system works as an oracle. It’s no different than a random encounter table or, for that matter, a game system. It’s a way for a GM to generate outcomes via some internal logic that is independent of them, which allows them to encode ideas they wouldn’t necessarily think of themselves when simply improvising off the cuff. It’s just in the prep phase rather than the running phase of the game for the GM.
Additional Ideas
Instead of assigning two levels of services – town and city, we could assign three and see where things end up. Services with a range of 4, 3, and 2, for example. I’m not sure how this will affect our ability for settlements to contain the services of all settlements below them, but that ought to hold for the reason that having to go to two different places for two different services is a pain in the ass and that would cause the services to move.
This system could be used for distributions of things other than cities, such as magical sites in the world.
These market area borders could also be used as somewhat natural political borders, because they are based on travel times. With geography and artifacts distorting the regular grid shown in central place theory they’re irregular enough I don’t think players would notice unless it was pointed out or your campaign is taking place on an infinite plain. And there’s nothing stopping you from adjusting political borders after the fact as you see fit. The overlaps could be used as conflict regions where feudal lords are butting heads.
Even if not used for political borders you could have a go at using these areas as markets for item prices, though that would require computer aid very quickly. I’m still looking for better ways to handle simulating markets.
Speaking of computers, there’s also the temptation to set this up as a computer algorithm, either on a hex grid or operating on the pixels in an arbitrary image using shaders.
Bonus
My example map, cleaned up and colored to indicate market borders (I like to use yellow to represent fields), with a road system added.
Leave a Reply