2016-08-16 Alpine Map Generator

I’ve been working on the Alpine map generator some more. It uses Text Mapper to render the output into an SVG image and it uses the Gnomeyland icons by Greg MacKenzie so it looks nice. Sadly, I’ve developed a pathetic obsession about getting it “right”. To illustrate my obsession and to help me fight it, let me document what I’m talking about. This is a “bug” I just fixed.

Text Mapper

Here’s the old map:

The old map

What’s wrong you ask? I was confused by the canyon carved into the mountains from lake 17.04. I expected it to flow into 18.05. Let’s check the height map before lakes start flooding, looking for an outlet:

The initial setup with arrows pointing where the water wants to flow

Why would the river flow from 16.03 (height 7) to 15.04 (height 9)? This makes no sense.

So I studied my debug logs:

The key is the list of candidates after looking at the first round of neighbors: `1804 1603 1803 1703 1705 1604`. These are sorted by height, 16.04 is last, which is great. But it also means that 16.03 (wrong direction: east into the mountains) is the equivalent of 17.05 and 18.04 (south east, towards lake 18.05).

Clearly, I needed a better sorting algorithm for the next candidates to look for: the candidates at the same level needed to be sorted by their lowest neighbor which had not already been looked at.

A bit later:

`1804 1705 1703 1803 1603 1604` is the correct sorting order. 18.04 and 17.05 are at the front and the southern passage is discovered.

Notice my additional debug message I needed to check that for hex 17.03 the neighbor 17.04 is not checked. It would be the lowest neighbor indeed but we have already looked at it, so we need to ignore it. By the time we’re looking at 17.03, only the three northern hexes are options and 17.02 is indeed the lowest neighbor.

So now, since 18.04 and 17.05 are equally likely, the algorithm picked 17.05 and lake 17.04 doesn’t flow into lake 18.05 but their rivers meet in 17.06 and I think the map is much better, now. Here’s the corrected water flow map:

Correcting the flow of water

And with this correction, the final map also looks different. No more canyon into the mountains!

The new map

Now I get the urge to draw lines indicating the water divides. Noooo! 😄

And just in case I make further changes to the algorithm, here’s what the application would generate right now for this width, height, and seed.

right now

☯

Time passes and I’ve spotted another problem in the map above. Take a look at lake 34.05 which drains through one of the highest peaks in the area, 35.07. How on earth did that happen?

We need to look at the earlier maps again. Before the flood processor kicks in we can already see that any water on the peak 35.07 will immediately drain into lake 37.09.

So, the algorithm goes:

1. look at all the neighbors of 34.05. None look very exciting, they all drain back into 34.05.

2. look at our neighbors’ neighbors; ignore the two white fields, focus on the light gray ones, e.g. 34.06.

3. all its neighbors drain back into the lake with the exception of our peak, 35.07; and with that, we found our lake 37.09

4. looking at all our candidates, lake 37.09 looks like the most promising, since it lies lower than any of the candidates

And that explains it. The problem seems to be that once we are looking at a candidate like 34.06, we’ll evaluate all its neighbors, even the very high ones like 37.09, even if a candidate of similar height like 35.05 has a much better neighbor like 36.05 which would drain off to the north west.

My algorithm is not enough breadth first like water would be.

More tinkering ahead, I can feel it!

​#RPG ​#Hex ​#Maps ​#Text Mapper

Comments

(Please contact me if you want to remove your comment.)

⁂

Algorithm changed to be totally breadth first. I’m not sure it is better. 😄

– Alex Schroeder 2016-08-17 13:24 UTC