Creating Dungeons Revisted

So, back here again. With my campaign having started I figured I would write about making dungeons. Firstly for my own benefit in getting my thoughts straight. Secondly because other people might find it useful or interesting. And thirdly because I now have actually made a full dungeon rather than the simple one shot “dungeons” I made previously.

Step 1: Theme

The first step in making a dungeon (or adventure) is to figure out a theme. Taking my first dungeon for example, I actually started by designing an encounter. The encounter was based on the idea of constructs that blended into the environment (living statues, animated items, etc.). When I started expanding the idea into a full dungeon I needed a unifying theme. At first I went with “constructs” but there simply were not enough constructs (of an appropriate difficulty) to populate the dungeon. So I got creative, and re-flavored some things into constructs. But that only took me so far.

I needed a theme change. And then it hit me: Museum. The constructs make sense there as displays and guards both. And it opened me up to a few other things I could use. Now I had some elementals rooming a laboratory that some archeologists… found, and brought back. A few sentient constructs were hard to justify, until they were trapped in the museum by some unseen curator.

Step 2: Populating the Dungeon

As you might have surmised, these steps are not as sequential as I would like. But the idea still stands. After you know what your dungeon is about, you need things to go in it. The first part of this step is figuring out the encounters the players will face. In my case the flow of the dungeon would go something like this:
1. An initial encounter upon entering the museum.
2. Learning they need a pair of keys to open a large door.
3. Going on one of two branching paths. With at least one encounter along the way.
4. Puzzle to get the key. (With possible combat encounter if they “cheat” the puzzle)
5. Repeat for other side.
6. Final encounter in the treasure room.

So I needed an initial encounter (already made). Two encounters for each branch (four in total). An encounter for “cheating” on the puzzle (repeatable between the two puzzles). And a final encounter (also already made).

How I did it

And I got to work. The three of the four branch encounters where fairly simple, with the final one taking the longest to figure out. The “punishment” encounter was tricky, but a small reskin of an existing monster got me where I wanted to be. And we were almost done. Until I had one more idea.

Even with two puzzles this dungeon felt a little combat heavy, so I added a non-combat encounter. It is a creature from non-official sources that I just love the idea of: the “treasure weasel”. It presents itself as an unsolvable problem with the promise of treasure at the end. This way the adventures will keep trying to get the loot, but get more frustrated as time goes on. And that is the point, in lore these creatures feed on frustration. But once sated, these creatures also gladly give up the treasure they are guarding. Putting this back in the main hall, that they have to pass through several times, makes it unavoidable. And I have all the encounters for my dungeon.

Step 3: Set Dressing

This is the step I am still worst at. I need a description for each room and the kinds of things they find in there. So far I have gotten away with improv skills of “making it up as I go along”, but I need to think this stuff out more in the future. Some of the descriptions I have given were:
“Impossibly swirling marble walls, as if the marble was sculpted from clay”
“Benches made of copper”
“A stone slab bench made from an impossible fusion of obsidian and ivory”
And “Giant stone doors designed to rise into the ceiling”
So I think I am doing alright in the improv department… but I would rather not rely on it too much if I can avoi9d it.

The Advice to “Kill Your Darlings”

“Kill your darlings” is a bit of writing advice heard rather often in writing. In short it means to be willing to destroy elements of your have worked hard to create. To be willing to discard even your most cherished creations. This does not mean that you will get rid of those elements, but you must be willing to do so. This is because otherwise we can be blind to the problems that our “darlings” create in relation to the whole project.

So, why do I bring this up? Simple. “Kill your darlings” applies to much more than writing.

Programming Darlings

Early on in my project I created the randomized levels. With that I of course created the controls. A drop down window for difficulty and simple “New Level” button. But I also added a “Custom” difficulty that allowed the player to input their own target number. This, the “Custom” setting, was my “darling”. It has stuck around for far longer than it should have. I have for quite some time that the dropdown menu would need to be changed. But doing that would necessitate a significant rework of the “custom” setting, and so I put it off.

But eventually, I recognized that the “custom” difficulty setting had outlived its usefulness. And so, I removed it. And in doing so, removed the last thing holding me back from removing the dropdown menu and converting it into a spinner design.

In any creative endeavor, from writing to programming, to painting, and beyond, one must be willing to remove our favorite parts of a project. All in service of making a greater whole.

Changes: Visual, Functional, and Programmed

Changes are happening in my game. Lots of those changes are minor UI layout tweaks that are uninteresting to talk about. Bit of experimenting, little movements to make big differences, that type of things. But I have been making some more substantial changes too.

First Biggish Change

For the pre-made levels mode, there is a visual indicator of if you have previously completed a level before and if you have solved the level optimally. At first the indicator was a big “X”, but that had always been a placeholder. Next I tried a star shape to go with the twinkling star effect I put in the background, but that didn’t mesh as well as I had hopped. Then I settled on a circle that was filled with a dot when the appropriate condition was true. But recently an idea was suggested that I should have tried much sooner.

The idea was simple: Just have the word disappear and appear as needed. Having the entire word showing up and disappearing will draw the user’s eye, showing the change. I may add a few subtle effects to the appearing (very subtle animations to help draw the eye), but just goes to show that I should always strive to follow the K.I.S.S. principle. Keep It Simple Stupid.

Upcoming Change

The next change will take a bit more untangling and reworking than the last one. I am reworking the difficulty select for the randomized puzzles. Currently it is a drop down with the options of: easy, medium, hard, or custom. The rework is three fold.

First and foremost I am changing the dropdown to a spinner design. Originally I didn’t know what platform I would be releasing on, but now I have narrowed down to a mobile release. I light of that, I am trying to eliminate dropdown boxes wherever feasible, to avoid people fat fingering the wrong option.

Next is to remove the “custom” difficulty option. I liked the option at the start, but in light of various design decisions I have made, I have decided to scrap it. Which leads to the third change.

Up to this point when you selected a easy, medium, or hard difficulty puzzle it would give you a puzzle with a preset number of moves needed to complete it. This change is to add a small randomized element. So instead of always giving a puzzle that needed 4 moves to complete an easy puzzle will need between 3-5 moves to complete. This will be reflected in the Target # the player can see, so they know how many moves they are expected to make.

Beyond All That

Those are the immediate changes I am making to my game. But some other things are in the pipeline that I have planned. But I can’t talk about everything all at once. Besides, if this project has taught me 1 thing it is this: Plans need to be fluid and you can’t stubbornly hold onto one idea.

Changes. Implemented and Planned

After another review of my game (and more importantly its UI layout) a few things were found to change. Some of these are a result of recent changes, some were ideas I had before but either never implemented or changed to something else.

First Change

The first change I made which led to some of the other changes was actually a programming change. In the play scene for pre-made levels there is a level select element. The up and down options could be held down to cycle through the levels without constantly clicking/tapping. But it only went at one speed. I changed that so that it sped up as time progressed. Took a bit of coding to get all the proper flags in place, but now you can get much farther much faster than the old version, without sacrificing accuracy for short jumps.

Knock on Changes

The first big change that the improved level select caused was to the “Next Level” and “Previous Level” buttons. Previously I had those two buttons in the lower corners of the screen so you could jump to new levels freely. But back then the level select was… clunky. Now that level select is more smooth those buttons don’t need to be available all the time. But I did still have a use for a “Next Level” button. It now shows up during the “Level Complete” state of the game, around the center of the screen. This is to give the player a direction to go after they complete a level.

Planned Changes

A few other minor changes have also been made, but two major changes/reversions are also being considered. First is one likely to happen and stick around: auto level changes from the level select. Right now, after navigating to the desired level number the player must press another button to actually go to that level. The proposed change will cause the level change to occur as soon as the level up/down button is not being pressed. The second change is a bit less likely, removing the Main Menu level select.

Right now I have a level select screen in the main menu before starting pre-made levels proper. But that screen also has some useful info about uncompleted levels that can guide the player on what level they want to do. So I am very reluctant to remove it. More likely is that I will change the select method to match the one in the play area scene.

Creating a One Shot

Ahead of my campaign starting, our group is going to have a session with about half the members missing. The three options for this day are as follows. Don’t meet up, play a different board game, or let me run a one-shot adventure as practice for my campaign. I would prefer to go with the last option, but what should I do for it?

First and foremost, for those that don’t know, a one-shot adventure is a game of D&D designed to be done in a single session. No or limited ongoing implications, fast and fun, wrapped up in a bow in one sitting. It allows for players to try out new characters and for DMs to try out new… anything they want really. No long lasting consequences mean if things go pear shaped everyone can laugh it off.

So What About My One Shot?

There are several paths that can be taken when sitting down for a one-shot. The first, very common, option is to find a pre-written one. Plenty of them exist online, just a matter of finding the one you like. The other much more difficult option is to design your own. Lots can go wrong with this approach, but that is half the point of a one-shot. Of course you can also hybridize these approaches. Find an existing one-shot and edit it to your liking. But I am going with the “design your own” method.

The primary reason for this is that for my eventual campaign I am using my own setting, and I want a practice run in that setting. But also, I want the challenge and freedom that comes with making my own one-shot.

The Nitty Gritty

After some thought, I have broken the one shot down into something of a 3 act structure. I didn’t realize it was a 3 act structure until I was writing this, but it works out to that. Each of the “acts” will see the party faced with an entirely different set of problems to solve and decisions to make.

act 1

The first act sees my players on a ship heading to the new uncharted island. let my players introduce themselves and get their bearings. Meet the crew, see the other adventuring party, notice those clouds on the horizon… wait. A squall suddenly hits the ship. Now for the first bit of “conflict” each of the players will take turns describing how they use their skills to try and help the situation. This is something I am stealing from a D&D twitch stream I am watching. But it does not matter how well the players do, the ship is going to run aground on a deserted part of the island.

So what is the point if the players can’t effect the outcome? Based on how well they do they may get certain perks in the rest of the adventure. Maybe they did enough that the captain gives them each a healing potion, or maybe less of the crew is injured and can be more helpful latter on. I won’t punish my players for messing up this part, but I will reward them for doing well.

act 2

This act is fairly short. Ship is a wreck and most of the crew isn’t going anywhere for a while. So they need to make contact with the main settlement on the island for aid. That means someone needs to go and get the help. There are two adventuring groups, my players and a more seasoned and of higher level NPC adventurers. My group now has a choice, either go for help or stay and keep the sailors safe. Whatever they don’t do the more seasoned adventures will do (and probably better). This is a branching path and determines which of two third acts I use.

act 3

If the players decide to go for help, I will have them do some survival based checks to navigate the island (if they did well enough in act 1 a map may have survived). But the culmination will be a big fight with something nasty before they can get to the aid they need. weather they ambush it or it ambushes them will be determined by how they proceeded to this point.

If the players decide to play bodyguard they will have to post a watch. Over the course of several “days” they will have chances of seeing what is about to happen coming, or losing supplies if they fail too badly. With all of this culminating in a Goblin raid. However, if they players did well enough in act 1 (or helped enough in the “downtime” days) the sailors won’t just be dead weight. They did have a ship after all, and ships have cannons.

Lights Out Progress Report

So, where am I in the development of my game? For a while it has always felt like I am almost there. Almost at the finish line. Then I find something that needs to be fixed, or can easily be improved upon, or was a placeholder that I just got used to. And it keeps getting extended. So where am I?

What I am Doing Now

Right now I am focusing on cleaning up the “level select” mechanic. Initially I had a simple level select as a menu that could be called up in the game scene itself. But I was never completely happy with it. It was small, no room for more buttons, going large jumps of levels took a while. Lots of problems, but a good proof of concept.

Now I have a level select in the main menu before you transition into the game scene. With buttons to go both small jumps and big jumps. Even text to tell you where the earliest uncompleted puzzles are so you can go back and do any you skipped.

Originally I was going to remove the level select from the game scene. But the longer I look at it, the more I think I can just polish it up a bit and keep it. But this might just be not wanting to discard work I have done.

So What is Next?

Next is three things. First is to finalize a design choice I have been fiddling with in the background for a while. Next up is to decide how this game will be distributed. The two main options are: free with ads or small upfront price with a free demo version to get people interested. Based on which of the two I go with I either need to design where the ads go, or figure out what I will strip out for the demo version.

And then I should be almost done… unless I find another thing to do.

Populating My World

Now, the setting for my campaign is a brand new island, but that doesn’t mean there won’t be people here. While it is true there won’t be any natives (at least as far as anyone is aware) plenty of people have an interest in this island. Some for a fresh start. Others to plunder the riches of the dungeons. Some for the mystery of this place. And a few have arrived to safeguard against the potential danger this place represents.

Primary Settlement

The first group my adventuring party is going to encounter is the primary settlement created by the adventures exploring this island. This settlement is split into two sections: the civilian flotilla and the adventure’s stronghold.

The Flotilla

The flotilla is a collection of ships and semi-permeant floating structures a few miles off shore. Viewed from the outside it looks like a small floating city, with almost all the accommodations you would expect from a well established settlement. Blacksmiths, eateries, tailor shops, housing, a town square, even a hospital all exist in this floating city. As for why the civilians live off the island, that’s simple. The Island is dangerous. Seemingly random beasts sometimes appear, and it is safer for the civilians to just not be in harm’s way. Not to mention easier for the adventures to drive off the beasts.

Adventure’s stronghold

The stronghold is the on land coastal settlement of the adventures. While it doesn’t have as many of the accommodations that the flotilla has, it is hardly bare bones. One giant bar services the adventures, with enough partitions that it functions as almost 5-7 bars. Several weapon and armor shops with gear from all over the multiverse. Many so called “general stores” with all the gear an adventure could want. And then you have the administration.

This is a stronghold after all, so those in charge had to fortify it. Several barracks line the impressive outer walls, with enough semi-retired adventures living in them to fight off several Dragons if it came to it. For those adventures not in the full time business of defending the settlement there are boarding houses randomly distributed throughout the settlement… At least they appear random, until you note the even distribution and a few other patterns that guarantee whatever threat the settlement faces: someone will be on scene quickly. Finally we have the administration of the entire settlement, flotilla and stronghold both.


The group primarily in charge of this settlement are “commonly” known as The Insatiable Scholars. This is a group I created for the backstory of an old character I once played. In short they believe Magic has no inherent morality, whether it be a firebolt, the magic to become an undead Lich that feeds on souls, or even healing magic. To them the magic itself is not good or evil, although the consequences of a given use may be. Along with this amoral stance is a generations long quest to learn all there is to know about magic. Understandably, an island connected to all the planes of existence, that seems to spontaneously create dungeons and magic items, presents an irresistible siren’s call to them. With their considerable resources, connections, and raw power they got themselves put in charge of the island’s exploration and investigation.

In game terms this means that the primary contact for my group is going to be a very powerful Wizard. This Wizard is going to be a bit absent minded and quirky, but have a bit more level headed wife to keep him on track. Both are very powerful, but so caught up in administrative work and keeping this place from falling apart that they can’t actually go and investigate as they wish. While they will provide the party with some support, they aren’t going to be able to wave their hands and make problems disappear for the party (the way a level 20 player might).

Everyone Else

This is getting a bit longer than I first thought, so I will give a quick round up of the other factions on the island at the start of the campaign. I may return to these and expand on them in a future post.


Firstly there are at least 3 goblin tribes that disappeared into the Island’s interior and disappeared. Are they dead? Fractured into more tribes? Combined into one goblin empire? No one is quite sure. But it is known that at least some of them live on, as goblin raids and ambushes are not unheard of.


Next up is the “local” fauna. Creatures from all over the multiverse appear to just… show up on the island. They struggle for dominance, some going extinct on the island before more creatures arrive to put everything into chaos again. Almost like the island itself is “borrowing” from other places to create a new ecosystem all its own.

Other Problems

It is speculated that some of the big boogeymen of the D&D world also have outposts on the island. Beings like the Mind Flayers, Cults dedicated to Dragons or Demons, covens of Necromancers or Vampires. Almost nothing is off the table. But by the same token almost nothing is yet written in stone.

Dragons (In my dungeons? more likely than you might think)

The last group I have decided will be part of the setting is a “lauth” of dragons. Long story short a “lauth” is a small group of dragons that have agreed to a common goal, becoming something close to a clan of dragons. These dragons need have nothing in common besides this singular goal, so traditionally good and evil dragons may align together.

In my case the lauth on this island will be comprised of several metallic, chromatic, and even gem dragons. No one is quite sure what their goal is, but tow things are certain. They seem to have the uncanny ability to know everything that is happening on the island at any given time. And they have made a habit of intercepting adventurers returning from a dungeon dive to take the magic item they retrieved. Curiously though, despite the dragon’s ability to simply overpower the adventurers and take what they want, they almost always offer a trade for the item in question.

Returning to Old Problems

As I started working on my game there were one or two things that I came across that I didn’t fully understand. Okay, there were a lot of those. But one or two I got to a “good enough” state and moved on. Well, that came to bite me in the ass recently. Specifically with the Canvas Scaler. Most of my game’s visual elements are UI objects, as such they scale to the camera to always be in a specified relative space on the screen. But how they scale is determined by a multitude of factors, starting with the Canvas Scaler.

I won’t get into the minutia of the Canvas Scaler here. But put simply you can choose to set a maximum size, minimum size, or a scaling style for the UI elements. Took me a while to decide what was best for my project, and I am liable to change it again. Before my recent dive into the Canvas Scaler, some objects would scale strangely and end up off screen. And then I figured out why… and it was dumb.

A common way to organize Unity project game assets is to group them under “empty game objects”. These objects are 1 dimensional points in space with no physics, but are useful for grouping objects to make the scene more manageable. They can also be used to apply a single transform (movement, scaling, rotation) to an entire group. I was using these empty game objects for both purposes. Making my scenes easier to manage and to move objects as a group. Unfortunately, UI elements and normal game objects don’t play nice together. And by grouping UI elements under an empty game object I disconnected their scaling from the Canvas Scaler. I needed a new solution.

Thankfully the solution was staring me in the face. I had already been moving UI elements independent of an empty game object, so I just needed to find a UI element that could stand in for one. And I did. It has a few kinks to work out (mostly from adopting it so late), but it shows promise.

Physical vs Digital Prototyping

Sometimes in design you can’t just jump in and see what works. And for me, that is a bit hard. When people are standing around deciding the “best” way to do something, arguing the merits without seeing the result, I will often just go and do the thing. That way we have something tangible to compare, change, and discuss rather than abstracts. So finding something where that approach is… counterproductive, is a bit like hitting my head on a low beam: startling, annoying, and gets my attention.

So if I can’t just jump in and mess with things, what do I need to do instead? Simply put: I need to make a “prototype”. By which I mean, I need to make a rough draft of what I want the final product to look like. And that leads to three possible ways of doing it.

First is the option I use most often, make a mock up in program. For my game projects that would mean either making a new scene or rearranging an existing scene in Unity. The big advantage is that this is like putting paint on canvas, if it works no further work is needed. The two big downsides are that it can take a lot of time and suffers a lot from “good enough” syndrome, where you have it in place so it is “good enough”.

Next up is to make a mock up outside of the development software. My first instinct would be to make a Power Point “presentation”. This would mostly be an artistic representation of the final product, sometimes with screenshots of the game itself. Upsides are that it is fairly easy to edit a “completed” idea and doing repetitive images is as simple as copy/paste. Downsides are that, again, it can take a while to get things in the positions you want them. And once you have invested that much effort you might say “good enough”.

Finally is the solution I was resistant to trying, but now embrace: paper prototyping. Simply put it is drawing out the ideas on paper. Even if it is just prototyping a part of the UI design, it is so much faster and cheaper to test things in paper. That is the primary advantage of paper prototyping: the speed of being able to try things. So long as you can put aside the idea of needing the prototype to “look good” and simply accept it as “functional” it works wonders. But on the downside, if you need to wow someone with the looks… this isn’t going to do it. But that isn’t the point anyway. The point of paper prototyping is to get lots of ideas out rapidly. Then you can see what works and what doesn’t.

To loop everything back to the start, and my method of “just try it and see if it works”. I think I have come around on the idea of paper prototyping actually fitting that idea. It isn’t just debating ideas, but seeing how they could work. And doing it much faster than most other methods.

Results of Feedback

So I got some feedback from my playtest build. Several bits of feedback where simple bug fixes or graphical mistakes that were easily fixed. But there was one big bit of feedback I didn’t expect: people didn’t know what to do with the game.

Now I had kind of seen this coming. Several times I started making a tutorial level, only to abandon it as the design left the tutorial behind. I figured if I needed it I would get back to it when I was sure of the rest of the design. Well… turns out I need something.

So a simple plan formed: basically make a slideshow explaining the mechanics of the game. Each game mode would have its own collection of images to describe how that mode functioned, and the player could advance through them at their own pace whenever they want. No forced tutorial or “Now you do the thing” hand holding. Know what your doing? Get straight to the puzzles. Want to figure it out yourself? Go for it. Need a hand figuring out the new mechanics? I got you covered. Completely lost? Simple explanation just a click/tap away.

When I was first making my tutorials I was doing “all the things”. Slowly introducing concepts and elements so as to not overwhelm. Showing patterns in the puzzle without going “Here: see this!” But in all that I forgot one of the first design principles I was ever taught: K.I.S.S. Keep It Simple Stupid. And that is what the new design is: simple and too the point.