Neighbour aware tiles without terrain tool

Questions
1

Hi, I just started using Tiled a few weeks ago, and I’ve been searching up and down for a solution. I’m sure it’s been done before, I just can’t figure out how.

My team is making a procedurally-generated 2D platformer in Unity, and we’d like to use Tiled and Tiled2Unity to create the room templates. We want to be able to create rooms using one ground tile, without manually placing corner/wall tiles, and without requiring a background. Theoretically, each ground tile would check its neighbours and turn into one of the ground/wall/ceiling/etc variations. Additionally, we’d like to be able to hand place special tiles like diagonals, which are treated as a ground tile by its neighbours, but wouldn’t automate themselves.

To my limited knowledge, the terrain tool wouldn’t be able to transition a tile to nothing, as we need the background to be transparent (we’re doing stuff with the bg in Unity). Plus I’m not sure how to generate collision with the terrain tool.

The solution seems to be to use automapping, but we’re using the 47-variation blob style tileset, and that seems like a huge undertaking to handmake rules for each variation, especially taking into account the special tiles. If anyone has already created a rules set for a 47-tile thing, I’d be amazed, and ask if I could use it!

Another solution would be to have Unity do the tile automation, as it seems fairly straightforward in C#, but Tiled2Unity creates the map on a mesh, and my team doesn’t know how to separate each individual tile. (This is our first project using Unity).

Finally, there’s bypassing Tiled entirely in our pipeline and just making the templates in Unity scene view. However, that’s way more difficult than we thought, and Tiled just seems so powerful that I know there’s a way to do it that I’m just not seeing. Plus I wouldn’t know how to do it other than placing one game object sprite per tile, and that seems like it could become very resource intensive (though I’m just the art guy, not the programming guy).

So yeah, like I said, I’m sure this has been done, so I’m sorry to have to ask, but I can’t find a solution anywhere. Automapping is likely the key, but it seems like a lot to create by hand. If anyone has any other solutions, or if they’ve already created a set of rules I could use, I’d be very grateful! Thanks again!

2

If the terrain tool would work otherwise for this, maybe it would be possible to use some kind of “background tile” that you simply ignore in your engine?

I do not really understand the issue here. Would you have 47 different rule tiles, or 47 different variations? Wouldn’t you need to set this up for the terrain tool if you would like to use that too?

Otherwise you might be able to automatically generate your rules for automapping with some kind of script.

Regards,
Ablu

3

That… is something I never though about! I’ll play around with that. I did just figure out that collision settings on a tile work even when that tile is created from the terrain tool, so that might be the way to go.

The tilemap we have has 47 (well 48) types, depending on the tiles next to them. The best example I can give is

The difference between this and the terrain tool is that the terrain tool seems to alter the surrounding 8 tiles (or 4 tiles around a vertex if you hold ctrl), whereas this only alters the placed tiles themselves. (I guess the same functionality could be created by filling the room with the wall terrain and erasing the spots that should be open).

That would be great if I could! I’ll start looking into the tmx format and see if I can make anything of it!

Thanks again,
Mik

4

Ah, right… I wanted to point this out too, glad that you found it out yourself :slight_smile:

Right… The Terrain tool currently does not support 8 directions. It can only work on vertices / edges. You will need the terraintool for anything else.

5

I’ve found an example on the issues log where someone wants to do what I’m looking to do; terrain-style mapping with 1x1 tiles rather than 2x2 or 3x3 as it is now.

The solution there was to use the automapping tool, which makes sense. At this point, I need to either buckle down and start making up rules, or find a way to do it with scripting. Unfortunately, like I said, I’m the art guy, not the programming guy.

6

Note that I’m definitely interested in adding an additional tool that will work with the kind of tileset you’re working with. It may be possible to do it based on automapping rules, but actually it would make a lot of sense to implement this algorithm in a dedicated tool so that it can be very fast and with preview.

The main problem I see is how you would tell Tiled about the structure of your tileset. Already with the terrain tool, this can be a tedious process because you need to tell Tiled for each tile corner what terrain it has. And your tileset has even more combinations. We may just have to rely on a certain common tileset organization.

7

I’ve created a ruleset for the 16-tile version. I’m not 100% certain if I’ve created it in a way that’ll work off my local computer, but I’ve attached the rule tmx and a tileset I’ve altered. The rule uses input and inputnot layers to determine if there’s another B tile in a cardinal direction or not, then creates the proper result.

autotile.tmx (4.9 KB)
cheatsheet.tsx (335 Bytes)
rule1.tmx (9.1 KB)

I wouldn’t know anything about implementing it within Tiled by itself, except that it would likely be easiest with a bitwise checker, example being from http://www.saltgames.com/article/awareTiles/
That example only checks the four cardinal directions, the 16-tile version. To expand it to 8 directions, the page says that you’d need 81 tiles to expand it to the 8 directions, but realistically you only need 47.

This image shows the 47 tiles you’d need, as well as the sum that corresponds with each tile.

As for structuring, I can’t imagine a tool like the terrain structure tool working for this. The best solution I imagine is to determine the common tileset organization by numeric order. An alternate can be found http://www.cr31.co.uk/stagecast/wang/blob.html

Which shows you a more visual way of doing it.

8

Hello. I wanted to chime in on this subject as it has been something that I have been working through on my project.

I too have found that the 47-auto tile setup works best for my needs, and I wanted to share with you my method I have used to address it.

I hope to work with bjorn (or perhaps by myself) to edit the Tiled Editor directly with my method, or develop a new method that works more globally.

But for now here is what I do:

I have created a special tileset format that looks like this:

Where the first tile of each auto-tile set is the “magic tile”. In the tiled editor it self you draw with this tile, but in game, it merges the like tiles together. Like so:

I do not use bitwise operators, I did read an article recently how they could be used for selection of which tiles to use based on the directions (as you point out in your post). I made my game pick the neighbor tiles by using a series of if statements and switch/cases… haha.

It gets the job done for my purposes, but my team members struggle to predict the end result while they are mapping. And this is why I would like to edit the Tiled Editor, make my own branch or something, that includes this method visually while you are editing the maps as well. And I would like it to hopefully use the bitwise method instead of my inefficient method.

I don’t know, what do you think? Do you think the way I currently do it good enough?

Thanks!

9

I think this is going to depend on who has time for it first. But there’s also two parts to this, the backend implementation and the UI. And I think for something like this, the actual brush implementation is going to be pretty straight-forward. The tricky business will be adding a UI where the user can tell Tiled how to treat the tiles.

To implement this brush, we’ll need to associate with each tile:

  • The terrain the tile is to be associated with (this is not done by the terrain tool, which stores this information separately for each of the tile’s 4 corners).
  • Its index in the blob, which could be expressed by indicating for each side and corner whether it expects a tile of the same terrain type there or not, from which the blob index can be calculated.

One open question for me is whether this should be a separate tool, or whether this can be combined into the Terrain Brush. It would be rather neat if this could be combined into some kind of all-powerful terrain-and-fences tool, but I’m not sure if that wouldn’t just become too complicated.

10

Pleased to find this thread. The artist/designer I’m working with on a game has just pointed me at http://www.saltgames.com/article/awareTiles/ and asked if it can be done. So I’d like to +1 this feature. Is there an official Issue/Feature Request I can upvote?

Right now for our game 4 neighbour directions should do, which I think I can easily implement in a .tmx conditioner/importer. I’d just add a property on 16 adjacent tiles in a set and swap out the gids appropriately using the binary mapping described in the article. This should allow the level editor (human) to place any of the 16 tiles in the map and they would be corrected automatically later on.

It would be nice to move the above process into the Tiled editor tool if possible, so that the results can be seen immediately (and ideally undone if necessary) is a plugin the right way to go here? I guess it would also be good to be able to apply the routine using a mask, so maybe some combination of auto-mapping might be required too?

Thanks for any advice

11

I don’t think so yet, feel free to create one!

12

See Blob tilesets using automapping? for a full set of rules.

Regards,
Ablu