Regions and Settlements

Posted by Chris Rosser on Sun 27 July 2014
Hello! This site is archived and no longer maintained. For Chris' main site go to

In my last post, I wrote about my logic behind generating the populations of a realm's capital city and all lesser cities and towns. Since then I've written code, changed my approach and little and am now thinking about generating more information about each settlement.

Firstly though I want to backtrack and talk about regions within a realm.


When I first posted about how I would organise settlements within a realm, I suggested that each realm would be divided into a number of regions each stored in its own subdirectory. Within that subdirectory I'd put each settlement.

This is appealing for a number of reasons. Most obvious is that it breaks up the parent directory, which might have more than a hundred settlements (thousands if I include villages). The other reason is that kingdoms and empires were often divided into regions that may have been governed as almost autonomous realms in their own right.

An example of this is medieval England, which although quite centralised for a pre-industrial state, included a principality after 1291 (Wales), and several duchies (York, Lancaster, Cornwall, Clarence, Gloucester, Ireland etc etc) many of which were created in the 14thC. Further muddying the waters are English counties (there's a lot of them) which were governed by earls and were for practical purposes the true administrative subdivisions of the kingdom. A system of Counties and Duchies also divided France and France also included sub-kingdom, like England during the Angevin dynasty.

Another good example is the Roman Empire, which was divided into Provinces (Senatorial and Imperial) and client states.

So using England as an example, I could structure the realm as follows:

    + duchy-of-cornwall
    + duchy-of-clarence
    + duchy-of-lancaster
    + duchy-of-york
            + York
    - principality-of-wales
            + Chester

There's two drawbacks to this system. Firstly there's the complexity of administration; in England as we've seen, duchies were ceremonial rather than administrative divisions. Counties pre-date duchies by hundreds of years and were themselves divided into smaller baronies.

Secondly the deeper we drop our content the more fiddly it is to address it with our scripts. I'm comfortable with the notion of creating a sub-realm but further dividing these is not something I personally care to do at a directory level, though I will consider storing further subdivisions within the _realm_index.json file.

If I run with this idea, I'll have to backtrack slightly. I need to expand the create_realm tool to include a create sub-realm function. I'll also need to update the structure of the _realm_index.json file to include a new regions array, which would look like this:

    "Kingdom of England" : [
        "name" : "Kingdom of England",
        "slug" : "kingdom-of-england",
        "area" : 130395,
        "regions" :[
            "Principality of Wales" : [
                "name" : etc,
                etc :   etc,
                "regions" : [
            "Duchy of York" : [],
    "Kingdom of France" : [],
    "Kingdom of Poland" : [],

Area of a region

The easiest way to determine this will be to specify the size of the region as a percentage of the realm. That will be one of the first questions the tool will ask.

Population density of a region

Simply calculating the area of the region as a percentage will not determine the region's population. Regions within the realm will have different densities; those with more arable land and closer to the urban centres will have a much greater density than peripheral, remote and mountainous regions.

One approach is to specify the population density of the region and from there we can determine the actual population. The problem here is that we'd need to create program controls to ensure that we don't accidently create regions with populations that are bigger than the realm.

The other approach is to specify the population of the region as a percentage of the realm's population. That way we are always working within the boundary of the realm's total population. From there it's a simple matter of calculating population density.

Note that while we at here it will be worth noting how much of the region is arable land. Arable land is the basis of subsistence and our realm's economy.

Settlements of a region

As with our population, it's not enough to rely on the area of the region to determine its urban population pool. A region might be large (50% of the realm's area) but sparsely populated (10% of the population) due to its geography; so giving the region 50% of the realm's total urban population wouldn't make sense without some socio-political justification (which we are free to do, but we need to control it).

As with our approach to the realm population, we must specify a percentage of the total urban pool who live in that region. From there, we can use our settlement generator to spit out the settlements according to whatever level of centralisation we choose.

Fleshing out our settlements

Now that we've introduced regions into our realms we need to ensure that our settlement generator can cope. That should be straight forward but I'll report back later; today I want to concentrate on generating more information about our settlements.

Settlement templates

As with realms, I've baked in support for creating different templates because one size is not going to fit all. Maritime cities are going to be different to mountain temples, particular when it comes to generating the businesses and trades of a settlement (see below).

Likewise, by using templates we can further customise the structure and content of the settlement's main markdown file.

We can also use templates to reduce repetition when we want to create a lot of settlements that are similar like a cluster of city-states or a bunch of border forts.

Adding flavour

So far our settlement has got a name and a population and a markdown file for writing all the qualitative stuff. I believe however that it's worth recording other quantitative data in our json file.

To begin with I want to record:

  • The size of the settlement (its area specifically)
  • It's type (city or town) and political role (capital city, regional capital) and if it has a charter
  • It's location (region) and if it's designated as part of the realm's core or frontier
  • If it's fortified and garrisoned and if so, the size of the garrison
  • The size of its hinterland (area and population)
  • A city map (just a link to an image)

The size of settlement can be calculated by dividing it's population with it's population density. Factor in if the settlement is walled and if the population has spilled outside a walled area.

The type can be determined automatically by the threshold we set; for example anything about 2500 will be a city. We may also need to note if other factors determine that a city is, for example it might need an official royal charter or have a cathedral (or similar institution). It's political role will be automatically assigned if it's a capital city.

Location and core/frontier designation will be important for determining other information. A frontier city may be much more likely to be fortified either for current or historical reasons. A city in the realm's core may be much safer from external strife but may still be heavily garrisoned by a civilian guard to keep the populace under control.

The location will be automatically updated with the region but in future I may want to include a more accurate descriptor.

The size of the hinterland is important because it tells us a lot about the settlement's economy and political influence. A settlement must have a sufficient hinterland to feed its population or it must do so through trade. Large settlements will have a large sphere of influence that may extend beyond the amount of land needed. Therefore it may have access to important natural resources. The flip side is however that the city will also need sufficient control keep it's urban and rural populations pacified. Alternatively it may be close to a mightier neighbour and is part of that's settlement's sphere of influence.

So how do we calculate how much land is needed to support our settlement's population?

Again I'll turn to Ross's article, where he notes that a single square mile of land can support approximately 180 people. That means that for a city of 15,000 people, we need the agricultural output of 83.3 square miles. That's assuming however that this land is given 100% over to feeding the settlement when in reality it would also have to feed the people who are working that land and only a surplus would go to the settlement.

The hinterland then needs to be large enough to feed both the settlement and the people living in the hinterland. Getting that right will take a little juggling. For example, let's assume that we have a population density of 50 people per square mile. We'll assume that's enough labour to get the most of the land so each square has a surplus worth 130 people. So to calculate the amount of land needed to feed the city (and those working the land) we divide 15,000 by 130 to get 115.3 square miles. 115.3 square miles at out population density yields 5,765 people living in the hinterland.

However, we've made assumptions that are undermining our results. Firstly our population density is our national average; good, productive land will be much more densely populated. Most of Britain's population is and has always been centred in the south because that's where we find the best agricultural land and weather. So each region needs to have a different density as we note above.

Our second assumption is that 50 people is enough to yield the full productivity of our arable land. We know however that Medieval agriculture was labour intensive and inefficient. Even if everyone of those 50 people were farmers and their labourers, that would not be enough to realise the full productivity of that square mile unless you introduce labour saving devices such as water wheels and wind mills.

  • five men, a day to reap and bind 2 acres of grain
  • 1 team of oxen could plough 1 acres in a day

Later on I'll also want to record:

  • Districts with the city
  • Economic information
    • Its revenue (taxes, tolls, businesses, and tariffs, tribute)
    • Its expenditure (maintenance, construction, wages, military, welfare, tribute)
  • Military information
    • The make up of it's garrison

Businesses, services and trades

Ross's article includes a methodology for generating businesses, services and trades who operate within a settlement. His approach is to specify a support value for that business, which is the amount of population required in a settlement to support said business. It's a excellent approach and one he based on primary information from Paris. It's works as follows.

A shoemaker is given a support value of 150 people required to make one business viable. In a city of 25,000 that means we'd expect to find approximately 166 shoemakers.

We'll stick with this approach and will store our business and support values as a json file. Which looks something like this:

    "shoemaker" : "150",
    "brewer" : "400"

Ross's list is comprehensive and based on a Parisian tax list of 1292 but what if we want to add more, change values in one city, or tailor business to suit a particular city type, location or geography. Our approach will be to use our settlement templates, each of which will include a trades.json file which we will tailor to the template.

Now we can create a harbour settlement template and alter the businesses and their support values according to a settlement that derives much of its economic wealth from the sea. In such a city we're going to have more fishermen, fish merchants, sail makers, net makers and shipwrights than a land-locked city such as Paris. We can have a template based on a legionary fort, castle, monastery, mining community, university town etc etc; the choices are endless.

This template gets duplicated when the settlement is created and thus we can alter business and their values in one settlement without affecting the template or other settlements.

The next consideration is that I ultimately want to use this as data source for a lot of our economic modelling (which I'll get to in a later post). For example I want to assign each business a wage and possibly other information down the track. To accommodate this, I'll set each business as an array so I can simply add more key value pairs as I need. For example:

    "shoemaker" : [
        "support-value" : "150",
        "day-wage" : "10"
    "brewer" : [
        "support-value" : "400",
        "day-wage" : "15"


The day wage is artibtary at this stage; it could be dollars, pounds or sesterses. All I really want to establish is differences between each business. I'll explore this at length when I start economic modelling.



Wow you read this far! This site is archived and no longer maintained. For Chris' main site go to