TilePipe2

is the second iteration of the TilePipe project. The original TilePipe can be downloaded from here https://aleksandrbazhin.itch.io/tilepipe.

About

Most game engines supporting 2D tilemaps also support autotiling - substituting a tile variant depending on it's neighbors. That way a level designer is able to paint a terrain with a tile like with a brush while the proper tile variants are chosen automatically. To create such an autotile an artist has to copy and paste one tile multiple times to create all possible tile variations.

Generally you need a texture like this to do it:

Tipepipe is meant to help an artist creating a 2D autotiling tileset by automating the copying routine. Instead of 47 or 255 tiles one has to draw only a couple of parts (like center, sides and corners) and have everything else generated. 

Tilepipe can

- copy the parts to create all needed tile variants

- generate neighbor bitmasks that define each tile variant usage

- generate collisions considering non-transparent parts solid

The latter 2 are  important  if you export to a game engine,  since it's also a lot of work.

How it works

TilePipe2 takes an input texture, breaks it into parts

Applies some rules to combine them, each looks like this:

And places the result in a grid as defined by the template

To get the result ready for autotiling

All three input parts are modifiable by user. But rulesets and templates are mostly covered by the examples, you need only to draw some parts.

How the parts are combined can be set up through the UI.

• How much pixels should sides overlap the center (merge and overlap sliders)
• Randomization fine tuning
• Resizing
• Filtering (smoothing)

Tilepipe is an opensource project using the Godot engine, code: https://github.com/aleksandrbazhin/TilePipe.

If you want to report a bug or propose a feature - open an issue. Previous versions can be found in https://github.com/aleksandrbazhin/TilePipe/releases

Tutorial materials

Awesome video from one of the TilePipe2 early users. 

Links

Github - https://github.com/aleksandrbazhin/TilePipe.

Discord - https://discord.gg/B4VBVYG

 Reddit community - https://www.reddit.com/r/TilePipe/

Documentation

Motivation behind the project

There are several projects that address this issue, namely LDtk (opensource) and TileSetter (proprietary). Both include a tilemap editor.

With this project I was trying to implement the most straightforward approach to generating autotiles, leaving the tilemap editing to be done in the game engine of the user's choice. At the time of writing the project supports only plain texture or Godot3.x tileset format export. But other exporters are planned, namely for the Tiled level editor.

An important part of the project is being open, so the creators can rely on it in the long run safely and invest their time into learning it and setting up their own templates and rulesets.

Terms

- Tile. A specific type of terrain. It is something you can draw your map with. It can have multiple variants which are selected depending on tile's neighbors.

- Subtile. Is one tile variant, which is used in a specific neighbor configuration. Variants differ since the tile on the edge of a terrain zone looks different from the inner tiles.

- Tileset. A collection of tiles used in the game engine or level editor. Some tiles can be "autotiles", some can be plain ones.

- Input texture. A drawing consisting of all the parts that are used in the tile. What parts you need to draw depends on what ruleset you use. As of release of TilePipe2.0 version all the parts need to be placed in a row. You can have some of them randomly subsitiuted to have some variety, for this you need to place parts below each other in a column.

- Tile part.  A part which is to be combined to create each subtile. First part in input texture is always the tile center. How many parts you need for the sides and corners depends on what ruleset you use. Each subtile always consists of 9 parts: center and 8 side and corner parts which are placed on top of it.

- Neighbor bitmask. In the template tab you can see the numbers over each subtile. These are bitmasks of the 8 neighboring tile of the same type. They are counted from the top clockwise, if there is a neighbor we have a 1 in binary representation of that number, otherwise we have zero. So they differ from zero (0000 0000) for a subtile with no neighbors to 255 (1111 1111) for a tile fully surrounded by the same terrain.

- Ruleset. Rulesets are sets of rules dictating which parts should be used in which order to create a specific subtile. They are a JSON files, which are then visualized in a separate tab in TilePipe. You can change them in any text editor ot create any kind of rules. Some of the rulesets in the examples are the most useful, so just copy them to the rulesets/ subfolder of your project. There is a JSON schema, specifying the format and autochecker script, you can find both in the github repository in utils/.

- Rule. Each rule defines what input parts are used at which position of a generated subtile, should it be rotated or flipped on x or y axis.

- Template. Templates are png images, but only those placed in the templates/ subfolder of your project will be discovered. They consist of 32x32px squares, each of which is divided into 9 smaller squares. Each of those nine represent a tile's neighbor, which will affect the selection of the subtile. The smaller squares can be either white or transparent (no neighbor of the same tile) or of any other color (there is a neighbor). The central square represents the tile itself and if it's white, no subtile will be rendered at all. These template images are then recognized by TilePipe and the result is composed by this templates. The format could as well be text or JSON based, but images are easier to manipulate for an artist.

Using the terms:

TilePipe2 just generates all the subtiles needed for creating an autotile from the tile parts provided in the input texture. The resulting subtiles are placed as defined in the template. For every bitmask defined in the template, this program first looks for a rule in the ruleset, then combines the input tile parts to generate a subtile for this specific bitmask.

First of all you need to draw the parts that are repeated in tiles. This is a drawing specific to the ruleset you use. For example, if you have a sideview game, your tiles may be symmetrical left to right but not symmetrical top to down. So you'll need different parts for top and down of tiles, but can use only one side. And sides must be flipped, but not rotated for such game. That's the ruleset named in the examples "8_part_side_symmetry", and there is also an input texture for it with an example tile setup.

You can also setup a template, which determines places for the tiles in the resulting tileset, but in most cases you are good with the default. If you still want to do it, just rearrange tiles in the example texture using any image editor.

User project logic (add/use)

First, any asset has to be added or copied into the project folder. You can do it yourself or with the help of the provided GUI. But the easiest way is to just start off with one of the examples. Copy the example folder and go from there (you can delete all the tiles, but keep the rulesets and templates).

TODO: GUI tour

GUI screenshot

Motivation behind the TilePipe2 rewrite over TilPipe

1. The project GUI logic became too complicated with no room to add new features.

2. Ability to save and use custom rulesets (previously named presets). These are now json files, schema is included in the project. There is a viewer in the GUI.

3. Project-like logic for every directory. Several tile sources now from a project, which can be exported at once.

4. Every data is now explicit, there is minimal built-in logic (not examples, not templates, not rulesets). It's a VCS-ready approach, all the changes are now trackable. Everything previously built-in os now distributed as the examples.

New in aplha 4