Walls, how do they work?

In this post I’m going to explain how walls work in King under the Mountain. Not in the gameplay sense of them blocking movement (and light sources!) but in the technical sense of how the art assets are put together and handled.

First of all, no, this isn’t the monthly dev update to signify that development has kicked back into full swing *just* yet. Instead I’m trying to lay out some groundwork and guidelines to hopefully get some help with the project as well as a sort of technical primer for anyone interested.

It’s no secret that King under the Mountain‘s visuals are heavily inspired by Ryan Sumo’s work on Prison Architect by Introversion. Much like the floor tiles, the walls need to seamlessly tessellate with each other and may end up forming many different shapes, such as differently aligned corners and T-sections of walls.

When I first tried to get my head around how I’d go about making something like this work, I came across the Prison Architect sprite sheets that show the wall assets as follows:

These sprites are drawn in the correct position as determined by the game engine. Unfortunately, this set of sprites means that any walls more than 1 tile “thick” show up like the following:

As King under the Mountain needs to depict vast mountains made up of many tiles, I had to come up with something better (or at least different) to be able to show several wall tiles next to each other without these gaps in-between.

So to begin with I tried to figure out how many different possible “layouts” of wall tiles there could be. The simplest approach is to say that for any tile which is a wall, it has 8 neighbouring tiles, which themselves may or may not be a wall.

A sharp computer scientist would realise that if we always assume the central tile in the diagrams above is a wall, and the 8 surrounding tiles may or may not be a wall (a binary distinction) this can be represented as 8 bits of binary information, which just so happens to be a byte!

So with this stroke of understanding, there are at most 256 different possible wall layouts! Which is certainly far too many to want to store on a spritesheet or even draw to begin with. Fortunately, among the 256 different possible layouts there are a lot of duplicates of how the central tile would look.

Armed with this knowledge I wrote a little script to figure out all the “meaningful” different wall layouts, which resulted in the following list of 30 unique layouts required. Note the numbering using the binary identification from above.

For the early stages of development I had all 30 of these sprites in the spritesheet for the initial walls. I should have realised when quickly knocking up the programmer art there was a lot of duplication and cut-and-pasting of specific sections, in particular the corners (or not).

Using these 30 different unique layouts let me show any possible layout of wall tiles depending on if their neighbour tiles contain a wall or not. This does mean that all walls have to roughly align with the other types, particularly straight-edged walls with rough-edged walls, but it seemed the appropriate solution.

Eventually I had the eureka moment that each of these 30 unique wall tiles are made up of a different combination of 4 sub-sections – the top-left, top-right, bottom-left and bottom-right sections of each tile. A bit of working out later and I had a set of only 5 unique tiles that can make up any wall layout!

King under the Mountain uses 64×64 pixel tiles for the underlying art assets to allow for some level of detail balanced against the size requirements of wanting many different types of walls and floors to be used. Ideally the entire set of tiles are loaded onto the graphics card as a single image (a spritesheet) so that sections of this image (each tile) can be very quickly blitted to the screen without having to load a new texture and bind it to the graphics card. Most graphics cards have a max texture size of 8192×8192 pixels which is a lot but would eventually get filled up if every type of wall needed 1920×64 pixels (plus some bleed) when I really want to have a very large amount of variety in different types of walls and flooring in the game.

Due to the alignment of the “tops” of the walls, they’re split up at 32 pixels along the width and 50/14 pixels along the height of the tiles.

Splitting the wall tiles into these quadrants allows for different combinations to be drawn into any of the 30 unique layouts discovered.

This was the main breakthrough in figuring out how I need the art assets to be created but it poses a slight challenge for an artist to make sure everything lines up correctly. Generally when it comes to tiles they “only” need to line up along the edges of the tile, but with this splitting of the tiles the different sprites also need to match up when split up along the x = 32 and y = 50 pixel positions.

The other issue with aligning walls is that the “tops” and “sides” of the walls need to line up with each other across different tilesets as well as with each other in the same tileset. I ended up copying a similar approach to that used in Prison Architect (though not the same dimensions as PA’s tiles are stored as 50×50 px) to define a set size for these top and side areas of the walls.

Note that there’s also a fairly thick border around the tiles and this may change in the future. Rimworld, for example, does not have straight-edged wall tiles which would fit better in this setting rather than the always-straight edges of Prison Architect. Dealing with the edges of the tiles potentially being transparent will require just a bit more work in the engine than what happens currently (which always comes with a performance cost too).

The next step comes in designing a series of overlays for these wall tiles to the above specifications to represent other materials embedded in the wall, in our case mostly gems and different types of metallic ores, to represent rock walls containing valuable resources. By matching the “shape” of the 5 different wall layouts (mostly matching up on the edges and angles in the wall image) the engine supports drawing a further layer of “wall” assets on top of the base wall. For example (and again please excuse the poor programmer art) here is a set of sprites to represent gems to go over the 5 different layouts.

Finally, most of the art assets for King under the Mountain are actually drawn and stored in (relatively light) greyscale (as with the gems above) – this is so the art assets can be “coloured in” by the engine as they are rendered to the screen to represent different materials. In the case of the rock walls, different kinds of rock, and similarly different colours of gems can represent emeralds, rubies, sapphires and so on.

And that’s how walls work! At least so far. At some point we’ll be looking for artists to follow these guidelines to produce environmental assets, so if that might be you please get in touch with me at ross@kingunderthemounta.in

Right now though (October 2017), real life problems are holding me back from being able to invest any money into development so I’m not able to contract any artists just yet. That said, if you’re interested and would like to be involved when we do get to that point, please let me know!