Designer Diaries – Ananda Guneratne

Designer Diary: Corrupted by Ruin #3

I think I’ve figured out a workable system for combat in Corrupted by Ruin. The biggest constraint is that it must be fast and uncomplicated since each hero incursion potentially initiates multiple encounters. Forcing players to go through the same actions many times will get repetitive. The natural model for quick, simple combat is an idle system where the player sets up the battle and lets it play out. Just think of Loop Hero, where the player speeds through hundreds of fights in a run. So I decided to have a similar system, where combatants have health bars and cooldown timers and attack random targets.

Idle combat comes with its flaws. My chief concern was that it would muddy the differences between different monsters, which happens in “Hero’s Hour.” I think I can get around this by limiting the number of combatants on each side to eight, but this still leaves the question of how to distinguish monsters from each other without the ability to select actions. And I think I have found the answer – a variant of my idea to incorporate Spirit Island threshold mechanics, but one that treats monsters and heroes as asynchronous element converters.

Here is how my new system works. Each creature has two or more actions, each with a priority. It goes through its list in order until it finds something it is capable of doing. Each ability may have an elemental cost and might produce some elements. However, these are available to any creature on either side of the fight – for example, the heroic cryomancer might use the water element your slime produced to boost a spell, or your salamander might benefit from the enemy flame knight’s fire generation. Each battle becomes a converter-based economic game.

One implication of this system is that speed matters a lot. If you see a slow hero that needs fire to be effective, you can counter it with a faster monster that also uses fire because it is more likely to get the element first. Or, if there is a quick hero that consumes water, you might avoid using water monsters.

Another neat thing that I can do with this system is to change the behavior of creatures depending on what is available. For example, maybe there is a troll that typically guards other monsters, but if you flood the room with psychic energy, it goes berserk and starts attacking. The player can then use elements to choose a strategy for their side and manipulate their enemies.

One concern with any combat system based around synergies is that players will get locked into a pattern. If a combination of monsters is good, why not just use it every time? I predict that my elemental conversion system will avoid this because even the same team of monsters will behave very differently depending on the enemy heroes they face. Furthermore, even though you fight the same heroes in multiple rooms within a single incursion, the rooms can also consume and produce elements, which should be enough to shake things up.

Designer Diary: Corrupted by Ruin #2

I spent the last week at a game design retreat, and among other things, one game I tested was “Corrupted by Ruin.” I don’t have a digital prototype yet, so I printed out some tetrominoes and monster cards and had people play it as though it were a board game.

There are some pretty significant differences between digital games and board games. Some games that work great in the digital realm fall flat in the real world, and some things don’t make the transition in the other way very well either. Still, paper prototyping is a great way to validate an idea, and it is a good sign if something works well even without a machine.

While playtesting, I realized that the triggering mechanism for an incursion makes a big difference in how it feels. Traditionally in tower defense games, the player alternates between constructing defenses and operating them (actively or passively) against regularly scheduled waves of intruders. For example, in “The Last Spell,” the player builds structures and upgrades their heroes during the day and then deploys them against the monsters that attack every night. I initially approached my design this way since it is about defending a dungeon against heroes.

The problem is that this leaves the player very little control over where the heroes enter the dungeon. A big part of the game is engineering encounters to maximize the effectiveness of the monster and room combinations. If the heroes can enter the dungeon anywhere, the player has little control over their path. Seeing where the heroes enter ahead of time doesn’t help much either because the player can’t rearrange their rooms to account for it.

So instead, I tried letting players trigger the incursions. I added “staircase” tiles around the map, and whenever a player would connect to a staircase tile, heroes would invade. The player’s incentive to go after staircases was that defeating heroes was necessary to win. The resulting game felt much more interesting to me. The player is still playing defense, but now they control when and where they fight the heroes.

Roguelike games tend to have a proactive aesthetic, where the player is constantly advancing spatially towards a goal. Reactive gameplay clashes with this. I tried out “Tower Tactics: Liberation,” a tower defense roguelike, and found this contradiction to stand out. You move from place to place, and in each location, you set up towers and defend against waves of enemies, but the contrast between the map movement and the lane defense is a little jarring. By flipping the script so that the heroes react to the player’s incursion, I hope to align the high-level gameplay aesthetic of conquering land after land with the lower-level conquest of a single kingdom.

Giving the players complete control of hero incursions also has implications for what happens when the heroes invade. Deterministic combat allows players to calculate the exact results of triggering a battle rather than relying on their heuristics. I want to avoid this because it is tedious for the player. Also, with more control over the path the heroes take comes the obligation to make the associated decisions more interesting. I think my current combat system is too plain to justify this, so I am starting to think about more interesting mechanics for combat. I will most likely want a puzzle of some sort.

Another problem that I solved through paper playtesting was how to handle monster recruitment. My previous system involved buying monsters from a pool of available ones, with new monsters unlocked by building specific types of rooms. That has three problems: First, it obligates the design of a matching room or monster even when it doesn’t necessarily make sense. Second, players already draft rooms, and doing the same for monsters feels repetitive. Third, it doesn’t interact very much with the tile-placement mechanics that are central to the game.

The solution turned out to be very simple – monsters, like gold, start each level embedded in the map. When you cover them with a tile, they join your dungeon. Now I can design monsters independently from rooms and even associate them with map types, and monster drafting interacts with room placement to enhance both.

To “mine” monsters out of the ground implies that monsters are a finite resource. Limited upgrades for monsters also make sense since they feel less generic than they would under a drafting system.

Designer Diary: Corrupted by Ruin #1

I’ve started working on a new computer game. I initially envisioned it as a cross between Dungeon Keeper 2 and FTL; you build a dungeon, gain monsters, and move them around your dungeon to respond to adventurers that try to invade. By surviving over several rounds, you gradually corrupt and take control of the land you are in, and a run involves corrupting several such lands.

In contrast to Icewords, for which development was very ad-hoc, I’ve decided to plan this game out in advance. I am making a game design document in as much detail as possible to have a clear picture of where I am going. I am also experimenting with test-driven development, using the Godot unit testing framework WAT.

Understanding the genre expectations of players is crucial when making a game. You don’t have to adhere to all of them, but it is easier for players to understand a game when they are already familiar with aspects of it. Dungeon Keeper 2 is the best example of the genre I am targeting. Some of its features that I see as essential are building a dungeon out of different types of rooms, attracting a variety of monsters to your dungeon, and using those monsters to fight off heroes that try to invade. Mining for gold while building tunnels is another iconic mechanic that would be good to replicate.

I decided to start my brainstorming with the concept of rooms. A large part of the progression that I envision in my game comes from unlocking, building, and upgrading many different types of rooms. Each room has a different effect and spawns a unique minion type. Some rooms can also transform when connected to others, an idea I got from Loop Hero. For example, placing a Library next to a Graveyard transforms it into a Haunted Library. Players like having little secrets to discover.

My initial vision for the rooms was as square tiles placed in a grid, like in Galaxy Trucker. When designing any spatial game about building something, I always ask: “Why does it matter where I place things?” In Galaxy Trucker, many threats come from a predictable direction and are more likely to occur in some rows or columns than others. While this makes sense in space, I didn’t see an obvious way to do something similar underground.

There are all sorts of ways you can make positioning matter based on the abilities of certain rooms. I object to relying exclusively on room abilities, however. It places a burden on new players; to make intelligent decisions about placement, they need to learn the nuances of each room. Therefore their heuristics are not transferable when exposed to new room types. I wanted to provide a reason to put a room in a particular location independent of what the room did.

I decided to try using tetrominoes instead of uniform square tiles. Most games that deal with tetrominoes ask questions about how efficiently they tile the board and what is on the spaces they cover-up. The latter focus is perfect for a game about building a dungeon because it is naturally suited to mining mechanics: you can print resources on the board for the player to harvest by covering them up.

Cover-up mining is probably enough to justify tetromino placement, but I wanted to make efficient tiling a focus too. In Dungeon Keeper 2, you gain a mana resource based on the area of your dungeon. In thinking about implementing a similar system, it occurred to me that rewarding the playing for dungeon area and penalizing them for dungeon perimeter naturally incentivizes efficient tiling. Mechanically, the player gains energy for each tile in their dungeon and loses it for each adjacent empty tile. Thematically, rooms generate mana and radiate it off into the environment. Mana thus obeys similar rules to real-world heat, which I like.

Such a system gives players two contradictory guiding reasons for tile placement. They want to spread out to harvest resources on the map, but they want to stay compact to minimize mana radiation loss. On top of this, they need to consider room evolution and any room abilities that care about proximity or adjacency. Overall, I think this gives enough reasons to care about where they place their rooms to make tile positioning meaningful.

At this point, I decided to try out unit testing in Godot while implementing classes to handle tetromino rooms and maps. I tried using GUT first but didn’t like that I couldn’t use arguments in my constructors with it, so I switched to WAT. I also prefer WAT’s integration with the editor over GUT’s requirement that you launch a scene to run your tests.

The biggest unexpected thing I learned is that unit testing is great for giving you feedback without having to implement example scenes. Previously, when making games in Godot, I would rush through a slapdash setup to get something I could play, leading to messy code that I would have to refactor. Psychologically, we want to see results for our work, and it is hard waiting for thousands of lines of code before you see anything happen – plus, you are almost sure to have an error somewhere. But being able to write a unit test and then immediately see results reduced this need a lot. Unit testing doesn’t just help you catch errors; it also helps you stay motivated.

Combat is the next consideration, which I am still debating. The planned structure of the game is that you cycle through the phases of building rooms, preparing for the heroes, and fighting the heroes. At first, I imagined this working like FTL boarding mechanics where monsters and heroes in the same room will automatically fight each other, and the challenge is allocating your monsters. Heroes would enter the dungeon from doors that lead out, so the layout would influence where threats appear. Battles would happen in real-time, perhaps pausing to cast spells or issue orders.

However, I’m not sure how interesting I can make that without becoming inaccessible. Crew combat is simple in FTL because you have to manage other things simultaneously, like weapons and power allocation. But if the focus is on fighting alone, I’m not sure it would be interesting enough to justify the phase. The issue with idle combat is that aside from the choice of where to allocate forces, the player has very little to do. Also, the idea of independent heroes invading from many different points feels off; capturing the traditional feel of a party venturing through a sequence of encounters would be better.

Another problem with real-time combat, in general, is that it severely limits the feedback you can give the player about differences between units. For instance, I recently played a newly released game called Hero’s Hour, where you recruit armies comprising many different types of units. However, combat involves a real-time battle where your entire army fights the enemy army, and it is difficult in the chaos to tell how each type of unit differs from the rest. I have observed this with RTS games as well; real-time combat smooths over the unique properties of each unit. I want the different monster types to have personalities, not blur together into generic minions. Therefore, I realized that I needed to have turn-based combat.

Currently, I am considering a system where a single party of adventurers encounters one room of your dungeon at a time, and you deploy monsters (and traps and spells) to that room as though you are playing cards. I was thinking about a turn-based idle system where heroes and monsters alternate dealing their damage, but that adds a lot of time to the game, and I’m not sure how your choices would change between combat rounds. If a spell is good to play, wouldn’t you spam it? And if you can’t, then why have multiple turns? Instead, my current vision is that there is one round of combat in which you play your cards and hit resolve, and then the heroes progress to the next room.

I’ve been playing a lot of Spirit Island lately, so it occurred to me that the power thresholds mechanic would work well with such a combat system. Each room and monster in the room provides elements, and each room, monster, trap, and spell has two effects – a weaker default effect and a better effect that applies when used in a room with the matching elements. I still need to figure out what makes the most sense thematically for how traps work.

I love reading or listening to post-mortems and designer diaries, but my games often have few records about why I made the choices I did or what issues I encountered. I think recording my reasoning as I go is valuable not just for looking back but also to help understand my design choices as I make them, so I will make more of an effort to post about it here.

The difference between cards and dice

Dice have been a looming problem in Dungeon Rancher for a while. Every monster uses dice to track its level by the number of dice on the card. On top of that, players must roll enough dice to feel secure in feeding their monsters. Given four colors of dice, even the most conservative estimate puts the total dice required at 120. This is prohibitive on cost alone, but dice are also inconvenient for tracking states because it is easy to knock them over, losing information.

For these reasons, we’ve decided to try switching to using cards to track monster levels instead of dice. Each monster has a stack of cards, and to tend to it you must play a card equal to or greater than the top card. Instead of four bags of dice, there are now four decks of cards. This has major implications for the game.

When we used dice to represent levels, the highest die determined the difficulty of tending to the monster. It is inconvenient for players to search a pile of cards, so now only the top card matters. Since it would be too powerful to train a monster by changing just one card, we decided to remove the training mechanic altogether. Rerolls became the ability to discard a card and redraw from that deck.

Fortunately, we have space for the card piles above or below each monster because we limit rooms to two monsters. This is good because the new resource cards need to be the same size as the draftable cards since some are in the draft. The change also makes it much easier to theme the resources because we can use thematic icons rather than pictures of colored dice.

Players naturally hold all the cards they gain from different sources in their hands – both the drafted cards and the produced ones. Therefore we had to modify the rules about discarding your hand at the end of your turn. Now players must only discard down to their hand size, whether they keep drafted or non-drafted cards. Their hand size is equal to the number of rooms they control, making room building a little more interesting.

Finally, we decided that all monsters should start at level 1. To level them up faster, players may spend a new type of token to tend to them again.

Using a different type of component to represent information always has consequences. I find it is best to go with whatever changes are suggested by the new medium rather than forcing it to work the same way as the old one. The same is true when working under component restrictions. For example, if you are involved in an 18-card contest, don’t try to cram a bunch of state information into the cards. Just use them the way cards are typically used and make a good game within those bounds.

Evolution of Dungeon Rancher Monsters

Early on, we knew that the monsters in Dungeon Rancher would have abilities if only to differentiate them from each other. There are four resources players use to feed monsters. Since each monster uses two resources, this implies a total of 4 choose 2 = 6 monsters. We gave the Dragon and the Golem simple resource production abilities to start with while testing other aspects of the game.

It wasn’t too long before we added abilities for the rest of the monsters as well. One useful principle we discovered is that abilities that don’t require keeping the monster around are unthematic because they make the monster feel more like a resource card than like something to raise. For instance, one version of the Golem’s ability allowed players to discard it to build a room for free, so players treated it like a “free room” card and always used it immediately.

We settled eventually on the concept that each monster would have a different scoring ability. After some experimentation, we further determined that such scoring abilities should always force the player to take on risk for more points. For example, the Dragon scoring ability increases its value for every ‘6’ on it, making it much more difficult to tend. Under this system, creatures represent different ways for the players to challenge themselves to increase their score.

The newest addition to the monster mechanics rewards players for placing monsters with matching “personalities” in adjacent rooms. For example, placing a creature with a food symbol on its right in a room to the left of one with a matching food symbol on its left produces a single food resource, which is automatically useful since you have two monsters that require it. The objective was to make monster placement more interesting. Adding this mechanic costs very little because it echoes the existing mechanic that adjacent matching rooms produce magic resources.

When game procedures inspire new mechanics

Game procedures are what I call the various maintenance tasks required in any board game to keep the game going, such as reshuffling decks, sorting the supply, or counting up victory points. They are the sorts of things that would be automated in the computer version of a game. An important part of board game design is streamlining procedures so they are not noticed by the players, since they do not contribute anything positive to the experience of the game.

Sometimes, in the course of improving game procedures, you find a new twist on your mechanics. This happened to me recently in Dungeon Rancher. I had been using six-sided dice to indicate monster levels, and one of my playtesters remarked that in the real world it is inconvenient to have to find a value on a die – in TTS, of course, you can just press the corresponding number.

I had not been intending to use dice in the actual game (the level die was a placeholder), but this got me thinking – how could dice be used to represent levels in a way that didn’t require the onerous procedure of locating a face? As it happens, when players are tending to monsters in Dungeon Rancher (a task that requires assigning a die that equals or exceeds the monster’s level), they tend to place the die on the monster to remind themselves that they have tended that monster. This inspired me to use the number of dice as the level, rather than the maximum die.

Each time your monster levels up you have to assign it a die matching or exceeding its highest die. The die you assign remains on the monster, increasing its level and potentially increasing the required value for the next time you need to tend to it. The required procedures are very smooth because they already match what the players needed to do; no additional steps are required.

This in turn led to some new mechanics revolving around rerolling dice – both dice used to tend monsters and dice already on the monsters from previous rounds. Thematically, this works very well – if you give the monster high-quality food, it becomes spoiled and will want high-quality food in the future, but you can attempt to tame it and reduce its pickiness. The mechanical process ends up feeling very rewarding, as players must balance caring for their monsters now with keeping their monsters as docile as possible for future rounds.

The lesson I take away from this is that sometimes the best source of mechanical inspiration can be coming up with ways to remove mundane chores from the game.

Cutting mining mechanics from Dungeon Rancher

Recently I oversaw a playtest of Dungeon Rancher in which rounds took 20 minutes (the target is 6). This was an increase of 4 minutes per round from the previous week, so I focused on determining why it was taking so long. It turned out the main culprits were the new dice-selling mechanic (which has since been removed) and the Mining Phase.

The Mining Phase was the mechanic I was most excited about going into the project initially. In games like Dungeon Keeper 2, there is a mechanic in which digging into a gold vein is likely to reveal further gold veins because they tend to be grouped. I wanted to replicate this feeling without any spatial elements by having decks of cards where certain cards allowed players to change the deck from which they drew.

We removed the mechanic of needing specific cards to switch decks after a previous playtest but left the four decks with different resources, each coded to one of the four needs of the game. The red deck had the least challenging monsters, allowing players to save minions for use generating red dice. The green and yellow decks provided green and yellow dice directly. And the blue deck provided tunnels and blueprints for building the rooms that passively generate magic each round.

Unfortunately, the mining phase takes too long. Players have also said that it feels very swingy; this is probably due to the threat system where resource cards have threat symbols that increase the strength of the next monster encountered if its color matches. Running into a lot of monsters means you won’t have time to gather resources, and finding many resources means the first monster you encounter will probably wipe you out.

The other cost of the mining phase is in explanation time. Between the threat system, the differences between the different decks, and capturing monsters, it adds a lot to the explanation time and some aspects are difficult for players to remember, such as the nuances of each mining deck.

As much as I wanted the mining mechanics to work, playtesting indicates that the cost is too high for what they add to the game. Therefore we are removing mining from the game. The core fantasy of the game is raising monsters, which does not require the mining minigame. To replace it, we are adding a Drafting phase in which players draft monsters, resources, and rooms into their dungeon. Drafting solves the problems that led to the removal of Mining because it takes very little time to explain and can be done quickly and simultaneously.

Drafting will hopefully also address feedback that the game lacks player interaction. The difficulty with player interaction is that it can lead to longer playtimes and is often not compatible with simultaneous gameplay. Drafting interactions are one of those rare exceptions.

Pushing your luck in Dungeon Rancher

I’ve started work on a new board game, this time with a collaborator. The game, Dungeon Rancher, is a push-your-luck game about raising monsters in a dungeon. It involves mining for resources and monsters, building your dungeon, and providing for your monsters. Monsters can be kept or sold after each round – if you keep them, they double in value, but it becomes harder to satisfy their needs.

I used to be indifferent to push-your-luck as a genre, but my mind changed after playing The Quacks of Quedlinburg. I think the great thing about push-your-luck is it provides decisions without an obvious solution; sure, you could compute the probabilities if you tried, but the optimal move is often fuzzy.

Currently, Dungeon Rancher pushes players’ luck in three ways:

During the mining phase, the player chooses how deep to mine. As they mine they reveal monsters. If they reveal too many, the monsters attack their dungeon.
When deciding where to house monsters, there is no limit to how many monsters may be housed in the same room. However, if any monster in the room rampages, the player loses all the monsters in that room, so cramming monsters into 1 room is risky.
Monsters double in value every round, but the risk of them rampaging, damaging their room, and escaping also increases.

One possible issue with this is that both dice and cards are sources of luck in the game, whereas it is generally recommended to use only one or the other. Dice provide a straightforward way to represent an escalating risk. The player needs to roll above a threshold for each monster each round, and that threshold increases along with the monster’s level. Cards are a convenient way to have random encounters with monsters that can then be captured.

Right now, after one playtest, housing monsters has proven to be not that risky since players have little trouble caring for them and are able to build large dungeons. Monsters also do not rampage as much as predicted. The mining phase push-your-luck mechanics are working well, however.

One dynamic of Quacks that we borrowed is that pushing your luck too far is not completely punishing – it offers the player a choice of consequences. In this case, if monsters attack the dungeon the player can either defend the dungeon – abandoning any loot they collected – or keep the loot and allow the monsters to destroy a few rooms. I think this choice is important to lessen the sting of getting unlucky.