Skip to content
stefanbeller edited this page Aug 27, 2011 · 8 revisions

Table of Contents

What is AutoMapping?

It is automatic mapping. Automatic explains this way: It delivers you a rule based support to automatically setup some layers, most often some standard ground layers. So the goal of AutoMapping is, that you only need to draw within one layer and everything else is setup for you. This brings some advantages:

  • working speed - you need less time to setup a map.
  • less errors - the main reason is to reduce the error rate. If you have setup the rules properly, there is no hidden error.

examples

Automapping explained(Youtube)

The Mana World rulesets

How does it roughly work?

The AutoMapping feature will check some special layer you draw in. And whenever there is a change, it will be checked if any rule matches and if so this rule gets applied at the correct position.

Parts of a rulefile

A rulefile is a standard map file, which can be read and written by tiled. In one rulefile there can be defined multiple rules.

Some map properties can be set to make AutoMapping more powerful:

  • DeleteTiles - This map property is a boolean property: it can be true or false. If rules of this rulefile get applied at some location in your map, this map property determines if all other tiles are deleted before applying the rules.
Consider a map where you have multiple layers. Not all layers are filled at all places. In that case all tiles of all layers should be cleared, so afterwards there are only the tiles which are defined by the rules. Since when not all tiles are cleared before, you will have still tiles from before at these places, which are not covered by any tile.
  • AutomappingRadius - This map property is a number: 1, 2, 3 ... It determines how many tiles around your changes will be checked as well for redoing the AutoMapping at live Automapping.
  • NoOverlayingRules - A rule is not allowed to overlap on itself.
  '''''introduced at 0.8.0'''''

Parts of a rule

rule regions

A rule consists of three different things, strictly divided as in the Input-Process-Output model. The input section in this context is called rule_region. It defines a region in which the rule is processed. This region can be of any form such as a rectangle, circle and so on. To define a rule_region for a rule, you need to have a tile layer called 'RuleRegions'. Each region is described by coherent equal tiles. (It does not matter which kind of tiles are used here, just make sure they are all equal. So even transparent tiles would work, but it actually sucks, because you will mess it up!)

rule condition

The processing of a rule is quite simple: For all positions in your working map it is checked if there is shape of rule_region, at which the rule applies. To see if the rule applies the set layer of the working map is compared to the ruleSet and ruleNotSet layers of your rule map. If there is a match then the rule_output is copied over from your rulefile to the working map. To decide if it is a match or not, it is necessary to describe what is desired in an exact way. It is done in the rule_condition section. The rule_condition section consists of the layers 'RuleSet' and 'RuleNotSet'. There can be multiple layers of each.

rule output

All Layers Rule_* of the rulefile will be copied over to the working map if the rule matches.

glossary

This naming convention is used:

  • a working map is a map which you are working on, i.e. that will be the map of your game afterwards.
  • a rulefile is a file where some rules are stored.
  • a rule is the combination of a rule_region, a rule_condition and a rule_output
  • a rule_region is a region defined by coherent equal tiles in a rulefile in a layer, which is called 'RuleRegions'. It describes the region, where the rule_condition and rule_output are taken from.
  • a rule_condition is found in a rulefile in the layers, which are called 'RuleSet' or 'RuleNotSet'.
  • a rule_output is found in a rulefile in layers, which have the prefix 'rule'.
Clone this wiki locally