Isometric terrain

Question

I am trying to make an isometric terrain editor. My problem is not to do with making isometric graphics or rendering them, rather it is to do with indexing of tiles.

Let's say I'm making a hill at tile(10,5). This would mean that tile(10,5) will be type corner_1, tile(11,5) will be corner_2, tile(10,6) will be corner_3, and tile(11,6) will be corner_4. This will create a peak in the middle of the four tiles.

It seems simple to start with, but there are so many possibilities. If we have two hills that cross over each other, we would need inverted corner tiles. If we had a diagonal mountain, the surrounding tiles would need to be turned into diagonal inverted corner tiles. I've already created most of the images for the tiles http://opengameart.org/content/simple-iso-city-work-in-progress. My question is, is there already a set of "rules" I can follow for how terrain modifies itself around surrounding terrain? Or do I have to figure out every combination of tiles myself?

consider asking here gamedev.stackexchange.com its stackoverflow specifically for game dev. — Ronen Ness
I would create your hill (aligned to mxn cells as a voxel map and derive/render the tiles directly from it. It is hard to think through all the combinations this way you have enough tiles to manage smooth hill or transition in a specific way do not bother with all combinations the tile set would be huge and user unfriendly. — Spektre

Eike Decker Eike Decker · Accepted Answer · 2015-10-29T08:37:55

If you want to know the number of combinations, you have to consider the neighborhood of your relevant field and the potential different elements there.

Say you have have 4 neighbors and two tile types (0 and 1), then the number of combinations is 16: Each neighboring cell can have either the same field type as the center one (type 1) or the other type (0).

Center type | north | east | west | east
     1      |   0   |  0   |  0   |  0
     1      |   1   |  0   |  0   |  0
     1      |   0   |  1   |  0   |  0
     1      |   1   |  1   |  0   |  0
     1      |   0   |  0   |  1   |  0
(...)
     1      |   0   |  0   |  1   |  1
     1      |   1   |  0   |  1   |  1
     1      |   0   |  1   |  1   |  1
     1      |   1   |  1   |  1   |  1

You might see now that this is actually binary counting. If you have 8 neighbors, you might already guess, you'll have 256 different combinations. This is of course a lot... you can get that number down by mirroring cases, but that often doesn't look so well in a shaded environment as your link refers to.

If you have more tile types to combine (desert / grass / stone), the number of combinations is then (number of types) ^ (neighbor count), so for 3 tile types and four neighbor cells, you'll have 3*3*3*3 = 81 cases. If you have different height levels (say 2), you'll have basically doubled the number of types, so it'll be 6*6*6*6 = 1296.

You probably don't wanna do this (manually). You might consider modelling and texturing the tiles in 3d and render them on an atlas and do some post effect filtering (color palette) for your game's style. The data amount isn't that bad for a pixelated game like that. The texture would be quite huge, but I believe games from ~2000 have actually done that at times. (If your tile size is 32x24 and you have 1296 tiles, you'd need around a million pixels for space, which is about as much as a 1024x1024 texture can hold).

Isometric terrain

1 Answers