As a rule, I don’t play anything that brands itself as a “roguelike” or a “rogue-lite”. Occasionally something comes along that looks really pretty, or has a lot of buzz, or looks like it might have other elements that make up for the many downsides of roguelikes, and I always regret doing so.

What’s a Roguelike?

This is Rogue:

It’s a PC game from 1980. It had a fantasy theme, and was particularly notable for using the extended ASCII character set for all of its graphics, and for randomizing the map every time you played. It was fairly successful, and inspired numerous “roguelike” games, like Angband and Nethack.

Early versions of Rogue didn't have a save system, but saving was added as later versions of the game became longer and more complex. Saving let players play the game across multiple sessions, but it also let them reload from the last save on death or -- worse -- reload from the last save if the game's randomness just wasn't going their way. To mitigate this undesirable player behavior, the developers implemented a system where the player's save data was deleted after it was reloaded. Thus you could save and reload to play across multiple sessions, but as soon as you reloaded at the start of a session the save data was wiped. With no previous state to reload if you died or things weren't going your way, death became "permanent", and this "permadeath" became a core mechanic of roguelike games.

In 1993 Chunsoft released Fushigi No Dungeon for the Super Famicom, and in 1995 they released the more-popular sequel, Shiren the Wanderer.

These games were homages to their roguelike forebears, and made some interesting choices in what aspects to update and what to leave. While they added beautiful 16-bit graphics with animated characters, they kept the randomly-generated levels, the turn-based movement and attacking system, the “random attack rolls”, the hunger system, and permadeath of the 80s roguelikes.

With its beautiful graphics and sound and unusual and byzantine systems, Shiren garnered a cult following in Japan, and among cool American fans of Japanese games. In 2008 it finally got a US release on Nintendo DS, and the world was doomed.

The Roguelike Renaissance!

Fast forward a few years, and there are hundreds of games on the market, most of them indie games, loudly proclaiming how roguelike they are. The more “roguelike” ones have all the hallmarks: random levels, random attack rolls, turn-based movement, hunger, and of course permadeath. Some others bill themselves as “rogue-lite” because they only borrow a few elements; usually the random levels and the permadeath for starters, and maybe a few others.

Why so popular? Basically two reasons:

So What's the Problem?

In early arcade and console games, death was always "permanent" and required the player to start over from the beginning each time. But the games were generally designed to emphasize very short play sessions with a focus on getting a high score over an endless (barring game-crashing bugs) series of repeating levels. In both cases, a factor of this short, repetitive nature was the limitations of the amount of ROM available.

Home computers of the era, on the other hand, often had disk drives, which both freed them from the ROM limitations of arcade and console games, and let them save data to disk. This allowed computer game developers to create games that were longer and deeper than their arcade and console counterparts, and let players save their progress so they could play a long game over multiple sessions, and not have to start all the way over from the beginning if they died. This "reloading on death" feature worked fine in games with set content, and bolstered games that relied on a lot of trial and error. But it caused problems in games with a lot of randomized elements, especially when elements were randomized on the fly, and players could keep reloading until they got the random result they wanted.

When Rogue implemented saving, the developers quickly followed it up with permadeath to keep players from "gaming the system" and giving themselves an unfair advantage. But permadeath in a roguelike also means a near-total loss of prior knowledge, as the player starts all the way over from the beginning and all the levels are randomized again. That’s not too bad, and can be fun if handled well, but in many cases the combination of permadeath with a roguelike's enormous amounts of randomness can put the player at an unfair disadvantage.

A Diversion into Mazes

Here’s a maze. Take a second to solve it really quick, either with your finger or just by following the path with your eyes:

Done?

How long did it take you to figure out that the maze was unsolvable?

Here are three more mazes. In the third one, you have to get the key to unlock the door to get out:

You probably realized right away that the first one was solvable and the second one wasn’t, and with the complication of the locked door it probably took you a fraction of a second longer to determine that the third one was also unsolvable if you start from the top, but solvable if you start from the bottom.

Here’s another maze. In this one, you have to eat an apple every 5 spaces, or else you die of hunger. Is it solvable?

The bigger the maze and the more complicated the rules, the longer it will take you to solve the maze, or to determine if the maze even is solvable. Even if I’ve thrown a hundred of these at you and you’ve gotten really good at telling at a glance if a maze is solvable, all I have to do to vex you is limit your visibility:

Now you have to explore at least some of this maze to know whether or not it’s solvable.

And now you have to explore even more. Is it unsolvable? Maybe you just didn’t pick the path with the optimal number of apples.

And this is why I Hate Roguelikes: most of the time, it is impossible to win a roguelike, because the random elements align in one of a million different ways that make it unsolvable. It’s like having a book of 100 mazes, and 99 of those mazes are unsolvable, but the mazes are big and complex enough that you have to spend a few hours on a maze before you realize it’s unsolvable. And then you have to start all over from the beginning on the next maze, with nothing gained from the time you spent on the previous ones.

Too Many Vectors

“WHAT?” you say, “that’s crazy sauce! Surely only a tiny minority of developers would be sadistic enough to make their games unsolvable, and then go to all the trouble of creating multiple elaborate systems to obfuscate the fact that the game is unsolvable!”

And you are correct! Very few developers would intentionally make an unsolvable game. But there are many, many developers who delve into the dark arts of procedural generation and randomness without understanding how much work has to be done to constantly analyze and counterbalance the randomness to create something solvable.

The “apple” maze above was inspired by the last “roguelike” game I tried to play (because it was pretty, and I wanted to support the indie developer). The game had the usual procedural level generation and permadeath, and a whopping four different health meters: damage, hunger, thirst, and temperature. If any of these dropped to zero, you died, and had to start over from scratch, with a newly-generated world. Unlike most roguelike games, however, the “overworld” was linear; you’d go from one location to another along a linear path, and the order of the locations and the layout of each location was random. After trying and dying a few times for reasons that I thought might just be me getting used to the system, I had one run where I died of hunger… because there was zero food anywhere on the route. There was no way I could’ve played more skillfully to avoid dying, there just wasn’t any food that time, so I died of hunger.

The developers had put all this effort into creating this beautiful game with these elaborate systems and all these different random vectors, but hadn’t realized that “a few bad rolls” of the randomizer would totally break the game; I count myself fortunate that, in this case, I ran into this shortcoming right away, rather than having put hours of careful planning and work into a run only to have everything undone by a coin-toss and lose all progress.

The thing I hate about roguelikes is that no matter what you do or how much you plan or how well you understand the game, you can lose it all on a coin-toss and have to start all the way from the beginning with nothing to show for all your effort.

Of course, this means the opposite is true as well: when Shiren the Wanderer started becoming popular among us cool American fans of Japanese games, I tried playing it for a while, and then when I got sick of “losing to the randomness”, I just used emulator save states to savescum all the way through the game by “winning to the randomness”. When I was hungry, I’d save and open the next chest, and if it didn’t have food in it I’d reload until it did. If I missed with an attack, I’d just reload until the attack hit. I did this all the way through and won the game, which really upset my fellow cool kids who had spent hours rolling the dice and failing, and thinking they were getting “better” at the game. My rolls of the dice were just as legitimate as theirs, I’d just made sure that they were favorable as well.

Roguelikes don’t just have one or two random elements; a core tenet of the genre is that they’re random in a dozen different ways at once. All this randomness takes a ton of work to balance, and many developers don’t even realize it needs to be balanced at all. All these layers of randomness also make it difficult to tell if an aspect is broken; a broken system could be indistinguishable from a validly random system, especially when several random systems are intertwined.

I realize that some people enjoy total randomness; slot machines aren’t going away any time soon. But I suspect that a lot of people who play roguelike games think that they’re games of skill more than chance, and their own game design illiteracy combined with the games’ complexity of vectors makes them think that when they lose it’s because they did something wrong, and when they succeed it’s because they did something right, rather than a total roll of the dice. People are used to playing solvable games, after all, and have no reason to believe roguelikes would be otherwise.

Solving the Unsolvable

We’ve identified that the two major problems with roguelikes are permadeath and overwhelming randomness, which lead to unsolvable games. So what can we do to fix them?

Permadeath Must Die

I’ve been lying to you a little. When I said that “permadeath means losing all progress”, that’s not entirely true. It was true of Rogue, and some of the first roguelikes, but since Shiren (and probably earlier), games have made little “concessions” to dull the sting of permadeath a little. In Shiren, you meet people along your journey and send them back to the starting town, and even after you die a permanent death, those people you send to town are hanging out in the starting town’s tavern, and most of them will give you some little benefit that can help you on future runs. Spelunky tempers its permadeath with “the Tunnel Man”, who charges an enormous fee that you can pay off a little bit at a time over the course of many runs, and when payment is complete he will build a tunnel that you can use to skip a few levels on all subsequent runs.

These concessions don’t really mitigate the downsides of permadeath, but rather come across more as acknowledgments that permadeath sucks, and apologies for implementing it.

At the polar opposite end of the “save system” spectrum is “quick save”, the ability to quickly and arbitrarily save at any time, and quickly load one of those saves if things go bad. This has been the defacto save system for PC games since the 90s, and for console games starting in the Xbox 360 / PS3 era when internal hard drives made saving easy and cheap.

Quick save has its own problems, however; the ability to arbitrarily save at any point drastically reduces all of a game’s risks, which in turn makes the game less engaging. This gave rise to the derisive term “savescumming” which I mentioned earlier; the practice of constantly quick saving, and rolling back to the previous quick save not only on death, but in the event of anything in the game not going exactly the way the player wanted it to. Savescumming is especially problematic in games with significant random elements; the player can quick save before “rolling the dice” on a random element, and then reload until that random element produces exactly the result he wants, as I did when I used an emulator’s save state feature to “savescum” my way through Shiren. Backlash against quick save has probably been a contributing factor to the popularity of permadeath as an alternative.

In between these two -- but closer to quick save -- is save points; you can only save at designated checkpoints (and saving happens manually and/or automatically), and when you die you restart from your last save, with exactly the same progress you had when you saved. This at least preserves the risk of “losing all progress since the last save point” without the soul-crushing risk of “losing all progress and having to start over from the beginning”. This balance can also be easily tweaked by the developer by adjusting the frequency of save points; a game where the save points are few and far between has higher risk than a game with save points every 10 feet. Save points come in two varieties; manual save points where you have to make a conscious decision to save -- typically at a specific landmark or in-game “machine” -- and automatic save points where the game saves automatically when triggered to do so, usually by some event advancing the plot or a quest. Automatic save points are often accompanied by a quick save system, to reinforce their assurance to the player that they can quit and come back at any time without losing any progress.

A happy medium between permadeath and save points that’s arisen in the last 10 years is “Souls Death”, popularized by the Dark Souls series. These games have typical save points, and when you die you return to the last save point, keeping your progress and equipment and plot advancement -- including equipment and plot advancement you’ve gained since the last save -- but you leave behind all of your currency at the spot where you died. You can then go back to that spot and retrieve that currency, but if you die again before reaching it, that currency is lost forever, as your death creates a new pile of your current currency for you to attempt to retrieve on your next run.

Although convoluted, this system has been well received because it balances the “losing something that can’t be restored by reloading” of permadeath with the baseline progress-saving of a save point system, while also adding another exciting layer of risk with the chance to retrieve your currency from the last run.

Curb Your Randomness

As a roguelike moves from the left to the right on the above chart, and permadeath gives way to more and more granular saving, you have more opportunity to scrutinize the rampant randomness that’s core to the roguelike experience, and the veil lifts, and you realize that that randomness needs the permadeath to survive. Without the permadeath, players can just savescum to one degree or another (even if save points are few and far between, you can still savescum to an extent) and game the randomness to what they want rather than fighting against it and mistaking random chance for legitimate challenge.

This is why permadeath is the most important factor to a roguelike, and the one element you’re guaranteed to find in anything that calls itself “roguelike”; it is the mechanic that makes all other roguelike mechanics possible. (In fact, even when a game checks many of the other “roguelike” boxes but doesn’t have permadeath, it usually doesn’t get labelled a roguelike.)

Even with permadeath intact there are plenty of ways that roguelikes can and have made themselves “move solvable”, and they all involve making the game less random. The first element to go is almost always the random combat; replacing totally luck-driven combat with a totally- or mostly- skill-driven system makes any game a whole lot more fun, and goes a long way toward making a roguelike feel more fair. The vast majority of modern games that call themselves roguelikes have already made this change.

Digging deeper than that, however, gets a little more complex and starts to require a lot of work without a lot of obvious payoff. At this point, there are three options: 

Option 1: Self-aware randomness

Examples of the first option are hard to identify, because it all goes on “behind the scenes”. Although it’s definitely been implemented in numerous roguelikes and in other games with random elements (we implemented a complex system for making sure the semi-random dispersal of planets was “fair” in Paper Galaxy, for instance), it’s hard to know for sure and impossible to know exactly how without looking into the game’s code.

A hypothetical example would be an improvement to the game I mentioned earlier with the hunger mechanic, where no food sources appeared and I died of hunger. A more self-aware system would guarantee that a location with food would appear in the first X locations, and another would appear every Y±Z locations thereafter. This would guarantee that the player wouldn’t die of starvation just from a bad roll of the dice, and a next logical design step from this would be to create situations where, even though the player knows that there’s another food source coming soon, they don’t know exactly how soon, and have to choose between playing it safe and stockpiling food, or taking a risk and going light on food to leave more inventory space for rare crafting supplies or something.

Option 2: All outcomes are valid

Examples of the second option can be found in the procedural dungeon layouts of Let It Die and Sundered. In Let It Die, the dungeon is divided into “areas”. Each area has a specific set of rooms with multiple exits, and these rooms are shuffled with their exits randomly placed together to form each area.

Here’s one possible configuration of the rooms in the Tagahara area in Let It Die. The round area toward the middle is a wide vertical shaft with one entrance at the bottom of the shaft and the other two at the top, creating very different navigation challenges (while also fighting off enemies) depending on which entrance you enter through.

Similarly, the map in Sundered features a combination of static areas that are always the same, and large dynamic areas that contain smaller rooms in random configurations.

In this Sundered map, the areas with dark vignetting are static areas that are always the same, while the light gray areas are filled with smaller, randomized rooms. These rooms are placed in such a way that the gray areas are always completely filled, and all of each area’s doorways are accessible, but the optimal path through an area is unknown until the player starts exploring it.

In both of these games, the areas are procedurally constructed in a way that the player won’t know exactly what to expect and will need to do some exploring to find the way through, but all possible configurations of the rooms do have a way through, and although some configurations may require a different approach than others, none are “unfair”. These games also both “compartmentalize” their procedural generation into specific areas while leaving other areas static, giving the player some reliable landmarks rather than throwing them entirely into an ever-changing sea of randomness with no clear direction.

Option 3: Uncrucial randomness

This option is about making sure that “bad luck” (either a single random event or a series of random events) can’t kill the player outright, with no option for the player to overcome or adapt to those events. Although it’s a multiplayer game, and played in short sessions, the chests in Fortnite are a good example of this option. Each chest contains a (semi-)random assortment of weapons and items, and getting good random items out of a chest can give a player a leg up, but a skilled player can still come out on top even if every chest they open contains the worst equipment.

Conversely, this option is also about making sure that “good luck” can’t unilaterally win the game with little or no application of skill. Again, in Fortnite, getting the best possible weapons from every chest you open won’t get you very far unless you’ve developed the skills to use them effectively.

An example of this option failing is the “Oriental Medicine” decal in Let It Die. It’s an item that can be found randomly, and equipping it causes your character to constantly rapidly regenerate HP. Without it, you must constantly monitor your HP, and keep a stock of food in your precious limited inventory space that you can use to regain HP if you get low. With the decal, however, you can completely ignore healing for the entire game, and you’re effectively invincible for the first ⅓ of the game (until you reach a point where enemies deal damage faster than the decal can heal).

Takeaways

So what should you take away from this, other than (hopefully) an understanding of why I hate roguelikes, and you should too?

For Developers

If you’re designing a game, be it a roguelike video game, or some other kind of video game, or a boardgame, or a tabletop roleplayer game, or whatever else, the new tool in your designer toolbelt I most want you to gain from this is:

CRANK THOSE KNOBS.

Crank all of your random elements all the way down to “suck”, and see if it becomes impossible to win, no matter how good a player is at the game. If you already have a playable version of your game, then hopefully you’ve created options to inject “the worst possible luck” into every random element for testing purposes. If you haven’t, or if your design is still just on paper, then try to run this simulation in your head.

Then, when you’re done with that, try cranking all the random elements all the way up to “perfect luck”, and see if it becomes impossible to lose. A lesser version of this would be a lucky event or string of events that negate all risks and turn the game into a dull cakewalk, with the player skipping over huge swathes of plot and mechanics because it’s all superfluous if you’re lucky enough.

Please note that I’m specifically talking about random elements here, and not talking about player level or progression; a billionth-level player wading casually through challenges is totally different from a player who got the “ring of invincibility” as a random loot drop wading casually through challenges, because the former is a payoff for the player’s hard work levelling, while the latter is pure luck.

For Players

I hope that this crazy diatribe has given you some insight into random elements in games, and as you play games in the future you’ll be more critical and aware of which things are happening because of something that you specifically did or didn’t do, and which things are happening entirely because of random chance. Of course it’s important to note that some amount of random chance can be fun, and different people have different levels of tolerance / enjoyment for it, but I think the better one understands what is choice and skill and what is random chance, the better one will enjoy video games, and life in general.

Special thanks to http://www.mazegenerator.net/ for helpin’ me make mazes.

Updated 1/20/20 to properly credit Rogue itself with the creation of "permadeath", a mechanic which I erroneously thought had come later. Thanks to the commenters who pointed this out!