AuthorTopic: Tiled -- Automapping Rules  (Read 7539 times)

Offline astraldata

  • 0010
  • *
  • Posts: 391
  • Karma: +1/-0
    • View Profile
    • MUGEN ZERO

Tiled -- Automapping Rules

on: September 13, 2014, 01:37:48 am
https://github.com/bjorn/tiled/wiki/Automapping

and

http://www.youtube.com/watch?v=UUi0lD1pxyQ


I don't know if it's just me, but I'm just not following this stuff.

I know some of you use Tiled to make your level designs, so I was wondering if anyone here would please explain how to make automapping rules for a platforming tileset in Tiled?

I got how the layer-naming stuff works -- I just don't understand the logic behind the "rule" stuff (regarding placement of which tiles on what layer to get what result), and the website is no help, nor is that video.

This is the tileset I'm using and trying to make autotile/automapping rules for:
I'm offering free pixel-art mentorship for promising pixel artists. For details, click here.

     http://mugenzero.userboard.net/

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile

Re: Tiled -- Automapping Rules

Reply #1 on: September 13, 2014, 03:00:23 am
Here's a minimal example with a very rapidly prototyped 8x8 tileset.

It mainly extends grass fringes.

There are two rule sets present.

One maps each tile to itself. This is important because isolated tiles will otherwise not be included on the output layer. These are 1x1 patterns.

The other recognizes the pattern 'grass top without a fringe' and outputs 'grass top with a fringe'. This is a 2x1 pattern.

Layers included are similar to the example set:

"Regions, Input_set, InputNot_set, Output_Ground"

And in broad summary, this is saying to look for input in a layer named set, and output a layer named Ground.
Tiles in Input_set are checked for their presence, tiles in InputNot_Set are checked for their absence. The combination of the two is how the rule 'X tile without Y tile' is expressed: I placed the lower grass tile in the lower cell of the 2x1 in the Input_set layer, and the fringe tile in the upper cell of the 2x1 in the InputNot_set layer, and finally both together in the Output_Ground layer. A variation of this could be used to remove fringes, for example (by including both together in the Input_set layer, none in the InputNot_set layer, and only the lower grass tile in the Ground layer.)

Regions expresses the area of pattern recognition, with careful isolation of each individual pattern. I made a very visible tile "R" for use on this layer, a practice adopted from the examples. Normally, you should map the Regions layer first, because all tiles on other layers should fall within the regions defined. Tiles outside those regions will be ignored (ie. have no contribution to the ruleset).
Regions do not need to be rectangular, although I think they do have to be contiguous. I later defined a rule
where the input regions are

Code: [Select]
#.  .#
.#  #.

and the output regions are

Code: [Select]
.#  #.
..  ..
To automatically insert diagonal grass edges at platform edges. These are 8-directionally contiguous.


Finally, the rules.txt file lists which rule files to use. In this case it only references one. The result is that maps saved in that directory use those rules when 'Automap' is invoked. In general you should isolate each individual group of effects in a individual rule file, so you can control the order in which they are applied, which is a principle I broke here -- the 'map tiles to self' rules should really be in a separate file.

You can test it by loading ruletester.tmx and hitting Automap -- a Ground layer is generated which is identical to the input except it has longer grass fringes.

Before:



After:



Looking at your tileset, you could begin by making similar rules: You have a series of tiles with both dirt and grass, where the 'upper' grass tile to finish it is inferrable from the base tile, so you could make some 2x1 patterns to define that.
You could continue by making a few 3xN patterns for the dirt in the bottom-left corner, to take the generic dirt tile, detect that it is vertically isolated, and output the correct 'tapered column' tiles in the bottom left. I believe you can randomize this (pick randomly different dirt tiles for the 'mid' part of the column), but I haven't got experience with that yet. (EDIT: I got that working, following the same method for randomization listed on the wiki page)
« Last Edit: September 13, 2014, 05:38:38 am by Ai »
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline astraldata

  • 0010
  • *
  • Posts: 391
  • Karma: +1/-0
    • View Profile
    • MUGEN ZERO

Re: Tiled -- Automapping Rules

Reply #2 on: September 13, 2014, 06:11:20 pm
One maps each tile to itself. This is important because isolated tiles will otherwise not be included on the output layer.

Not sure I understand this part.

I'm mainly having a hard time understanding how to deal with pre-existing tiles. For example, the tile example you gave only showed how to use the "inputnot_" layertype, which is helpful, but it didn't show any rules for how to change, for example, the normal (no-fringe) grass tile to a dirt tile if there were two of them stacked vertically. Or even better, if there was a dirt tile to either side of the bottom newly-made grass tile (which now should become a dirt tile, assuming it's possible to make rules for either of these scenarios).

Where I'm at currently:

http://host-a.net/u/Ace/tiled_example.zip

The above is what I've come up with so far, but it's not where I want it to be. You can use the red "I" square to draw a single tile and two tiles side by side or vertically and it should 'work', but I can't get any farther than that. My rules just aren't working for more complex configurations. I'm using "Use automapping while drawing into layers" in the preferences, but I know it's my rules that are broken since it will work when you draw to the left but not when you draw to the right. Any idea what's going on?
I'm offering free pixel-art mentorship for promising pixel artists. For details, click here.

     http://mugenzero.userboard.net/

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile

Re: Tiled -- Automapping Rules

Reply #3 on: September 14, 2014, 03:33:15 am
The comment about mapping tiles to itself is not necessary, it's just one way to do things. If your output layer is the same as your input, I don't think it is necessary.


I've looked at your rules, and I'm confused (particularly, I don't understand why you have a special tile 'i' rather than drawing with a particular tile)

So I decided to start them from scratch.

First I made some rules that turn your sample map into a sensible graphical map.

replacement platformer-rules.tmx

Try running automap manually, with these.

These are probably not the rules you want (they are not designed for automap-as-you-draw usage), but they may prove instructive. In particular they carefully isolate each pattern so that it doesn't step on other patterns toes. Inadequate specificness of patterns is probably the cause of your directional difference in automapping behaviour (two of your patterns are both being applied, in a way that creates a nonsense result. It's like how in Python, "http://urls.com".replace("http://", "https://").replace("s","soup") gives a quite different result from "http://urls.com".replace("s","soup").replace("http://", "https://") .

I haven't solved the problem completely to my satisfaction, but there are some rules in this file which allow reasonably sensible drawing of some shapes using tiles #53 (for columns) and #54 (for everything else --autograssing and autocornering right now), starting from say, a single 'top' grass tile.

Some rules need more careful checks using inputnot (largely unused in this ruleset). Some rules use the second input layer (in cases where there are rules where more than one possible tile should match in a particular location, but the output tile for the pattern should be the same), most do not. I'm not sure what else to say, the difficulty in getting things to work right with rules is like I said, mainly algebraic/programming -- thinking of how your rules will interact and ensuring it is sensible.

I've noted that there is some inconsistency in how Tiled applies patterns; With my case it doesn't appear to be directional, rather, the result when dragging seems to not apply rules, and when clicking rules are applied. Maybe this is intentional, in any case it is something to keep in mind.

I hope that helps. I find it difficult to discuss this subject usefully in a non-realtime communication medium.
« Last Edit: September 14, 2014, 03:38:40 am by Ai »
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.