Map Tiling Algorithm

The basic idea of this algorithm is to use a pre-processing step to find all edges and then select the correct smoothing tile according to the shape of the edge.

The first step would be to find all edges. In the example below the edge tiles marked with an X are all green tiles with a tan tile as one or more of their eight neighbouring tiles. With different types of terrain this condition could translate to a tile being an edge tile if it has neighbours of lower terrain-number.

Once all edge tiles are detected the next thing to do is to select the right smoothing tile for each edge tile. Here is my representation of your smoothing tiles.

Note that there are actually not that many different types of tiles. We need the eight outer tiles from one of the 3x3 squares but only the four corner squares from the other since the straight-edge tiles are already found in the first square. This means that there in total are 12 different cases we must distinguish between.

Now, looking at one edge tile we can determine which way the boundary turns by looking at its four closest neighbour tiles. Marking an edge tile with X just as above we have the following six different cases.

These cases are used to determine the corresponding smoothing tile and we can number the smoothing tiles accordingly.

There is still a choice of a or b for each case. This depends on which side the grass is on. One way to determine this could be to keep track of the orientation of the boundary but probably the simplest way to do it is to pick one tile next to the edge and see what colour it has. The image below shows the two cases 5a) and 5b) which can be distinguished between by for example checking the colour of the top right tile.

The final enumeration for the original example would then look like this.

And after selecting the corresponding edge tile the border would look something like this.

As a final note I might say that this would work as long as the boundary is somewhat regular. More precisely, edge tiles that do not have exactly two edge tiles as their neighbours will have to be treated separately. This will occur for edge tiles on the edge of the map which will have a single edge neighbour and for very narrow pieces of terrain where the number of neighbouring edge tiles could be three or even four.

The following square represents a metal plate. There is a "heat vent" by the top right corner. We can see how as the temperature of this point remains constant, the metal plate converges to a constant temperature at each point, being naturally hotter near the top:

The problem of finding the temperature at each point can be solved as a "Boundary value problem". However the simplest way to work out the heat at each point is to model the plate as a grid. We know the points on the grid at constant temperature. We set the temperature of all unknown points to be room temperature (as if the vent had only just been turned on). We then let the heat spread through the plate until we reach convergence. This is done by iteration: we iterate through each (i,j) point. We set point(i,j) = (point(i+1, j)+point(i-1,j)+point(i, j+1)+point(i,j-1))/4 [unless point(i,j) has a heat vent of constant temperature]

If you apply this to your problem, it is very similar, just average colors instead of temperatures. You would probably need about 5 iterations. I suggest using a 400x400 grid. Thats 400x400x5 = less than 1 million iterations which will be fast. If you only use 5 iterations you probably won't need to worry about holding any points constant color, as they wont shift too much from their original (in fact only points within distance 5 from the color can be effected by the color).Pseudo code:

iterations = 5for iteration in range(iterations):    for i in range(400):        for j in range(400):            try:                grid[i][j] = average(grid[i+1][j], grid[i-1][j],                                     grid[i][j+1], grid[i][j+1])            except IndexError:                pass

Ok, so first thoughts are that automating a perfect solution to the problem requires some rather meaty interpolation maths. Based on the fact that you mention pre-rendered tile images, I assume that the full interpolation solution is not warranted here.

On the other hand as you said, finishing off the map by hand will lead to a good result...but I also assume that any manual process to fix glitches is also not an option.

Here's a simple algorithm that does not give a perfect result, but that is very rewarding based on the low effort it takes.

Instead of trying to blend EVERY edge tile, (which means that you need to either know the result of blending the adjacent tiles first - interpolation, or you need to refine the whole map several times and can't rely on pre-generated tiles) why not blend tiles in a alternating checker-board pattern?

[1] [*] [2][*] [1] [*][1] [*] [2]

I.e. only blending the tiles starred in the matrix above?

Assuming that the only permitted steps in value are one-at-a-time, you only have a few tiles to design...

A    [1]      B    [2]      C    [1]      D    [2]      E    [1]            [1] [*] [1]   [1] [*] [1]   [1] [*] [2]   [1] [*] [2]   [1] [*] [1]   etc.     [1]           [1]           [1]           [1]           [2]           

There will be 16 patterns in total. If you take advantage of rotational and reflectional symmetry there will be even fewer.

'A' would be a plain [1] style tile. 'D' would be a diagonal.

There will be small discontinuities at the corners of the tiles, but these will be minor compared to the example you gave.

If I can I'll update this post with images later.