More on Tile Swapping

Posted July 3, 2014, 10:01 p.m.

After playing a bit more with tile swapping, I realized that the logic used to match up lines like roads and fences is very similar to the logic used for matching up filled shapes like terrain in an RPG or solid shapes in a platformer. The only real difference is that filled shapes need to look at surrounding tiles that touch on diagonals rather than just adjacently. Anyhow, I was able to extend the logic in the Stencyl behavior to fill shapes as well as detail the edges. The tile sheets I've been able to find online are often incomplete (mathematically speaking), so I threw a really simple template together for the purposes of demonstration. Pretend that these shapes are beautifully textured.

Blocks placed without using edge pieces, either by a lazy (efficient) level designer or an algorithm.

By specifying a Tile sheet and Layer, the game can scan across the tiles and replace them based on their surroundings to create coherent shapes.

Offloading the work of placing edge pieces onto the game itself not only saves time for hand-made levels, but would allow for me to set up an algorithm that roughs out terrain on its own before figuring out what edge tiles go where. Do this multiple times with different tile sheets and you can make maps! The resulting shapes are smoothed, though there currently aren't any slopes or gradual transitions from vertical to horizontal. I considered putting the logic in for this, but most games don't use ramps all that often. Those transitions might be added as part of a higher-level algorithm's later passes through the level design depending on what kind of level is being made.

Three types of center tiles from three different tile sheets are layered like one would expect for a map, again without edge pieces.

By replacing at runtime, multi-layered shapes like over world maps can be created with minimal effort.

Though pretty cool (to me at least), the ability to fill in edge tiles is sort of just a logistical footnote in the process of procedural generation. Next is the heart of procedural generation - the procedure. Making interesting environments depends chiefly on the sort of game they'll be used in, and has to take into account what the player is capable of. How high can they jump? How fast can they run? How much of each resource are they likely to have? Are there time constraints? All of these questions determine how the magical algorithm is formulated to make a space at once interesting, different each time, and coherent.

Now, to think of a game that would use the tools that I've spent all this time creating...