DunGen - Procedural Dungeon Generation

Hi, question about the navmesh generator. I have it working, no errors but I am wondering if its working right. It navmeshes each room individually, then creates links. Should it navmesh the whole dungeon since it all touches? I only ask because when the AI goes between rooms its like it dashes through, like a leap forward. I assume it does that because the gap is larger. If I manually bake it will back it all, is there a way to bake it after its created?

 

DunGen 2.11.9 Beta 3 Released

I didn't even know the old SECTR VIS package had been deprecated. It looks like the new version still uses all the same components so I'd have thought it would still work.

I'll have to take some time at some point to upgrade to the new version myself and see what's up. For now, I'll remove any mention of the integration from DunGen's asset store page.

As for the built-in culling solution, it has a very narrow use-case. It works best when you have closing doors on the entrance to every room so the player will only ever see two rooms at any time. It's not very useful if the player should be able to see through multiple rooms in a line; for that, you'd need an external culling solution like SECTR.

For some reason, Unity's default AI behaviour for traversing off-mesh links is to go through it at 2x the agent's speed. It's possible to use a custom script to override this behaviour.

There isn't a way to bake the entire dungeon after it is created in the current version, but I've now added this as an option in the new beta build.

 

Are there any downsides to baking the entire dungeon rather than creating off-mesh links?

 

I think it would mostly be an issue of performance.

While I've found Unity's runtime NavMesh generation to be really fast, if you have a large or complex enough dungeon it might start to slow down. Pre-baking each room into the prefab will always be the fastest. If you're not using the pre-baked mode, there shouldn't be a difference (generating the entire dungeon's NavMesh at once might even be a little faster).

The biggest difference is that doors would need to be handled differently. Off-mesh links can be enabled and disabled at runtime to allow agents to pass through doors only when they're open. Without them, you'd need to add a NavMesh Obstacle to the door. The obstacles would need "carving" enabled so they actually cut a hole in the NavMesh - which is a lot more expensive than just toggling an off-mesh link.


It's probably something that needs to be evaluated on a case-by-case basis. The performance hits might be completely unnoticeable in your particular project.

 

I see, for my dungeons they are relatively small so doing it once would be good. I will look at making a script too for now since I have most of my game complete. Thanks for the info.

 

Makes sense. I will mention that I own several dungeon building assets, and the main reason I immediately came to this one over anything else was because I expect it to be easier to achieve decent frame rates using Sectr. It worked out that I actually really like where this has gone, and I think I can manage anyway ... but the easy of Sectr integration is something that really made this product stand out for me, even when I know I can accomplish my dungeon in different ways using a variety of different products. I can just focus on building my rooms, and not worry about how to optimize it.

So ... if there is something wrong, it would be great to fix it . Im still assuming the problem is me, but feel free to check.

 

Question, does this support 2.5D and side scrollers ? And are there any demo videos or themes to showcase how it looks or works ?

Something like INSIDE or MARIO kind of stuff OR a game created using 3d assets but in 2d/side view

 

Yes, DunGen supports 2D, 2.5D and 3D. Side-scrollers are also not a problem. I don't have any videos showcasing these use-cases yet unfortunately.

Ultimately, DunGen works the same way regardless of what type of project you're working on: you just hand-make some rooms, mark the doorway positions/orientations, save the rooms as prefabs, and let DunGen piece them all together.

 

I'm having problems. When I generate my dungeon, some of the doorways are not blocked and end up opening the player to an endless drop. What are things that can cause this and how do I fix it?

 

Make sure that all of your doorways have got at least one entry in either the "Random Prefab" or "Scene Objects" list in the Blockers section. Prefabs are automatically placed at the location of the doorway; scene objects must be inside the tile prefab and need to be positioned manually to block the doorway.

 

I am having the same issue as @Lokiare. Sometimes the starting tile has all doorways blocked. Sometimes there is an empty doorway, which leads to nowhere.

---

Edit: I have been doing tons of testing. I got it working properly. I think the issue was that the pivot point of the wall tiles are at the left instead of at the middle. I had to wrap the wall blocker in an empty game object, and then make that into a prefab. That put the pivot in the correct spot.

https://imgur.com/a/SGO54Tf

I just used cubes for walls to test it out. Tomorrow, I will try to replace the cube walls with actual wall tiles and see if it works.

@Aegon-Games - Does it matter if the colliders on the walls are box or mesh? I am wondering if that was also part of the issue also.

 

hello,
I am having an issue :
Failed to generate the dungeon 20 times. This could indicate a problem with the way the tiles are set up. Try to make sure most rooms have more than one doorway and that all doorways are easily accessible.
include in Demo Scenes and Analysis Scene

I tried to move the door away from the room, but it didn't work.
@Aegon-Games

 

I'm glad you got it working properly. Yeah, connector and blocker prefabs are placed at the pivot of the doorway, so your prefabs need to share the same pivot for them to line up correctly. Another thing to be aware of is that prefabs also have their scale reset when placed, so if you're using scaled-up cubes as walls they need to be wrapped inside an empty object as well. I'm thinking about changing the scaling behaviour in a future version.

The type of collider on the walls doesn't matter.

Did the error message say anything else? It should give a list of reasons for tiles failing to be placed.

 

Thanks for the quick reply. Speaking of scale, when the blocker is inserted into the western doorway of the room, the scale is normal. On the other 3 walls, the scale is double on the Y axis.

Screenshots: https://imgur.com/a/6qNQl3Y

All my doorways are the same and I am using the same blocker for each doorway. Why is this happening?

 

"We can add a Local Prop Set component to any GameObject in our tile (Add Component > DunGen > Random Props > Local Prop Set)"

Which GameObject do we attach this to? I made a new GameObject called "Prop Generator". Is that okay or will I run into problems?

 

DunGen resets the local scale of placed blocker prefabs after parenting them to the doorway. The blocker itself should have a scale of (1,1,1), but if any of its parent objects are scaled, the blocker will be too.

That's fine - it can be attached to any object in the tile.

 

Oh man, I just read that Dungen has no more SECTR integration and I'm like

Nnnnnnnooooooooooooooooooooooooooooooooooooooooooooooooooooo!

Heh, crap.

 

I just noticed this thread and happened to see the discussion about the latest SECTR not working.

I have a project I started back in June using the new SECTR and it worked last time I checked.

I just loaded it again to check and yep, it's working. Zooming out in the editor above my dungeon and moving the player around culls entire sections of the dungeon when "Cull in Editor" is enabled.

I'm using simple culling setting on the DunGen SECTR script.

 

I want to confirm that the SECTR integration indeed still works!

 

Where did you read that?

I don't really understand what SECTR does, but if you only need culling, DunGen has a script called BasicRoomCullingCamera.cs. By default, it will cull all the rooms except the one that you are inside, as well as the next room. See the readme for more info.

 

Sorry for the confusion about the SECTR integration. I removed any mention of it from the asset store page because I couldn't be sure it still worked with the new version of SECTR. I do intend to upgrade to the new version soon so I can make sure the integration always stays up to date, but I've been working on some other DunGen stuff over the last few weeks.

DunGen 2.11.9 was just released on the asset store (changelog is available on the original beta post). I've also made a lot of progress on 2.12, and we're working on a new top-down sample project to go with it. Hoping to have a beta version out soon.

 

Does this mean we need to upgrade to the most recent version of SECTR?

 

No. I believe the integration works with both the old and new versions of SECTR right now. Unless the API changes in future versions, I shouldn't have to make any changes - but if I do, I'll try to keep the integration working for the older versions as well.

 

I am thinking about created random floor and wall materials. What is the best way to do this?

 

Probably with a custom script that waits for a completion event from DunGen (see this example) then loops through the renderers for your wall/floor meshes and changes the material.

You'll need some method of identifying objects that need their material changed (by layer, tag, or using a custom component and FindObjectsOfType()).

The generator's CurrentDungeon property gives you access to tile information if you want the randomness to be applied per-tile instead of glabally.

 

Added a new built-in culling component "AdjacentRoomCulling"

Does this replace the BasicRoomCullingCamera?

 

I have an idea for a feature. The rooms could be flipped on the X and/or Z axis to add more variety.

 

I've had the same idea too some time ago, I wonder if its possible to do without creating an entirely new room. Also I think this might create issues with colliders so this might not even work

 

No, the old component still exists. They both do the same culling but the old component performs culling for each camera before it is rendered (and reverts the culling after the camera is done rendering), whereas the new component updates the culled tiles only when you transition from one room to another.

This makes the new culling component much more performant, but means it doesn't support multiple cameras and overwrites the 'enabled' property on renderers and lights whenever the culling is updated - so if you use this property in your own code you may not want to use this version of the culling. There are also some properties on the culling component that let you specify per-renderer and per-light overrides if needed.

Negative scaling seems like it could lead to a lot of unintended side-effects (backwards text, physics issues).

At the very least, I know box colliders give warnings about being negatively scaled and I can't imagine it would be good for the rest of the physics system either.

 

I can't get the auto door to work. I didn't make any modifications to it. I just added the prefab to my scene.
https://imgur.com/a/I0A6647

 

The auto-door prefab from the demo was only made to work with the demo character. It's looking for the demo's PlayerController component on the overlapping object in the OnTriggerEnter() method.

 

Version 2.12.0 - Asset Store
Be sure to backup your project before updating to a beta version of DunGen
Available on the Asset Store as of 20 November 2019

UPGRADE WARNINGS:
- This version includes breaking changes. Doorways must have their sockets re-assigned using the new system. Up-direction must be re-assigned in dungeon generator settings.

- Some folders have been restructured in this version. If upgrading, the older version of DunGen should be deleted from your project first to avoid problems




Features

• New Dungeon Crawler Sample (Extract from "DunGen/Samples/DungeonCrawler.unitypackage"). Requires Unity 2019.1 or higher
• Doorway sockets are no longer hard-coded and are instead assets that can be added without modifying DunGen's source code
  • Doorway size is now part of the new DoorwaySocket asset instead of being applied to each doorway instance
• Doorway socket connection logic can be overridden by providing your own function to DoorwaySocket.CustomSocketConnectionDelegate
• Added a new constraint in generator settings to enforce a minimum padding distance between unconnected tiles
• Added a new constraint in generator settings to disallow overhangs (so rooms cannot spawn above other rooms)

Enhancements

• Door prefabs are now parented to their doorway objects, rather than the dungeon root
• Added a new icon for doorways
• The maximum overlap between two connected tiles can be tweaked in the dungeon generator settings
• Simplified up-vector selection
• [New in Beta 2] If no socket is specified for an entry in a TileSet's locked door prefab list, the locked door can be assigned to any socket - previously this stopped the door prefab from being placed at all

Bug Fixes

• Assigning a prefab to a key is now optional
• [New in Beta 2] Disabled doorways are no longer considered when connecting tiles together or when calculating tile bounds

 

The sample requires 2019.1+, but the code still runs under 2018.4?

 

DunGen still works as far back as 2017.1 and that's not changing with this new version. The new sample is the only part that requires 2019.1 because that was the version we made it with - the prefabs don't work properly if it's opened in 2018.

 

I noticed that you keep releasing Betas. Is there a LTS version of DunGen also? I am new to Unity, so I don't fully understand how that works.

 

Is there a way to make room tiles connect only via separate hallway tiles, while making sure hallway tiles always have a room connected to them?

IE: Start room, a hallway tile is connected to that, and a room is connected to each exit on the hallway, and so on?

 

Was this ever addressed?

RakNet, Aug 30, 2019

 

The only versions of DunGen are the stable Asset Store build and the current beta version. There's no long-term support version of DunGen.

I haven't tried this myself, but you could make two doorway socket types called "Room" and "Corridor". All doorways in your rooms would be assigned the "Room" socket, and the doorways in your corridors would be assigned the "Corridor" socket.

Normally these two socket types wouldn't connect, but we can write some custom connection logic so that "Room" and "Corridor" sockets only connect to one another.

Information on how to make new socket types and how to override the matching logic can be found in the "Socket Types" section of the readme.

I can't remember what I did about that, but I can't find anything in the changelogs that references this issue.

I've just looked into it again now and I can't reproduce the issue myself in 2.12.0 beta. Disabling the doorway component's GameObject doesn't seem to affect the bounds generation at all. Neither does parenting the doorway object to a disabled GameObject.

 

That would be the issue, it SHOULD affect the generation. If I have a doorway that is on a disabled game object, that is because I don't want to use that doorway. At least in my version it still connects that doorway.

 

New install of 2.12.0 beta 1... new sample project is a really nice addition.. but it doesn't work properly for me. Running on 2019.2.11f1.
picked up the key but it fails to unlock the gate. I've explored the rest of the map and there is nothing left.

 

Okay, that's easy enough to fix - I'll put it in the next beta build. Your original comment mentioned incorrect bounds generation and overlapping tiles and it sounded like that was the problem (which is what I couldn't reproduce).

Strange, I've never run into that problem before. Do you get any error messages at all? I'll try running it on the same Unity version and see if I can reproduce it.

EDIT: I also can't seem to reproduce the issue in Unity 2019.2.12f

 

I had it happening every time. Let me try again. Fresh install into new project.

 

ok I installed dungen beta into a fresh project and 2019.2.12f1 and it worked fine.
I notice that in 2019.2.11f1 it wasn't opening any doors, not just the door to the graveyard.. even the normal wooden doors did not trigger/open but I was allowed to walk through the closed doors. The graveyard door did not allow me to walk through though.

 

I've set my tiles and the global dungeon generator not to allow rotation, but I'm getting rotation on my 2D dungeon:

I've tried all combinations of the allow/don't allow rotation checkboxes.

 

Since props and doors will be randomly generated, are prebaked navmeshes inaccurate?

 

Should the Dungen doorway be the size of the door, or the size of the door frame? I have a big door that has a smaller frame.

This is a picture of the door halfway open.

 

The new version allows you to bake everything just as the dungeon is first generated.... before SECTR or other systems cull them. its supposed to be faster than runtime navmesh generation.

 

I think that would bake at runtime. I am asking about the prebaked option.

According to the documentation: "Pre-Baked Only – Don’t add any new navigation mesh surfaces at runtime"

 

Runtime bake has a different meaning... it means that if you can bake navmeshes on the same scene you are currently playing... like throwing a plank to create a bridge and being able to cross over with ai/navmesh.

 

You should only have to disallow rotation globally in the dungeon generation settings (on the runtime dungeon component) like this:


(Left checkbox enables the override, right checkbox is whether tile rotation is allowed or not)

Both methods are working fine for me in the newest version. There was a problem with the per-tile setting that was fixed in 2.11.3 but I don't think I've made any changes to this code since then so it should still work in any version since then.

Anything that is spawned/destroyed during dungeon generation won't contribute to the NavMesh if you use the pre-baked mode. Doorways should still work properly though as off-mesh links are placed to bridge the gap in the NavMesh between rooms.

The full dungeon bake mode is probably the easiest option to guarantee that the NavMesh is accurate (and is required if you need an actual navmesh connection between rooms rather than an off-mesh link). It's the most expensive choice but we're doing the same thing in the new sample and there's no noticeable performance problem. Maybe it would become a problem in a scene with a lot of objects, but it seems fast enough for now.

Clarification: Whenever I say "runtime" when talking about NavMesh generation, I mean "once, after the dungeon has been generated", not that it will adjust the NavMesh in real-time while playing.

The doorway size should be what the player can see through. Note that it's only used for visualisation unless you're using the SECTR VIS integration.