Tilemap Design: Build 2D Worlds Efficiently

An efficient tilemap is the result of four decisions made in the right order: tile size, tileset structure, autotiling setup, and layer separation. Made out of order, each one becomes rework — art that does not line up, transitions drawn one at a time, collision that drifts away from the ground it was meant to match. Made in order, painting a world turns into assembly: you draw a small tileset once, then lay out whole biomes in minutes while the editor resolves the corners.

This guide covers the four decisions with concrete defaults, then the workflow that keeps them consistent across a full game. It is about the craft of designing tilemaps; if you are choosing which editor to paint them in, the companion tilemap editor comparison covers Tiled, LDtk, Godot and the rest tool by tool.

The short answer#

Decision	Safe default	What it prevents
Tile size	16×16 or 32×32 px, one size per game	Redrawing the whole tileset mid-project
Tileset structure	Fill tile → edges → corners → props	Tiles that never compose into scenery
Autotiling	16-tile set to start, 47-tile blob when corners show	Hand-painting every transition
Layers	Terrain, collision, decoration, gameplay, each separate	Art and logic drifting apart

None of these are stylistic preferences. Each one either removes a class of future work or guarantees it.

What a tilemap actually is#

Strip the tooling away and a tilemap is three things: a grid, a tileset, and a map that says which tile sits in which cell. The point of the arrangement is compression. Instead of storing a 1920×1080 image per screen, you store a 32-tile palette once and a small number per cell, and any screen the level needs is a rearrangement of the same parts.

The trick is older than the tools. The NES addressed the screen in 8×8 hardware tiles, yet Super Mario Bros. stores its levels as 16×16 metatiles, each assembled from four 8×8 tiles — partly because the hardware assigns color palettes to 16×16 regions, partly because a level built from bigger units is smaller data and faster to author. That trade, authoring unit versus rendering unit, is still the one you are making when you pick a tile size today. Terraria and Stardew Valley both run on 16×16 tiles four decades later, for the same reasons: readable grids, compact art, levels that read at a glance.

Decision 1: tile size#

The tile size is the first permanent decision in a project, because everything downstream — sprites, doors, platforms, jump distances — is measured against it.

Size	Used by	Fits	Cost
16×16	Terraria, Stardew Valley	Retro looks, dense detail per screen	Every pixel counts; slow to draw well
32×32	Most modern 2D indies	Hand-drawn styles, readable mobile art	4× the art per tile; rooms feel closer
48×48	RPG Maker MV and MZ	Story games with big expressive props	Engines and asset packs must match

Three rules keep the decision safe:

• One size per game. A 16×16 tileset next to a 24×24 prop breaks the grid, and fixing it after the fact means redrawing art.
• Scale in whole multiples. A 16×16 game scaled 3× stays pixel-perfect at 48 px per tile; scaled 2.5× it blurs or bleeds. Choose sizes that divide your target resolution cleanly.
• Size characters against the grid. A character roughly one tile wide and two tall (Stardew's farmer is 16×32) reads correctly in doorways and corridors. If the character fits inside one tile, rooms designed around it feel cavernous.

Decision 2: structure the tileset#

A tileset that composes well has an order to it, and the order matters more than the art style:

1. Fill tiles. The plain ground the map is mostly made of. Draw these first; they set the palette and the level of detail everything else must match.
2. Edges and transitions. Coastlines, cliff tops, grass-to-dirt boundaries. These are the tiles the map uses most after the fill, and they are what autotiling will manage.
3. Corners and junctions. Inner corners are where amateur maps fall apart — the missing concave piece where a river bends around a hill.
4. Props and decals. Rocks, flowers, cracks. Scattered on top of finished terrain, they carry most of the map's character for the least structure.

Keep the tileset small enough to hold in your head. A 32-tile set that composes cleanly beats a 300-tile set nobody can navigate, and a new contributor can learn the first in an afternoon.

Decision 3: autotiling#

Autotiling is the single highest-leverage mechanic in tilemap design: the editor looks at a tile's neighbors and picks the transition tile for you, so you paint terrain and the coastline resolves itself. The standard schemes:

Scheme	Tiles	How it matches	When you need it
4-bit bitmask	16	Four direct neighbors (N, E, S, W)	Most terrain; the right starting point
8-bit blob	47	All eight neighbors, diagonals included	Terrain with inner corners: coasts, caves
Wang tiles	Varies	Colored edges instead of corners	Procedural generation, unusual shapes

The numbers are not as bad as they look. The 8-neighbor scheme has 256 possible neighborhoods, but most are rotations or mirrors of each other, and 47 unique tiles cover all of them. Every serious editor implements one of these: Godot calls them terrains (on the TileMapLayer node since 4.3 replaced the old TileMap), Tiled ships Terrains plus the more powerful Automapping rules, and LDtk treats auto-rendering as the default way levels are drawn.

The practical advice is to start with the 16-tile set and upgrade deliberately. Sixteen tiles is an evening of drawing. Forty-seven, with correct inner corners, is a week — worth it when your game is coastline and cave systems, wasted on a grid of city streets.

Decision 4: layers by function#

The layer stack is where tilemap design meets engineering discipline. Split layers by what they do, not by how they look:

• Background and parallax. Sky, distant silhouettes. Drawn behind everything; the 2D scene design guide covers how far parallax planes should be pushed.
• Base terrain. The autotiled ground layer, one material per layer where possible. Tiles that share a texture render in batches, so a layer that mixes five tilesets renders as five; keeping materials separate keeps draw calls down.
• Collision. A dedicated layer the physics reads. Not painted boxes over art — a collision layer, so redrawing a cliff updates walkability with it.
• Decoration. Two layers (behind and in front of the player) cover most needs: furniture the character walks in front of, overhead branches they pass under.
• Gameplay. Triggers, spawn points, checkpoints. Living on their own layer, they can be moved by a designer without an artist repainting anything.

The test of a good layer stack is destructive: delete the decoration layers and the game should still be playable, because nothing mechanical lives there.

The workflow: blockout first, art second#

With the four decisions made, the day-to-day workflow is a loop:

1. Blockout. Paint the level in flat grey fill tiles, no transitions, no props. This is the layout pass — corridors, sightlines, encounter spacing.
2. Playtest the greybox. The level must be fun before it is pretty. A boring layout with finished art is a decorated problem, and every art hour spent on it compounds the loss.
3. Mark up. While the layout is still cheap to change, put collision and gameplay layers in — walkable surfaces, hazards, triggers.
4. Autotile pass. Swap flat tiles for real terrain and let the editor resolve edges and corners.
5. Decoration pass. Props and decals, then a single polish pass. The scene composition basics piece covers where to break the grid deliberately so rooms stop looking mechanical.
6. Keep the sources. The tileset master (Aseprite or equivalent), the map project, and the exported files are three different artifacts. Version-control the first two; treat exports as build output.

This loop is the whole difference between efficient and inefficient tilemap work. The expensive passes run only after the cheap ones have validated the level.

Common mistakes#

Mistake	What it costs	Fix
Changing tile size mid-project	Every tile and sprite redrawn	Fix the size before the first tile is drawn
Hand-painting transitions	Hours per map, inconsistent corners	Set up autotiling before the first real level
One do-everything layer	Collision drifts from art; slow redraws	Split by function, test by deleting decor
No padding in the exported tileset	Texture bleeding at non-integer scale	Export with 1–2 px margins or extruded edges
One giant map for the whole game	Slow loading, unwieldy diffs, huge saves	Split into rooms or screens; loads, diffs and saves stay small
Editing exports, losing sources	One-way door back to the last backup	Masters under version control, exports as build output

The padding mistake deserves a note: when a scaled GPU samples a tile, pixels from the neighboring tile can bleed in at the edges. A margin or extruded edge around each tile in the exported atlas is a one-time fix; discovering it after shipping is not.

How Egmatic fits#

Egmatic is a no-code 2D editor and engine built on AI, currently pre-alpha, and its tilemap support is built around exactly this workflow. Tiles paint onto independent layers in the scene editor, gameplay attaches through nodes instead of code, and because the map you paint is already a scene in the engine that runs it, the greybox-to-playtest loop is one click rather than an export-import round trip. The blockout pass that most level designers skip because their editor is not their engine is the pass Egmatic is designed to make cheap. The current state is on egmatic.com; the waitlist there is how you watch that claim turn into a button.

Which decisions matter most#

If nothing else survives this article, keep the order: size, then structure, then autotiling, then layers, then art — always art last. The four decisions interact, and every one of them made early costs a day, while the same decision made late costs the levels already painted on top of it. For the tool side of the equation — which editor paints these layers, at what price, with which export formats — see the tilemap editor comparison; for shaping the rooms the tiles fill, the level design tutorial and the 2D platformer level design deep dive pick up where the grid ends.