DCDB (Dungeon Crawler Deck Bulder)
Description
DCDB (Dungeon Crawler Deck Builder) was a personal project that I worked on for about a year to test out a combination of mechanics.
Pre-production Design Process
I set out to create a deckbuilder in the style of a classic Dungeon Crawler, like Wizardry or the Gold Box games. I started with a list of cards and enemies that made up my major strategies. I wanted to include character creation, wherein the player forms a party of a variety of classes. These characters have their own experience bars and levels, which would unlock class-specific cards. Otherwise, you would acquire more generic cards that any character could carry from combat encounters and merchants. I also used a procedural generation add on in Unity called “Dungen”, which allowed me to easily create tiles that would connect when a new level was needed. By putting combat triggers on these tiles, I could easily test a random series of combat encounters.
Iterations on Combat
I began with cards being very similar to reference games, such as Slay the Spire and Gordian Quest, wherein specific types of characters (in this case based on class) acquire permanent cards based on their level. In testing though, I realized that I could easily include randomized effects on cards, such as gaining HP on play or dealing additional damage.
What Went Wrong?
Inventory management for the party proved to be very tedious. I spent a lot of time working on the UI for deck viewers and party trading, and the design was not going to be viable for Gamepad support (which was outside of my intended scope but is a smart thing to design around anyway).
For the encounters, I wanted to take inspiration from dungeon crawlers where there is a seamless transition into combat from the first-person exploration mode. At first, I drew the cards and the enemies both on the Screenspace UI layer, but that meant that I was unable to take advantage of shader effects, post-processing, and lighting on these elements. It made the enemies look very out of place. So instead I spawned the enemies in world space as 3D objects with a billboarded sprite. While this created a more cohesive visual style, it was very difficult to account for which direction the player entered the encounter from and the distances that looked good from the player’s perspective. I tried including a command to unlock the camera, which would traditionally be static during a combat encounter like this so that enemies could be outside of the camera’s initial view. This somewhat worked, but due to the perspective, UI elements on the enemies would easily become distorted. The shader effect on characters also looked weird when characters were far from the camera. It was an interesting experiment, but I think it needed more consistency from the level design to shine.
Engine choice. While I was working on this prototype, Unity Technologies unveiled their controversial new pay-per-download plan. As a solo developer, it told me that Unity was going to become completely unviable for any small-scale commercial game, as well as would become less valuable compared to alternative engines for mid-sized and even larger studios. Given this, working on personal projects in Unity felt much less valuable as both a learning exercise and a potential commercial endeavor.
What Went Right?
In an iteration of the cards, I added limited-use cards (inspired by consumables from Griftlands), which I brought over into my next game. The idea is inspired by The Legend of Zelda: BOTW and TOTK. In this game, it was burdensome due to the aforementioned inventory management between characters. But it has legs in a game where you play a single character and have a single deck to manage.
Dungeon Crawling Reward Loop: The benefit I found with limited-use cards, is that there are interesting decisions to be made both in the card design and how the player benefits from these cards. Generally in a deckbuilder, cards are a resource that has a cost to be both acquired and removed. But if a card has a limited number of uses, the only cost to the player to remove that card is to use it a certain number of times. The risk to this approach is that the player feels limited and wishes to hoard their cards for fear of needing them later. I decided to play into this by giving cards value, which they can be sold for at a merchant. So there are benefits to keeping cards that may not even be useful in combat, in the hope that you come across a merchant that you can offload it to.