Tag: tile placement

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.

What Loop Hero Does Well

I beat Loop Hero recently. It is an excellent game with a core gameplay loop that is addictive and engaging. You play as – or perhaps, manage – a hero in a world that has been forgotten (literally) and walk around a circular path placing tiles. Each tile provides both opportunity and danger, often in the form of enemies to fight. The hero automatically battles monsters (with no input from the player) and receives equippable loot that modifies their stats. Once you die or retreat, you return to your camp and use resources acquired during the expedition to improve your base. Then you embark on another journey.

The best part of the game for me was tile placement. What makes tile placement engaging is the interactions between tiles. Some tiles transform others; if you put a meadow next to something else, it will become a blooming meadow, increasing its healing by 50%. Other tiles complement each other very well; swamps make healing lethal, and vampires heal their allies, so it makes sense to place vampires by the swamp. With over fifty different tiles, exploring the rich heuristic tree of tile placement and synergies was what kept me returning to the game.

Tile design in Loop Hero follows the principle that every choice should provide both risk and reward. There are very few tiles that are pure upside; nearly all of them pose some threat to the hero, and the challenge is finding ways to mitigate the danger so you can enjoy the reward. This is a tried and true principle of game design, and it is executed very well here. I think my favorite example is the smithy, a building that consumes unused items to give you a defensive buff, spawning a golem after the sixth. The cleverest part is that killing the golem gives you six items that are often more valuable than the ones you lost, so you are punished for your greed but rewarded for facing the punishment.

The game also features three types of heroes to choose from, each with radically different mechanics. When I realized that the third hero was the final one, I was disappointed that there weren’t more. But as I kept playing, I came to appreciate the stark differences between them. Each hero has a central, unique mechanic, and the same tile might have very different implications for different heroes. For example, the first hero gets stronger the longer the battle takes, so a tile that reduces everybody’s attack speed is better for him than for the other heroes. The different hero-tile interactions added another dimension to the tile placement subgame, which kept things fresh even when I used the same tiles in each game.

Four Quarters made an excellent decision in using idle-style combat with no player inputs. Players will often fight dozens of monsters in a given loop, and having to make combat decisions would slow the game down to unbearable levels. Removing choices from battles leaves more time for tile placement. This is a useful general principle- whenever you have two subgames, and the first is much less engaging than the second, paring down the former gives players more time to focus on the latter.

I wish that inventory management had received the same treatment as combat, though. The hero has several item slots and the loot that you equip buffs different stats. You have to ask yourself questions like, “is 20% evasion better than 5% vampirism and 8 defense?” Each item has a numerical level as a rough guide to its strength, but sometimes your strategy may require a lower-level item with the buffs you want over a higher-level one irrelevant to your build. One benefit of the system is that it helps the player identify with the hero. Eventually, however, the constant need to compare item stats begins to feel math-y and tedious. I found inventory management to be the least compelling part of the game.

The other main subgame involves building your camp between runs. Much like expeditions, building your camp involves placing tiles on a square grid with placement mattering for certain tiles. For example, the Farm produces one food resource for each of its surrounding tiles that is empty. Constructing buildings is the primary way you spend resources gained during an expedition. Base-building is fun, but only in the same way that incremental improvements between games are satisfying in any roguelite. Players like progression and like seeing numbers go up. Letting them build a base to increase their numbers is difficult to get wrong.

Within the base-building subgame is another subgame where you can craft and equip special non-inventory “camp items” between expeditions. Initially, these confused me because the effects of each item were so weak. For example, the Loaf of Bread only gives you +10 HP (for reference, the total HP for the hero rises from the low hundreds to over a thousand by the end of an expedition). However, as you upgrade your camp you gain more and more camp item slots, so you might eventually equip 30 Loaves of Bread for a respectable boost of 300 HP. This is fun in the late game where it provides highly granular customizability to your hero but is less relevant early on when you can’t equip enough camp items to make a difference. Overall, I would prefer stronger items and fewer slots. I didn’t feel that I needed the level of control that the game gave me, and redoing my build was tedious.

Foreshadowing is important in single-player games, and Loop Hero does a great job of foreshadowing everything. Since players create the obstacles, they are very aware of what they will be facing. Progress bars provide clear reminders of how close the player is to facing the boss or reaching the next day, and the loop-based structure of the environment allows them to predict that the next loop will be similar in many ways to the last.

There is something powerful about loops in games. There is a great article about the roguelike game Unexplored that sums up why they work so well:

Interconnecting spaces are a good thing because they naturally bring you back to where you started, helping you to feel your character developing. When you return to familiar surroundings with a new item or weapon you tend to realize the difference between how you were before and how you are now, and get a handle on your hero’s journey.

Alex Wiltshire, How Unexplored generates great roguelike dungeons

In Loop Hero, each new turn around the map sees you facing the same challenges as before, but with new gear and new tiles to shake things up, providing a strong feeling of progression.

Overall, I found Loop Hero to be both rewarding and educational as an example of good game design. After beating the game and seeing almost all of the content, I don’t feel much of an urge to keep playing, but I am sure I will want to return if Four Corners releases any more content.