DUNGEON MASTER

OVERVIEW

Genre: Roguelike, Auto-Battler, Strategy
Engine: Godot 4.1
Duration: 12 months (ongoing)
Team Size: 2
Role: Director, Designer, Programmer

ABOUT

Dungeon Master is a reverse-roguelike, where players control the monster at the end of a dungeon, and their goal is to guide the Hero in defeating them.The game emphasizes planning and risk-assessment, as they use Curse (equivalent to Mana) to summon monsters that the Hero can gain XP from, while trying not to defeat the Hero entirely.The game is currently in beta development, following a successful paper prototype phase.

Key Skills

  • Project Management

  • Systems Design

  • Prototyping

  • Balancing

  • Playtesting

  • Artistic Direction

PRE-PRODUCTION

Dungeon Master was inspired by the act of grinding in RPGs, and began with the idea of an auto-battler where you control the enemy team. The player would have indirect control of the protagonist, instead choosing the enemies they face with the goal of making the protagonist stronger with XP and items.Encounters would happen one at a time, before culminating in a powerful boss encounter which would test whether the protagonist had gotten strong enough. The difficulty curve was inspired by Risk of Rain's system where players can stay in a level to gather all the gear, but the game scales in difficulty with how long their playthrough has lasted.

As the game evolved in scope, its systems were designed to be simple to iterate upon. A perceived fault in many roguelike titles is a lack of content or updates, where successes in the genre such as The Binding of Isaac and Vampire Survivors created a set of strong central mechanics that are easily and rapidly iterated on.As the game evolved in concept, 3 design goals were chosen:

#1 The player never directly controls The Hero

#2 The player should be able to predict and follow all outcomes of an encounter

#3 In relation to #2, the game should never be solvable

PROTOYPE

The first prototype was developed using an online playing card tool called playingcards.io. Using a tool like this allowed for rapid development, prototyping and playtesting.One restriction of this format was the lack of ability for any scripting and computation. This meant that many operations that would be trivial in the digital version, like damage calculations, were tedious and time consuming in the prototype. This restriction lead to an increased effort and awareness on how much mental load the player was under at any given step, and trying to spread that as evenly as possible.In the end, this restriction lead to more interesting design decisions. For example: the Vampirism trait originally restored some HP on hit, however, this overlapped with other traits that had an on hit effect, as well the the damage calculations themselves. Instead, the trait was reworked to restore a portion of a monster's max HP on death, leading to other unique interactions, and added strategy.

At this stage, the game underwent frequent playtesting by myself and others. This was crucial in adjusting balance, and discovering areas of the game that were uninteresting, or too cumbersome for the analogue prototype.Two notable problems that were revealed during playtesting were that players didn't have enough incentive to utilize monsters like the Ugly Goblin, which had an effect to buff other monsters, and that players couldn't rely on when items would spawn.To account for this, item drops were changed from a flat 30% per encounter, to 10% + 10% per monster played. Additionally, the Ugly Goblin was reworked so that it added an additional 20% to the item drop rate.Afterwards, players felt far more rewarded when items spawned, and the Ugly Goblin saw far more frequent usage.