Slow Rush Studios logo,
    depicting an apprehensive-looking snail rushing forward

Slow Rush Studios

◂  Loading Levels
News index
Level Progression  ▸



This week I added support for tile maps, so levels can be created with the LDTK editor.


The core idea of tilemaps is that if you design some square images which neatly fit next to each other, you can stick them together to make a much bigger image that looks like a coherent whole.

Here's a quick1 example; say you've decided that you want your level design to look like this:

Example of an LDTK intgrid
This is what LDTK calls an 'intgrid': a grid where each cell is simply represented by a number (e.g. 0 = navy, 1 = orange).

Then you can take a bunch of tiles packed into one image like this:

Tileset from LDTK example
The Cavernas tileset; a sequence of 8x8 pixel images.

And stick those tiles together to get exactly your original level shape:

Output tilemap from LDTK example
Tiles from the tilemap applied to the LDTK intgrid, to make a much nicer looking level.

Now you have a much nicer looking level, and you only had to draw a few2 tiles.

Of course, placing each of those tiles by hand would be tedious, so you can define "auto-tiling rules" that automatically place the right tiles, based on which tiles are around:

Example tiling rules from LDTK
LDTK auto tiling rules used in the previous example. Each of those places one of a few tiles in a cell.

Tilemap Tradeoffs

On the one hand, designing levels using tilemaps in this game is pretty obviously a good fit: currently every piece of a starting level looks a lot like that LDTK intgrid example above.

On the other hand...

A more flexible graphical approach would be to have a really big image for each type of atom, and "cut out" the appropriate bit of the texture: 3

Sketch of an alternative cut-out based approach.
You'd find the space that some stone atoms occupy, and set the color of the stone atoms based on where those atoms appear in a larger texture.

That seemed like a potentially prettier outcome, but to make it look good you still have to figure out what to do at the "borders" (transitions between different types of atoms) - and that seems like it'd be either back to auto-tiling again, or require an even more complicated approach. So it didn't seem worth going down that route for now.

Overall, A+ level editing is secondary to "it's about time to start building some actual gameplay", so I decided the tradeoffs of using tiles and LDTK are acceptable - at least for now. 4

Tilemaps in Action

I made the world's most basic tilemap in Aseprite and got the approach working:

LDTK-based level in action. Acid corrodes tile-based stone atoms just the same as normal stone atoms!

Internally, everything runs just as it did before, except each atom just has a different starting color:

  1. The LDTK file says what atom type should be created in each 8x8 cell, and also what tile should be there.
  2. We load the correct tile image from the Aseprite image file.
  3. We create a bunch of atoms and look up each atom's starting color from the tile image.
  4. If there is no tile, we just generate a color as before. 5

I also went a little out of my way to make level hot-reloading work; if either the Aseprite image file or the LDTK level file are updated, the level will automatically reload to show the changes: 6

Hot reloading in action. Offscreen, I first change the LDTK level layout a few times, then change one of the underlying tiles.

Playable web build‎

Here, see that beautiful stone tileset in action:

Click to focus, then play with keyboard and mouse. No mobile support! Give feedback.

Only levels starting with main: (all 2 of them!) are LDTK-based levels, so only they use the stone tileset:



For an excellent extended example, I recommend this breakdown of Celeste's tilemapping.


Only 22 tiles, in fact. All the other tiles in the example are unused here.


This cut-out approach seems to be how the Worms series textures their levels. And Factorio uses it for concrete too.


Also I figure I can work around some of the issues. For example, to allow tiles to be e.g. 4x wide, I could make make the outer 2 pixels on each side of an 8px tile be transparent, and then when reading the saved level from LDTK into the game, just ignore those transparent pixels; that would let me move along.


I kept support for non-LDTK levels too, so those also use the generated colors still.


Unfortunately, this approach of assigning colors to atoms at the start does mean that the whole level gets reset even when only the image file is updated: some atoms change their color over time, so even if we kept track of where atoms have moved to, it might be incorrect to change their color.


Hint: use the debug menu (F2) and re-read the bit about repairing the slow physics bridge in Let Sleeping Atoms Lie.

◂  Loading Levels
News index
Level Progression  ▸