@Ratamorph Thanks for the bug report. I’ve fixed the issue and it will be available in the next update
Automatically apply different themes to various parts of your dungeon using the new clustered theming feature
It groups all connected corridors together into clusters. The room and corridor clusters are then applied different themes automatically without having to deal with volumes
This will help in adding variation to your level. The following level uses 3 different themes
I’ll create a more beautiful example with the Hell Forge demo
You do this by enabling clustered theming from the configuration
Then assign the themes you’d like to add on various clusters.
Here is how the clusters are created (debug data, each color is a cluster)
Height variations will also be taking into consideration as long as it is able to reach it (though a stair). It can also be turned of (notice lower right corridor)
The system is generic enough to allow different builders to also use this feature. For now, only the grid builder uses it
Hi Ali Akbar, I really appreciate the viral and horde-forming mechanics in Zombie City. In my opinion, one of the most effect uses for Zombies, I wish more Zombie games would take advantage of the Viral mechanic.
City Builder is looking really nice. Atter viewing the Zombie City, I can definitely imagine putting City Builder to use in developing a Alien Invasion Survival/Crafting Game concept I’ve been stewing over. Keep up the awesome work!
Thanks, Looks good! I am still on DA 2.2.0 since some of the bugs mentioned in later updates worried me and I have built a lot around the query feature. The clustering feature removing the need for volumes would be nice, making it less level dependent for a runtime project and giving the ability to override whole corridors, which is exactly what has been a struggle
Hey, a quick feature request, it would be nice to be able to drag static meshes and actors from the Content Browser and drop them into the graph of a Dungeon Theme, automatically creating the proper Mesh or Actor node. This would make the workflow for creating a new theme much quicker!
EDIT: Found a bug. If an Actor has a Child Actor Component and you increase the Cell Size of your dungeon, the Child Actor’s positions do not update.
Nice to have more control over themes and the avoidance of too many themereplacementvolumes scattered all over the level is a nice addition, too.
Will be really handy if used in conjunction with the “gameflow” editor on which you work. Entrance, exit, bossroom or library with clustered theme control will be great.
Studying the screenshot of your debug dungeon I found some problematic areas in the layout. Stairs that are at room borders are not only visually very ugly but can break
gameplay as unreachable areas where doors meets stairs could be generated.
Is it possible to limit heightvariations to corridors and suppress them near rooms? I really like having heightvariations in the random levels but it’s problematic without control.
@RoyAwesome That’s definitely a useful feature and is on my todo list. I’ve tried to implemented it a few weeks ago but couldn’t find a way to get the drop event from the graph editor. I’ll have a look at how the blueprint editor does it (when you drag drop function names into the blueprint editor) when I get time
I just tested and couldn’t reproduce the bug. Could you give more info on how the blueprint is built?
@Laurentius it should be possible, I’ll add a flag after the next update (2.5+)
I’ve tested this again and the physics constraint doesn’t work if one of the components is static. I’ve fixed the issue and it will be available in the next build
The issue is fixed and will be available in the next update. This was caused due to an optimization I have while rebuilding the dungeon. On a rebuild, previous dungeon actors that are similar are reused and just moved around (instead of recreating them). I’ve added a flag to mark all actor node created actors as complex actors. These actors would not be reused and will be recreated. This will make the physics and everything work correctly by destroying the old ones and recreating them again. The destructible actor is also marked to be recreated (as we want the fractured mesh state to be reset on a dungeon rebuild at runtime)
@dkoding The physics constraint works fine with the latest dev build at runtime. (Note: I had to move the door a bit up (~15 cm) so the door does not collide with the ground and was not opening)
@dkoding actor scaling issue is fixed
I’ve uploaded 2.4.0 to the website. I’ll test on Mac and submit to Epic for marketplace update
- Clustered theming allows different themes to be automatically applied to different parts of the dungeon. This helps in adding variation to the level
- Event listeners can now modify the marker positions before they are sent to the theming engine, giving more low level control
- Added an experimental city builder to build simple city layouts
- Added variations to the city builder by randomly merging nearby city blocks
- City blocks of custom sizes are supported (e.g. 1x2, 4x5 etc). This helps in placing larger structures (e.g. parks, parking lots, larger buildings etc)
- Fixed scaling issue with actor nodes
- Fixed physics errors with certain actors while rebuilding the dungeon. Actors spawned by the actor node are not reused on a dungeon rebuild. Instead, they are destroyed and recreated to avoid physics errors
- Dungeons spawn in the correct level when used with world composition, instead of always spawning in the persistant level
- Fixed lightmass warnings on light actors while building lighting
- Added a helper function in the Isaac builder to clear the styling information from specified isaac room (useful for creating large spawn / boss rooms)
- Added new misc examples in the quick start guide
Quick start guide has been updated for 2.4. You can download the new sample content (Misc examples) from there
Rad, thanks for the fix! It was a minor issue, but i’m glad you found it and fixed it.
Really happy for these bug fixes! Can’t wait for Epic to approve the new version.
I have my dungeon set for manual painting only, (0 cells) and am painting it at runtime. Problem is the cells never seem to combine to make a room. They stay areas with fences instead of rooms with walls. Did I miss something somewhere or is this a 2.4 thing?
Thanks Ali, looking forward to testing it!
Hello Ali Akbar, I’m curious if there will be an all-in-one pacakge for Dungeon Architect | Landscape Architect | City Architect?
[MENTION=28980]Ali Akbar[/MENTION]: City Builder … 10 points … it is awesome. I got a chance to work with it last night and it is really cool. I will upload a screenshot when I am happy with the final result.
Just a quick question for the meshes.
I am assuming the pivot points should be centered on the mesh?
What direction should the mesh be facing ideally? (i.e. x or y facing)
I need to modify the meshes I am using and just wanted to make sure I get it right and not waste time with multiple imports and edits. 8-}