Implement Tilemap AutoTiles

[ilexp]

As previously described in issue #249, the tilemaps plugin needs some kind of AutoTile feature. This feature will affect Tileset and editor implementations, but is mostly transparent towards Tilemaps themselves.

• There could actually be two distinct types of AutoTiles: "Invasive" AutoTiles (that actually generate new tiles internally) and "Non-Invasive" AutoTiles (that just automatically choose from a set of existing tiles depending on their surroundings).
• For editor convenience, it could be possible to specify additional tiles an AutoTile connects to.
• Also have a way to not use AutoTiling in specific cases, or use specific AutoTile-versions on mapper's choice, see here.

[ilexp]

AutoTile Template: All 47 permutations of an expanded AutoTile:

• Always look at the center tile of each 3x3 quad.
• Grass tiles represent "Tiles not equal to center".
• Flower tiles represent "Don't care"

[ilexp]

There is also this AutoTile format.

It would make sense to support any of them via customization on a case by case basis. Just let the user specify per-autotile, which existing tiles have which role and let the system generate the rest based on the available sub-tiles using a predefined priority / order.

[ilexp]

Progress

• Created the tilemaps-autotile branch for this feature.

Immediate ToDo

Core

• Introduce a BaseTile field to TileInfo, which is a link-back index to the single root tile that represents the AutoTile group.
• Introduce a AutoTileInput class that defines a single AutoTile in the source dataset.
  • This is what the editor / user will define.
• Introduce a AutoTileInfo class that represents a single (generated or as-is) AutoTile in the target dataset.
  • This is what will be generated during Tileset compilation.
  • For each surroundings / AutoTile index, there is a mapping to a valid tile index. No exceptions. If there is none for a given setup, use a suitable fallback instead.
• Define a way to specify a tile's surroundings with regard to selecting the correct AutoTile index.
  • Could be a flags enum of type byte.
• Provide functionality to apply AutoTiling rules to a set of tiles. This could be part of a Tileset implementation.
• Introduce logic to auto-generate additional tiles based on the existing AutoTiles.
  • Auto-generated tiles should not show up anywhere the user directly interacts with or reviews a Tileset.

Editor

• Apply AutoTiling rules to all tilemap tool implementations. Ask the environment whether AutoTiling is active / should be applied or not.
• Add a toggle button to specify whether AutoTiling should be active.
  • With brush sizes and similar features in mind, think of a way to keep this generic enough to add other properties later.
  • When selecting a tool, select it config in the Object Inspector?
• Introduce a new Tileset Editor Mode for specifying AutoTiling information.
  • Each layer represents a single AutoTile. Add / Remove layers possible.
  • The first selected tile will always be the root / base tile. Deselecting it will reset all information on that layer.
  • All further selection happens on a vertex-basis in order to specify each tile's surroundings.
  • Also have a way to specify any tile as a connecting tile to this AutoTile.

Sample

• Supply the sample tileset with all the required AutoTiling information.

[ilexp]

Progress

• Added BaseTile field to TileInfo struct.
• Added TilesetAutoTileInput class.
• Added TilesetAutoTileInfo class.
• Added TileConnection byte flags enum, easily cast-able into an array index for tile index lookups.

Immediate ToDo

Core

• Provide functionality to apply AutoTiling rules to a set of tiles. This could be part of a Tileset implementation.
• Tileset.TileCount needs to be revisited to account for constructed tiles. There needs to be one count with only the source tiles considered, and another with really all of them considered.
• Introduce logic to auto-generate additional tiles based on the existing AutoTiles.
  • For each surroundings / AutoTile index, there is a mapping to a valid tile index. No exceptions. If there is none for a given setup, use a suitable fallback instead.
  • When constructing missing tiles from existing ones, derive tile info from source tiles: Height, vertical / flat should be the same, collision needs to be pieced together.
  • Auto-generated tiles should not show up anywhere the user directly interacts with or reviews a Tileset.

Editor

• Apply AutoTiling rules to all tilemap tool implementations. Ask the environment whether AutoTiling is active / should be applied or not.
• Add a toggle button to specify whether AutoTiling should be active.
  • With brush sizes and similar features in mind, think of a way to keep this generic enough to add other properties later.
  • When selecting a tool, select it config in the Object Inspector?
• Introduce a new Tileset Editor Mode for specifying AutoTiling information.
  • Each layer represents a single AutoTile. Add / Remove layers possible.
  • The first selected tile will always be the root / base tile. Deselecting it will reset all information on that layer.
  • All further selection happens on a vertex-basis in order to specify each tile's surroundings.
  • Also have a way to specify any tile as a connecting tile to this AutoTile.

Sample

• Supply the sample tileset with all the required AutoTiling information.

[ilexp]

Progress

• Refactored Tileset compilation in preparation of additional AutoTile logic. Moved most of the functionality to the new TilesetCompiler class, explicitly specified input and output data, and split up the single compile method into multiple smaller ones.

Immediate ToDo

Core

• Generate passive auto-tiling info during Tileset compilation.
  • Set each tile's BaseTile field.
  • Properly configure TilesetAutoTileInfo tiles, so all of them are defined.
• Provide functionality to apply AutoTiling rules to a set of tiles.
• Generate active / constructive auto-tiling info during Tileset compilation, i.e. introduce logic to auto-generate additional tiles based on the existing AutoTiles.
  • Tileset.TileCount needs to be revisited to account for constructed tiles. There needs to be one count with only the source tiles considered, and another with really all of them considered.
  • For each surroundings / AutoTile index, there is a mapping to a valid tile index. No exceptions. If there is none for a given setup, use a suitable fallback instead.
  • When constructing missing tiles from existing ones, derive tile info from source tiles: Height, vertical / flat should be the same, collision needs to be pieced together.
  • Auto-generated tiles should not show up anywhere the user directly interacts with or reviews a Tileset.

Editor

• Apply AutoTiling rules to all tilemap tool implementations. Ask the environment whether AutoTiling is active / should be applied or not.
• Add a toggle button to specify whether AutoTiling should be active.
  • With brush sizes and similar features in mind, think of a way to keep this generic enough to add other properties later.
  • When selecting a tool, select it config in the Object Inspector?
• Introduce a new Tileset Editor Mode for specifying AutoTiling information.
  • Each layer represents a single AutoTile. Add / Remove layers possible.
  • The first selected tile will always be the root / base tile. Deselecting it will reset all information on that layer.
  • All further selection happens on a vertex-basis in order to specify each tile's surroundings.
  • Also have a way to specify any tile as a connecting tile to this AutoTile.

Sample

• Supply the sample tileset with all the required AutoTiling information.

[ilexp]

Progress

• Now generating passive auto-tiling info during Tileset compilation.
• AutoTile input is now considered in Tileset config hash.

Immediate ToDo

• Introduce a new Tileset Editor Mode for specifying AutoTiling information.
  • Each layer represents a single AutoTile. Add / Remove layers possible.
  • The first selected tile will always be the root / base tile. Deselecting it will reset all information on that layer.
  • All further selection happens on a vertex-basis in order to specify each tile's surroundings.
  • Also have a way to specify any tile as a connecting tile to this AutoTile.
• Supply the sample tileset with all the required AutoTiling information.
• Apply AutoTiling rules to all tilemap tool implementations. Ask the environment whether AutoTiling is active / should be applied or not.
  • Have a central implementation of applying these rules, ideally in the core.
• Add a toggle button to specify whether AutoTiling should be active.
  • With brush sizes and similar features in mind, think of a way to keep this generic enough to add other properties later.
  • When selecting a tool, select it config in the Object Inspector?
• Generate active / constructive auto-tiling info during Tileset compilation, i.e. introduce logic to auto-generate additional tiles based on the existing AutoTiles.
  • Tileset.TileCount needs to be revisited to account for constructed tiles. There needs to be one count with only the source tiles considered, and another with really all of them considered.
  • For each surroundings / AutoTile index, there is a mapping to a valid tile index. No exceptions. If there is none for a given setup, use a suitable fallback instead.
  • When constructing missing tiles from existing ones, derive tile info from source tiles: Height, vertical / flat should be the same, collision needs to be pieced together.
  • Auto-generated tiles should not show up anywhere the user directly interacts with or reviews a Tileset.

[ilexp]

Progress

• Added a draft / scaffold for the new AutoTile TilesetEditorMode.
• Added icons for the above mentioned editor mode.

Immediate ToDo

• Refactor the existing Add/RemoveTilesetVisualLayerAction into something more generic that simply adds/removes an item of type T to/from an IList<T> as used by one of the various Tileset layer-like properties. There will likely be more in the future, and having two UndoRedoActions for each of them despite essentially doing the same is a bit overkill.
  • Requires Tileset instance, PropertyInfo and item.
• Implement the new Tileset Editor Mode for specifying AutoTiling information.
  • Each layer represents a single AutoTile. Add / Remove layers possible.
  • The first selected tile will always be the root / base tile. Deselecting it will reset all information on that layer.
  • All further selection happens on a vertex-basis in order to specify each tile's surroundings.
  • Also have a way to specify any tile as a connecting tile to this AutoTile.
• Supply the sample tileset with all the required AutoTiling information.
• Apply AutoTiling rules to all tilemap tool implementations. Ask the environment whether AutoTiling is active / should be applied or not.
  • Have a central implementation of applying these rules, ideally in the core.
• Add a toggle button to specify whether AutoTiling should be active.
  • With brush sizes and similar features in mind, think of a way to keep this generic enough to add other properties later.
  • When selecting a tool, select it config in the Object Inspector?
• Generate active / constructive auto-tiling info during Tileset compilation, i.e. introduce logic to auto-generate additional tiles based on the existing AutoTiles.
  • Tileset.TileCount needs to be revisited to account for constructed tiles. There needs to be one count with only the source tiles considered, and another with really all of them considered.
  • For each surroundings / AutoTile index, there is a mapping to a valid tile index. No exceptions. If there is none for a given setup, use a suitable fallback instead.
  • When constructing missing tiles from existing ones, derive tile info from source tiles: Height, vertical / flat should be the same, collision needs to be pieced together.
  • Auto-generated tiles should not show up anywhere the user directly interacts with or reviews a Tileset.

[ilexp]

Some mockup screens for the new AutoTile mode of the TilesetEditor:

Basic idea behind this: After selecting the base tile, the user "carves free" all the connected parts of border tiles, so the AutoTile base part will be highlighted in the end.

• "Carved free" parts are displayed normal, all others are overdrawn with a 50% black or 50% background color.
• The surrounding tile border display width should be 1/4 the displayed tile size.
• Additional connecting tiles are not highlighted, but outlined in some signal color, light blue in the above mockups.
• Make sure to reflect the AutoTile internals: AutoTiles always define their own border tiles, not surrounding unrelated tiles. When carving free parts of a tile, the center will always be part of the AutoTile. There is no such thing as "edge only" carving.
• Make sure to respect "don't care" cases accordingly and do not allow to specify redundant information for th0se cases.
• For a specific border configuration, there can only be one tile. Only enforce this after completing a drawing operation, so the user can safely complete the intended operation.

[ilexp]

Progress

• Refactor the existing Add/RemoveTilesetVisualLayerAction into the more generic Add/RemoveTilesetConfigLayerAction and used it for the AutoTile editor mode.
• Implemented adding / removing AutoTiles, as well as editing their names and IDs.
• Implemented basic AutoTile editing.
• Implemented basic AutoTile data transformation in the TilesetCompiler.

Immediate ToDo

• Improve the first AutoTile editor mode implementation.
  • Slightly highlight the hovered tile, in addition to the specific region.
  • Draw connection region outlines.
  • They can improve overall visibility, especially in cases where the tileset is very dark.
  • They can also improve the distinction between mid-tile borders and between-tile borders.
  • Draw an outline only on TileConnection outlines within a tile, not outside. The above mockup is wrong in that regard.
  • Introduce a way to specify additional connecting tiles and document it in a way that the user will be able to see it without reading a tutorial.
• Apply AutoTiling rules to all tilemap tool implementations. Ask the environment whether AutoTiling is active / should be applied or not.
  • Have a central implementation of applying these rules, ideally in the core.
• Add a toggle button to specify whether AutoTiling should be active.
  • With brush sizes and similar features in mind, think of a way to keep this generic enough to add other properties later.
  • When selecting a tool, select it config in the Object Inspector?
• Derive the "nearest matching" tile during Tileset compilation, if there is no direct match available.
  • Resolve all "Don't care" situation as described in the diagrams in one of the first postings.
• Generate active / constructive auto-tiling info during Tileset compilation, i.e. introduce logic to auto-generate additional tiles based on the existing AutoTiles.
  • Tileset.TileCount needs to be revisited to account for constructed tiles. There needs to be one count with only the source tiles considered, and another with really all of them considered.
  • For each surroundings / AutoTile index, there is a mapping to a valid tile index. No exceptions. If there is none for a given setup, use a suitable fallback instead.
  • When constructing missing tiles from existing ones, derive tile info from source tiles: Height, vertical / flat should be the same, collision needs to be pieced together.
  • Auto-generated tiles should not show up anywhere the user directly interacts with or reviews a Tileset.
• Supply the sample tileset with all the required AutoTiling information.

[ilexp]

Progress

• AutoTile editor improvements.
  • Per-Tile hover highlights.
  • Connected region outlines are now displayed clearly.
• Introduced shift-click as a way to specify additional connecting tiles and documented it using the editor help system.

Immediate ToDo

• Derive the "nearest matching" tile during Tileset compilation, if there is no direct match available.
  • Resolve all "Don't care" situation as described in the diagrams in one of the first postings.
• Apply AutoTiling rules to all tilemap tool implementations. Ask the environment whether AutoTiling is active / should be applied or not.
  • Have a central implementation of applying these rules, ideally in the core.
• Add a toggle button to specify whether AutoTiling should be active.
  • With brush sizes and similar features in mind, think of a way to keep this generic enough to add other properties later.
  • When selecting a tool, select it config in the Object Inspector?
  • Shared AutoTiling switch state could be implemented as an environment property, which the tool's base class redirects its get and set to.
• Supply the sample tileset with all the required AutoTiling information.
• Create a new issue for the below generative auto-tiling part.
• Remove (non-implemented) "Generate Missing Tiles" option from the current version.
• Merge back to master and release.

---

Split this up into a separate issue

• Generate active / constructive auto-tiling info during Tileset compilation, i.e. introduce logic to auto-generate additional tiles based on the existing AutoTiles.
  • Tileset.TileCount needs to be revisited to account for constructed tiles. There needs to be one count with only the source tiles considered, and another with really all of them considered.
  • For each surroundings / AutoTile index, there is a mapping to a valid tile index. No exceptions. If there is none for a given setup, use a suitable fallback instead.
  • When constructing missing tiles from existing ones, derive tile info from source tiles: Height, vertical / flat should be the same, collision needs to be pieced together.
  • Auto-generated tiles should not show up anywhere the user directly interacts with or reviews a Tileset.
• Consider ways of making tile indices for generated tiles stable across different compilations.
  • Probably can't be done 100% perfect with tileset-only measures
  • The only thing that's guaranteed to be persistent / stable is the source tiles, because they're visible to the users and it's intuitively understandable that moving them around will screw up the map. So users will avoid doing that. They may extend the tileset towards the bottom though, since that's keeping the existing indices stable.
  • If the stored Tile(map tile) info was BaseTile + TileConnection, AutoTiles would be guaranteed stable, since the BaseTile is always one of the source tiles, and TileConnection would be relative to that.
  • Adjust tilemap data serialization to actually store data this way, while resolving it on load?
  • Won't work, because there is no guaranteed tileset at load to resolve this.
  • Wouldn't help for runtime cases at all.
  • Change Tile struct to actually include only BaseTile + TileConnection, not the post-compile tile index.
  • Bad for pretty much any component that requires the tile index, data duplication, out of sync problems, etc.
  • TilemapCollider, TilemapRenderer, ...
  • Extend Tile struct to include BaseTile + TileConnection as redundant info?
  • Serialization wouldn't actually save the final tile index at all.
  • Tilemap could update final tile index when loaded and on changes of both tilemap and tileset. Hint: The tileset's compile hash can be compared to determine if it changed since last time.

[ilexp]

AutoTile test tileset for the non-generating setup:

All 47 permutations of the test AutoTile are in there. The compiler should properly map them, and the AutoTiling algorithm should be able to use them accordingly.

[ilexp]

Progress

• Moved "Generate Missing AutoTiles" into separate issue #370
• Revisited TileInfo and Tile structs to provide more practical data, rather than conceptual data.
• Addressed the generated tile persistence issue by serializing base tile and connectivity state, and extending the Tilemap implementation to resolve the final tile index on load and on change. Until resolved, a Tile that was generated using the index-based constructor will share the same base and final tile index as a fallback.
• Removed GenerateMissingTiles option.

Immediate ToDo

• Derive the "nearest matching" tile during Tileset compilation, if there is no direct match available.
  • Resolve all "Don't care" situation as described in the diagrams in one of the first postings.
• Apply AutoTiling rules to all tilemap tool implementations. Ask the environment whether AutoTiling is active / should be applied or not.
  • Have a central implementation of applying these rules, ideally in the core.
• Add a toggle button to specify whether AutoTiling should be active.
  • With brush sizes and similar features in mind, think of a way to keep this generic enough to add other properties later.
  • When selecting a tool, select it config in the Object Inspector?
  • Shared AutoTiling switch state could be implemented as an environment property, which the tool's base class redirects its get and set to.
• Address the issue of deferred index resolve when painting AutoTiles.
  • Perform the tile index resolve step manually in the editor code, instead of relying on Tilemap to do this when the change event is fired?
  • Modify Tilemap to perform the resolve step in each EndUpdateTiles and SetTile call, rather than the event?
  • Introduce a second Tilemap change event that triggers immediately without waiting for the last EndUpdate call, and then use that one instead for this case?
• Supply the sample tileset with all the required AutoTiling information.
• Merge back to master and release.

[ilexp]

Progress

• Added both DontCare and non-available fallbacks for AutoTile connectivity states during Tileset compilation.
• Applying AutoTiling rules in all editing operations.
• Undo / Redo support for AutoTile painting.

Immediate ToDo

• Add a toggle button to specify whether AutoTiling should be active.
  • With brush sizes and similar features in mind, think of a way to keep this generic enough to add other properties later.
  • When selecting a tool, select it config in the Object Inspector?
  • Shared AutoTiling switch state could be implemented as an environment property, which the tool's base class redirects its get and set to.
• Have different AutoTile painting modes.
  • No AutoTiling.
  • Direct-only AutoTiling (Don't update neighbours)
  • Full AutoTiling.
  • More?
• Supply the sample tileset with all the required AutoTiling information.
• Merge back to master and release.

[ilexp]

Progress

• Various bugfixes, tweaks and API improvements on AutoTile related Tileset things.
• Introduced different AutoTile painting modes and made the EditTilemapAction use them.
• Now allowing to proper multi-assignments for certain connectivity states. They will no longer be resolved with the default / main tile index when its tile's connectivity state would match the already supplied BaseIndex tile's connectivity state.

Immediate ToDo

• Properly deal with cases where users specify only an index, not a base index + connectivity state.
  • Provide better tile init API, so the typical cases can be easily dealt with.
  • Create tile from base index + state.
  • Create tile from resolved index and derive the rest.
  • Constructor vs Tile.CreateXY calls.
• Add a toggle button to specify whether AutoTiling should be active.
  • With brush sizes and similar features in mind, think of a way to keep this generic enough to add other properties later.
  • When selecting a tool, select it config in the Object Inspector?
  • Shared AutoTiling switch state could be implemented as an environment property, which the tool's base class redirects its get and set to.
• Supply the sample tileset with all the required AutoTiling information.
• Merge back to master and release.

[ilexp]

Done. Release in progress.