Loading system introduced for generating levels beforehand.
Dungeon tile set, level-loading from file, and dungeon creation online.
Yep, can still break barrels.
Here’s a little explanation on the dungeon level generation:
First, for simplicity I had the level generated based off of an image loaded at boot. Here is an example of what that image might look like:
the map: each pixel representing a tile
Next, I set up a sprite sheet representing all of the possible positions of wall pieces to create the dungeon. With these and the knowledge of adjacent wall pieces, we can create a dungeon with connected wall pieces throughout.
Deciding which tile to use can be simplified to what surrounds it. Here is a figure I’ll be referencing:
Say the 1, 2, and 4 tile are present. We would then select from our sprite sheet the wall piece that represents a bottom right corner. If 5 is present, we’d have to choose an entirely different block.
I’ll use a notation for defining its position using a set of necessary boolean values (booleans not affecting the output tile omitted). For example, the bottom right corner piece requires position 1, 2, and 4 to be true (I already said that), but it also requires that 5 and 7 be false (otherwise they’d be different pieces). However, the value of 3, 6 and 8 make no difference in this case. Therefore, we can abbreviate this tile piece to: (1, 2, 4, !5, !7).
(1, 2, 4, !5, !7) tile
How do you know whether a tile position is require not (!tile) or not relevant (not included in notation or check)? Well, using the 8-bit system that I’ve been describing you’d have to consider that each tile has numerous exit points.
possible exit points (the point to which the graphic extends)
These are all of the possible positions of which the tile’s graphic can end. Positions 2, 4, 5, and 7 fill the adjacent wall’s graphic out to the shortest exit point. If two of the cardinal positions are true and adjacent ((2, 4), or (2, 5), for example), and the in between corner position is occupied (1 and 3 respectively), then that corner’s exit point is pushed to the wall (corner point). Here are some pictures showing that action taking place.
positions 2 and 4 are occupied, so the exit pointof the graphic is close to the corner, but because the corner piece is not occupied, it it not filled to the corner like the other corners.
Pic 1: (tiles not to size), Pic 2: adding an 8 tile, Pic 3: with appropriate fill
The thought process of removing a corner piece
This means that sometimes the corner pieces are relevant to the selection of the tile (both nearby cardinal tiles are occupied), and other times the existence of corner tiles makes no difference. This is how we’d decide whether a tile is !tile or just non existent in the notation.
Now that I have each tile’s value, all I have to do is determine the current tile’s value and find the matching tile (from the sprite sheet). Finding the current tile’s value requires checking the existence of an identical tile type in each of the (1 through 8) tile positions. For example, if a tile at position 1 exists, set 1 to true else to false (!1). Afterward, find tile of identical criteria and place tile. There should only be one tile with each criteria if done properly.
All of the tile positions (pre rotation)
The finished product
Do remember, using a large number of boolean values would be silly despite what was described prior. You should try implementing a bit field containing all of the positions’ values, explained in further detail here: Adventures in Bitmasking