DunGen - Procedural Dungeon Generation

Thanks for your reply Billy, but you must have a very old version of DunGen. The post you referenced is from August 2014, over a year ago. That line of code doesn't exist any more, so there's no way for me to implement your suggested solution. I'm running DunGen version 2.6.0, which was released back on June 30, 2015.

@AegonGames - is this something others are reporting (incorrect number of side paths, as I mentioned above), when using your most recent version?

 

Actually, I'm reviewing the documentation and realizing now that Branch Count is not actually the number of branches in the dungeon layout, but rather a limit of the number of branches from any given tile. Am I reading that correctly?

If so, then how can I ensure that I get exactly 3 branches in my layout?

 

I am using DunGen v2.6.0 (same as you). The line of code is still in there, though modified slightly and located on a different line than the old post suggested.. Use 'Find' to locate the only line of code that contains the following..

branchCount = Mathf

..and you'll see what I'm talking about. Try commenting out that line of code, and see what happens.

 

ok, maybe disregard that... I just opened up my project, and double-checked... (It was generating 8 to 12 branches when I first 'fixed' this, but now it's only generating 2 to 3) I suppose it's possible that this commented line didn't fix the problem afterall. hrm

 

Since DunGen automatically generates a room's bounding box around all renderers and colliders in the prefab, having objects within the prefab but outside the bounds of the room isn't possible. One way around this could be to place all of your decorative objects on a specific layer, then modify the CalculateObjectBounds function in "DunGen/Code/Utility/UnityUtil.cs" to not include objects on that layer.

You could also place a sort of spawner object (like the included Random Prefab prop) which doesn't have a mesh or collider, but will spawn an object into the scene once the dungeon is generated.

Yeah, you're reading that correctly. Unfortunately, with the way DunGen generates layouts one room at a time, dungeon-wide constraints like that are tricky (and pretty much impossible to guarantee). Branch paths in DunGen were only ever meant to add a bit of interest to an otherwise linear path

 

Thanks for replying! Could you explain this method in more detail?

 

Thanks for your reply. If branch paths aren't the answer, how would you recommend creating a level with DunGen that has (exactly) 3 different goal end caps? Is this simply not possible with the current version?

 

Hello AegonGames,

i have a few questions about DunGen Generator,

1. Is it possible terrains in Dungen use to gernerate some Dungens ?

2. It is possible before entering a Dungen Dungen is a random generated further when you reach the end of Dungen levels and going for example through a teleporter to the next decisions that then a randomly generated applications created ?

I hope you understand the question

I want a tower build with Dungen's from one lvl to the next lv up or to go down and that's just important to be dungens randomly generated so that nothing looks the same

 

The issue with placing objects outside of a tile (while still being part of the tile prefab) is that those objects would be used when automatically generating the tile's bounding box.

If you were to instead place a "Random Prefab" prop script on an empty GameObject, the chosen prefab would be placed into the scene after the dungeon has been generated and the placed object wouldn't count towards the tile's bounding box.

It's a little clumsy but I suppose you could re-generate a dungeon if it doesn't match what you want. That might not be too bad if you want at least 3 branches, but re-generating until you get exactly 3 branches is likely going to take too long.

1. I don't think you can rotate terrains in Unity, so you wouldn't be able to use them with DunGen unless you also disallow rotation on the tile itself.

2. You'd have to program that logic yourself, there's nothing built in to DunGen to do that for you. It's easy enough to have some sort of interactable object like a door at the end of a dungeon which will clear thee current dungeon and build a new one for the next floor.

 

@AegonGames - thanks for your reply. Is this kind of functionality likely to be added in the near future? Do you feel that it would be worthwhile to have the ability to specify the number of branch paths?

Or should I just start hacking something together myself?

 

I would love to see an option where we could set the actual number of branches. I think I assumed the same as others, that it was what we were setting. I was more playing/testing than actually building though, so when it didn't work as I expected I kinda overlooked it for now. But I would really love seeing an actual setting where we can set a specified number of branches.

 

if it weren't for Arcanor's persistence in getting to the bottom of this, I would have continued to assume that my game was generating 5 or more branches too. It was only because of our interactions on this Forum that I took a second look and noticed that the branch paths were not working as I believed they should. With that said, I think I'll try AegonGame's recommendation to retry generating random dungeons, and only accept generations with (in my case) 5 or more branches.

 

Hi m8 just a simple question, is this already support pathfinding or if not are u working on it?? I know there are plenty of other solutions for that but if is all implemented in on single pack will be very cool

 

I doubt that kind of functionality will be added any time soon unfortunately; I'm still thinking of how I could implement it, and I'm not sure it's really possible to do it in a nice customizable way with how DunGen works right now. It might have to wait until I finally get around to working on 3.0

I decided not to do built-in pathfinding. It's a little out of the scope of this project and I didn't really see the point in including my own implementation when there are existing assets that would likely do a much better job (and this one is free).

 

Thanks for your reply and honesty.

Is 3.0 ever going to happen, realistically?

 

Hi,

I've been browsing through pages for 25 minutes and I can't find the answers. Some questions come to mind before purchasing:

1. How do you handle lighting in Unity5? Simply you don't (no GI, no reflections, etc.), or is there a way to, I don't know, maybe pre-bake the lighting on prefabs? I know it's not DunGen's responsibility to do that, I just ask if anyone figured it out.

2. Same question about Navigation. I've seen somebody say that Rain can bake navigation on runtime, but did someone test it and can confirm?

3. Occlusion, as I understand, needs to be handled with SECTR, Right?

4. Static batching doesn't work in this case, right?

Thanks for answers and sorry if it was answered somewhere before. Also future buyers could probably use some summary of what can (and how) or can't be done in Unity 5.2 with this asset.

 

I hv the exanct same question, specially about the navmesh baking..

 

It should; I have no plans to abandon the idea of a complete overhaul. Unfortunately, 3.0 is going to have to wait until my income is a little more stable. I (perhaps stupidly) jumped straight into game/tool development as a full-time job, so as much as I'd like to work on things purely for the fun of creating them, I'm kind of constrained by what brings in enough money to let me keep doing this. At least for now - as S***ty as it sounds - I'm primarily "doing it for the money" and overhauling an existing piece of software has to take a back seat until I'm in a more comfortable position to work on it.

I'm not exactly a Unity expert so hopefully someone can correct me if I'm wrong on any of these points.

1. As far as I know, there's no way to pre-bake lighting on prefabs so Unity's built-in "dynamic" GI won't work. There's a post here suggesting that baking on a per-prefab basis might be a possible future workflow, but I think for now you'll either have to do without or see if there are any truly dynamic GI solutions available elsewhere.

2. I've baked a runtime navmesh myself with RAIN and didn't run into any issues. The process took about 10 seconds on the demo scene (will likely be longer with a more complex scene) but can be run in the background. Here's a screenshot of the results:



And for anyone who's interested, here's the script I wrote to generate the navmesh:

Code (CSharp):

1. public class NavMeshGen : MonoBehaviour
2. {
3.     public RuntimeDungeon RuntimeDungeon;
4.     public NavMeshRig NavMeshRig;
5.     public int ThreadCount = 8;
6.  
7.  
8.     private void Awake()
9.     {
10.         RuntimeDungeon.Generator.OnGenerationStatusChanged += OnDungeonGenerationStatusChanged;
11.     }
12.  
13.     private void OnDungeonGenerationStatusChanged(DungeonGenerator generator, GenerationStatus status)
14.     {
15.         if (status == GenerationStatus.Complete)
16.             StartCoroutine(GenerateNavMesh());
17.     }
18.  
19.     private IEnumerator GenerateNavMesh()
20.     {
21.         var navMesh = NavMeshRig.NavMesh;
22.         Bounds dungeonBounds = UnityUtil.CalculateObjectBounds(RuntimeDungeon.Generator.Root, false, true);
23.  
24.         navMesh.UnregisterNavigationGraph();
25.  
26.         transform.position = dungeonBounds.center;
27.         navMesh.Size = 1.0f;
28.         transform.localScale = dungeonBounds.size;
29.  
30.         navMesh.StartCreatingContours(ThreadCount);
31.         Debug.Log("Generating Navigation Mesh..");
32.  
33.         while(navMesh.Creating)
34.         {
35.             navMesh.CreateContours();
36.             yield return new WaitForSeconds(1.0f);
37.         }
38.  
39.         navMesh.RegisterNavigationGraph();
40.         NavMeshRig.Awake();
41.  
42.         Debug.Log("Navigation Mesh Generation Complete!");
43.     }
44. }

3. Like global illumination, I think Unity's occlusion culling needs to be baked as well. There are a number of different occlusion methods you could use in its place, but for indoor environments portal culling like that provided by SECTR VIS is probably the most efficient solution - the environment is already split into chunks with connecting doorways so there's no additional setup required.

4. I'm not sure exactly how Unity's static batching works. I'd assume there would be no batching in a runtime generated dungeon, but for the demo scene, Unity reports the following:

Batches: 210
Saved by Batching: 1252

There is also a StaticBatching.Combine method but again I'm not sure how that is supposed to work (whether it's intelligent about what to batch or has to be told explicitly). Using this function on the root of the dungeon changes the above values to these:

Batches: 108
Saved by Batching: 1354

These numbers all change from run-to-run (even though I'm using the same DunGen seed) so I really don't know if static batching works or not.

 

I'm not the best person to answer questions, but just in case no one more experienced answers in a timely manner ...

(EDIT: As I was finishing this Aegon answered above, but I'll go ahead and post this just in case it is helpful, or so I can be corrected if I'm saying something that's dumb. )

1) Not related to DunGen, but I think if you bake lighting on each room as a separate scene, then load them additively, the lighting remains intact. I haven't tried it yet, but I believe this reflects the user experience reported in the SECTR and Advanced Additive Scenes threads.

It seems to me that it might be possible to feed DunGen a bunch of blank dummy rooms for the purpose of making the map, with each dummy containing code to bring in the real rooms (that match the dummy volumes) via additive loading. I suppose part of the process might involve moving and rotating the rooms to fit their DunGen orientation.

2) IIRC, several nav plugins can generate a navmesh at runtime. RAIN is one of them, and it is free. So if anyone is inclined to test the runtime capabilities on any scene (it doesn't have to be DunGen) and report back, that could resolve this question.

3) DunGen has been given an option in the code to facilitate working with VIS. Another occlusion plugin that would work is InstantOC. InstantOC uses raycasts (you specify how many) on colliders, plus decay time (you set how long to wait after the last collision before re-hiding the item), to decide what should be displayed in the field of view. If you want, you can set it up so that each area has an IOC trigger collider on it such that when a raycast from IOC hits it, that room and all its contents is displayed. (Or you can write something simple like that for yourself.)

4) I'm not sure to what extent batching will be needed if you're tightly controlling which rooms display using something like SECTR and/or an OC method.

 

Nice i will test the scripts to generate navmesh dynamicly with dungen,. Just a question where u attached the script? to empty gameobject or some specific dungen object? Ty

 

It shouldn't matter where you attach it as long as you fill in the "Runtime Dungeon" and "Nav Mesh Rig" properties in the inspector. I made an empty GameObject and attached the above script and RAIN's NavMeshRig component.

 

Ty

 

I'm looking over the documentation and everything seems simple enough, but I'm wondering, is there a way to make the dungeons generate with more rooms? I'm interested in buying but one of the big parts of my project is making it so the dungeon gets progressively bigger the deeper you go.

 

Thanks for the answers

 

@AegonGames ,

If I ask very nicely is there any way you would consider implementing Playmaker Integration/Actions support? - it would undoubtably make this Asset more attractive and marketable to the Unity Asset Store community...

 

Hi!

Is there anyway to find out all the spawned doors for a given room? Even shared doors?

I need to be able to lock all the doors to any room, even if that room didn't spawn the connecting door?

Thanks!

 

Hi! I have a trouble to make dungeon in script. (script is for making a dungeon when it needs)

error is below.

Destroying GameObjects immediately is not permitted during physics trigger/contact, animation event callbacks or OnValidate. You must use Destroy instead.
UnityEngine.Object: DestroyImmediate(Object)
DunGen.DungeonGenerator:ClearPreProcessData() (at Assets/DunGen/Code/DungeonGenerator.cs:759)
DunGen.DungeonGenerator: PostProcess() (at Assets/DunGen/Code/DungeonGenerator.cs:854)
DunGen.DungeonGenerator:InnerGenerate(Boolean) (at Assets/DunGen/Code/DungeonGenerator.cs:280)
DunGen.DungeonGenerator:OuterGenerate() (at Assets/DunGen/Code/DungeonGenerator.cs:165)
DunGen.DungeonGenerator:Generate() (at Assets/DunGen/Code/DungeonGenerator.cs:122)

..and some _PROXY objects has remained in hierarchy.

I just wrote script.

void Start()
{
dungeon = this.gameObject.GetComponent<RuntimeDungeon>();
dungeon.Generator.OnGenerationStatusChanged += StatusChangedHandler;
}

public void MakeDun()
{
dungeon.Generator.Generate();
}

What did I do wrong?

 

Technically it's possible to adjust the values of the DungeonFlow asset at runtime to do what you want, but it's not supported functionality and could cause problems.

In the new beta build (below), I've added a "Length Multiplier" option to the generator settings that will let you change the length of the dungeon's main path at runtime between each call to Generate() (1.0 = normal size, 2.0 = twice as long, 0.5 = half size, etc). Is this kind of what you're looking for?

PlayMaker integration has been on my todo list for a while but I never picked it up until today. In the new beta build, there's initial support for three PlayMaker actions:

Generate - Generates a new layout using settings from an existing RuntimeDungeon component
Generate With Settings - Generates a new layout using settings you can specify through the PlayMaker UI
Clear - Removes a dungeon created by an existing RuntimeDungeon component

I only vaguely understand how PlayerMaker is used so there might be some issues with my implementation. To enable integration, just double-click the "DunGen/Integration/PlayMaker" package to extract it; if you have PlayMaker, it should just work.

The Tile component has a list of all active doorways; if you need to also know about adjacent tiles, the Doorway component knows which other doorway it's connected to. To lock all doors for a specific tile, you could do something like this (assuming the doors you want to lock were added as a "Door Prefab", the lock & key system can't be controlled after the dungeon is generated):

Code (CSharp):

1. // Get the tile that you want somehow
2. Tile tile = ...
3.  
4. // Loop through each used doorway in the tile - used doorways are those that are connected to other tiles
5. foreach(var doorway in tile.Placement.UsedDoorways)
6. {
7.     // Only one door prefab is spawed per doorway-pair so it might be on this doorway, or it might be on the other
8.     GameObject doorPrefab = (doorway.UsedDoorPrefab != null) ? doorway.UsedDoorPrefab : doorway.ConnectedDoorway.UsedDoorPrefab;
9.  
10.     if (doorway.UsedDoorPrefab != null)
11.     {
12.         // Do something with the door prefab
13.     }
14. }

In the new beta build, this shouldn't happen any more.


Version 2.7.0 (Beta) - Download
- Injected tiles can now be marked as required. If a required tile is not present at the end of the branch path stage, the generation will fail (and retry until the layout is successfully generated or until the maximum number of failed attempts is reached)
- [NEW] Added a new "Length Multiplier" option to the dungeon generator. The main path length of the output dungeon will be multiplied by this number. Allows for dungeon length to be altered at runtime between calls to the Generate() function
- [NEW] Added support for PlayMaker actions for generating and clearing dungeon layouts
- [NEW] Fixed an issue that was causing dungeons to not generate properly when Generate() was called from a physics trigger/contact


New Versioning Convention
I'm also going to start using a better versioning convention from now on - the way it was before was a little random. Now I'll be using Major.Minor.Revision where:

Major - Large breaking changes and potential complete overhauls
Minor - New functionality that shouldn't break when upgrading from previous versions
Revision - Bug fixes only

So that's why this is version 2.7.0 now instead of 2.6.1

 

@AegonGames ,

Excellent. I'll give it a try soon.

 

Hi

Any chance of the next build including these demo scenes:

https://dl.dropboxusercontent.com/u/267687927/DunGen/Demo2/Web Player.html

https://dl.dropboxusercontent.com/u/267687927/DunGen/Web Player.html

I just want to see how you do the long corridors and different levels


cheers

Nalin

BTW even cooler would be a video if you could explain how you put it together

 

Sorry, I can't include those demos in DunGen; I lost them some time ago. They're old (from v1.0) though and I really need to replace them, I'm just not sure when that's going to happen.

I can't remember exactly how those scenes were put together but looking at the top one, it seems the long corridors are actually multiple smaller ones attached together. I guess I removed the entire wall when it was attached to another room rather than just making a small gap for a doorway.

The different levels thing is easy enough to achieve though. Just make a tile with a staircase and put a doorway at the top and bottom of the stairs and it should just work. You'll want to make sure that any multi-floor tile is tall enough (at least twice the height of your regular tiles) so that your different floors don't intersect with one another.

 

I tested 2.7.0.

Maybe I'll back 2.6.0
I used InstantOC for Occlusion culling, It didn't any problem with 2.6.0, but after updating that has errors.
I don't know why it occurred.

 

I also noticed with 2.7.0, you no longer use DestroyImmediate, so now you get objects existing while they're still waiting to be destroyed, even when checking them after the level generation status has been set to Complete.

For example, I have spawn locations in some pieces that get destroyed when they're not picked by DunGen, but they're now still being found when I check for all spawners after generation has finished :/

EDIT:

I'm now working around this by calling my code after yield returning 0; to wait until the next frame after I receive the dungeon generation success status change. (so all objects are fully marked as destroyed). Maybe DunGen should do this internally before changing to success?

 

I have some error report ... can this be addressed ASAP please?

Exception20:10:29 ArgumentOutOfRangeException: Argument is out of range.

Parameter name: index System.Collections.Generic.List`1[DunGen.Graph.GraphNode].get_Item (Int32 index) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Collections.Generic/List.cs:635)
DunGen.Graph.FlowNodeReference.get_Node () (at C:/Pixellore/Project/Biomass/Biomass_PC/trunk/Assets/Standard Assets/DunGen/Code/DungeonFlowGraph/References.cs:25)
DunGen.Tile.get_Node () (at C:/Pixellore/Project/Biomass/Biomass_PC/trunk/Assets/Standard Assets/DunGen/Code/Tile.cs:52)
DunGen.DungeonGenerator.<PlaceLocksAndKeys>m__1FE (DunGen.DungeonGraphNode x) (at C:/Pixellore/Project/Biomass/Biomass_PC/trunk/Assets/Standard Assets/DunGen/Code/DungeonGenerator.cs:928)
System.Linq.Enumerable+<CreateSelectIterator>c__Iterator10`2[DunGen.DungeonGraphNode,DunGen.Graph.GraphNode].MoveNext ()
System.Linq.Enumerable+<CreateWhereIterator>c__Iterator1D`1[DunGen.Graph.GraphNode].MoveNext ()
System.Linq.Enumerable+<CreateDistinctIterator>c__Iterator3`1[DunGen.Graph.GraphNode].MoveNext ()
System.Collections.Generic.List`1[DunGen.Graph.GraphNode].AddEnumerable (IEnumerable`1 enumerable) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Collections.Generic/List.cs:128)
System.Collections.Generic.List`1[DunGen.Graph.GraphNode]..ctor (IEnumerable`1 collection) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Collections.Generic/List.cs:65)
System.Linq.Enumerable.ToArray[GraphNode] (IEnumerable`1 source)
DunGen.DungeonGenerator.PlaceLocksAndKeys () (at C:/Pixellore/Project/Biomass/Biomass_PC/trunk/Assets/Standard Assets/DunGen/Code/DungeonGenerator.cs:928)
DunGen.DungeonGenerator.PostProcess () (at C:/Pixellore/Project/Biomass/Biomass_PC/trunk/Assets/Standard Assets/DunGen/Code/DungeonGenerator.cs:843)
DunGen.DungeonGenerator.InnerGenerate (Boolean isRetry) (at C:/Pixellore/Project/Biomass/Biomass_PC/trunk/Assets/Standard Assets/DunGen/Code/DungeonGenerator.cs:280)
DunGen.DungeonGenerator.OuterGenerate () (at C:/Pixellore/Project/Biomass/Biomass_PC/trunk/Assets/Standard Assets/DunGen/Code/DungeonGenerator.cs:165)
DunGen.DungeonGenerator.Generate () (at C:/Pixellore/Project/Biomass/Biomass_PC/trunk/Assets/Standard Assets/DunGen/Code/DungeonGenerator.cs:122)

It seems like it is happening at placing locks and keys, but I have never ever used that feature.

I have checked my flow asset and it indeed doesn't have any keys or locked door settings.

 

So I can't use either Destroy or DestroyImmediate without it causing issues? Looks like I'll have to just wait a frame before changing the status to complete then. It feels a bit hackish but I suppose it can't be helped. I'm doing this in the new beta build, let me know if you run into any other issues.

Those line numbers don't seem to line up with what I've got so I wasn't able to get to the root of the problem. However, in the new beta build it'll just skip over the PlaceLocksAndKeys() function entirely if you don't have a KeyManager assigned so this should solve your issue.



Version 2.7.0 (Beta) - Download
- Feature Injected tiles can now be marked as required. If a required tile is not present at the end of the branch path stage, the generation will fail (and retry until the layout is successfully generated or until the maximum number of failed attempts is reached)
- Feature Added a new "Length Multiplier" option to the dungeon generator. The main path length of the output dungeon will be multiplied by this number. Allows for dungeon length to be altered at runtime between calls to the Generate() function
- Feature Added support for PlayMaker actions for generating and clearing dungeon layouts
- Bugfix Fixed an issue that was causing dungeons to not generate properly when Generate() was called from a physics trigger/contact

* New *
- Bugfix The dungeon generator will now wait one frame before changing its status to "Complete" to ensure all unused GameObjects are properly destroyed first
- Bugfix Fixed an error that caused DunGen to try to place locks & keys using a DungeonFlow without a KeyManager assigned
- Bugfix Tiles placed using the tile injection system should now correctly make use of their full range of possible spawn locations
- Bugfix Injected tiles should no longer occassionally overwrite tiles placed by a node in the DungeonFlow

 

Hello,

I downloaded the beta and I can't seem to find where you mark injected tiles as required. Can you set this option with code, by modifying the "DemoTileInjector" script, for instance?

Thanks

 

That's strange. That feature was just.. gone. I must have overwritten the project or something while juggling between Unity 4.3 & 5.0. Luckily it was relatively simple to implement so it didn't take long to put it back in; I'd better be more careful next time though. Sorry about that!

If you download the beta again, you should see a new IsRequired field in the InjectedTile class (and corresponding parameter in the constructor).

 

Probably a thing one want to have with a dungeon generator is Door-Based-Culling. I tried to get that SECTR_VIS-Door-Culling to work - aka that part that culls everything behind a closed door and sets it active as soon as the door is triggered to open.

For a start i added the following to PrepareForCulling in class SECTRCulling to the last loop, foreach (var conn in [...] Connections):

Code (CSharp):

1. if(doorway.HasDoorPrefab){
2.    portal.Flags = SECTR_Portal.PortalFlags.Closed;
3.    doorway.UsedDoorPrefab.GetComponent<SECTR_Door>().Portal =  portalObj.GetComponent<SECTR_Portal>();
4. }

As you can see i added SECTR_Door to my doorPrefab, this could be done (and configured) automatically by the Doorway class, as the door awaits a portal to use to work properly.

Then, on top, to have shared children like lights and most importantly doors to be culled correctly, one has to click "Fix Shared Children", a Button that appears for each room/tile at runtime in the SECTR_Sector Inspector.
I found out how it's done by Script but didn't figure out where to apply in the DunGen code, when generation is complete and there is still a reference to the sectors available.

From SECTR_SectorEditor:

Code (CSharp):

1. List<SECTR_Member.Child> sharedChildren =  mySector.GetSharedChildren();
2. if (sharedChildren.Count > 0 && GUILayout.Button([...])){
3.                 MakeSharedChildrenMembers(mySector, sharedChildren, "Fix Shared Children");
4. }

 

Thanks, seems to be working fine now

 

I hadn't looked into using SECTR's door based culling until now but I've got something working in the new build. I'm not sure exactly what that snippet from SECTR_SectorEditor is doing but GetSharedChildren is compiled out of any non-editor build so it can't be used at runtime.

For the doors, I'm parenting them to the dungeon root at the moment to avoid incorrect culling. I assume objects can belong to multiple sectors at once and that's how you're supposed to handle doors & lights but I'll have to spend a little longer with SECTR to figure out how that's done.




Version 2.7.0 (Beta) - Download
- Feature Injected tiles can now be marked as required. If a required tile is not present at the end of the branch path stage, the generation will fail (and retry until the layout is successfully generated or until the maximum number of failed attempts is reached)
- Feature Added a new "Length Multiplier" option to the dungeon generator. The main path length of the output dungeon will be multiplied by this number. Allows for dungeon length to be altered at runtime between calls to the Generate() function
- Feature Added support for PlayMaker actions for generating and clearing dungeon layouts
- Bugfix Fixed an issue that was causing dungeons to not generate properly when Generate() was called from a physics trigger/contact
- Bugfix The dungeon generator will now wait one frame before changing its status to "Complete" to ensure all unused GameObjects are properly destroyed first
- Bugfix Fixed an error that caused DunGen to try to place locks & keys using a DungeonFlow without a KeyManager assigned
- Bugfix Tiles placed using the tile injection system should now correctly make use of their full range of possible spawn locations
- Bugfix Injected tiles should no longer occasionally overwrite tiles placed by a node in the DungeonFlow

* New *
- Change SECTR VIS culling is now easier to enable. Just unpack "DunGen/Integration/SECTR_VIS.unitypackage" and select "SECTR VIS" from the list of portal culling solutions in the dungeon generator settings. It's now also much easier to integrate your own portal culling solution; just derive a new type from PortalCullingAdapter and implement it's abstract methods.
- Feature Portal culling will now also automatically handle doors placed by DunGen so that rooms are culled when the connecting door is closed. There is now a Door component which will automatically be added to door prefabs placed by DunGen. This component includes information about which doorways and tiles it is connected to and has an IsOpen property which is used to turn portals on or off when used with portal culling
- Change As a result of the new culling changes, door objects are now parented to the dungeon root, rather than their doorway to avoid being incorrectly culled
- Change Doors placed by the Lock & Key system are now considered the same as a door prefab and so will also benefit from the above


This will likely be the last new set of features for 2.7. I'll be submitting it to the Asset Store once I'm sure everything's working properly.

 

Hello,
Just wanted to say that I own your asset, and love it, but wish that the RuntimeDungeon would have a way to be generated via a coroutine out of the box so that I could avoid some hiccups while i'm generating.

Do you think that could be a possible addition to 2.7?
It seems easy enough (I've done it myself, but I'm not a fan of editing code within packages I've downloaded as any updates could destroy my work) I also understand you have a roadmap you're aiming for and this may not fit in, but i just wanted to throw this feature request out there

 

Would the coroutine be for splitting generation time across multiple frames? It won't make it for 2.7.0 (I've already submitted that to Unity) but this is definitely something I'll try to get done for the next version.

 

I have some serious memory issue with the dungen.

I am not sure how dungen manages to load the prefabs to be instantiated..

But I have many tile variations in my flow and whenever unity try to instantiate flow asset into scene or (not sure 100%) but when I select flow asset in the project view, Unity memory just shoots up almost seems like it is trying to load all the prefabs that the flow is depends on.

If this is true, this can't be like this... I think somehow, the flow only need to have reference that the Unity don't think it needs to load them into Editor and load and instantiate them only when they are needed..

Can you shine a bit more about this issue?

Also, basically, whenever I build my project, Unity crashes afterward because Unity editor is trying load all the prefabs that are associated with the flow asset. (out of memory)

I made work around for the runtime as I don't touch or load flow asset until I need to and it seems to work ok, but in Unity editor, this can sometimes be impossible, because you have to select the flow asset to edit them.. or when Unity builds player, it goes through all flowmap asset and seems to load all the tile prefabs.

 

Also this error

ArgumentOutOfRangeException: Argument is out of range.
Parameter name: index System.Collections.Generic.List`1[DunGen.Graph.GraphLine].get_Item (Int32 index) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Collections.Generic/List.cs:635)
DunGen.Graph.FlowLineReference.get_Line () (at E:/Pixellore/Subterrain/trunk/Assets/DunGen/Code/DungeonFlowGraph/References.cs:41)
DunGen.Tile.get_Line () (at E:/Pixellore/Subterrain/trunk/Assets/DunGen/Code/Tile.cs:66)
DunGen.DungeonGenerator.GenerateBranchPaths () (at E:/Pixellore/Subterrain/trunk/Assets/DunGen/Code/DungeonGenerator.cs:543)
DunGen.DungeonGenerator.InnerGenerate (Boolean isRetry) (at E:/Pixellore/Subterrain/trunk/Assets/DunGen/Code/DungeonGenerator.cs:276)
DunGen.DungeonGenerator.OuterGenerate () (at E:/Pixellore/Subterrain/trunk/Assets/DunGen/Code/DungeonGenerator.cs:165)
DunGen.DungeonGenerator.Generate () (at E:/Pixellore/Subterrain/trunk/Assets/DunGen/Code/DungeonGenerator.cs:122)

 

Also gets this error every time I generate map for the second time.

KeyNotFoundException: The given key was not present in the dictionary.
System.Collections.Generic.Dictionary`2[DunGen.Tile,DunGen.DungeonGraphNode].get_Item (DunGen.Tile key) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:150)
DunGen.DungeonGraph..ctor (DunGen.Dungeon dungeon) (at Assets/DunGen/Code/Graph/DungeonGraph.cs:28)
DunGen.Dungeon.PostGenerateDungeon (DunGen.DungeonGenerator dungeonGenerator) (at Assets/DunGen/Code/Dungeon.cs:47)
DunGen.DungeonGenerator.PostProcess () (at Assets/DunGen/Code/DungeonGenerator.cs:872)
DunGen.DungeonGenerator.InnerGenerate (Boolean isRetry) (at Assets/DunGen/Code/DungeonGenerator.cs:287)
DunGen.DungeonGenerator.OuterGenerate () (at Assets/DunGen/Code/DungeonGenerator.cs:162)
DunGen.DungeonGenerator.Generate () (at Assets/DunGen/Code/DungeonGenerator.cs:127)
DungeonManager+<GenerateDungeonCorroutine>c__IteratorA3.MoveNext () (at Assets/Game/Script/SceneManager/Dungeon/DungeonManager.cs:67)

 

I have commented out postprocessdungeon part and it seems to bypass the error... but it still leaves door prefabs (connection doors) behind from previous generation.

Did the Clear function in Dungeon forgot to clear door prefabs by adding this?

foreach (var tile in doors)
UnityUtil.Destroy(tile);

in Clear funtion?

 

Also a question.

Archetypes can have tile sets. And each tile set has tile with weight value.

If I set weight value in one of tile sets, does it work in conjunction with the other tiles in the archetype?

Meaning if I set one tile 0.5 and others 1 in one tile set and all other tiles has 1 in the other tile sets
the tile I set as 0.5.. does it behave the same as if I put every tile in one tile set?

or

the weight value only applies per tile set?

 

Yes, exactly what i meant thank you very much!

 

really need help with errors... asap

 

I generate a proxy object (just a bounding box and markers for doorways) for all potentially usable tiles in the pre-processing step before the dungeon is generated. In the new beta build (below), I've added an option to try to load tiles on an as-needed basis. In the generator options, uncheck "Pre-load Tiles". I'm not sure this will actually help though, it all depends on how & when Unity loads prefabs into memory.

For archetype weighting, I'm pretty sure the tile weighting is per-tileset (DunGen picks a TileSet completely randomly, then uses the weighting for each Tile).

As for those errors: I haven't been able to reproduce them. Can you give some more information please?
1. Which version of DunGen (and Unity) are you using? DunGen version should be listed in the Readme file.
2. Are you generating dungeons at runtime or in-editor?
3. Is there any specific situations that these errors occur in or is it consistent?

Version 2.7.1 (Beta) - Download
- Change There's now an experimental option to not pre-load all tiles before generating a dungeon layout