Map Tiling Algorithm

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!

---

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 = 5
for 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]

Ie 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.

链接地址: http://www.djcxy.com/p/6838.html

上一篇: 如何制定2048年游戏的复杂性？

下一篇: 地图拼贴算法