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.

Ex Nihilo IV: Tectonics I

My previous work involved manually drawing out the tectonic boundaries. With the advantage of distance, I'm no longer married to that concept. Instead, we can generate them from scratch.

To approximate an irregular but blue-noised grid, I'll grab a Poisson Disk Sample from all points on the map. This is a pretty useful algorithm to know, so it's a good chance to rewrite it to be a bit more efficient. After generating the points, tectonic plates are generated as a Voronoi map with the Poisson Disks as the centers (the shapes it generates are too uniform, so I'll revisit that later). A Poisson radius of 100 hexes yields 36 centers and the following map. Oceanic plates (approximately % of the total area, close to Earth) are shown in a lighter shade.

Each plate is assigned a random Euler pole and angular rate of rotation. I can use this to find the strength of collision at each boundary. I'm not super satisfied with the equations I'm using but they can always be modified.

Next, the rate of tectonic uplift for a given hex is determined by each fault's effect on that hex, with a bonus for continental plates (which are lighter and tend to "float"). High uplift values will generate mountains and island chains.

In the past I've played around with various combinations of Perlin noise, domain warping, and other forms of distortion applied to the uplift map to get interesting topographies. The final topography is heavily dependent on the uplift value: the droplet model algorithm gives interesting local topography but is ultimately overpowered by the underlying uplift. So it's important to get it mostly right to begin with. That being said, I find it important not to get too caught up in fine details when there is underlying code to fix. And there is a lot of code to fix and refactor.

To get a rough idea of the kinds of terrain this will generate, we can mock up the elevation values from uplift (essentially scaling from 0 to our max height 25599) and apply a sea height of whatever makes the land percentage 29%. I changed the continents slightly from the plate image above.

Note how straight the lines are, something that will need to be fixed.

The elevation generator is quite slow (particularly given the size of the map), and so it may be a while before I have this round of kinks worked through. My basic algorithm is a droplet model which erodes land based on the tectonic uplift, water erosion, sediment deposition, and coastal erosion. In the past I have used the Wei-Zhou-Dong algorithm for depression filling (which makes all rivers flow to the sea), but I am not terribly pleased with it this time around. We'll see.

Elevation XVIII: A Bigger Map

The map I've been using is about half the size it should be. So I wrote some code to generate a map of arbitrary size. I'm actually a little mad about it, since it took about half an hour to generate what took me months to figure out 3 years ago. But I'll be better for it.

The next step is to regenerate elevation and terrain, wind and currents, climate and all that good stuff.

If you're just starting out, don't make the same mistake I made; do this in a language that can handle big data efficiently. Python can barely chug along through this stuff.

Ex Nihilo III: River Travel

 The first obstacle I encounter when finding river routes is that there's no immediate correlation between AP and river vehicles (barges, small ships, etc). So we begin with some initial thoughts and observations.

Almost all relevant river travel will be by barge or similar vessel. The navigability of a river will then be dependent on the depth of the river and to some extent its velocity - some rivers may be too fast to pole or tow against. Once width becomes an issue, the point is moot anyway.

The numbers I'm getting from my velocity model (I've since tweaked the width and depth equations slightly) appear roughly commensurate with the numbers ORBIS uses. They apply a constant 65km/day rate, which is about 1.6 mph. If I only consider 10 hrs of daylight travel, we can get that number up to 3.2 mph (ah, what if I used daylight hours based on latitude as my indicator? Thoughts for later). This indicates that river travel will only be faster than dirt roads or lower. However, the cost will be much cheaper than overland travel. This kind of problem can be left with partially incomplete information, as this makes the party's decisions much more realistic.

Assume a river with downstream velocity $v = 1.837$ mph. This is equivalent to a day's journey (10 hours) of 18.37 miles. For a party traveling on land with 3 AP, that's the equivalent of 6.123 mi/AP. My assumption here is that river travel works by the same AP travel rules as travel on foot.

By the same measure, moving upstream against the current is a much slower affair. ORBIS puts upstream motion (by poling, horse-hauling, or even tacking) at 15 km/day. Therefore, we can put an upper limit on navigable rivers at where this advantage becomes moot, about 2 mph of downstream velocity.

Consider two hexes, A and B. The river flowing from A to B is 26 ft deep, 612 ft wide, and has a velocity of 1.837 mph. There is also a high road which runs throughout.

Traveling along the road with 3 AP takes 2.56 total AP (thanks to the maintained road) and 0.85 days. However, since the river is not quite fast enough, rafting down takes 3.27 AP and 1.09 days. These differences can add up for a long journey.

Say we wish to travel back from B to A. The road journey takes 0.85 days as before. But fighting against the current slows our barge to 25.6 AP, 8.5 days!

This has a few implications for travel and trade. First, there will be a severe resource asymmetry for downstream collection centers. In this case, a good might be 10 times more expensive in B than in A! Due to the upfront costs involved, trade will always move by water if possible, regardless of small disadvantages in time. Second, travel will likely also be asymmetric, as it will often be faster to raft downstream and walk back upstream. In fact, we have real-world examples of this, where cheap flat rafts would be brought down the Mississippi then disassembled in New Orleans, after which the crews would travel on land back up the river.

So it seems we will need a few different pathfinding tools:

• Routes by land only
• Routes favoring water wherever possible
• Routes combining water and land for maximum speed

Ex Nihilo II: Routing

I worked the number of total polities down to the low 2000s. This is probably still pretty high, but it takes a while to simulate warfare between so many cities, so I'll call it here.

The next thing is to place roads, according to Higher Path rules. I briefly tried a modification, where the number and type of roads was determined by the total infrastructure, and not the infrastructure category. For example, rather than primary, secondary, and tertiary routes, a hex with an infrastructure of 61 could have 1 low road (35), 1 cobbled road (20), 1 cart track (6), and finish out the 6 total connections with trails (0). This all adds up to $35\cdot1 + 20\cdot1 + 6\cdot1 + 3\cdot0 = 61$ total. However, I didn't much like this as the resultant network was weird-looking, with all routes being pulled towards the local center.

It's got kind of an artsy feel to it, but massive infrastructures would be necessary to make any kind of even network. So I went back to the old way but will continue to think about it.

It's a busy-looking map, but remember that this is primarily DM-facing (more accurately, computer facing). All we need to know for now is that there is a road from A to B of type C. From hence we can apply A* route-finding algorithms to find optimum travel paths between hexes. I'm using the AP weights from here, assuming a normal walking pace. The function will return both the route taken and the cost in AP, so that travel times can be determined for the trade network.

Note that these don't take into account the convenience of river travel if available. A comprehensive model will present the players with a plan involving the cheapest method: a boat from A to B, then overland from B to C, then finally upriver to D. For this, I'll probably rely heavily on the fascinating work by ORBIS. In the same manner, I need to re-address sea travel, so those are next on the list.

Ex Nihilo I: Starting Off

It's been a while since I've had much time to devote to my projects. I'm starting to get the itch to actually play again, and the problem rears its head that it's just not done. Nor will ever be done. I've spent a good deal of work on the tribal development system, which would eventually give rise to settled civilizations and more complex societies. I still want to develop that out, but a project of this magnitude is lifelong.

My thought at the moment is to generate a more or less fully populated world, without the benefit of the procedural history system. I would lose a lot of that organic weirdness, like the records of wars and such, but it would significantly shorten the timeline to a version that could be used in an actual game.

Instead of slowly planting and growing cities, I just place them according to the design principles I developed last year: the carrying capacity is determined first by the desirability of the location and then by proximity to nearby cities. This yields between 15,000 and 20,000 cities, ranging in size from villages of 200 to cities of about 75,000 inhabitants.

Infrastructure map: humans (green), elves (red), dwarves (blue), halflings (orange)

Not sure why halflings seem to dominate but there is plenty of time for modifying the variables later. This also brings to the front the issue that the world is roughly twice as small as it should be, and is incredibly habitable. Nothing wrong with that, but I do want to rework the map size (which gave me so much trouble 3-4 years ago) to be closer to Earth's surface area.

On the first pass, each city is its own hegemony, leading to a very busy map. About 86% of the habitable surface has at least 1 point of infrastructure, which is almost nothing anyway.

Hegemony map, very cluttered

The next step is to collapse these thousands of independent tribes into larger hegemons. Through the sword. This thins out the cities and yields a nicer political map.

Hegemony map, starting to firm up

This is approximately 10k hegemonies and about 25k cities. This is more than a pretty good start to create a playable world. I'll tweak this process some more, then begin to add resources and trade networks.