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).
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.
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.
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)
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
Is this right? I can’t tell.Some order is made. Detection of closest face online. Distinction between visible faces somewhat established. Cutting of faces (for blocking blocks) online. The loop through all of the wall points has been created. Getting closer.
If I know anything about this lighting, it’s that I’m pretty close to finishing this portion. And by portion I mean the “light detection” or where the light beams should go. Afterward, I’ll have to tackle the lighting effects (how the lighting affects the environment) and I’ll probably put up a write up on my light detection method. Back to woik.
Written in Java using the LWJGL and SlickAndCode.
Zaljin’s work: zaljin.com.