Auto-tiling Standardization
Friday, April 19, 2013 - 18:05
Are there any defacto standards for auto-tiling layouts?
Any body put any serious thought into auto-tiling?
Benefits of a standard for auto-tiling:
- Standard template for artists to build off.
- Allow drop-in replacement of any suitably sized conforming tile-set (or any with proper scaling).
- Automated relayout to other auto-tiling regimes.
- Others?
Should be elegantly addressable. eg. neighbour bit field
Regimes:
- Connectivity: 4-connected, 8-connected
- Subsets: 1 wide (fences, narrow walls, etc.), > 1 wide
- Internal transitions, exeternal transition (ie. terrain fringing)
- Diagonals?
- Non-square tiles (ie. hexagonal)?
Every now and then I see a thread from a programmer wonder how to make use of a tile set, or a programmer who doesn't have the first clue how to drive an image editor to transform it into the layout they want.
Auto-tiling should take some constraints, like smaller tilesets. i.e. tilesets wirthout digonals nor transitions. I tried to use some 2d side scorller tilesets to try this system, and I just goit only stranges errors...
But a template for doing some tilsets would be useful. Doing a standard would help programing.
Auto tiling for 4 way connectivity requires 48 tiles. Thats all you need. I have extended 48 tiles to 64 and made a template. caeles has improved upon that and came up with a perfect looking tileset with no seams. There are alternative tiles that can break uniformity too.
However, these are good for top down or lpc style games as it is biased to square tiles. If looking from an angle (iso or orthogonal) tile width should be more than its height and would require another template.
But how do you address those layouts without an accompanying neighbourhood to tile mapping table? That's the idea behind laying out in neighbour-bitfield order: it's its own neighbourhood to tile mapping.
Those layouts look to be designed more for aesthetics (seam minimization, symmetry maximisation) than for programmatic simplicity.
The layout should be the same for any orthographic square-grid tiling.
Red warrior needs caffeine badly.
I designed my layout to create tiles faster. Without seams it will be even faster, when I get time I can type a tutorial about it. With seams it takes less half an hour to create a tileset (see cobblestone tileset), without seams I suspect it will be like 15mins or so. I could create mapping table for these tileset and possibly an application/script for auto tiling. However, it will require some time. Once done, they can be reused in different games.
For orthographic, the height/width ratio should be different, thats all. Otherwise, (assuming 1/2) from the world perspective, roads will have 2x height then width. Although I havent tested, for isometric a 45 degree rotation then scaling height to 1/2 should work as well. But probably the textures would look a bit flat.
These tilesets can also be used transparent on any other tileset, however, there is another issue of having specific transition tiles, or transitions that takes larger space. For instance cliffs/walls or water to grass crossing.
Im jumping into this thread because soon (relatively) I will need to have a system that can do full auto-tile. We did something similar with LPC tileset before, but that was relatively easy.
Layout by neighbourhood bitfield order is certainly neat for having concise engine code. But it has issues:
- One wants to have variations of tiles to break monotonicity. But the number of variations is not spread uniformly over the neighbourhood configurations. For example the pattern recommended for the LPC had two variations of "singular", four variations of "middle" and no further variations.
- In fact, in general the field does not consist of bits, because along "yes" and "no" there is "don't care". That's why the templates linked by cemkalyoncu have 47 tiles, a prime number. (He states 48, because he includes "empty". I would prefer to defer that one to the tilesheet pertaining to the outer terrain type.) In those templates, the typical source of "don't care" is that diagonal neighbourhood, e.g. in direction north-east, is only relevant when neighboorhood holds in directions north and east. Sure, you could eliminate "don't care" by placing copies of tiles. But that is needlessly wasteful, in the example you have a blowup factor of over 5. And it would allow variations for the wrong tiles: each "bend" would get 16 variations while "middle" gets none.
Different projects have different needs of multiplicities of variations; that alone defeats a universal standard.
I will happily admit that optimizing my template for seams, symmetry and memorizability was done purely for the fun of it, with no regards for my fellow programmers. Meanwhile cemkalyoncu pointed out that seamlessness actually helps the artist. And I believe the other optimizations help in coding the bitfield-to-tile mapping (which inevitably is a manual task).
By the way, in the project Cuyo we put some thought into our templates (partly because we hoped to achieve universal templates...). In particular, the 4x4 template which ignores diagonals (by Immanuel Halupczok) is good for both the artist and the coder (it is used for example in http://opengameart.org/content/cuyo-level-noseballs). If you are still looking into templates, you might want to browse http://cvs.savannah.gnu.org/viewvc/cuyo/data/pics/?root=cuyo. There are even templates for isometric map layout.
Another lesson from that project is subdividing tiles into quarters to achieve a smaller template. For example, the 64 (or 47) actual tiles in my above template use only 5 variations per quarter, so a template with 5 tiles could have sufficed. (For a non-seamless such template see my recent Slime submission.)