Dungeon Architect

Community Showcase Game Development
1481

I’ve updated an early access version of 2.5.0 so you can start using the new snap builder. There’s also a demo scene with around 20 snap modules to get you started. Download the snap demo files from

2.5.0-EA1 (Early Access)
Change Log:

  • Rewritten the snap builder to use blueprints, instead of levels for modules. This greatly improves the performance and stability
  • Added a snap demo example with 20 modules of various sizes
  • Fixed initialization issues with the actor node in the theme editor

The new blueprint based snap builder is fast and stable. This dungeon contains hundreds of rooms and was generated in under a second (the algorithm is fast but complex rooms may take more time to spawn)

There are still some issues to be resolved (the construction script messes up the state of the doors so you’ll have to build the dungeon after opening the map. I’ll fix this in the coming days

I’ll create a tutorial soon

watch?v=pKeHsHekjpE

2392×1386 252 KB

3391×1380 218 KB

1482

Any Dungeon Architect pros want to join an early access game on Steam PM me!

1483

I am interested in buying this for the City builder. Do you have a demo of how this works for UE4? I seen it for unity on YouTube I would like to be able to create City Scenes for my game. Is this plugin compatible for VR? Looks wonderful.

1484

Perfect, ! Looking forward to testing 2.5.0-EA1

1485

@lafilmcompany: I haven’t tried it using the VR editing, but definitely levels created with it will work in VR. Because of the need for 90 fps though what I’ve found is that it’s best to use static lighting for lightmaps in VR as much as possible. So what I’ve done when I’ve used it on VR projects is compile out maps using static lighting and saving levels just to try to keep the frame rates as high as possible (which is important for VR).

1486

Ive been testing the 2.5 snap builder. Sadly, its useless for me.

Ill grab the code from 2.4, the one that uses maps, and try to work with it. The reason is simple. Im doingVR, and i need static lighting. With the map snap system, lighting could be baked, and performance can be good. But with this system, lighting cant be baked into the modules, wich makes it useless from a VR perspective. Ue4 does not do any kind of culling on the lights other than simple frustrum cull, and that means that if i look to the center of the map, all the lights in all the modules will be calculating, completely destroying performance. If those lights cast shadows, the murdering of performance will be a serious thing, making any kind of half-big dungeon unplayable. Without the shadow casting, then light bleeds beetween modules.

Its nice how fast it runs now, and how it doesnt crash every time you exit play in editor, but i have no other , becouse the older version was WAY more performant. It also could use the navmesh from each of the modules, avoiding a global rebuild of the navmesh.

watch?v=TfBsDIJDajU

This is a video of the prototype im doing. This would be completely unplayable on the new version, as each module would need to be a blueprint and i cant bake light or navmesh.

Good that we have the source code, becouse i needed to edit it anyway to create my own tightly controlled dungeon. Such a shame you had to change it to use blueprints, what made the snap builder so strong is that it could use levels.

There is also a bit of feedback i have:

There is no way whatsoever to control the layout of the dungeon. You only have main path, branch end, main path end, and main path start. Its common to see 2-3 modules repeating in a row (easily seen in the video, there are 8 different modules). There is also no way to tell it to not repeat the branch end modules. Something i wanted to do is to have 3 different branch end modules, and use each of them in 3 different branches. But there is a that it will repeat 1 module in all 3 branches. That layout editor you were working on for other types of dungeons would be good for this.

Another thing that would be great is a “forbid” filter on the doors, so you can tell it to forbid putting a “hallway” room after another “hallway” room.

1487

Why can’t you set your static meshes in the BP actor to be static and cast static shadows ? After level is generated, build lighting and it should have lightmaps.

1488

The whole point of using a generator is to build random levels at runtime.

1489

Indeed, and in runtime you can’t have anything baked. So, real-time lighting is the only way to lit your randomly generated dungeons. No lightmaps at all. So, I am not sure why you saying you can’t bake lighting since, well, you can’t have baked lighting to begin with.

Navmesh generation is an issue, I agree.

1490

I have been struggling with this as well. Is there a workaround way you can think of to force UE to cull? Is there a type of volume or perhaps just a special mesh which would force lighting cull? This would help not just in snap builder, but in any reasonably sized DA level as well.

1491

Because with the old snap builder he could gen lightmaps for each piece in the level for them, then they will have lightmaps when generated.

TBH, I also need something like this but stayed away from the snap builder when it was using levels for each piece due to the overhead in building pieces in separate levels, but this has me rethinking it.

1492

Have you tried the forward renderer? Ive seen massive speedup on the dungeons with it, becouse it will do some light culling due to the way it tiles the lights (but too many lights will be too much work on the shader).

1493

Using levels as pieces is a bad idea IMO.

1494

That is amazing!!

1495

Outside of VR I agree, but for VR the ability to bake the lightmaps and then snap the pieces together is pretty crucial to avoiding dynamic lighting while being able to generate at runtime.

1496

Well, to be fair, only handful of people use it for VR :wink: Also, you don’t have to avoid dynamic lighting, just plan ahead and get clever with optimizing layouts. Lastly, dungeons generated offline can have baked lighting and I am 99.9% positive that generating them real-time will not make your game better. There are other ways to make pre-cooked dungeon feel like it’s random. I am personally going this route - many pre-cooked dungeons. If people really want more out of the game, either tech by then will be more optimized and handle lighting well, or I can simply generate more dungeons and offer them for free for as DLC.

1497

Doesn’t really matter if it makes it better when runtime random dungeon layouts is the #1 requested feature by potential players.

I think having a system that could support the level based snap pieces and the blueprint ones would be ideal.

1498

Hi,
Is there a way to exclude static meshes in a theme from being instanced by DA? If not, can you include a checkbox which would exclude a SM from being instanced? This would save me from replacing all SMs I don’t want instanced with actors.

Thanks!

1499

Well, you might have a handful of people asking about it now, but at the end of the day you will end up with finished game sooner and have a lot more paying customers who are engaged with pre-cooked dungeons. Just talking out of experience.

There was something about sub-level based system that didn’t work (and couldn’t work), which prompted to move to BP-based pieces. I forgot what it was.

1500

Meh, it’s not a handful, it’s basically all players interested in the game that request this. And I also agree with them: randomized layouts at runtime provides a lot more replay, even if the areas are more generic (I have plans to combat this anyway).

Plus, runtime generation is a major benefit of using DA in the first place.