Making a roguelike is hard
In which I reflect on my mountain of failed projects and why I still find the genre interesting to work in
As is standard for game developers, I’ve started and then abandoned a lot of projects. My favorite type of project to start and abandon is a roguelike. In some ways it’s a genre that naturally calls to weirdo programmers like myself. It looks like a terminal! It has swords and magic! You can use all those algorithms you learned at university!
Since I’ve spent so much time working within the genre, please indulge me in talking about them for a while.
Ok, but what is a “roguelike”
If you have no idea what I’m talking about, let me give you some background.
The genre started with the game Rogue, originally released in 1980 and continuously developed for years afterwards. The creators, Michael Toy and Glenn Wichman, were making text adventure games together while they were at university. They were continually disappointed that they couldn’t play their own games, since they knew all the solutions to everything already. Their innovation with Rogue was that game elements were randomized every time the player started a new game. Since the player could no longer memorize the layout of the game, it became an interesting puzzle even for themselves.
Rogue inspired a bunch of similar games.They were “like Rogue“ so they ended up getting called “roguelikes.”1 One of these games, called Hack, started out as a near-copy of Rogue in its early versions. Over the years it added more and more features, significantly diverging from its inspiration. Eventually the developers started coordinating using this new thing called the “internet,” and from then on it was called NetHack. This is when I made contact with the genre.
As a kid, I somehow stumbled upon NetHack, a weird, free game none of my friends had ever heard of. At the time it was already in the version 3.4 series of releases. The design had matured and stabilized, and it was much larger and more complex than Rogue ever had been. Everything about it had an intoxicating air of mystery for me: the austere graphics, the opaque systems, the banal items, the hidden items, the cursed items. Even getting stuck, unable to find a required secret door, was interesting, and never would have happened in any other game I played. Everything about NetHack felt magical and its ideas have been deep in my brain ever since.
In 2008, indie developer Derek Yu released a game called Spelunky, which took elements of the roguelike genre and mixed it with a 2D sidescrolling platformer. The game was hugely popular, and it inspired a new genre of “roguelite” (with a “t”) action games that have mostly displaced traditional roguelikes in commercial game development. These are not my focus here so I won’t talk about them too much, but it’s what many people think of when they hear the term “roguelike.”
The most striking thing about traditional roguelikes is that the “graphics” are drawn with textual elements: lines of dashes and pound symbols become rooms and corridors that the player, an “@”, explores. Monsters and items are assigned other letters and punctuation. It’s an unusual mix of a concrete representation of geometry and physical space, and an abstract symbolic representation of characters and objects with single characters. This makes sense given the constraints the game was developed under. In 1980, personal computers were still very expensive and not particularly common. Students at universities used a different set up than we’re used to these days. There was a “mainframe” computer that did all the computation and many simple “terminal” computers that would access it, both communicating exclusively through text. So in order to draw anything, it had to be drawn in text.
In terms of mechanics, Rogue was based on Dungeons & Dragons tabletop roleplaying. Dungeons & Dragons was extremely popular in the 80’s, and so there were a lot of games in this vein. Some of these were very successful and are well known even today, like the Ultima series. Others are now obscure curiosities, like Advanced Dungeons & Dragons: Cloudy Mountain for the Intellivision.
When you actually play Rogue, you explore a dungeon, find useful treasure, and try to fetch the ultimate artifact at the bottom of the dungeon. That’s all pretty normal for Dungeons & Dragons games. But it introduced two major innovations: one is that many elements, including the layout of the dungeon, are randomized for every new game and need to be rediscovered; the other is that your save data is deleted when your character dies. If you want to play again, you have to restart. This means that your actions have permanent consequences. These two mechanics are what people think of as the defining characteristics of roguelikes, and have been carried forward into the modern roguelite action genre.
The simple text-based graphics of traditional roguelikes aren’t just a stylistic choice. Because everything is rendered so abstractly, it’s very easy to attach a lot of mechanical complexity onto each symbol. As an example, in most roguelikes, if you see the letter “g” that represents a goblin enemy. Whereas in a modern graphical game, a goblin enemy would be a 3D model, and have separate animations for all its attached mechanics: walking, running, attacking, dying, and picking something up (for example). If you wanted to add a new behavior and its associated mechanics, like drinking a potion, in the former case all you would need to do is add the behavior and maybe write a new message (”The goblin drinks the potion.”). In the latter case, you also need to add a new animation, ensure it’s compatible with the potion 3D model, and maybe add a sound effect. That’s a lot more work! Removing that extra complexity gives the developer the freedom to experiment with the game’s mechanics and systems rather than spending energy visually representing them. This in turn leads to surprising creativity and texture lurking under the surface of roguelikes.
Another thing that draws me to traditional roguelikes is that they are turn-based2. There just aren’t that many turn-based genres anymore. I like turn-based games. I like being able to take my time thinking about what to do and being able to get distracted and walk away from the game without worrying about pausing or reaching a good stopping point. A lot of modern turn-based games really lean into the “thinking about what to do” aspect and can become very slow and complex. In comparison, most decisions you make in roguelikes are pretty trivial. Explore here or there first? Pick up the sword or don’t? Combined with their short playtime for a single game, they lend themselves well to what might be called a “casual” style of play, despite their difficulty.
And look, I’m a sucker for finding a magic sword in a treasure chest. Who isn’t?
Making a roguelike
I’ve worked on a lot of roguelike projects. I think I’m up to 9 or thereabouts. Most haven’t been successful. I have finished two of them, but both were for the 7 Day Roguelike game jam3, so they were intended to be small, short projects. None of the others really went anywhere. So I guess I have a lot of experience with failure.
Why is this so difficult?
Game development is really, really hard, just as a baseline. Roleplaying video games in general (not just roguelikes) are even more difficult than average. While their mechanics appear simple on the surface, they often have a lot of mechanics, and they all need to harmonize together. If the mechanics don’t achieve this harmony, often the game doesn’t work at all: it’s impossible, or trivial, or simply doesn’t make sense. The games also need a certain minimum playtime for that mechanical harmony to actually pay off. If the game is under the minimum playtime, the mechanics feel pointlessly complex, like a watch with no face.
These problems mean that they’re difficult to iterate on — iteration being key to making good games. When you’re developing, it’s hard to tell whether you’re actually making progress towards a harmonious whole, or just throwing more things onto a big chaotic pile.
I think in my projects I’ve exacerbated the problem by being overly focused on delivering all the expected features, like creating a certain number of dungeon floors, or designing full sets of weapons and armor, or getting an interesting dungeon layout from the level generation algorithm. Because these are the expected features, it essentially means I’m procrastinating on figuring out what’s interesting, weird, or catchy about the game. I’m slowing down the iterative process for no reason.
It doesn’t help that a lot of these projects started because I wanted to learn a new technology, and I needed a project to try it out with. Once I got a solid handle on the technology, the project lost its importance.
Design trends in roguelikes over time
The mechanics of the original Rogue are about conserving resources. A winning player judiciously uses their resources (magic items, usually) only to deal with monsters that are a real threat, and moves quickly through the dungeon to avoid running out of food. They also need to be fairly lucky. (Rogue is a difficult game.)
The second wave of games, that NetHack was a part of, are less interested in this specific gameplay. Instead, they tend to give players a lot of resources so long as they can patiently grind4 for them. A winning player in these games is instead one with a keen sense of which situations are safe and which are dangerous. They leverage this knowledge by sticking to the safe situations and running away from the dangerous ones, and in this way accumulate resources without dying for as long as necessary to win the game.
At some point in the last couple decades, grinding became passé. It’s now viewed derisively, as a way for developers to lazily pad the length of their games, or worse as a way to create addictive experiences. To be honest, I think this shift in viewpoint has led to better design and tighter experiences overall. But this shift occurred more-or-less around the release of Spelunky and the corresponding shift to making action games with roguelike features, rather than the genre’s traditional turn-based roleplaying games. As a consequence, there are very few of the latter type that have been put together carefully enough to avoid grinding5. And the designer does need to be careful! If there’s any path in the game that loops back onto itself while the player gains resources overall, then the player can take that loop as many times as they like for infinite benefit.
Remaining design challenges
I think there are two major unsolved design problems in the genre: boring exploration and a broken health economy.
Boring exploration
When you start a new game in any roguelike, you know very little about what you will encounter. You have to explore and uncover the random dungeon that’s been created for this particular game.
Exploration is necessary; there must be at least some amount of it to make the game work. The alternative would be to reveal the entire game to the player right from the beginning, but then you’d have something more like a puzzle game, where you sit and examine the dungeon, deduce via examination the correct sequence of moves, and then input them to win6. That’s not really the same genre.
But also, exploring a dungeon is just cool. The dungeon is dark, and in the darkness lurk both danger and treasure. The thrill of adventure comes from not knowing what you’ll discover and what’s going to happen! That’s the Dungeons & Dragons influence shining through.
Unfortunately, in practice, exploration bogs the game down. When you say “exploration” it sounds cool, but most of the time you’re really just walking around. Sometimes the walking is good: you’re revealing new areas. But sometimes you hit a dead end and have to walk back to the last fork in the hallways to continue exploring. And even worse, sometimes you reveal a new area and there’s nothing interesting there. In this case, the random dungeon layout is a double-edged sword. It’s very hard to coax the algorithm into placing treasure and monsters just right, so that every area is actually worth exploring.
This is such a big problem that most roguelikes, even newer versions of old roguelikes like NetHack, have a feature called “auto-explore.” When you auto-explore, your character will autonomously navigate to the closest unexplored location, revealing it, and then will repeat this until either something interesting shows up (treasure or a monster, in most cases) or the entire floor is explored.
Dungeon Crawl Stone Soup takes this a step further by automating other kinds of backtracking. If you want to travel to a particular area, you can input that area’s name and your character will autonomously navigate there. If you remember seeing a magical item that you didn’t pick up, you can search for it by name, and your character will autonomously navigate there too. The game takes pride in the amount of automation that it has available, and it does make the game quite breezy to play, though it also makes the experience unsatisfying and disorienting. Now I’m here, now I’m there, oh there’s a monster, now I’m somewhere else. You’re like a tourist on a bus being driven past all the sights at highway speeds.
How could you improve the exploration experience, without resorting to automation? Here are a few ideas.
The simplest solution would be to slide the amount of exploration down as far as it can go. For example, you could make each level be completely visible, but not reveal the subsequent level. This would definitely reveal interesting things at the appropriate frequency — it’s very easy to put monsters and treasure on every level. And it would reduce backtracking by preventing the player from walking into dead ends, since they can see in advance there’s nothing there. This example feels a little extreme, but it would probably work.
Another solution is to simply make the levels extremely small. This is what designer Michael Brough does in his roguelikes (868-Hack, Imbroglio, and Cinco Paus). Backtracking is reduced just through fewer actions required to backtrack. In fact, each level is so small that Brough often adds extra backtracking intentionally, so that the player doesn’t finish too quickly!7 I quite like Brough’s games, and I think this is a solid solution, though small levels come with other challenges.
A final approach would be to do something very unusual, like remove the grid-based movement completely. The player could hit a button and simply move to the next area, a little bit like how auto-explore works but without replacing many smaller commands in sequence. I tried out something like this in one of my 7 Day Roguelike entries, The Princess of Mud. In it, you press a single button to move to the next room, you press another button to fight the monsters, and then you press a third button to pick up the treasure. The game doesn’t work very well for other reasons8, but I still think this part of it works ok.
Broken health economy
Most roguelikes have a mechanic where you regenerate health over time. The regeneration is slow enough that it’s not typically relevant within the space of a single combat encounter, but it does mean the player can stop and wait in order to fully heal any time it’s safe to do so. This is common enough that most games have what’s called “auto-rest,” directly analogous to auto-explore. Auto-rest causes the character to do nothing until fully healed, which prevents the player having to press the “wait” button a bunch of times to heal manually.
The temptation is to do this after every single fight. The only thing preventing you from doing so is another mechanic called “hunger.” Your character must periodically eat, or they will become weaker and eventually die. Usually, you must make progress in the dungeon to find more food. Hypothetically at least, hunger is supposed to prevent you from resting too often, on pain of running out of food. Unfortunately, in practice, very few games have their hunger system strict enough to actually encourage the player to continue without resting. Tuning hunger to be that strict can create a punishingly difficult game. Just Brogue and the original Rogue attempt to be strict in this way (as far as I know), and they could both fairly be called punishingly difficult. All other games err on the more generous side, which also creates a lot of opportunities for resting.
One solution to this is obvious: do not regenerate health by waiting. This causes other issues though. The game needs to provide the player with some other source of reliable healing, otherwise the character will be inexorably worn down by damage over many encounters.
Roguelite action games, even ones where the player could hypothetically avoid all damage if they were good enough, typically give the character small amounts of healing when they make progress through the dungeon. This is a great system when all you’re doing is moving from level to level, but it makes less sense when “making progress” is ill-defined or very irregular.
Roguelikes usually have some kind of basic single-use healing item, so a designer might be tempted to give out more of these to make up for the lack of regeneration. However, healing items tend to be very powerful in roguelikes, so this can be hard to balance correctly. They allow the player to take on much more dangerous situations than they could otherwise, because the plentiful healing items create a generous safety net for as long as the player tracks their current health. In cases where the items are rarer, the player has to be proportionately more careful.
One final idea is to make healing items usable only outside combat. The tricky part is that what counts as “outside combat” is often poorly defined. The obscure game The Ground Gives Way has a “rest” command (no relation to the auto-rest command), that consumes a food item and restores the character’s health, but can only be used when there are no monsters left on the level. That’s the only instance of this idea put into practice that I know of. I’d like to see other variations tried.
My next roguelike
These problems show up with remarkable consistency. I think that’s what draws me back into roguelike development again and again, despite all my failures: there are ideas in the genre that are interesting, but are burdened with design choices that hold back their potential. Roguelikes deserve to be given another chance!
Since writing the initial draft of this post, I started a new roguelike project. It’s called Lark. You might notice the first commits are from October 2024; I’ve started this post over from scratch three times already. (Writing about roguelikes is hard too, I guess.)
In Lark, my idea for solving the exploration problem is to make all the spaces fairly small, and have them be either revealed from the start or quick to reveal with just a few movements. By stringing together many of these small spaces, hopefully the player will still get the excitement of discovery but without lots of extra, uninteresting movement. I expect to also prohibit backtracking completely, which should eliminate another source of uninteresting movement.
For the health economy problem, I hope that simply adhering to the principle that waiting should never grant health or any other resource, any design problems that result can be fixed as they arise.
Finally, to avoid getting bogged down in the expected features, I’m trying to assemble a pile of unusual elements first. Maybe they won’t cohere in the end, but maybe they won’t have to. I’m also trying to avoid generalizing anything too much. Generalizing a game mechanic is both a lot of effort, and tends to make it boringly repetitive. Hopefully Lark will be interesting, at the very least, even if it doesn’t end up working. I’ll let you know how it goes.
First-person shooters used to be called “doomlikes,” through the same etymological process.
“Turn-based” means the action doesn’t advance until you make a decision, like in a board game.
A “game jam” is an event where participants try to make a whole game within a very short time limit. In this case, 7 days.
“Grinding” in video games refers to repeating a safe action for a marginal gain over and over.
Basically just Brogue and Dungeon Crawl Stone Soup, at least among popular games.
Desktop Dungeons is an example of this kind of game, sort of.
See this blogpost on the design of Cino Paus.
The main problem is that it’s quite confusing to play. Things happen very quickly, but the text-based graphics don’t lend themselves well to following what’s going on. Roguelikes are normally turn-based for a reason! There are also some technical issues with the controls that really puts people off.