This asset provides all the essential components you need to start making your own first-person grid-based dungeon crawler, in the style of classics like Eye of the Beholder, Dungeon Master and Legend of Grimrock. Let players create a party of varied character classes and have them fight, solve puzzles and loot their way through intricate, multi-level dungeons. The project is built on well-organized and commented blueprints, using a heavily data driven design which makes modifying and extending the toolkit simple, even for non-programmers.
This toolkit contains many assets that were not made by me, but which are licences under liberal creative commons licenses. I am extremely grateful that these amazing content creators have made their assets freely available. Without having access to these assets it would have been a much bigger challenge to create good looking game examples. You do not need to buy the toolkit to use these assets as they are freely available elsewhere. The included assets are as follows:
A new tutorial for the Dungeon Crawler Toolkit is live. The tutorial explains how to add new stats to DCT and use these to add new game mechanics. As an example I show how to implement a hunger system in DCT.
There are five enemies included. Three different slimes (normal, fire and ice) and two skeletons (normal and lich). They have varying difficulty, size and abilities. But perhaps you meant something else?
Hi DredyKabal, this is a pretty complex question, so I thought the best way to answer is would be to give you the steps for achieving this. The suggestion below is a relatively quick mock up, so there is plenty of room for improvement, and depending on how you’re designing your game you might want to do things differently. But this should hopefully be enough to get you started.
I will be using the SK_Slime skeletal mesh as a placeholder for representing the player characters. I modify the skeleton of this skeletal mesh and add two sockets to its hands for holding items:
Next I’m creating a new blueprint for representing our visual player characters in the game. I’m calling it BP_CharacterActor. I add the slime skeletal mesh and a couple of empty static mesh components for holding items. I attach these components to the two sockets we just made:
Next in the event graph of this actor I add two events that respectively move or turn the actor. These will be driven externally by our DungeonPawn:
I also add some code for changing the appearance of our held item meshes when an item is equipped, as well as an event for animating the skeletal mesh when an item is used:
Ok, our new blueprint is done. Time to hook it up to our DungeonPawn. In BP_DungeonPawn I’m creating a new variable that will hold references to all our CharacterActors, as well as keep them paired with the appropriate BP_PlayerCharacter object. It is a TMap with a BP_PlayerCharacter reference as a key and BP_CharacterActor as a value. I’m calling it CharacterActors. At BeginPlay I loop through all the PlayerCharacters stored in the game state, create a CharacterActor for each, place it in a simple grid surrounding the center of our pawn and add them to our CharacterActors TMap, like so:
I increase the length of the SpringArm to 200 and hit play. We’re getting somewhere:
As soon as we move the slimes stay put, though. Time to hook up the pawn movement code to the events we made in our CharacterActors earlier.
This is part of the MoveStep event:
And this is part of the MoveTurn section:
Great, now we’ve got our slimes moving along with our pawn, but we still cannot visualize them equipping items. This is going to take some work.
We go to WBP_Slot, the widget blueprint representing inventory slots. We want to add functionality that can affect other blueprints in our projects, like our CharacterActors without making our code too spaghettified. Event Dispatchers are a good fit for this. I add two new event dispatchers to WBP_Slot, to be called when items are equipped, unequipped or used. I have them take a WBP_Item blueprint as a parameter:
I call them in them in the following places:
Ok, so far so good. Now we need to tie these interface events to the appropriate slots and call our item equip and use events from there. We can use WBP_MiniCharacter for this, which is the tiny “character sheet” that shows our portrait, health and what items are equipped in our hands. Here is what I do:
And there we are! We are visualizing our characters, they are moving along with our pawn, can equip items and animate when the items are used. Clearly there is much room for improvement, but this should give you something to build upon:
Hi, I asked this on the discord, but maybe it’s better here for posterity. Does the DCT integrate with your other kit, the Advanced Turn Based Tile Toolkit? That would be some awesome functionality if it did.
Hey, they don’t integrate super easily out of the box, but with a bit of work it should be possible for them to borrow quite a lot from each other. I am planning on creating a tutorial for this in the future.
Just submitted a new DCT update to Epic! It should be live in a few days. Check out my Trello for an overview (The list titles v.1.1): Trello
The biggest change is the modular item rules, which allow you to define rules for when and where items can be added to/removed from slots and when they can be used. Rules are added to two new arrays in the item data table and defined within two new types of Object blueprints. This consolidates a lot of the rules that were previously spread over multiple locations, such as needing to have enough mana to use an item, not being allowed to pick up passive powers, having to wait for item cooldown etc.
Utilizing these new rules I’ve also added bows that require ammo and a greataxe that requires two hands to use.
Also: Secret doors!
v1.1 (sent to Epic)
Modular item rules for when items can be added to/removed from slots and when they can be used
I have tested converting DCT to UE5 early access and everything seems to be working fine. The appearence of the UI is different due to different defaults in the engines, but I can’t see any issues in the gameplay logic. If you are porting over a dungeon map from UE4 to UE5 you might have to recompile some of the BP_Interactable actors in the scene to make sure their grid placement is updated, but that is the only small issue I’ve encountered so far. I’ll be continuing to test DCT out in UE5 and will do my best to make sure that converting a project is hassle free.