DunGen - Procedural Dungeon Generation

I can't see any problem with this restriction. If the set size is 1m and I assemble my tiles on a grid that is made of 1m blocks, it seems like it would be easy to adhere to this design rule.

 

All of your proposed changes sound great. Would this also encompass the changes you wanted to do to the door portals (non-AABB), possibly on the floor or ceilings?

That restriction sounds 100% reasonable. Worst case, if you really need a room that's 6.5 units wide, you can make it 7 units wide and just have one wall be composed of a thicker wall prefab.

I'm assuming that this would also make it easier to have everything grid-aligned, if the user wanted everything aligned in such a way. Is that correct?

 

First of all, thank you for providing some feedback on planned/upcoming features.

One of the reasons I choose DunGen over other random dungeon generators in the asset store was the ability to have random dungeons on one hand but nice control on creating the rooms / connectors on the other hand.

I understand where you are heading to and I think there are several charming aspects to it.

But for me personally, as I'm more a programmer person I'm relying on graphical assets from other persons. With the current process, I can search in the asset store (or somewhere else) and if it fits the theme I have in mind I can use it. I don't need to care if wallsizes / floorsizes matches each others as long as the overall flow feels right (e.g. some artists using 1.5 x 1.5m tilefloors and others may use 1 x 1).
With the requirements you mentioned, I may have to be very careful not to mix up something or to be very selective with the assets beeing purchased or try to get an dedicated artist which again can get costly.

On the other hand, you mentioned that you maybe try to get rid of the requirements to have to doors all the time on the outer borders of the AABB. Would the new requirements mean that we can have only rectangle rooms with a multiply of a standardset or could we still get non-rectangle rooms?

How would you implement the control of the corridors. What requirements to the assets are needed? Double-sided walls / single sided? Again, I'm maybe a bit concerned about the restrictions which comes with it. Currently I don't mind to set up a few small corridors based on the assets I have - they are really a no-brainer and easily made.

Looking forward what you come up with.

BR
Wyl

PS: I was thinking that something is going on as you moved the new dungeon flow to the ToDo-list in trello

 

Sounds like a very mild limitation for a lot of additional functionality. I'd be totally in favour of that.

 

Thumbs up as long as it doesn't affect prop placement system.

 

Double thumbs up for whole number dimensions- as already mentioned you can have irregular dimensions fit within whole numbers. That being said, I prefer to work to the nearest meter already so this limitation wouldn't deter me at all.

 

Yes, the proposed changes effectively make the whole of DunGen grid-based.

Basically, for each archetype, DunGen would require a number of prefabs: a corridor (2 walls), as well as an inner and outer corner piece. If it were to support multi-floor dungeons, you'd also need to provide a staircase segment.

The prop placement system would remain untouched.

 

Thanks for the responses. It seems the reaction is mostly positive but there have been a couple of issues brought up that I hadn't thought of - which is why I'm always going to ask about things like this before just implementing them.

Multi-floor Dungeons
I completely forgot about this. My ideas so far wouldn't support multi-floor setups - I might be able to come up with a solution that does though.

3rd party assets not fitting to the grid
I could make the grid size configurable but that wouldn't solve the problem of having assets from different sources that are different sizes.

Complex Tile Collisions
The proposed changes actually make this impossible. Each tile would need to fit into an axis-aligned box with dimensions that are multiples of the grid size. You could still have complex room shapes but all doorways would have to lie on the edge of this bounding box.


I think these problems are going to stop me from implementing the proposed changes into DunGen. I'm considering splitting DunGen into two assets: One that continues on the current path of having zero-limitations and being completely design-driven. The other would allow for the new features I already mentioned (and more) that aren't possible with how DunGen currently works. The latter would also likely be more robust and efficient since it effectively boils the whole problem down to a simple grid.

If I were to do this, I'd make it so that anyone who had bought DunGen up to that point would get the new one for free, I'd probably drop the price of both assets as well. Of course that leads to other problems - I don't think Unity would provide me with a way to do this, so anyone getting the new asset for having previously purchased DunGen would have to download it through my website, not through the asset store. It might also prove to be too much work to maintain two procedural generation assets, especially when they're effectively competing against each other. I could also include both types of generation in DunGen but I feel that would make the asset bloated.


I'm just brainstorming ideas here, nothing is set in stone just yet. I want to know what everyone thinks before making such a huge change to DunGen.

Thanks again for the feedback.

 

This sounds fine to me. Like others here my prototypes are regular sizes. And door placement might be easier when using a snap tool.

Will individual tiles still allow doors to be at different heights? I would like to have rooms with sloping floors, and dungeons that undulate up and down. I would be happy to snap vertically. I suppose I might like maybe 5 different vertical positions.

I like the current "natural" feel of cave-style dungeons where the tile floors are not all on the same plane.
Separately, I also like the true 3D dungeons were you can get chains of rooms running under or over previous rooms.

 

Later on it might be interesting to see what happens with other grid types, such a triangular or hexagonal grids. The rooms might be more difficult to create but some very interesting layouts would be possible.

 

You could have a Basic version of DunGen that only does 2D grids and a Pro version that also does 3D grids and design-driven layouts.

One of DunGen's strengths seems to be making a lot of dungeon from few prefabs. And regardless of the layout engine that strength would still be a key feature.

 

I think the corridor idea is the key here. Tiles could be placed almost anywhere and as long as there was enough space between them to dig out corridors it would probably be possible to always join them.
Since the corridors would be so prominent - the resulting dungeons would probably contain a lot of them - it would be important to allow controlled variations. Random props would be good for clutter and for wall details. I would suggest allowing users to specify a number of corridor segments (with selection weighting) for each corridor type. Corridor would effectively be an additional and mandatory tile, which must include 4 parts.

I guess each wall would also contain half the roof and floor. The inner corner would include a quarter, and the outer courner would include three quarters.

You might also have to allow corridors to intersect, but all possible intersections could probably be handled with the two corner pieces and one wall.

3D might also be possible but might need an additional piece: a height change mechanism like stairs, a ramp, an elevator, etc.

 

Could you possibly release the new version as an add-on that temporarily has dependencies on the current version for free. Just be sure to be very clear in the description that it REQUIRES the original version. After an appropriate grace period remove the dependency and increase the price. Also be careful not to be too vocal about your intentions to convert the free asset to a paid asset. An example would be UFPS of an asset that has add-ons.

I'll speak for myself when I say I wouldn't have a problem with spending a few bucks on the add-on so you can minimize people "purchasing" it for free, simply because it's free.

 

As long as it's possible (and not impossible, as it is with the current system) it sounds reasonable, as it could always be a "possibly in the future" type of addition.

I think that this falls under "not your problem". I can totally understand wanting to be as easy and supportive as you can, but you can't expect to support every third-party asset. Us developers have to have something to do.

That's disappointing, but I still think that the proposed changes have more positives than negatives.

I think splitting the asset would start down a path to development being discontinued on at least one of them in the near-future. One of the assets would inevitably sell more than the other, one asset would require more support, and eventually one, if not both, would be discontinued as you get burned out trying to support two similar, but discrete assets.

I would suggest archiving the current version, and continuing on with your proposed changes. Anyone who buys it can still request archived versions, so if they need something the current DunGen has, they can request the archive. Otherwise, I think your new changes will make this an overall-better and more flexible asset, with a few restrictions that are completely understandable.

You can't support every kind of dungeon ever -- I'd pick the most popular kind and make it the best generator for that particular type (like you've already proposed).

 

With this part I completly agree - maintaining two similar products may end in having 2 products which are not what you like to be. Additionally, based on the code-base, it may introduce the problem of generating unwanted bugs 'cause in your mind you were in DunGen1 and doing some bugfixing but in reality you were in DunGen2.

For this part:

and this part

have the emphazes of beeing a bit rude.

Let me explain why:
As mentioned, intially one of the benefits of DunGen which make it stands upfront from other generators already was the total freedom of building rooms in any shape and type but still have an random dungeon everytime.

There are already several grid-based (even multi-floor) dungeon generators out there. There was a reason why I choose DunGen. By the way, with the current options it is already now possible to generate multi-height dungeons with Dungen - you only don't have the ability to have 'doorways' on the floor or ceiling directly.

Now as you mentioned, the proposed changes are better and say that everybody can live with that restriction. I for myself, don't like to have an grid-based dungeon generator again - this means I can't live with it. I have made several of those already and I want to have more uncommon dungeons. If you may want to tell me that DunGen isn't then for me.. than it should be, but it's not what was in the inital package.

Coming back to what you mentioned of making the best generator of that type - I would counter you and say, it would be perfect to get rid of grids (already there currently), hopefully find a way to get rid of the limitation of the AABB collider to have more freedom with placement of doorways, etc. I don't think the 'archived' version for those who want it would be an option as well - how to deal with bugfixes (if needed) etc.. it would be again a 2 version type of thing.

Nevertheless, I will see were DunGen is heading as the decision at the end is Aegon

BR
Wyl

 

If it came off as rude, I didn't intend it to be so. I was a bit blunt, but it reflected my opinion accurately.

I was actually about halfway through a post that was aimed largely at countering the points you brought up, but I realized that it wouldn't accomplish anything. We're at opposite sides of this argument, and there are merits to each side. Personally, I believe the changes proposed would be a huge boon and ultimately make DunGen the superior dungeon generator, but I can see your points as well. No point in arguing semantics.

 

In addition to randomly placed rooms or instead of?

 

I think the meaning was that the rooms are placed randomly in the beginning of the dungeon generation and afterwards connecting all of them with corridors.

Which brings me down to a further question: How would we control the 'grid size' of the dungeon? How can it be guarenteed that no dungeon fails to be generated - in addition to adding branches etc? If the grid size is to small, maybe it fails to put the number of rooms into it - on the other hand, if its to big it ends up to have endless corridors. And additionally, it maybe needs alot of crossing corridors which could be counter-productive to an dungeon flow?

 

I also agree that the proposed changes would be overwhelmingly beneficial with all that they bring. You can do a lot within a grid system while still giving the external impression of something quite varied, particularly when you cleverly hide the designated boundaries with a more interesting visual mesh.

The advantage is that you suddenly 'know' the bounds of a room and can then set about running algorithms to join them up without worrying about low level fitment. I'm biased as I'm building everything myself, and can't imagine approaching the task without standardising a minimum unit of size, even if it's not currently a firm requirement. It's practice that pays off significantly when you set other items up, knowing a doorway will always line up to the nearest metre for example.

I do respect the asset is unique in the store in that it doesn't rely on grids, but I also believe you could easily achieve as much complexity with grid aligned rooms as without, assuming we are limited to doorways facing along xyz axes (and the art assets you have are actually made that way!) in fact, you could have a doorway facing along the x direction, but with the frame visually 45 degrees offset, and a player would think it was a diagonal connection.

Appreciate it would be a lot of work to convert a system of arbitrary rooms to the grid, so understand hesitation to make the change.

 

Incoming essay...

In addition. If you've played Diablo, it's kind of like what Blizzard do with some of the campaign areas, important tiles can be hand-placed and the rest of the dungeon can be generated around it. I just mentioned that as something that could be possible with the proposed changes since it's something that I've had people ask about and it's not possible with the way DunGen currently works.

The actual size of the grid could be adjusted as the rooms are added, the grid cell size is the only thing that needs to remain constant. To avoid crossing corridors as much as possible (if that's what you want), I can use a path finding algorithm to work around what's there. With the proposed changes, it would also be possible to control how tightly packed rooms are to a certain extent so you won't have really long corridors unless you wanted them.


The results from the proposed new system would be the same as the current version, the only thing that would change would be the requirement for tiles to fit within a box that has dimensions that are multiples of a constant grid cell size and that doorways would need to be placed on the edge of this box. If I can guarantee this, then it reduces the complexity dramatically and allows me to implement some more complex functionality into DunGen.

Just to clear up any confusion, here are some examples of the tiles you could make with the proposed new system:



The bottom tile is a complex shape and some parts of it don't align with the grid. The only important thing is that the doorways (red) align with the bounds of the room (blue) and that the dimensions of the tile boundaries are a multiple of some constant grid cell size.


I'd like to point out that all three web player demos already adhere to this restriction - I thought it would be a non-issue since snapping to a grid is generally the way you handle modular assets anyway (this only applies to the bounds of the room, anything contained within can be wherever you like). I hadn't considered getting assets from different sources and having them all be different sizes though.

I'm not really sure how to handle this now. I do think the proposed changes make DunGen better in general and open up the opportunity to add more features that currently just aren't possible. But I obviously don't want to move DunGen away from what made people interested in it in the first place.


I suppose with the current layout generation method being limited in terms of the new features I can add, once everything on the roadmap is done there's really not much more I can do. I could finish everything on the todo list in the current version and have version 3 move onto the new system. Version 2 would still be available from our website for those who want it and I can still provide bug fixes and support, it's just unlikely to receive any new features.

Honestly, I'm not happy about the idea of archiving the current version but I'm also not happy with the way DunGen is currently working. It's just not robust enough for most people to consider using in a production environment and it won't be until I can remove the chance that it will fail. I'm not going to do anything just yet, I'll think about it for a while and welcome any other comments/questions/concerns people might have.

 

Hi, I was going to provide some graphic examples of what I thought you were driving at, as on reflection I didn't articulate my point well. But the above perfectly illustrates what I meant by 'particularly when you cleverly hide the designated boundaries with a more interesting visual mesh.'

I guess an extension of the feature could be to have an overall conformal dimension for each room, and then additionally have some kind of interface to tag the grid units within the boundary that are 'occupied'- this could mean getting fitment approaching tetris pieces. You'd need to step through the height of each room this way too, for rooms that are more than 1 unit high.

For example, the top left hand layout in your image. You would tag all but that lower quarter of 9 squares as occupied. Then you could have another room nestle into the unoccupied area. You'd thereby achieve more freedom to make interesting layouts, in fact more freedom to do this than currently.

 

Reading your explanation (and thanks for the pictures) as well as the response from ddnharris as well as some further thinking myself...and evaluating other tools as well (e.g. ProBuilder).

First of all, if I talk for the minority and if you consider yourself already that the current version you build DunGen is limiting yourself already I'm for an move to the grid based version as well

Wouldn't it an idea - taking ddnharis into account - as we would already define a grid that you include a grid layouting function into dungeon that everybody sees when they violate that layout. Additionally, when you use the grid layout, wouldn't it possible to set some flags on it that DunGen knows which one it can use and which one not? E.g. flag all of the floors from the first room as 'occupied' and the other nine in the lower right corner as free? With this option the algorithm wouldn't need to rely on the AABB but only on the information from the grid flags.

Additionally, maybe there would be again the possibility to 'flag' vertical/horizontal grids with a doorway-component - if dunGen is using it, it will be replaced by the defined doorway type.

Only some brainstorming.

With all the changes you should really consider why someone should choose DunGen and not other generators from the asset store, i.e. what are the selling points (currently local probs, global probs, lock and key system and the total freedom as long as there is no movement to the grid).

BR
Wyl

 

Can't you just use a mode switch?

It seems like you could have the current mode of DunGen be the default mode, and if a checkbox is checked in the inspector ("Grid Align = X"), then you apply the new rules.

That way you don't throw away any of the original functionality, and you can add the scripts that provide the new functionality.

 

How about allowing us to run a batch process testing out the random keys, and only keeping the ones that work?
That way I could keep all the current benefits and still ship a guaranteed 10,000 working levels. Or 50,000 if I let the generator run longer.

 

Yeah, I think going for a tile-by-tile approach rather than an AABB for room bounds would probably be best. I had some concerns about doing that but actually thinking about it, it shouldn't cause any problems and would finally give you complex tile collisions (plus it's much easier to implement than it would be with the current system).

I think it would be a good idea to have some sort of grid visualization and possible snapping if I went with the proposed changes. That's definitely something I'd be looking to do.

While I haven't looked through all (or even most) other procedural generation assets out there, of the ones I did find, none let you design the rooms by hand.

I'd like to avoid that if possible. I think it would make DunGen bloated and more difficult to maintain. Also, later on, when new features are added for the new system, that would likely break compatibility (for example, if the new system supported loops in the layout, I'd need two copies of the dungeon flow editor to handle both cases).

That could work. Although it would take some time to run through. If each dungeon layout only took 60ms to generate, creating 50,000 would take 50 minutes, and that's not accounting for the layouts that fail, so you still might not have 50,000 usable layouts. I suppose a relatively lengthy build process once before release wouldn't hurt - though it would need to be repeated whenever any changes are made to the dungeon.


NOTE: I'm still not sure what's happening with DunGen just yet. I'm just saying "the new system" because saying "the proposed changes" in every sentence is getting annoying to write, and probably even more annoying to read.

 

Feature request: progressive map generation.
(DunGen working something like super-SECTR STREAM.)

This feature is a bit specialised but could also help to avoid failed map generations. It uses the key feature of DunGen: fitting two tiles together without bounding mesh intersection.

If I am using closed-in tiles (rooms, not outdoor tiles) then I only really need the current room and the rooms connected to it. It would not really matter if the map looped back on itself and later rooms occupied the same space as earlier rooms. As long as the player could not see it then it would not matter.
In fact, there would not even have to be a map. When the player moved to a new room the next rooms would be selected and joined to selected doors. And old rooms (connected to the previous room) could be destroyed.

I could store the state of each room (doors opened, puzzles solved, monsters, dead bodies, empty treasure chests, etc) for later reuse. (It would be nice if DunGen could automate the store/restore.) The random number seed system could be used to make sure the same rooms appear on the way back, or it could just be stored. Or I could just force the player to keep moving onwards using one-way doors.

This system would also allow for endless dungeons.

Performance is likely to be high on all platforms. Occlusion culling would be implicit.

 

This is a really good example, actually. Most shapes will fit into a rectangle of a given size, so you're actually not losing that much freedom from a grid-based approach. More complex shapes just take up more grid cells.

I also wanted to point out that you could, feasibly, even make diagonals, just so long as the ends are straight so doorways line up on the grid.

I've yet to find one that lets you design rooms like this (that's why I bought this!). That's also why I've been a strong advocate of the new system, as you get the predictability of a grid-based approach, while having the freedom of hand-designed rooms (and even randomly-generated rooms, like you said earlier).

Also, on the subject of assets of a different size, couldn't the designer just make the grid a factor of the least-common denominator? (Like, if you have assets of 4, 8, and 32, your grid-size could be 2 (or 4, even, in this case)).

Alternatively, you could just warn the designer that your algorithm is having trouble piecing their stuff together.

 

As cool as endless dungeons would be, progressive dungeon generation isn't something I can support in DunGen. There are just too many features that rely on the dungeon being generated in advance.

Yeah, that's something that would work in most cases. It won't work quite as well when your assets are really odd sizes, but then I'd question why an artist would be making a modular asset that's 1.3653 units wide in the first place.


Anyway, here's a breakdown of my current idea for a possible new layout generation algorithm:

1. Place first room
2. Place a new room on top of the last
3. Pick a doorway on each tile to be connected later
4. Nudge the new room until it's no longer colliding with any other (with a customizable buffer size). The tile is more likely to be nudged in such a way that the selected doorways are facing each other (also probably customizable).
5. Repeat from step 2 until all tiles are placed
6. Connect all of the marked doorways together
7. Continue the rest of the process as usual (props, lock & key, etc)

And here's an example of how I expect it to work:


To avoid any confusion: in the above animation, the doorways just aren't marked until they're chosen to be used - you'll still handle doorways the same as in the current version.

I haven't actually started programming anything so there's a good chance it won't work as nicely as I think it will. I'm still welcoming any comments/questions/concerns/suggestions about the proposed changes, nothing is set in stone.

 

Hi there,

the short animation remindes me a bit on the generation of the dungeons from TinyKeep.

One thing to consider: If you go that way, I think that corridors more or less a must. You mentioned earlier that you want to have that piece costumizeable from 0 to 100%. I don't think this will (at least in the first iteration of the new DunGen) be feasible if you want to guarentee that every dungeon will work. I think this should work as well and will be only a soft limitation.

Looking into the creation of TinyKeep dungeons and the above animation, I was thinking if it wouldn't be the best way that the dungeon creation is based on 2 layers. The high level layer would be the node itself and at the beginning it populates the node with all the different rooms. It then moves the room from the center to the outer bounderies as long until no room intersects with any other.

In the second stage (as it knows the final sizes of the nodes) all nodes again are starting from the center overlapping each other and drifts them away until no room/corridor intersects between the nodes.

You mentioned additionally that there is maybe the option to preplace 'strategic' rooms like in diablo. I would suggest to handle it in that way that those rooms are again only a node in the dungeon flow and not fixed somewhere in the scene or the grid. That way you have still full control.

Hope what I have written is understandable - otherwise I will try to sketch some programmers art to further clarifaction.

BR
Wyl

PS: Yep, I missed the creation of rooms within the random enviroment as an key selling point in my last post.

 

Absolutely agree with Wyl- pre-placing strategic rooms would be great, but would make most sense if you were placing them within the generative system, as a 'node', rather than in the scene itself. Maybe you could even have a layout GUI that allows the user to save a bunch of different templates for later (can imagine you might want quite complex, sprawling layouts for high-level dungeons)

Seems like corridors could be repeats of single units long items, with single 90 degree turns, and then mesh combine once placed? or somehow procedurally extend to fit the required length?

Would also like the possibility of room to room connections if the room grids happen to line up, so you don't always have a corridor. Between the green and red rooms in your animation for instance.

 

I bought DunGen for first-person games. WebDemo 2 really caught my eye. I particularly liked the way the map was three dimensional, and you could walk over and under other parts of the map. And in WebDemo 3 there were ramps and stairways.

I'm not too impressed by the idea of planar, rectilinear levels. I've seen too many of these. And way too many boring, samey corridors! Procedural dungeon generation has been around since Rogue in 1980. A quick search of the Asset Store found at least 6 procedural or modular dungeon generators.

I would like to encourage Aegon Games to keep DunGen standing out from the crowd. To me, Dungeon Flow, tiles being 3D prefabs, doors at different heights, and random props are key selling features.

 

Right.
So how about the more relaxed collision detection by only looking one room ahead and behind when laying out the map?
How about instantiating and destroying rooms as the player moves through the map? Or maybe disconnecting them and moving them out of the way - anyway, just making sure map collisions are not visible to the player.

 

My intent is for none of that to change. Dungeon flow, tiles as 3D prefabs, and random props are all unaffected by the proposed changes (and in some cases, can be improved upon because of it). The multi-floor capabilities of DunGen is the only thing I'm still looking for a solution for - although even that might "just work" if I extend my idea to a 3D grid.

I won't be removing existing functionality - the intent of the proposed changes is to make DunGen more robust so that I can add more features.

 

I think with the adding features and most propably going grid based, the biggest hurdle will be what is the most user friendly option to go full 3D.

For me currently is getting more and more the question, when you will make the decision how and where to move on with DunGen and what does it mean for the current prefabs for it. I'm currently holding off with using DunGen - or better to say with creating room prefebs - as I'm unsure if I will stick with 2.2.2 of DunGen or will move to 3.x ff as it fits the bill. I don't want start over with the rooms afterwards if I move to 3.x

Any idea when you will start with the decision and the requirements? And any idea when we will have access to the new version? Would it even be an option to have some sort of internal 'alpha/beta' testing with growing function for selected customers?

Thx in advanve
Wyl

 

If I decide to go with the new system, it's going to take a while before I get it into a usable state. I'd suggest sticking with what you're doing for now. I'll try to make the transition from 2.x to 3.x as seamless as possible - if you're planning on transitioning to the new system later, pick a grid size and stick to it when placing your doorways. That way, you shouldn't have to remake any of your rooms.

I'll think on it for another couple of days then if I still think the new system is the better option, I'll start working on it. It'll take at least a few weeks, maybe a month or two before I'll have something to release though.

I'd like to allow automatic alpha/beta access to anyone who has purchased DunGen, so I'll see if I can get a system for that set up for when I've got something that can be tested.

 

Very much in favor of the grid based direction. It has a lot more flexibility than people realize.

 

Hi AegonGames,

When DunGen fails to generate dungeon ( as there is no guarantee of 100% success in dungeon generation, especially when it get complex ), is there a "way out" for us to reach/load other scene, instead of get "stuck" with the current scene where DunGen fail.

eg, if DunGen fail to generate a dungeon, we should be able to load another scene, instead of get stuck with "Fail" scene. Maybe an option in editor/inspector for us to input/specify which other scene to load ( and clean up unused resources/assets , if any ), if DunGen fails to generate.

At the very least, if a player encounter such situation where DunGen fails , they are able to continue thru other scene.

Thanks

 

The DungeonGenerator class has an OnGenerationStatusChanged event which you can hook that'll let you perform some custom logic when the state changes to "Failed". You could load a different scene or you could try to generate a dungeon using a different seed whenever it fails.

I'm actually thinking of removing the failed attempt count limit while not in the editor. It would still be there for you to see when your dungeons aren't being generated effectively while developing your game, but in a release build, DunGen would just keep trying until it succeeds. The limited failed attempts were mostly put in place to prevent situations where the editor would lock-up if it was impossible to generate a dungeon layout.

 

For what it's worth you should move to the new system to build the product into what you visualize it becoming.

With that said, could you add this to the roadmap: support for generating in the XY plane? Rotating the generated map is causing me problems when building out rooms. Thanks.

 

Thanks, I've added that to the roadmap.

 

DunGen is 50% off for the next couple of days

 

I like the sound of the new system

 

This plugin can generate dungeons only in runtime? It's possible to generate dungeons using Unity Editor?

 

Yes, it can generate dungeons in the editor as well.

 

Hi Aegon,

wanted to drop a note if you came to any decision?

BR
Wyl

 

I've been keeping an eye on this asset since it came out (finally grabbed it due to the sale ) and think of it as the best level generator on the store. It's freeform level generation and multi-tiered customization and randomization is unrivalled by anything else I've seen (the SectR integration is awesome too, I'll probably have to pick that up now).

That being said, I think you should go ahead with the new system. When you say grid-based, it brings to mind other tile-based generators where each grid element is a sizeable area, whereas the system as you describe seems much more flexible and granular. Monitors are grid-based systems, but they are capable of displaying every digital artwork ever created; it's simply a matter of using the appropriate resolution. However, I would definitely recommend going for a 3-dimensional grid, as that retains the current functionality and really opens up the possibilities.

I'm looking forward to seeing where you take Dungen from here on out.

 

Sorry for the late reply. I think I will go with the new system but the final verdict on that will have to come after I've made some progress on it to see if it works out as expected.

Thanks!

I absolutely will if I can get it to work. If I can't, it might even be better to just stick with the current system, rather than effectively remove a feature many people use.

 

Hello Aegon

There seems to be an issue with dungeon tile prefabs having more than one sprite renderer attached to them. I want to add a highlight for every cell in my tile which I will enable/disable at runtime later. Having one child with a sprite renderer attached works fine...



... but as soon as I add another DunGen fails to generate a valid layout.



Any idea why this might happen? All three Sprite Renderers are part of separate game objects and it seems to work fine outside of DunGen.

 

The initial tile set I used to create prefabs worked great but the one I've been trying to use now (which looks similar to your tiles btw) have given me nothing but grief and I haven't been able to work out why. I'll have to check the sprite renderer's later when I'm home to confirm whether my issue is the same.

 

Sorry for the late reply. I haven't been able to reproduce this - I tried using multiple sprite renderers in the demo scene and everything continues to work. I should point out that all colliders and renderers (including sprite renderers) are considered when calculating the bounds of a room. Is it possible that your sprites are overlapping the doorways slightly?