Procedural Dungeon Toolkit - Dungeon Themed Procedural Generation Toolkit

Quick note regarding the new update, when using Random Model Triggers with the updated Map Editor make sure that there are actually some Models present in the list located inside the Procedural Map Options drop down otherwise the trigger will try to pick a random model from an empty list and cause an error that crashes the generator before the rest of the map has generated. In normal situations the generator would turn on "No Model Mode" automatically if it encountered an empty list but apparently this does not work for the Map Editor's triggers. I've already implemented a quick fix for this error, however by simply making sure that there are models in the list you should have no problems

In any case, if anyone finds a problem or if you have any questions relating to this new update just let me know!

 

Here is an example on how to create "buildings" containing procedurally generated floor layouts by only using features available in the current version! Without changing the prefabs to better looking outside walls and windows the building looks quite funky from the outside so this kind of layout will most likely require some simple hand made pieces for outside facing walls and windows if you want the outside of the building to be good looking.

​

The following layout contains a corridor border on each floor and a center staircase to navigate the whole building. Corridor triggers are used to procedurally generate each floor starting from this center staircase and ending at the border.

​

When the game starts, these triggers create various different floors in the building and they are all contained within the border you have defined. This behavior is due to the "Corridor Priority" toggle being turned off which does not allow corridors to keep growing after they have encountered another corridor tile.

As you can see below, the floors are quite sparse using the current generation parameters. I tried tweaking them a bit to get better results but it seems like the available space is too small to create more interesting layouts. One solution to this problem could be to simply create a bigger layout or simply using room triggers instead.

​

Also, since this layout is using multiple stairwells above each other, we need to remove the Floor Tile that is usually added underneath this Stairs tile if there is another Stairs tile underneath it. This Conditional Removal of an object is all accomplished by adding a custom object using an Empty GameObject and using the below requirements and avoidance settings to detect and remove the correct floor prefabs.

​

As you can see below, this FlrRemover custom object works and removes the floor prefab making the stairs valid although the prefab itself contains some floating legs. Perhaps the avoidance settings could be upgraded to be able to remove certain parts of prefabs as well as entire prefabs or a new stair prefab could be created for this purpose.

​

If you want to try out the above map without having to draw it, here is the map file. Remember that you will have to create the FlrRemover object as I have shown above for the stairs to work properly and you also need to tweak the Procedural Map Options to only generate rooms.

 

Hello everyone, I hope you are all having an easy time using the new features! This is the first report on what is going to be the next update to the asset. For this update I will mostly be waiting for feedback concerning the asset as a whole to add a bunch of improvements that you guys feel would help you use the asset. Also and most importantly, fixes if any bugs are found. I will also be working on adding some actual gameplay to the demo scene with interactive prefabs, puzzles, secrets, objectives and ways to win / lose. The secret passage I have been talking about in a couple of previous posts will tie directly into that.

Feel free to post directly in this thread if you have any new ideas or want improvements to existing features and of course you can also email me at r3eckon@gmail.com

 

New addition to the asset that could be useful in a lot of cases : the ability to make translation settings relative to the orientation of your custom objects. Currently, all translation besides the W parameter of Vector4 translations are absolute, meaning they translate in the same direction regardless of the orientation of the prefab. This is good enough for some objects, but others require translation parameters that will be relative to the orientation of the matched pattern.

Here is an example of this feature in action, also the use case that got me to add this feature due to how time saving it was. The goal is to add a chest in every corner of a room at a 45 degree angle. The below pattern works fine for the Northbound direction.

​

Still assuming that this is the northbound pattern we can then create the right translation parameters to not only push the chest against the wall detected towards the top of the pattern, but also towards the other wall. As always some trial and error is required unless you know the exact size of your prefabs. In this instance I also rotated the prefab itself 45 degrees around the Y axis in inspector because rotations to the prefab are already relative thus will follow the object's orientation, while the "Rotation" parameters of the objects as shown below deliver absolute rotations.

​

Now, this is where the above "Translation Relative to Pattern" toggle comes in. Without it we would now have to create 3 more custom object slots, one for each possible direction that our pattern could be matched. This process can be quite long just to add a single object, as it involves creating the different patterns for each object and also figuring out the individual translation parameters.

​

Instead, we toggle on "Translation Relative to Pattern" and the translation parameters are going to be automatically matched to the orientation of your object. That way, only a single object, pattern and translation parameters are required to create every possible directional variant of the custom object. As you can see below, the chest model is added in every single corner of this room!

​

Without toggling on the relative translations, the chest is only going to be correctly placed in a single corner ( the one that matched in the Northbound direction ) while the others are going to have translation issues as seen below.

​

 

I've just found and fixed a bug related to the Avoidance and Priority feature of the asset. Currently, if a custom object is supposed to remove itself due to having a Priority of 0 and being on the same node as an object in its avoidance list, only a single instance of the custom object is removed from the node. This is due to the way I used to remove objects not finding every instance of the custom objects. While it already works fine for hardcoded objects being removed, the avoidance settings now correctly remove every single instance of a custom object from a node on which it is not supposed to be able to generate due to having it's priority at 0.

You can test this by creating a custom object similar to the torch object, adding it on the walkable tile and translating it towards the detected wall, then try to add the walltorch object to the avoidance list while keeping a priority of 0. The custom object should remove itself from the node and only leave the torch object, however this does not happen consistently. In any case, the fix is already implemented and tested so it will make it to the next update. Anyone who wishes to get the fix sooner can just contact me and I'll send you the edits required to fix this immediately

 

Does anyone know if the minimap gui can be put on a plane? Sort of like how dreadhalls does it as the player goes through the maze the map portion is visible but the rest is not? I want to use this for VR.

 

The minimap does render on an independent plane object that you can place anywhere you want to! I've simply attached that object to the player camera so that it looks like a GUI panel. You could make it entirely independent from the player and put the layout of the current floor on a wall or something as some office buildings and malls do, or just have it rotate to follow where the player is looking at in VR. I think dreadhalls had a more interactive map that only appeared if you had it equipped then looked down towards your hands, which would be possible to accomplish with a bit of extra scripting.

Having the explored portion being visible is also a feature already available with the current minimap script. It's quite basic however so if you've already got the asset and want to customize it, take a look at the "DrawMap.cs" script. It contains all the code currently being used to render the minimap.

 

I've wanted to update the brick texture for a bit now so here is a new one I've worked on today. I think it does pretty nicely and the edges seem to be even more seamless than with the current one. This new texture will most likely replace the demo brick texture in the next version

​

 

The lever prefab is now textured and animated, I've also made a quick toggle script for the levers that will later be customized to open the secret passages and trigger other interactive actions like opening cells.

​

 

Here is a quick video demonstration of the new Lever using scripts to activate the opening and closing animations of the Cell prefabs! Using two detection pattern for the lever custom object each Cell added to the level has a lever to open and close it. As you can see in the video, that lever can be added to two different locations relative to the center tile each depending on the environment around the cell.

​

 

Here is the new fake passage model using the new brick texture, I've got the UV properly matched and it seems to be tiling pretty much perfectly with the wall next to it. I should finally be able to use this model and create the actual secret passages very soon.

​

Also, given that I was working with the brick texture I decided to quickly whip up a single brick model that can be used to imitate a hidden pressure switch to activate traps and other secrets.

​

It fits in pretty nicely over any brick in the texture after a bit of stretching of the object to match the size of the brick it's trying to imitate.

​

 

Here is a very simple book model being used with various textures to fill the bookshelves which makes them look a lot less empty! By creating multiple variations of the bookshelf with different book positions this could be taken to another level and make the bookshelves much more diverse than they currently are. Each variation will also have its item spawners positions moved so that the items do not intersect with the book props. This will also contribute to making each variation a little more unique.

​

This method to diversify bookshelves gives much better results than the blocks of books I tried last time. I'll be using one of those variations to cover up the secret passage's entrance, with a specific book in the bookshelf acting as the toggle for the secret passage to open. I might also make multiple variations of the secret passage covering bookshelf to keep a certain puzzle aspect to the finding of secret passages.

I might also try to create a script that procedurally fills the bookshelves with props but that seems like a relatively ambitious task for the results it will deliver so unless I find a simple way to accomplish this I'll most likely stick with pre made variations of bookshelves.

 

Hey everyone, here is another progress report on the hidden passages. Today I added a new "Secret Corridor" and "Secret Entrance" tile types to the generator. As you can see in the below screenshot, the darker corridor spawning towards the right is this "Secret Corridor". This new type of corridor cannot connect to anything in the main layout, although sometimes the rooms can connect so this might call for a "Secret Room" type. Still, the dark corridors wont connect to the white corridors.

​

The "Secret Entrance" tile type is also used to start this corridor since, as I've said in a couple posts now, these corridors will be hidden behind bookshelves containing a special book that must be toggled to open the passage. The Secret Passage model will be added to the Secret Entrance tile type and a detection pattern will be added to add the special bookshelf in front of the entrance.

​

As seen above, Secret Corridor generation is already added to the PGTrigger system as a new type of trigger that can be added to the maps and models. I also want to make secret corridors appear randomly in regular rooms, most likely making use of the PGTrigger system and Avoidance systems to make sure no regular bookshelves are clipping.

Also, the core map generation algorithm has underwent a bit of cleanup to make it much easier to improve. The large amount of parameter my corridor generation function contained made it quite annoying to do any changes to the definition of the algorithm without having to update many lines of code to match the new definition. A struct now contains all the information the algorithm needs, making it much easier to add new variables to this algorithm without having to fix it in places where the new variables do not matter.

 

Here are the Secret Passage Entrances in action! Right now it all works as soon as you walk into the collider which can be annoying so I'll most likely add a key to press to activate it.

 

I've managed to add the secret passages to random rooms however it's still quite buggy for some reason so I might need to go test the implementation in my generation algorithm tester to see what the problem is. Vertically aligned rooms work fine yet the horizontal ones refuse to work properly. The feature might not work very well with "messy" style rooms either.

​

 

Alright I've finally nailed down the problem with secret passage generation with horizontal rooms, it now appears to work just fine in any direction and even with messy style rooms as you can see below. Still, this feature might not be the best thing to integrate randomly in layouts since secret passages are likely to be used with more important gameplay features or objectives to complete in the game.

​

With this feature completed I will now be working on adding a bunch of new GUI features that I feel would make the asset easier to use. One of the features I have in mind is the ability to add multiple detection patterns and multiple prefabs to single custom objects which will negate the need to create multiple custom object slots for custom objects that could share patterns or prefabs. Also, I'll most likely be adding a bunch of room generation related settings the the "Procedural Map Options" drop down to control max and min room size, messy mode, and the tile types used to generate rooms.

This next update probably wont release for a while so if you have any suggestions, feel free to share them with me so that I can consider adding them to the asset before then

 

Here are the custom object prefab variations that I talked about in the previous post now implemented and working as intended! The Custom Object editor GUI now features a new "+" button used to add a variant slot to the custom object. This variant slot contains a Name that you can change for your own convenience and the actual gameobject slot in which to drag your variation. The float slider is then used to control the frequency at which this variant can replace the main prefab. It is also possible to remove variants using their "-" button.

​

For this example I created a new slot for my planar wall custom object and dragged a new texture to the duplicated prefab to demonstrate the feature. The "WallPlane2" variant will replace the main "WallPlane" prefab about 50% of the time. In this instance the actual wall plane is the brick textured one.

​

As you can see below the wood textured wall now randomly replaces our brick wall in the dungeon! This feature would work better with another brick texture that still tiled correctly however this current setup is only to demonstrate that the feature works as intended.

​

While adding this feature I have also made a small edit to the behavior of the GUI. Changes made to custom object slots or anything else in the main dungeon generator GUI now cause the current scenes to be marked as having unsaved changes pending and will not be saved until you save the current scene. In the current release version the changes are automatically saved as you edit settings however this caused some performance problems with text fields and sliders. This new behavior, aside from being faster is also more natural to the behavior of the Unity GUI.

 

I've just added a small yet useful feature to the custom objects. A new "Random" orientation setting can be used instead of the "Automatic" setting. This orientation randomly picks a single cardinal direction and checks if the object can generate using it. This can be used to randomize objects that make use of the spawn chance even further. It is not equivalent to simply using avoidance to only keep a single version of the object on the node, as self avoidance would prioritize some orientations.

Here is a custom torch object being placed in a corridor using "Automatic" orientation.

​

And here is a very similar corridor using the "Random" orientation setting. Torches are not added on both sides as they did using the "Automatic" orientation and the side on which they are added also varied.

​

 

Hello everyone, here is a quick progress report on what I've been working on this week. I have mostly been improving the SpawnableMob.cs script which handles the AI behavior. Currently, AIs are quite "dumb" and only move to the point they see as the last known player location before stopping entirely until the player walks past them again. To make the bots more interesting, I have implemented two basic yet much needed improvements to their behavior.

The first improvement is the ability for bots to randomly pick a point in the level and walk to it. This point is currently a randomly chosen "Walkable" point in the dungeon, picked when the bot has reached its last target destination. While the chosen points currently can be of any tile type as long as it is not "Empty", I have created an alternate method that can list all tiles of a certain type in the map. This function can be used to direct the bot to a particular tile in the map if unique tile types are placed in certain locations.

The second improvement is the ability for bots to "communicate" the player position. Currently, if you are seen by the AI only this particular bot will move towards and chase the player using the position where they have last seen the player. With the new behavior, as soon as you are seen by a single AI in the level, every single bot knows where you are and starts rushing to this position. This creates a much more realistic and challenging to avoid group of enemies.

I should be back soon with a demonstration video and test build featuring the new AIs in action!

 

Here is a small video demo of the new random AI walk I talked about!

​

Also, here is a link to the related demo build for Windows 64 bit : Download

 

I've just uploaded another quick demonstration of the AI, this one shows off the group chasing of the player after AIs have randomly searched the map a bit. Player is the camera icon located at the bottom right of the scene view.

​

 

This looks like a very interesting asset (which I've just discovered).

However, I find the low ceilings rather claustrophobic. Maybe it's OK on some levels (I know dungeon overlords are often cheapskates), but I'd like to have at least some rooms with much taller ceilings. How hard would that be?

Also, in your demos you seem to be using a standard first-person controller. I'm interested in making a grid- and turn-based roguelike dungeon crawler. Would that present any difficulties? (I have no problem writing code myself; I just don't want to have to fight with how your asset works.)

 

Hello, thanks for your interest in the asset! Short answer is that both of your intended uses are going to work out of the box without problem, but let me expand on both questions ( especially the first one ) so that you can get an idea of how it would actually be done in practice. If this gets too technical or confusing just hit me up with a reply and I'll be happy to try and clear things up for you.

I'll start with the second question since it's the simplest to answer. I see absolutely no potential problem with you creating your own character controller. Procedural Dungeon Toolkit only uses scene objects and instantiates them in procedurally defined location around a grid based level map. Beyond objects that are linked to the generator, it does not interfere with or uses anything else in the scene. Better yet, the asset's main script features a method called "GetNodeCenter" which takes in the X,Y,Z indices of a spot in the level grid and returns the center of this particular node in world coordinates. Creating your script will simply mean using this parameter to place the camera and using keyboard inputs to rotate and move around the level.

Now let me move on to the tall ceiling rooms. To make rooms with higher ceilings you have have a couple methods available. The quickest but "dirty" way is to simply use the "Node Size" parameter. Since the generation of the level happens inside of a grid, this parameter allows you to set the size of all cells in this grid. Increasing the size of each cell ( node ) along the Y axis makes sure that each floor of your level will be placed higher than in my demo scene. At this point you can simply add the ceiling tile much higher at certain points in the level and it will not interfere with other parts of the level as long as each object stays within the bounds of its node. You will also need to scale walls up to avoid creating holes in the layout.

​

However, the "correct" way to accomplish tall ceiling rooms is to create a room template that spans multiple floors and use the procedural object placement / removal system to find and remove floor and ceiling objects that are in between the two floors of this room. By then placing the "Floor / Roof height" parameter to 0 ( which usually offsets each floor in the level grid by 2 times this value to make space for the two tiles ) , you can remove any holes created by removing the floor and ceiling tiles in that room without having to add an extra "cap" object to hide this hole. Here is the type of room this process creates :

​

While both methods can work just as good in many cases, this option is the most customizable since it allows you to edit a specific floor of this room to customize it. Here I've simply removed the corners of the second floor of the room which caused the generator to automatically add walls to block the holes created in the second floor.

​

Sadly there is a lot of z-fighting going on due to how the "Floor / Roof height" parameter is set to 0 which causes the ceiling tiles to be placed inside of the walls I've added in the top corners since this parameter usually follows the size of the ceiling and floor tiles. Using the usual default parameters solves the z-fighting but creates holes in the layout which you have to fill with extra objects, as you can see here :

​

This is the regular setup used in the demo scene. I've outlined the space which the floor and ceiling tiles usually take up. Filling these holes will require some extra procedural objects that can detect and cap these holes, so it's up to you to decide which process creates the best dungeon for your particular needs. If you intend on keeping my stairwells I recommend that you keep the node parameters intact and fill the holes. If you instead just want to have single floor dungeons that feature taller rooms, any method I've described in this post should work just fine.

I hope this reply answered your questions! If you have any more questions or eventually buy the asset and are having trouble setting up these rooms, just let me know and I'll help you figure things out

 

I've been playing around with the tall ceiling rooms and added a stair model alongside 2 tile types to add raised areas. Here is a screenshot of this type of room!

​

I think it looks pretty good, although the stairs model's texture is a bit messed up and the rest of the layout is broken due to the floor / ceiling setup. That setup would call for some slightly modified alternate versions of the level generation algorithm to all work properly, mostly since the current "staircase" generation code is still suited for the original stairwell prefab.

 

Since next version brings a new feature to the custom object system, I want to warn you guys in advance about potential issues this may cause with your custom object lists. The system should automatically update the custom object list with the necessary variables to make it work, however there is a risk that it could end up corrupting the entire list and deleting your object slots. This happened to my project a couple times throughout adding the alternate "Variations" slots and running into errors. Since I am not sure if the errors were responsible for corrupting the list or if the fact that the variables contained within that list being changed was what caused the problem, I want to make sure you guys to not lose any work progress due to this kind of thing happening.

Therefore, before updating to the next version, please make sure to back up your object list files and keep these backups in a location other than the unity project folder. To do this, simply copy the folder "Resources/PDTFiles" to a backup location. This will also back up your current generator settings, item list, saved map files or any room models in the folder if you have used the "Archive for Build" buttons. To restore this setup in the event that something goes wrong, simply replace the corrupted folder with your backup while Unity is not running.

To make this process easier in case future updates to the custom object system do end up corrupting the persistent data in use by the asset, I will be adding buttons to easily save and load the persistent data folder without having to go through the trouble of moving it manually. Beyond this new set of buttons, I should be done adding stuff to this next version and will be tackling the documentation needed for the update in the coming days meaning next update will finally be ready to release

 

Asset is currently on sale at 30% off for until the 11th

 

Just added the custom object list loading and saving feature I talked about in a previous post. This system will allow you to quickly switch between many configurations of the generator and potentially share your configurations with others!

​

The feature is straightforward, simply use the correct button to save or load object list files. Upon loading a new list using this button, a file named "CustomObjectListOLD.asset" is created to act as a back up of the previous list, which you can simply load back into the generator in case you accidentally loaded a new one before saving.

Also, I've finished writing up the update to the usage manual for next version. Besides some bug testing and the creation of an alternate demo scene showcasing the new style of level I showcased in previous posts, I should now actually be done with this next update. Speaking of the new layout style, here is a demo build showing off this exact layout! I've reworked the stair prefab a little bit and added wooden tops to each stair. You can download it here!

 

Even though I said I was done with the usage manual I think I'll take some time to write up a new section explaining the process behind archiving and loading different whole configurations of the generator. While making some finishing touches I decided to add the list saving / loading buttons to the item lists, making the saving of generator setups even easier and smooth a process.

Here is that process, which will be used to save and load entire setups of the generator. First, Map Options, Node Options, Performance Options and Hardcoded Object Slots are all using serialized variables meaning their settings will simply stay saved with your scene.

Next, Procedural Map Options, Custom Object List and Custom Item List files are all using persistent data meaning they have to be saved / loaded using their respective buttons. While you can already do it for Procedural Map Options, next version will add the buttons for the other two lists.

Finally, each Model or Map files needed for your levels to generate have to be loaded back into the generator. Since models and map files are already being saved to external files using their editors, the process will simply involve grabbing these files from their save location and including it with the aforementioned data. The "ModelList" file will recreate itself automatically as you add the model files back into the generator.

Basically, a folder containing every piece of data needed to recreate the generator's setup is created. In this folder save all of the persistent data needed to run the generator, along with a copy of your scene file and any map or model files needed. If the purpose behind this setup archiving is to share your setup, it would be smart to add instructions on how to get any extra prefabs that might not be included by default with the asset. Do not redistribute assets, simply give a link to where the prefabs can be obtained.

I may very well add a single "Archive Setup" and "Load Setup" button combo in another future version that could export all of the needed data automatically to a select folder, however the current way of going about things is fluid enough that next version wont really need it since the annoying part of the current release version, where you have to manually move files and restart the editor for changes to take effect, has been dealt with using the new load buttons.

Using this new process, I've been able to switch between vastly different setups in about a minute. The new part of the guide explaining this process entirely will be demoing the tall ceiling room I've talked about, which has already been archived into a complete setup using the technique described in this post

 

Version 1.24 is now live Make sure to back up the "Resources/Saved Data" folder before updating to make sure your current setups are safe in case the updated version of the CustomObject.cs class causes trouble. Once again, there should really not be any problems but I recommend you do it in case something does go wrong.

 

Hello everyone, I hope you all had a smooth experience so far with the new version! If you encounter any problems please let me know so that I can fix them as soon as possible.

In any case, I've already started working on stuff for the next update which will mostly consist of entirely new prefabs like the basic sword shown below as well as new variants to existing models and textures to use with the variant system. Gameplay related features are also being added to the AdvancedFPSControl.cs script, so far I've added basic item equipping used to holster or equip the sword prefab. I'll most likely also work on a few more interactive / animated prefabs to add to the scene as well.

​

As always, if you have any suggestions or feature requests, feel free to let me know

 

Here is a textured shield prefab to go with the sword! I've also experimented with adding a reflection probe to the scene to improve metallic objects. Although fully dynamic probe kills the framerate, having an OnAwake probe make a quick reflection map around the spawn still delivers some nice reflection with metallic materials while dynamically reflected lights still make the reflections look interactive without making the game unplayable.

 

Hi, i have a problem with the model editor, the custom rooms did not spawn. i looked the tutorial and the manual but even not spawn the rooms

 

Hello, I'm sorry you are having problems with the asset. First thing to make sure of when using room templates is that your dungeon canvas settings ( Map Options drop down ) creates a big enough area to generate your level. If your rooms features second or even third floors, you must make sure that the "Max Levels" setting is set to something like 3 or even 5 levels. Also, under Procedural Map Options, make sure that the "Model" parameter is set to something like .1 to force some models to generate.

If it still isnt working, the room model itself might have some problems. Make sure you have correctly selected the entrance door of your room model as being the Origin before saving it, otherwise the generator wont know how to move your template to correctly place the entrance next to the point where this room has been added. If you've added tile types to the "Type To Avoid" list, remove them, save the model and try again.

If you are still having problems after checking the things I have mentioned, it would be immensely helpful if you could send me your full generator setup that's causing problems. If you don't want to share your full setup, I'd only need the scene file, the Procedural Map Option settings file and any room model files. The process used to archive or load generator setups is described in Part 11 starting at Page 108. Once you've got all the files required to recreate your setup, put them in an archived folder ( zip or rar, any format will do ) and give me a download link here ( you can also send it to my email address r3eckon@gmail.com ).

I'll then try out your setup and see if I can find what's causing problems.

 

Hello all, here is another quick update on what I've been working on last couple days. As I mentioned earlier, I have been working on a couple new prefabs to add to the asset, mainly models that are to be used as Unique pickupable items that can then be equipped by the player. So far, I've got the Sword ready to go and I'll spend a couple more days on the "Oil Lamp" prefab. This prefab will make use of the PlayerInventory script to make it interactive, so that the emission rate of particle is going to be tied to the current amount of oil.

The equipping has already been programmed, however this script will most likely not be controlled through the GUI for it's first released version. This script also contains the more complex FPS movements I've implemented so far, such as leaning both sides and crouching. Crouching correctly interacts with the default FPS controller script and slows down the player speed.

Also, I may be able to add a visual solution to editing the translation parameters of objects. Basically, the idea is to use the current node parameters to create a cube in editor mode, either using drawn lines or an actual mesh with inverted faces to only show the inside of the area created by each node. This object is called the "Sample Node" and will then be used to easily apply translation parameters to your objects. What I have in mind is that when you enter this visual translation mode for a custom object, that object will be temporarily childed to the Sample Node and use the current translation parameters as the Local Translation of the object relative to its now parent Sample Node. Then, by moving the object relative to the Sample Node, you can visualize where the object will be placed relative to a level node and easily make changes to an object's position without having to go through guessing to correctly place objects. Upon exiting Visual Translation mode, you could either Apply or Cancel the new translation parameters. I feel like this feature could make it much easier to place objects around the level since it removes the guessing game when dealing with objects you don't know the exact size of.

Once again, if you have any feature ideas or requests for next version, be sure to let me know and I'll consider adding them in the next version

 

Here is the Visual Translation editor I talked about in the previous post! The "Use Visual Translation Editor" button shown below creates a bunch of inward facing planes building an area the size of a level node inside the editor, making it easy to visualize and place objects precisely within this area.

​

The object to on which you pressed this button is then placed within this area as it would spawn on a matching node.

​

The W parameter, which is a direction relative to the north of the Requirements Pattern of the object, is projected towards -Z in this editor since objects face in this direction by default. We can edit any object that way, here is the regular torch.

​

Below you can see both objects in the actual dungeon, with the shield being in between nodes just as it was appearing in the editor.

​

Overall this was pretty simply to implement and could be rather useful to remove a bit of the guessing that comes with placing more weirdly shaped objects around the level. I still have a couple things to work on to get this feature fully working and when I'm done I'll most likely be back with a video demonstration of this new feature.

 

Here is a little something I've created to help using the new translation editor. This simple grid shader allows us to set the amount of cells within the texture, the thickness of the grid lines as well as the color of those lines. It's nothing special or complicated and many shaders like it exist already but I'll still be including it with the Visual Translation Editor since it could be very handy.

​

​

 

Something I've realized while creating the visual translation editor is that the "Translation Relative to Pattern" toggle can, with a simple fix, negate the need to have the W parameter of Vector4 translations. There was a bug with the Z parameter of Vector3 translations where the pattern relative versions of this translation did not produce the same result as using the W parameter with the Vector4, while in hindsight they should have since the W translation pushes towards the -Z axis by default just like how the Visual Translation Editor showed objects resting against walls.

Now that this is fixed, applying a translation on the Z axis and using the Translation Relative to Pattern feature will have the exact same effect as using a W translation without the Translation Relative to Pattern feature. In my mind it makes more sense to either have all parameters relative to the pattern or none of them, since absolute translations are rarely used in the context of the asset, except perhaps for random translation parameters.

Anyhow, with the Visual Translation Editor being already useful to me in debugging problems with the asset by allowing me to see visually what's happening with objects I have high hopes that you guys are going to like this new feature

 

Last quick update before I post the video. Existing Vector4 translations are now safe to import and will automatically translate into appropriate Vector3 translations with the "Translation Relative to Pattern" option toggled on upon the object being opened in the editor. I got initially scared by the idea that refactoring and removing existing variables from scripts would break your data, however thanks to a godsend attribute and a bit of manual translation of vector parameters it all works out great.

Also, I finally made the main GUI remember its state. This basically removes the need to click through multiple buttons all over again just because you click on something else inside Unity. It's honestly been on my list of stuff to add to the asset for a while now as the GUI resetting was quite annoying. This makes it much easier to use the Visual Translation Editor as well, as you guys will see once I'm done editing the video demonstration of this new feature!

 

Here is the video demonstration of the new Visual Translation Editor being used to quickly move two types of torches!

 

Alright, rotations have been implemented and tested using the new Visual Translation Editor. After a bit of fixing of the "Rotation Relative to Pattern" toggle not properly transforming the rotation parameters, objects can now be easily rotated using the new editor and using relative rotation will mean that the rotation settings follow the pattern correctly. I originally intended the new editor to be only used for translations since rotation parameters applied directly to a prefab were already being transformed to be relative to a matched pattern. Meaning, by simply rotating the actual prefab itself, the applied rotation could already be used for relative rotation.

I'm a bit perplexed on how to go about dealing with pre-applied rotations to prefabs. Currently, this rotation setting is kept intact since many object just used this kind of rotation to be correctly placed in dungeons. However, using the new system this old way of going about things can get quite confusing, as the rotation parameter of the custom object might not be the same as the actual prefab's default rotation. I'll be back to confirm how I dealt with this once it's done, however I'm pretty sure that the best solution is to just discard prefab rotation settings and apply custom object rotation to the prefab like translations are working right now. Sadly this might break some object rotations.

In any case, this new editor will be renamed to "Visual Transform Editor" to go along with the idea that this editor can do more than edit translation parameters. Also, if I don't think of anything more to add to the asset before the end of this week, I'll most likely be starting on the Visual Transform Editor chapter for the Usage Manual so that this new update can release as soon as possible!

 

Today I took a bit of time to package the grid shader I've created into a free standalone asset containing the shader file and a ready material to drop on any objects you might want to render a grid on. The shader will still be included natively with the asset, I just wanted to make a standalone version of it much like I did with the item spawner. Until this new package validates, you can find all the files needed to use this shader on the github repository along with instructions on how it is used.

Also, on the matter I was still unsure about in the last post, I've went ahead and made sure the rotations are now discarded before objects are used by the generator. This means that only the rotation parameter of your custom objects will influence the rotation of instantiated clones used to build levels, which may break a few rotations at worst. Fixing this will simply involve setting the rotation of the objects using the new Visual Transform Editor to make sure they are facing in the right direction

 

Alright so this week I had a look at various problems relating to the Hardcoded objects in dealing with the new way of applying translation parameters. Since many of those prefabs used the W parameter of Vector4 translations, I had to add the "Translation Relative Toggle" to a couple of them to make sure that they still worked. I'm not sure I'll be able to implement the same translation conversion feature that automatically turns old Vector4 translation into compatible Vector3 translations with relative translation toggled on. So if you changed translation parameters of hardcoded objects, they will most likely be reset by the next update. However, on the plus side, you will now be able to customize some hardcoded slots quite a bit more. Objects that originally used the Vector3 translation have not been changed.

To be honest the hardcoded object slots have become rather obsolete ever since the original version of the asset which only contained this type of object. Since the custom objects are much more powerful and customizable than the hardcoded slots I see little reasons to keep them besides for the fact that they are used extensively with the original demo scene, but even then a bunch of custom objects could easily replace each hardcoded object in this scene. I'll most likely not be removing them for now since some of you might still be using them, but a future update may change that.

 

Next version has just been sent for validation and should be releasing soon enough The usage manual has also been updated with information relating to the new Visual Transform Editor feature, be sure to check that out to learn all about how this feature works! Note that the price for new users will be increased to 45$.

 

Here are the latest updates I've made to the tile map generation algorithm! Since the tall ceiling style layouts turn out to be pretty nice the generation algorithm needed a couple things to ensure those types of layouts can be properly dealt with. I've also implemented multi floor rendering for the animated previews which I think looks pretty neat!

​

One of the new feature that's useful for the original style of levels is the corridor self avoidance. This feature is most likely going to be a simple new toggle located in the Procedural Map Options drop down. It makes it so that corridors are not allowed to connect to existing corridors. Paired with an increased branching and the deadend cleaning, this new feature can create quite long and winding paths.

​

 

Version 1.25 has released yesterday! Make sure to back up your configuration before updating in case there are unforeseen problems with translations. You may also want to read the usage manual to learn all about the new Visual Transform Editor feature

 

I've recently been working on staircases for the tall ceiling layout and here is the first one I've come up with! It's basically just a 2x2 set of tile types added vertically, one of which is the Stairs type and the rest of them are of Staircase type. It then continues the corridor in whatever direction the staircase was added.

​

These new stairs can also be found and removed by the updated deadend removal algorithms, unlike the original staircases. I've already went ahead and added all the updates to the generation algorithm to the asset so they are already up and running in the asset!

​

Below you can also see that I've implemented the multi floor rendering for the in game minimap, which works really nicely with this type of level, however it's still somewhat buggy with the default demo scene's node settings.

​

The new parameters have also already been added to the GUI, as you can see here. The Using Planar Node Settings toggle makes sure that corridors will check above and below for existing tiles before being applied, which creates levels valid with the tall ceiling layout's node settings ( the "Planar" node settings ). There is also the Corridor Connections silder which controls how often new corridors are allowed to connect to existing corridors, using 1 or 0 to allow or disallow connections completely.

​

Going forward be working on adding new staircase styles, adding the tall ceiling feature to random rooms and also work on a few other improvements to the level generation algorithm before resuming the work I was doing on adding more prefabs before releasing the update containing these new parameters. Until then, if you wanna try generating and exploring a few of those new layouts, here is a demo build

 

Last couple days I got a bit more work done on the map generation algorithm that does not really deserve a video or a bunch of screenshot to show off.

First of all, I've implemented Immediate Execution for post generation triggers. This feature makes it possible to mark an added PGTrigger as needing to be executed right away in the generation process instead of waiting for the main generation to be finished. This in turn makes it possible for those triggers to then add more triggers, paving the way for level areas that are made up of a lot of linked rooms like some others dungeon generators can create. Old model files are going to be handled automatically to make sure your existing models are compatible with this new system.

Second is the new Parameter Scaling feature. Like the first addition to the algorithm, this feature is trying to pave the way towards having many styles of level progression be based upon the distance you are from the spawn floor. Basically, depending on the scaling style chosen, being 1 floor underneath the spawn floor can cause the Branching parameter to increase or decrease, making different floors look drastically different from each others. Some of the currently implemented scaling styles include Downwards ( Scaling higher as you go underneath the spawn floor ), Upwards ( The opposite of downwards ), Middle Out ( Scaling higher as you move away from spawn floor ) and Out Middle ( The opposite of Middle Out ). Currently, parameters are all scaled using the same scaling factor and style, however I want to make it so that each generation parameter can have its own Parameter Scaling settings because some parameters can fight each other and negate changes. For instance, increasing both the Branching and Ending parameters at the same time is basically useless.

Finally, to work with the previous feature, Spawn Point Selection is going to be added to the GUI as a simple way to select on which floor the spawn should be added. Currently, the spawn tile is automatically added as close as possible to the middle of the level, both in floor height and level width / length. Some simple new parameters are going to be added to the Map Options drop down that are going to be used to select from various automatically calculated spawn points as well as a manually input point within the level canvas. As I said, this is supposed to work hand in hand with the Parameter Scaling feature, so that you can create a level who's spawn is on the top most floor and have the level get bigger and more messy as you go further down the dungeon. This simple feature tested flawlessly with the animated map generation renderer so all that remains to be done is to add it to the asset's GUI.

Before ending this post, I'd like to mention that my second free asset, Simple Grid Shader, has recently been released to the asset store. It is the customizable grid shader used with the Visual Transform Editor extracted as another independent asset, like the item spawner asset. Be sure to check it out if you ever feel like you need a quick and easy way to render custom grids

 

Here is a sneak peek screenshot showing off the tile map view of the new types of staircases I wanted to implement! They are basically T and 4 way junctions of stairs heading towards the same level up or down direction. Sadly while they are quite rare to fully generate intact since most of the times the existing layout forces these junctions to instead creates "turns", however I feel like even those can quite a lot to levels.

​

Above there are some areas that appear like they should feature corridors are not showing up because of the old multifloor rendering method only showing one extra floor in each direction. For fun I had a go at rendering every floor using a tiny update to the method, and here is what the entire level looks like!

​

As you can see it is actually much bigger than it looks using the previous method. Note that anything that's darkened might not be 100% accurate to what the level looks like on that floor since multiple floors are being rendered on that layer. I've yet to implement all those new changes in the asset so far since I wont be doing that until I'm certain I'm done adding stuff to the algorithm.

In any case, I should be back soon to report on new changes once they are implemented, which should not take very long since I have not encountered any weird or hard to solve bugs with these new features so far!

 

Another feature that's been a part of the generator for a while without seeing much use was the Max Length and its related Current Count parameters, used to set a maximum length to corridors. To work with this feature, I have added a simple method to set the corridor that's the furthest away from the spawn point as a different tile type, the Ending type, shown as an orange tile. It could potentially be used to place a gameplay trigger to move on to a harder level.

​

As you can see above, while other deadend corridors have been trimmed, the ending tile is located at the end of a long "useless" corridor to make sure that this tile is located as far away as possible from the spawn (Darkened green tile). After noticing how the ending was located after a Boss Room model by coincidence, I saw an opportunity to implement two new parameters used to offset the Max Length and Current Count variables and force this behavior since it could be useful gameplay wise to force the ending to be located after a boss room.

Basically, since the Current Count variable controls where the furthest tile is located, manually increasing this value beyond the Max Length before creating a corridor will force the Ending tile to be located where this new corridor is being created. Since regular corridors don't go above the Max Length value in size before stopping, we must also increase the Max Length to make sure the new corridor can grow out a bit and this process has now ensured that the ending tile is located after a boss room.

Here is an example image showing the same iteration of the generator ( same seed ) twice, except the map on the right forces the ending to be located after the boss room, which also changes the map a bit due to the order of random rolls being changed.

​

Although the map on the left looks like the ending tile was further away, the fact that the Current Count parameter is manually increased tricked the algorithm into thinking the corridor was longer, thus forcing the ending to be located after the boss room! Like most parameters used to generate maps, the two new parameters can also work with floor based scaling as a way to make much longer corridors without having to increase the branching parameter.

To work with this new feature I intend on updating the Model system to allow for each model to have individual parameters much like items. Particularly the "Type" parameter to easily identify models, the Spawn Chance slider to control how often a model appears and is Unique toggle to create unique models. I also have in mind a new "is Required" toggle that could force the generator to find a map that features at least one model on which this parameter is toggled on.

Once again I'll be back soon with more information on new changes once they have been implemented and tested in the map generation algorithm

 

Here is a quick screenshot of a map generated using some of the new features I talked about in the previous post! I've actually changed one thing about the Uniqueness feature allowing direct control over how many instances of a particular model can be applied on a map. This parameter is dynamically decreased as models of a particular type are applied to the map until it reaches 0 and prevents the generator from using this model. A setting of -1 can be used to tell the generator not to use this parameter and thus making it possible to add as many iterations of that model as possible. Obviously, a setting of 1 can also be used to create unique room models like with a regular Unique toggle.

​

To create the above map I've also been reworking and then playing with the Max Length and Current Count offsets to see what delivers best results. The fact that I've increased the Max Length offset by quite a bit made it possible for corridors spawning from a model's corridor trigger to eventually add other models that also add further corridor triggers. While this demonstration app only features 4 model types which makes it a bit repetitive, I totally see kind of layout style being used to create levels with a better feeling progression with more room styles being used one after the other. By the way, it may be hard to notice but the "Ending" tile is present on the right side of this level, once again after a bunch of those corridor triggers that can only be accessed by progressing through rooms.