When the Map Makes the Dungeon
After playing the classic dungeon crawler, Eye of the Beholder for a few hours, I had a wacky idea that I needed to throw together. Playing a classic like this normally requires mapping the catacombs by hand as you go. This is a big change from more modern games, like Etrian Odyssey, where the mapping is built right in. This somewhat tedious, somewhat meditational practice made me wonder if it would be fun to create the dungeon as you map it, instead of vice-versa. Then a whole flood of mechanics came to mind that could go along with this, but the first step was a must: have the dungeon build itself from the map you make.
This is a prototype-prototype, so no definitive game was expected at the planned end of this exercise. I just wanted to rough out the concept and see if it felt like it had any legs. Everything is in Unity, and my rudimentary pixel art was done with Pyxel Edit.
Basic Layout
The biggest chunk of this project was building a mesh for the actual dungeon geometry as you lay out a map. To keep things simple (and classical, like Eye of the Beholder), I stuck with a nice grid of squares to represent each dungeon tile. Since I was trying to be speedy, I decided I would rely on raycasts to the dungeon grid plane to place the tiles. Each tile is one unit squared.
My simple plane with grid atop
I placed an orthographic camera looking down on the grid to capture mouse clicks to place the tiles. This could be considered a secondary camera to the primary, first-person view. You can see how I use this mapping camera over in my somewhat sparse UI on the right.
Editor view showing the first-person view and the ersatz UI
From the first person view, you can see the empty grid spread out in front of you. I tied ray-casting to the orthographic camera in the UI so that when you hover over a grid space, a highlighting object appears over that grid square, visible in both the UI and the first-person view. Clicking on a tile will add that tile to the dungeon mesh. This is when the actual mesh making begins.
Mesh Making
I split the dungeon into three mesh sections: floor, ceiling, and walls. The floor and ceiling are the most straight-forward. With each added dungeon tile, a four-vertex mesh is added to the existing floor and ceiling meshes, composed of two triangles (your typical square, folks). Each mesh has its own material, with its own tiled texture. For now, there is no variation among the tiles of each mesh, although this is something I’d like to implement.
A view looking up at the generated ceiling mesh with its texture applied
As stated earlier, I am just using one mesh each for the ceiling and floor, so new tiles are just added to the vertex, triangle, and uv arrays. The relative position of the different added tiles didn’t really matter at this stage, but I did keep track of each tile as it was incorporated into the mesh. This comes in handy when I started adding the walls.
To make the walls, I assumed that any floor tile with an adjacent floor tile would not have a wall between. Essentially, each space between walls would be an entire tile. So, as dungeon tiles are selected to be added to the mix, each tile’s custom class is updated to record which adjacent tiles are populated.
Cycling through each populated tile and placing walls on the sides that require them, and ensuring that the visible side is facing the side with the floor. In this quick mock up, I just clear the entire wall mesh and make a new one. This is what needs a major coding update, but wasn’t really required to prove out this concept.
You can see how it all comes together in this short video I made placing the tiles and then doing a bit of exploring.
A quick look at the Dungeon Maker concept
Future Ideas
The first step would be cleaning up the mesh generation a little, primarily with the wall methods mentioned. This would just involve some optimization of array manipulation for the most part -- this I will probably do regardless of any other additions. Also, some texture variety is needed, and I’ll have to gin up a shader to help with this, in addition to deciding if the textures will be random or intentional based on certain factors.
Outside of basic code and art improvements, I have had several ideas to make this into an actual game. Perhaps it would be fun enough to build a dungeon to reach a known treasure location? Certain obstacles could be in the way making this a bit more of a puzzler than a dungeon crawler. Maybe it could be a timed dungeon escape as a one-hit-kill monster or hazard chases your character as you map and run out of the created dungeon. Both of these ideas have some merit, and shouldn’t be too difficult as an extension of this prototype to test out.
Almost all of my other ideas involve digging into a combat system of some sort, and the options there just kind of explode. This is my main hesitation from continuing this for now. Not that I don’t want to work on such a thing, I just don’t have the time to commit to doing it well at the moment.
If you want any more details about how this was done so you can start doing something similar, feel free to send me an email and ask. No deep trade secrets here, and I’d love to help get someone started on a dungeon diving game with a twist.