Dungeon design templates

Inspiration taken from Squidi Net unfortunately I couldn’t find anywhere to post on his/her site about using their material as a base.

I’ve taken a short period of time away from Spell management and looked towards creating dungeons, which are dealt with specifically in release Alpha 0.0.11 and what I’ve devised is a template solution that allows the modder to broadly specify the kind(s) of dungeon(s) they want in the game.

The idea behind providing a template to generate a dungeon is very simple…I want anyone to have the ability to create/modify my game so they get a different experience every time they play.

For example there may be a single 10 level deep dungeon set in a castle or sewer environment. Or there could be a single overworld with a town and many dungeons littered around the “world” waiting to be explored.

  • Name:Dungeon of Decay
  • Type:Dungeon|<tileset name>
  • Parent:yes|no
  • Child:no|yes[<name of parent>|<level of parent to be accessed from>]
  • Restrictions:type<setting>|type<setting>
  • Season:summer
  • Time:18:00
  • Difficulty:Easy
  • Depth:10
  • Genus:goblin|orc
  • Nature:wildlife|insects
  • Boss: Manslayer|WargMaster| Arch Druid
  • Prize:orb of viewing|ring of greatness
  • Win:kill [boss]
  • Level:0|<type>|<size>

I’ve distilled generating a complete dungeon down to a single set of parameters. The combination of different settings should provide for a wide range of dungeons to be generated.

There now follows a brief explanation of the parameters:


This is a human readable description that is used to identify the dungeon.


This provides the basic instructions to build the dungeon including terrain types, room types, corridors, tileset.

Choose from…

  • Dungeon – structured layout to rooms and corridors.
  • Overland – a natural environment constructed to look natural
  • Cave – an underground twisty natural looking environment


This parameter allows you to link dungeons together, thus providing seemingly more depth, flexibility and enrichment to the game player.


This parameter identifies if this dungeon is “a child” dungeon, in other words it provides a link back to the dungeon that the player was in when he/she accessed this dungeon. A child dungeon cannot spawn other children.


This allows you to place restrictions on entering a dungeon, for example only the Adept class or Troll race can access the dungeon, it can provide some interesting game replay options.

Choose from…

  • Class – <type>|<type>
  • Race – <type>|<type>
  • Level – number (minimum level to access the dungeon)
  • Time – <start>|<finish> (defines when a dungeon can be accessed)


This provides both flavour and extra mechanics to the game, for example if winter is chosen then any “overland” journey has a higher chance of causing frostbite and cold based spells will be more efficient and effective.

Choose from…

  • Summer – heat
  • Winter – cold
  • Autumn – wind
  • Spring – earth


This provides both flavour and extra game mechanics, such as monsters only appearing at night or game events triggering at midday. Holy spells being more effective during the day.

Choose from…

00:00 – 23:59


This provides a measure when generating monsters, objects, dungeon rooms. For example if the setting was “easy” then you wouldn’t expect to meet any “elite” monsters in the dungeon.

Choose from….

  • tutorial – for training purposes only.
  • easy – low level monsters, common objects, >95% dungeon rooms connected.
  • medium – to be determined
  • difficult – to be determined
  • hard* – only available once you’ve completed the dungeon on difficult level.
  • insane* – only available once you’ve completed the dungeon on hard level.

*note these levels are provided as in-game options assuming you’ve beaten the dungeon.


How many dungeon levels are included in this dungeon. Obviously the larger the number the more levels there are the more variety within the game.

Choose from…

  • 3 – 99
  • * = random number chosen from 5 -> 25


This provides the range or type of monsters you can expect to inhabit the dungeon the more entries the more varied the monster races will be faced by the player. This parameter controls the non-critter monsters.

Choose from…

  • Orc
  • Goblin
  • Dwarf
  • Elf
  • Human


This provides the range of critter-monsters present in the dungeon, typically these will inhabit the upper reaches more so than the lower levels of the dungeon.

Choose from….

  • Insects
  • Cats
  • Nature
  • Mammals
  • Spiders


This single monster represents who the player has to kill in order to win the “dungeon” or even the entire game. This mob will should be hand crafted and be made available to the game outside of this template.


This is the prize dropped upon killing the boss, which can be used as a game winning condition, otherwise it becomes part of the players inventory. This should be a hand crafted object and stored outside of this template.


This provides the “win” condition to beat the dungeon, this could be as simple as killing the boss or something more complicated!

Choose from….

  • kill [boss name]


This parameter is used to define specific dungeon levels, for example dungeon level 0 could be defined as a town, and consists of pre-made types only, it is also used to specify the number of rooms in the level.

Choose from…

  • town (fixed size of small)
  • graveyard
  • forest
  • tiny – 4 -> 8
  • small – 9 -> 13
  • medium – 14 -> 25
  • large – 26 -> 40
This entry was posted in design, dungeon, pcg and tagged . Bookmark the permalink.

5 Responses to Dungeon design templates

  1. Lost Dragon says:

    I remember seeing themes in your code and thinking that it was a neat idea to make random dungeons have a cohesive feel to them (at least that is what I thought the themes were doing).

    If you’re interested, I finally set up a website for my project.


    I’m not as far along as you are. I got my line of sight function working finally and now I’m trying to figure out how to handle objects in the map. I can draw them but when the player goes to use them all my map tells me is that the objects are on a certain layer, they have a certain graphic, and they have a specific x,y coordinate.

    So basically if I put a book object on the floor the code would have to check which x,y space it was occupying so it’d know what book text to display – or it’d have to check which graphic it was using.. But then I’d have to make a different graphic for every book. Both of those options are kludges.

    I wish I knew how other games handled it. Most of the RPG projects I look at halt after they get into doing the “hard” part. Boo.

    I’ve been using the Tiled map editor up to this point (testing basically) but now I think I may have to make my own so it can have integrated object and npc editors. That’s some extra development I had hoped to avoid.

    Maybe it won’t be as bad as I think.

    Keep up the good work. 🙂

    • devonps says:

      You are correct my original dungeon themes were designed to provide a consistent idea, but after reading up on the dungeon template idea from Squidi.net I’ve decided I can embed my theme into a template.

      Had a look at your website and I like it – keep up the good work 🙂 – if you want we can swap links, let me know?

      Now on to the main topic of your reply….

      My original approach was to maintain a 2d-array for the dungeon and a separate array of the objects with location co-ordinates, for me, this has started to get a bit messy and (cpu) time consuming.

      My new idea, which will be incorporated into my planned future release – where I rework my dungeon creation from the ground up – will incorporate the following:

      dungeon(xlocation, ylocation).HasObject

      Essentially I will store the object id in this element and when I’m passing through my dungeon drawing routine it is a simple matter to place the corresponding object at the current x/y dungeon location.

      I’m hoping this will cut down on the number of lines of code I need to maintain and more importantly the number of in-memory arrays I’ll be using, plus saving the state of the dungeon should be quite trivial.

      A limitation of this approach is that you can’t store multiple objects in the same location but by tweaking the “HasObject” element from integer to string we can hold as many objects as you like.

      My previous example would now store objects as:
      dungeon(xlocation, ylocation).HasObject = “1|101|44|23|987”. As you can see the objects are stored in a delimited string and it’s quite easy to pass these through a couple of routines to display the object “on top” or “the biggest first”.

      I’m also thinking of expanding this approach to store the location of my monsters, for example dungeon(xlocation, ylocation).HasMonster.

  2. Lost Dragon says:

    Sure, we can exchange links. I’ll do that later tonight.

    I read what you wrote and it’s pretty interesting.

    I was initially thinking that my map object layer could store an object ID (instead of a tile graphic #).

    So in my draw routine I would have a function call that returned a sprite # from an object ID# and then the draw function would continue on and draw the object like any other tile. My object layer would be an array of comma separated values full of object IDs.

    From there any time the user wanted to look at an object, touch it, move it, etc. I could just get the object ID# and then I’d know what it was, where it was, what it did, and whatever other properties I had in the object UDT.

    I am not sure what I would do if more than one object occupied the same square though. I guess I could sort them by gold value.

    I could just disallow object stacking altogether too. I have played tile games where a lot of objects were stacked on each other and it is annoying to get to what you want. I’d rather have a pile of objects represented by a “pile of objects” graphic and then be presented with a menu to choose which one I wanted than have to manually click and drag each object on the screen. Ultima 6 had that problem. In U6 objects would stack up and if you wanted something off the bottom of the pile, you had to get everything on top first. Ugh!

    All of the maps I’m doing for my game will be pregenerated by an editor so I don’t have to deal with randomly generating dungeons, but I do have to make the editor itself.

  3. Lost Dragon says:

    I put a link up to your site. If you’d like to link to mine just use


    The domain will always point to the right place. Thanks!

  4. devonps says:

    I’ve added a link to your site 🙂

    I think your idea of a “menu” of objects to pick up has some merit and you should explore it further. For my game objects do not play a big part so I’ve not allowed objects to stack.

    For pre-generated levels, I used a quick method of using a text file that contained my dungeon level layout and then read in each part of that file and translated it into graphic tiles accordingly.

    I found the text file approach to be quick and dirty and it helped to keep my thoughts honest, i.e. centred on what really mattered.

    Good luck.

Comments are closed.