DunGen - Procedural Dungeon Generation

Hello, I'm having a lot of trouble with failed generations. Using a 1x1 square room with a door on each side, the generator has a medium chance of failing after 100 tries at <20 room count with no branching, and a seemingly 100% chance of failing at a 40+ roomcount. How is it possible for a four sided room to fail in generation? I can't think of a situation where it would get stuck.

Here's what the room looks like:


I've also tried moving the doorways 1 unit out, which didn't fix it. Any ideas?

 

Have you tried with more room variety? I've had dungeons fail frequently when using just square rooms like this. Since square rooms fit together so neatly, doorways are often blocked by other rooms, which leads to a lot of failed attempts when trying to place new rooms.

If you only want square rooms like this, you might want to increase the maximum number of failed attempts. That could allow DunGen to succeed more often, although it may also cause the generation process to take significantly longer.

 

I was simply using a single room so I could test this issue, I intend on having more rooms. I thought it'd be a good idea to have rooms that fit neatly together (room sizes are in multiples of the smallest room: 1x1, 1x2, 2x2, 4x2, etc) because it'd cause less problems. Is that not the case?

 

I think it generally is the case, but having tried to generate dungeons with just a single square room with a doorway on each wall, I've found it does seem to cause problems. I'm not sure exactly why, but the lack of variety really does affect DunGen's success rate.

 

I am really enjoying DunGen, however, I am having some trouble with having a particle system inside the tile prefab. If I have a particle system in the tile prefab, then the generator will fail alot or always fail. It seems to cause those red lines that make a square around the tile to always have a corner at the world origin. Image I discovered that if I use the randomprefab script to instantiate a prefab with the particle systems in it, then everything seems to work fine.

Is there something special that I need to do in order to use particle systems as apart of the tile prefab, or does having a particle system do something behind the scenes that makes this impossible?

 

DunGen uses all types of colliders and renderers to compute tile bounds, so it'll be using the bounds for your particle emitters as well. I can't think of a reason anyone would want this behaviour though so it's probably something I can just remove.

For anyone having problems with the tile bounds being calculated incorrectly, can you please go here and download the new version.

This version ignores particle emitters when calculating the tile bounds. It also ignores sprite renderers by default, but this can be changed in the dungeon settings if you don't want DunGen to do this.


Hopefully, this will fix the last couple of problems that have been posted. If it works, I'll get it pushed to the asset store.

 

I downloaded 2.3.2 from the link above but it still seems to fail as soon as the Sprite Renderer overlaps the tile's outer boundaries. On the plus side I can confirm that the number of renderers doesn't matter as long as they are within those boundaries.

 

I downloaded the version in the link and the particle systems still messed things up, however, I found where you check to see if it was a ParticleRenderer or SpriteRenderer and I added in ParticleSystemRenderer and now it seems to calculate the bounds correctly. Thanks for the quick response and code additions, it really helped me to located what was going on.

 

Are you using a plain-old Unity sprite renderer or is it some special type? I tried with a Sprite Renderer component and it seems to work for me.

Good to know, thanks.


I've updated the package here. It now just ignores anything that isn't a MeshRenderer (or a SpriteRenderer if you have "Ignore Sprite Bounds" set to false in the generator) when calculating the tiles' bounds.

I'll probably want to implement a more robust system to let people decide what should and shouldn't be considered for bounds calculations, but in the meantime, this should work for the vast majority of cases.

 

It seems to be fine after restarting Unity - deleting and importing the new version of DunGen apparently wasn't enough. Or I messed around with it long enough to somehow get it working. Strange.

 

Hiho AegonGames,

just dropping a short note to ask if you got any further with your evaluation of using the new system? And to ask the specific requirements - if already available - for the corridor. Perfect would be a short example. In that way, I could may convince the asset maker to prepare the needed pieces already

Thx in advance
Wyl

 

Hey man, great product! Absolutely love the ease of use.
Kind of have an issue though... Unless I am dumb and overlooked something super simple...
BUT! I cannot create random dungeons at runtime when the game built to iOS. In editor it works great and the random generation makes the game so much more fun. Something I'm missing for mobile??

 

It'll be longer than expected before I get the new system in place - I don't have any sort of time frame for when it will be ready, sorry. "Real-life" problems preventing me from working on DunGen. I'll still be around for support + bug fixes (though my replies might be a little slower), but I rarely work on the new version of DunGen right now.

Do you get any errors at all? I don't have the means to build for mobile so I haven't been able to test it.

 

Unfortunately I'm not getting any errors. It's super bizarre. Like, it loads the dungeon randomly, but the doors and the stuff that should be loading randomly is loading everything, if that makes sense. Like where doors should be the walls and blockers are there. I used the demo castle and crypt layouts you have set up and it loads properly in editor but on the phone it just loads EVERYTHING in every room. Super bizarre.

EDIT: So I tried building the game to Mac OS and it worked perfectly. So it must be a compiler thing. Maybe in Xcode there's something I'm missing. I dunno.

 

I'm not sure what would be causing that. From the limited knowledge I have of iOS, the only real difference is that it doesn't allow runtime compilation - so I'm looking through DunGen to see if I've used anything that can't be compiled ahead of time. But if this was the problem, I'd expect it to just not compile at all.

 

Hmmm... I didn't really think about that. I hope it isn't a huge problem though, if it is I guess I'll just premake a ton of dungeons and randomly decide which one to load between scenes?? I dunno. I didn't realize that was an issue... come on iOS. Bummerville!

EDIT: This is just a screenshot from the iPhone. See how it loads all the room placements randomly... but absolutely everything is loaded. So I dunno if this helps at all??


This is printed in Xcode while running in test mode. Does this make any difference?

Rethrow as TypeInitializationException: An exception was thrown by the type initializer for PredicateOf`1

at DunGen.DungeonGenerator.PostProcess () [0x00000] in <filename unknown>:0

at DunGen.DungeonGenerator.InnerGenerate (Boolean isRetry) [0x00000] in <filename unknown>:0

at DunGen.DungeonGenerator.OuterGenerate () [0x00000] in <filename unknown>:0

at DunGen.DungeonGenerator.Generate () [0x00000] in <filename unknown>:0

at DunGen.RuntimeDungeon.Start () [0x00000] in <filename unknown>:0




(Filename: Line: -1)

 

Instead of adding objects that are needed to the scene, DunGen has all objects loaded to begin with (the way you build the rooms) and removes objects that aren't needed in the post-process stage. I think that error might be stopping DunGen from running the code from the post-process step onwards.

"TypeInitializationException" jumps out to me as something caused by the lack of JIT (just in time) compilation on iOS. From that error, it looks like the problem is in the PostProcess() function so at least I have an idea of where to look. Unfortunately, that function is fairly lengthy and I don't have the ability to test on an iOS device so whatever I do will be mostly guesstimating.

 

Hiho,

as it is sometimes hard to identify why a dungeon isn't generated, would it be possible to add a sort of debug-flag to show/indicate (maybe in a sort of slow-motion) what DunGen is currently doing? Like adding rooms, deleting props etc? And include the possibility to show the half-finished dungeon in the editor when it fails?

I think this would greatly enhance the possibility to fine-tune rooms/prefabs, etc?

Thx in advance
Wyl

 

I'm not sure about this. The half-finished dungeon on its own wouldn't really provide much information. It would be easy enough to report which phase DunGen failed in but since only the layout (main + branch paths) phase can actually cause a failure, that information itself isn't helpful. The best way to show what's going on would be to allow the dungeon to be generated slowly so you can see the rooms being testes/placed/discarded but that would require a fairly major rewrite.

In the new system, this won't be an issue anyway since dungeons shouldn't be able to fail. It still might be worth allowing you to slow the generation down to see exactly what's going on though.



Version 2.4.0
A minor update. For those of you working in 2D, this new version allows you to specify the up-direction when generating a dungeon. So now you can use Unity's 2D functionality and have DunGen correctly generate a dungeon on the XY plane. It hasn't been fully tested yet so I haven't pushed it to the asset store, but it's available for download here.

 

Thx for the reply,

I should have known that such a request to provide visible feedback needs to be incorporated into the generator itself - as I rolled some of them myself. It's easier to calculate and provide the output as to show whats going on Maybe - when you have time - you could possible foresee such a system in the new generator from the beginning. From a user point of view, it adds a lot for debugging and testing

BR
Wyl

 

While the store page mentions several options for handling nested prefabs, I'm wondering if any of the other DunGen users have found one to be particularly more robust than others, or have any recommendations of any kind. Some seem aged/abandoned, and others seem to have unresponsive devs. Any input at all related to how well your selection has worked alongside DunGen appreciated.

Since we're not going to see this fixed in Unity 5 (Unity dev mentioned it will come after), might as well pick a horse and get racing now.

Follow up: Going through all the options I could find, it appears at this point that Prefab Evolution is the front runner ( https://www.assetstore.unity3d.com/en/#!/content/17557 ) - and there's even a free trial version. When I get a chance to work this into my work flow and give it a test with DunGen I'll share what I think.

 

I would be interested in that, too. I have reached a point where I see how not being able to do nested prefabs might be a problem in the long run. Guess I will give Poor Man's Nested Prefabs a go since it's obviously the cheapest of them all.

 

If I bake lightmap for every tile I use, will this work out just fine with DunGen?

 

If you can bake lightmaps for individual rooms it should work; but it would probably look wrong with the light suddenly cutting off at the edge of the room. If you're doing procedural content, you'll likely want to stick to dynamic lights.

 

Thank you. After some testing, I see that it is actually possible, I just need to assign lightmaps manually after I bake them and make sure they have coherent borders.

 

umm this has been done for years. Have you ever heard of texture baking? Its part of the standard toolkit for most 3D artists.

 

That is true, but for Unity, lightmaps are stored per-scene, not per-object, so I asked to make sure that DunGen really does not add any extra code to workaround this.

 

I like this product. I was wondering if you have a trial version that I can use to determine if this is suited to my project.

Thanks

 

Sorry, I don't. I've been wanting to make a trial version but never got around to it.

 

I was wondering if the feature exist,
Can DunGen generate an image based Mini-Map?

I feel that this is important, like assigning a picture representation for each chunks/rooms, and let it be combined into an image for use when DunGen has finished generating.

and..

I am planning on purchasing on the next discount.

Will there be discounts soon?

 

What I am doing is adding a sprite renderer to each tile whose layer isn't rendered by the main camera but a second orthographic camera pointing straight down towards the scene.

 

Hello,

Web Demo links are not working, neither in this thread nor from the links at the asset store.

 

For me they are working

 

I tried using with couple of third part assets like 3drt Dungeon Master Kit etc and I am not been able to successfully generate a dungeon. Either it is erroring out or creating a disjointed dungeons. I don't know what I am doing wrong. Any pointers should be appreciated.

Thanks

 

I am aware of this approach, but I prefer a cheaper alternatives, to just load a single texture.

Thank you for the suggestions!

 

Now they are working for me too. Fixed or server error, I don't know.

 

That's not a feature I have planned at the moment. I feel that the handling of a mini-map is a little too game-specific to include in DunGen. Also, if I recall correctly, writing to a render target requires Unity Pro, which I don't have just yet.

EDIT: Regarding the next discount: I've applied for another 24-hour sale slot but it's up to Unity if/when that happens

The links were working for me when I read your post so whatever it was, it seems to have fixed itself.

DunGen creating disjointed dungeons sounds like the doorways are too far away from the edge of the room, resulting in gaps when they are joined together. The problem with DunGen not being able to generate a dungeon is a trickier one; it could be caused by any number of reasons due to the trial-and-error nature of the way DunGen works right now. Here are a couple of tips that should help:

1. Never use rooms with only one doorway unless they're only going to be used for the start/end rooms.
2. Try to minimise the number of rooms with only 2 doorways. Basically, more doorways = more options for DunGen, so it's less likely to fail.
3. If possible, keep the walls & doorways snapped to a grid.
4. Variation in room shapes seems to help. Having all rooms as a single shape causes failures more often, I'm not sure why yet.
5. Make absolutely sure that your doorways are not inside the room boundaries. Currently DunGen doesn't give a warning when this is the case so some of your doorways could actually be completely inaccessible. Grid snapping helps avoid this.

Hope that helps.

 

Hi,

We modified the corridor of the demo project to end at a different height. But after generating a bunch of times it seems that branches that change height never connect to other branches that are also at that height. Is there a way to accomplish this ?

 

Came across this article today, thought it might be interesting to those of you following this thread. Enjoy! http://www.gamasutra.com/blogs/Joel.../Skyrims_Modular_Approach_to_Level_Design.php

 

I haven't been able to reproduce this problem. Do you have any screenshots showing what you're trying to do and what's happening?

 

Hi,

In the screenshots you see we added a ramp/stairs kind of piece, which is basically a modified version of the corridor of the demo. This is the only piece that was added, no pieces were modified.

This is as close as we got doing a lot (really a lot) of generating, and as you can see it still doesn't connect. Settings:

length: 33 - 33
branch depth: tried various values between 1 and 4, no difference
branch count: tried various values between 1 and 7. no difference

We are looking to create large loops that can go through various heights.

 

Today I came across this minimap generation system in the asset store: https://www.assetstore.unity3d.com/en/#!/content/20101
I didn't bought it up to now as I'm still in the middle of programming the ground framework, but this could be something interesting and may easy to integrate?

BR
Wyl

 

What's your "Connection Chance" setting (on the dungeon flow asset) set to? From your screenshots, I can't see any rooms that are forming a loop, regardless of height.

 

We tried various vales for the connection chance but no difference. The square rooms do loop back but only creating really short loops.

Do you maybe have an example that creates (large) loops?

It would be nice if there was an option where you can add a chance for branches to connect to existing branches.

 

It wouldn't be possible for branches to connect to existing branches with the way DunGen currently works, unfortunately.

A connection chance of 1 means that every doorway that overlaps another (but was otherwise unconnected to it), will be connected; so if it's at 1 and you're not seeing overlapping doorways being connected, then something is definitely wrong.

It might be that the doorways just aren't close enough to be considered overlapping. In DungeonGenerator.cs in the ConnectOverlappingDoorways function (it should be somewhere around line 520) you'll find this line:

Code (csharp):

1. const float epsilon = 0.00001f;

That number is the maximum squared distance between doorways that can be connected. So any doorway greater than ~0.0032 units apart (0.0032 * 0.0032 = ~0.00001) will not be considered. Increasing that number will allow DunGen to try to connect doorways that are further apart.

 

I am either doing something wrong or you can tell me whats happening. It seems no matter how I set the branch length, they are no more than two rooms long. Set them to branching depth 4-8 in the archetype and I still get two room branches. There is room for more but whats the deal?

 

I tested 2000 seeds of the demo scene and you're absolutely right, not one of them had a branch depth greater than two even though the branching depth is set to 2-4.

After looking through the code, I think I've found the problem. In DungeonGenerator.cs, in the GenerateBranchPaths function, you should see this line (around line 336):

Code (csharp):

1. branchCount = Mathf.Clamp(branchCount, 0, tile.Placement.UnusedDoorways.Count);

If you comment it out so it looks like this:

Code (csharp):

1. //branchCount = Mathf.Clamp(branchCount, 0, tile.Placement.UnusedDoorways.Count);

Things should work properly. It seems I was confusing branch count and branch depth and was capping the branch depth by the number of available doorways, which makes no sense. This bug must have been in DunGen since at least 2.0. Thanks for pointing it out, I'll get the fix submitted to the asset store as soon as possible.

 

AegonGames: TypeInitializationException is probably that you're using LINQ.

Unfortunately, the AOT compiler doesn't handle LINQ properly, and it fails in the worst way possible: it compiles, then works a few times, and after several times through the same segment of code it suddenly fails. The bug is apparently fixed in recent Mono, but Unity uses an old version. I haven't tried Smooth.Slinq to see if it fixes the problem; instead, I just deleted all mentions of LINQ, and used more cumbersome syntax to do the same work.

 

Thanks, that's not too much of a problem then. I used to avoid using LINQ before anyway so replacing it all won't be too difficult.

 

Hello. I am completely new to Unity and to Dungen. I've tried out the demo scene and seen the assets in the tiles. Just wondering, how were those assets generated, and can Dungen-usable assets be imported from other sources like Sketchup? Sorry about the noob questions, and thanks for the help!