Bitmask Autotile Generator for Godot & Unity

How to generate a 47-tile autotile template

Five steps from one source tile to a sheet plus the mapping your engine needs.

1. 1

   Start with one centre tile

   The generator needs a single filled tile — the texture that represents "this cell is solid ground". Edge and corner sources are optional refinements; without them the tool derives edges and corners from the centre tile so you can see the whole set working before you commit to drawing 47 pieces by hand.

2. 2

   Set the tile size before you generate

   Tile size drives the atlas dimensions, so a 32px tile produces a 256×192 sheet across the 8×6 grid. Match it to whatever your project already uses. Changing it later means regenerating, since every exported mapping references pixel offsets on that specific sheet.

3. 3

   Paint on the live canvas to test the ruleset

   Left click paints, right click erases. This is the part worth spending time on: draw an L-shape, a diagonal, a one-tile island, a hole in the middle of a filled area. Those are the cases where a hand-built tileset falls apart, and seeing the correct tile appear at each is how you know the bitmask is being read the way your engine will read it.

4. 4

   Inspect any tile to see the rule behind it

   Clicking a tile on the generated sheet reports its bitmask value, which neighbours are set, and how the tile is classified — isolated, edge, outer corner, inner corner, junction or filled. That mapping from a number to a picture is the thing that makes autotiling stop feeling like magic, and it is what you need when a tile is appearing in the wrong place and you are trying to work out why.

5. 5

   Export the sheet and the mapping for your engine

   PNG gives you the atlas. The metadata export gives your engine the mask-to-index table so it knows which tile answers which neighbour configuration — as a Godot or Unity mapping, a Tiled .tsx tileset, or an LDtk JSON definition. The PNG on its own is only half of a working autotile set.

How bitmask autotiling actually works

Why the set is 47 tiles on an 8×6 atlas, what the bit values mean, and when a different system is the better answer.

Where the number 47 comes from256 → 47

Each tile looks at eight neighbours, which is 2⁸ = 256 possible configurations. Most are duplicates: a corner neighbour only changes what the tile should look like when both edges beside it are also filled. A north-east neighbour with no north and no east neighbour is visually irrelevant — there is nothing for it to connect to. Normalising every mask by that rule collapses 256 down to exactly 47 distinct cases, which is why the blob set is the size it is. It is not an arbitrary art convention.

The bit values, and why the order mattersN=1 NE=2 E=4 SE=8 S=16 SW=32 W=64 NW=128

Neighbours are numbered clockwise from north, each one a power of two, so any configuration is a single byte. A tile with neighbours to the north, east and north-east has mask 1 + 4 + 2 = 7. Engines differ on which direction is bit zero and which way they rotate, so if your tiles come out mirrored or rotated, it is almost always a bit-order mismatch rather than a broken sheet — check the exported mapping against what your engine expects before redrawing anything.

What the 47 tiles are actually made of

One isolated tile with no neighbours, one fully surrounded fill tile, six edges, four outer corners, five junctions, and thirty inner-corner variants. That distribution surprises people: the bulk of the work is inner corners, the cases where a filled region turns back on itself. If you are drawing a set by hand and it looks wrong in complex terrain, inner corners are almost certainly what is missing.

Is there something better than the 47-tile system?

It depends what you are matching on. A 4-bit set that ignores corners needs only 16 tiles and is much faster to draw, and it is enough for blocky terrain where diagonal joins do not matter. Full 8-bit matching without the corner rule would need 256 tiles, most of them visually identical, which is why nobody does it. Wang and corner-matching tilesets solve the problem differently by matching edges between tiles rather than neighbour occupancy, which handles multi-terrain blending better but needs different authoring. The 47-tile blob is the standard because it is the smallest set that renders every distinct single-terrain case correctly — if you need less fidelity, use 16; if you need multiple terrains blending into each other, look at Wang tiles.

Godot 4 changed the terminology

Godot 3 called this an autotile with a bitmask you painted in the editor. Godot 4 replaced that with Terrain Sets and terrain peering bits, which is the same idea with different names and a different UI. The generated sheet works for both; what changes is where you tell the engine about neighbour rules. Searching for Godot autotile documentation will often land you on Godot 3 pages that no longer match the editor in front of you.

Computed from the tile catalog this generator uses. Inner corners dominate because they are the cases where a filled region turns back on itself — the part hand-drawn sets most often get wrong.

Where this fits in the pipeline

• Godot Autotile & Bitmask Guide

  The full walkthrough: terrain sets, peering bits, Unity and RPG Maker notes, and the art production order.

• Procedural Level Generation Guide

  BSP, cellular automata and noise, and how generated layouts feed a terrain set.

• 2D Procedural Level Generator

  Generate the map your autotile set renders, with a validated route from spawn to exit.

• 2D Game Dev Lab

  Every tool in the pipeline in running order — layout, tiles, collision, sprites, audio, economy.