When a Tileset Is the Wrong Answer
Tiles buy cheap repetition and cheap editing. When a project needs neither, here is what to build instead, including the hybrid nobody writes about.
Tiles are the default for 2D level art, and defaults get chosen by inertia. You open the engine, there is a tilemap node, the documentation has a tilemap tutorial, so the level gets built from tiles. No decision was made.
Often the default is correct. Often enough to matter, it is expensive and wrong, and the bill arrives months later as a level that reads as repetitive and a tileset nobody wants to extend. Tiles buy two specific things and charge two specific things, both concrete enough to test against your project this afternoon.
The short version. Tiles buy cheap repetition and cheap editing. They cost visual variety and the labor of a combinatorial system, since every material carries a full set of edges and corners that have to work against each other. A game with a few fixed rooms pays that cost and collects no payoff, and a painted room over an invisible collision grid gets bespoke art with grid-predictable gameplay instead. One override beats all of it: while the level design is still moving, use tiles regardless of the art argument.
What tiles buy
Cheap repetition. Art cost decouples from level size. One modest texture covers this screen, the next, and the four hundredth. The memory version is sharpest: an uncompressed 1920 x 1080 painted background costs 7.91 MiB of video memory against 2.38 MiB for a 600 x 1040 character sheet. Ten painted rooms resident is most of a small game's texture budget. Ten tiled rooms are one texture, sized by the limits that govern how large a texture should be. The test: does the amount of level keep growing after the art is finished?
Cheap editing. A tiled level is data. Anyone can move a platform, widen a gap or delete a room in seconds, with no round trip through a person who can draw. The test: will a non-artist need to change the shape of a room, repeatedly, after the art exists?
Answer no to both and you are buying a combinatorial system for nothing.
The two costs arrive later than the benefits
The first cost is the system. A material is not one square: a fill, four edges, four outer corners and four inner corners at minimum, each constrained on every side by what the editor can legally place beside it. Materials that touch multiply rather than add, since with n materials the touching pairs number n times n minus 1, over 2. Three materials is three transition sets; five is ten.
The second cost is variety, and it is structural rather than a matter of tile count. Both land late: you feel the editing speed in week one and the repetition in month four.
The repetition threshold: how much level pays a tileset back
Reason it rather than guessing. A tileset has a fixed cost paid once: the base set per material, transitions between materials that touch, above-grid decoration, the test map, integration. Call it S. A hand-authored screen costs R, each time. The crossover sits at N equals S divided by R, and above N screens tiles are cheaper on art alone.
Two things make it usable. First, count screens, not rooms. A room four screens wide and two tall is eight screens of surface. At a 1920 x 1080 camera and a 32 px tile it is 240 by 68 cells, about 16,300 tile placements, which nobody paints by hand. Second, get S and R into the same unit. If the tileset quotes at the cost of five painted screens, then at six screens tiles win and at four they lose.
S is a step paid up front and R is linear, so a small fixed game never reaches the step and a growing one clears it quickly. Projects that get this wrong are nearly always on the small side, buying a system that amortizes over eleven screens.
Why a tiled level reads as repetitive even with a large tile count
Players do not notice tiles. They notice period. The eye is an excellent periodicity detector and a poor inventory-taker, so a level with eighty tiles in it reads as repetitive the moment one distinctive mark recurs at a fixed interval. Adding fill variants therefore fails more often than it works: five variants shuffled across a wall still repeat, just at five times the spacing. Three fixes, in order of return.
- Strip the marks out of the fill. Fill tiles should be low-frequency and forgettable. Anything a player could point at and name is a landmark, and a landmark appearing twice on screen is the whole failure.
- Vary above the grid, unsnapped. Decoration placed freely combines with every tile beneath it instead of multiplying against the adjacency set. Ten such sprites break period in a way ten more fill tiles cannot.
- Vary at a scale larger than the grid. Light, silhouette, room proportion, a large foreground object. Repetition is visible relative to the frame, so variation bigger than the frame hides it outright.
Check on the assembled level, never the sheet: fill several screens, zoom out, hunt for a recurring mark, then scroll at full speed.
Editing velocity beats the art argument while the layout moves
If your level design is still changing, choose tiles and skip the rest of the cost case. A painted room turns every layout change into a repaint: a new file to commission, integrate and re-collide. Do that four times during playtesting and you have spent more than the tileset would have, on rooms you threw out.
A layout is frozen when playtest feedback stops producing collision changes and starts producing content changes. Before that, tiles. After it, the art argument governs, and converting frozen tiled rooms into painted ones is a planned step covered in replacing placeholder art.
The alternatives, and the project shape each wins on
Four approaches compete. Three are short; the fourth gets its own section.
Hand-authored room images. Each room is a composed picture, or a few layered pieces assembled into one. Wins when the room count is fixed and low, when players stop and look, and when the look is the selling point. Breaks when the level changes shape, and on memory once many rooms are loaded.
Modular chunks larger than a tile. Pieces sized in screens rather than 32 px cells. A measured hallway set from one science fiction game works this way: middle sections carry the corridor, top and bottom transition pieces frame it, each with variants. Combinatorial cost collapses because a chunk connects on one or two edges instead of four, and variety cost collapses because each chunk holds a screenful of unique art. Wins for linear levels of repeated stretches, and breaks when you need fine control.
Scattered decoration over a simple base. One flat ground surface with props placed on top by hand or by script. Wins in top-down games with large open areas, in generated levels, and any time the surface underfoot is not the interesting part. Breaks when the terrain has shape, since a scatter system has no concept of an edge.
The hybrid: a painted room with an invisible collision grid
This is the answer for a large share of small games and almost nobody writes it down. Paint the room as one piece of art. Author collision separately, on a grid, in a tilemap layer that renders nothing. The player sees bespoke art and plays grid-predictable geometry.
It works because the two purchases tiles bundle are separable. Cheap editing comes from the grid, and a collision grid is free: those cells are not art, nobody draws them, and there is no adjacency problem because nobody sees them. Variety comes from the painting. You give up cheap repetition, the benefit a small fixed game was never collecting.
It also fixes what painted levels are worst at. With free-form collision, ledge heights get hand-tuned per room, so the same jump feels different in two places. On a grid a ledge is two cells high everywhere and your movement tuning transfers.
How to keep the art and the grid in sync
Sync is designed in before the room is painted, not patched afterward.
- Pick the cell size first, from character height and jump height, exactly as for a real tileset. Nothing gets painted until that number exists.
- Put the grid in the brief. Every walkable surface, ledge top, wall face and doorway edge falls on a multiple of the cell size. One sentence, no drawing vocabulary, and sync becomes checkable.
- Take delivery with the grid visible, as an overlay or a second image. That catches a floor sitting six pixels below a cell line.
- Author collision from the art, in the editor, over what you can see. Never transcribe it from a design document.
- Store the room and its collision data as one unit. If the image can be updated without the collision moving with it, one day it will be.
- Ship a debug toggle that draws collision over the art in-game. An afternoon of work, and the whole defense against drift.
Write the cell size and the on-grid rule into your art bible. It keeps future rooms compatible with the ones you have.
What breaks when the two layers drift
Drift has one signature: a mismatch between what the player sees and what the player hits. Standing a few pixels above the floor, clipping into a wall, or worst, an invisible wall in open space. Players do not report these as art bugs. They call the game janky and stop playing.
The causes are predictable. An art revision moves a floor line and nobody re-runs collision, so the room is off by a constant offset with no error in the build. A prop leaves the painting and its collision cells stay. A room gets rescaled and the grid picks up a rounding error.
Two defenses cover all of it. Treat the collision layer as the only source of truth for gameplay and the painting as the only source of truth for the look, and re-run the debug overlay on every art revision, minor ones included. Then never scale a finished room: author at ship size, because a resize breaks both layers silently and at once.
A decision procedure for your own project
Copy this and fill it in once per game.
# LEVEL ART - which approach
1. SCREENS OF WALKABLE SURFACE (not rooms)
screens = [____] still growing? yes/no
2. IS THE LAYOUT STILL MOVING?
yes -> TILES. Stop. Revisit when frozen.
3. MATERIALS THAT CAN TOUCH
n = [__] pairs = n(n-1)/2 = [__]
sets to author = n + pairs = [__]
4. WHAT DOES THE PLAYER STARE AT?
rooms occupied for minutes: [________]
-> painted, whatever step 5 says
5. COMPARE IN THE SAME UNIT
tileset system cost S = [______]
cost per painted screen R = [______]
crossover N = S / R = [______]
screens > N ? yes -> TILES
no -> PAINTED
6. IF PAINTED, NEED GRID GAMEPLAY?
yes -> HYBRID: paint it, author collision
on a [____] px grid
no -> hand-authored, free collision
7. IF TILES, WHERE DOES VARIETY COME FROM?
above-grid sprites = [__]
larger-than-grid = [__________]
8. RECORD IT IN THE ART BIBLE
cell size, approach per area, collision owner
Step 4 overrides step 5 deliberately. A grid survives peripheral attention and fails direct attention, so the arena a player stares at for ten minutes gets painted even in an otherwise tiled game. If the procedure leaves you undecided, the decision tree for getting art settles it, since who makes the art changes what is affordable.
Mixing approaches without it looking inconsistent
Most shipped 2D games mix: tiled corridors, a painted boss arena, a hand-composed hub. It looks broken only when you mix for the wrong reason or join the pieces badly.
Split by function, never by budget. "Tiled because we ran out of money" produces a game where the cheap parts are visibly the cheap parts. "Tiled because the player runs through it, painted because the player stands in it" produces one where the expensive parts read as important. Same spend, opposite impression.
Hold four things constant across every approach. Light direction. Value structure, meaning whether characters read light on dark or dark on light. Saturation relative to the cast. Edge treatment, meaning whether art carries outlines and how heavy. Get those four to agree and a tiled wall and a painted wall belong to the same game. Baking a whole collection at once, as Makko does, holds them constant across the set.
Never join two approaches along a flat edge in the same plane. A tiled floor running into a painted floor shows the seam immediately. Put something at the join: a doorway, a depth change, a foreground object. Players accept large stylistic jumps across a threshold and notice tiny ones across an open floor.
Frequently asked questions
My game has about a dozen rooms. Should I still use a tileset?
Probably not for the art, possibly yes for the editing. Run step 2 first: if the layouts are still moving, build in tiles now and convert later. If they are frozen, a dozen painted rooms over a collision grid beat a dozen tiled ones for comparable spend, since each room gets a screenful of unique art instead of a share of one tileset.
Can I use a tilemap for collision with no tile art at all?
Yes, and that is the hybrid. Every mainstream 2D engine will run a tilemap layer whose tiles render nothing and collide normally. You get grid snapping, consistent jump heights, and level data you can diff, with no adjacency art to commission.
What about procedurally generated levels?
Generation forces tiles or chunks, since the generator needs pieces it can legally combine, and it removes the small-game exemption because level count is unbounded. Prefer chunks where the design allows: larger pieces mean fewer combinations and more unique art per screen, the standard fix for generated levels that all look alike.
I already commissioned a tileset and my game is small. What now?
Keep it and add above-grid variety instead of reauthoring. Freely placed decoration sprites, large foreground pieces and per-room color shifts attack the period problem without touching a tile. Then paint over the two or three rooms the player occupies longest.
Why does this say MiB and not MB?
Because memory and storage are counted in different bases. A mebibyte, MiB, is 1,048,576 bytes, or two to the twentieth. A megabyte, MB, is 1,000,000 bytes. Memory is physically addressed in powers of two, so every engine profiler reports the binary figure, and the numbers here match what Godot, Unity or Unreal will show you. Storefronts and drive manufacturers use the decimal one instead. At this scale the two differ by about five percent, so the same 1920 by 1080 background is 7.91 MiB and 8.29 MB. Same pixels, two labels. It is the same reason a drive sold as 1 TB shows up as 931 GB.