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:
Procedural level generation is a godsend to a small developer. If you are an indie developer, and you’re making a game with distinct levels, and you want your game to have at least 20 handcrafted levels, then you have to make tools for making levels, and then you (or someone you hire) have to carefully handcraft 20 levels. But, while you’re already making those level-crafting tools, if you put in the extra effort, you can make a system that procedurally generates levels, and then you can have infinite levels! Again, for X upfront cost, you can have a return of “20”, but for X+Y upfront cost, you can have a return of “infinity”. (How much "Y" actually ends up costing, and whether or not those procedurally-generated levels are as balanced and fun as handcrafted ones would be is another matter, which we'll get into later.)
The “roguelike” genre has a prestige to it, because people who are not game designers confuse “the thing I hate about roguelikes” with the “extremely challenging but ultimately fair” design of something like Dark Souls or playing a PVP game against highly skilled players.
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.