Map Tiling Algorithm

Question

The Map

I'm making a tile based RPG with Javascript, using perlin noise heightmaps, then assigning a tile type based on the height of the noise.

The maps end up looking something like this (in the minimap view).

I have a fairly simple algorithm which extracts the color value from each pixel on the image and converts it into a integer (0-5) depending on its postion between (0-255) which corresponds to a tile in tile dictionary. This 200x200 array is then passed to the client.

The engine then determines the tiles from the values in the array and draws them to the canvas. So, I end up with interesting worlds that have realistic looking features: mountains, seas etc.

Now the next thing I wanted to do was to apply some kind of blending algorithm that would cause tiles to seamlessly blend into their neighbours, if the neighbour is not of the same type. The example map above is what the player sees in their minimap. Onscreen they see a rendered version of the section marked by the white rectangle; where the tiles are rendered with their images rather than as single color pixels.

This is an example of what the user would see in the map but it is not the same location as the viewport above shows!

It is in this view that I want the transitioning to occur.

The Algorithm

I came up with a simple algorithm that would traverse the map within the viewport and render another image over the top of each tile, providing it was next to a tile of different type. (Not changing the map! Just rendering some extra images.) The idea of the algorithm was to profile the current tile's neighbors:

This is an example scenario of what the engine might have to render, with the current tile being the one marked with the X.

A 3x3 array is created and the values around it are read in. So for this example the array would look like.

[
    [1,2,2]
    [1,2,2]
    [1,1,2]
];

My idea was then to work out a series of cases for the possible tile configurations. On a very simple level:

if(profile[0][1] != profile[1][1]){
     //draw a tile which is half sand and half transparent
     //Over the current tile -> profile[1][1]
     ...
}

Which gives this result:

Which works as a transition from [0][1] to [1][1], but not from [1][1] to [2][1], where a hard edge remains. So I figured that in that instance a corner tile would have to be used. I created two 3x3 sprite sheets that I thought would hold all the possible combinations of tiles that could be needed. Then I replicated this for all of the tiles that there are in the game (The white areas are transparent). This ends up being 16 tiles for each type of tile (The center tiles on each spritesheet are not used.)

The Ideal Outcome

So, with these new tiles and the correct algorithm, the example section would look like this:

Every attempt I have made has failed though, there is always some flaw in the algorithm and the patterns end up strange. I can't seem to get all the cases right and overall it seems like a poor way of doing it.

A Solution?

So, if anyone could provide an alternative solution as to how I could create this effect, or what direction to go for writing the profiling algorithm, then I would be very grateful!

Answer 1

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.