What is core to a Roguelike?

For the duration in which I'm posting XCOM 2 Analysis posts on Mondays, posts unrelated to XCOM 2 I consider adequately complete and worth posting will be posted on Fridays.

Such as this one.

-----------------------------------

The 'Berlin Interpretation' is possibly the most widely-known attempt to define a Roguelike, and reading it was what provoked much of the thought in this post. Indeed, much of this post is an almost point-by-point response to the sub-points of the Berlin Interpretation. It's recommended you read it first so you have actual context on why I'm talking about the bits I'm talking about.

Before I get into the meat of things, it's also worth addressing a specific sub-point. Many 'classic' Roguelikes use deliberately primitive graphics in an attempt to imitate the original Rogue as part of the end-goal of being a... well, Roguelike. In and of itself this is fine, but some communities enshrine simple graphics as a critical part of the Roguelike experience, which is comedic in how it completely misses that Rogue was, to quote part of the page I linked to...

"...one of the first games to use a spatial representation of the world where the action unfolded (visually) instead of textual descriptions..."

In other words, the original Rogue wasn't a game deliberately flouting graphical-ness through ASCII art. It was the exact opposite, a way to produce the approximate effect of traditional art assets on computer systems that were literally incapable of outputting art assets. It was pursuit of graphics when none should have been possible!

So I always laugh when I see people earnestly arguing that being faithful to traditional Roguelikes means deliberately simplifying your graphics.

One final note before beginning in earnest: much of this post was originally written in 2012, with it only being recently that I got it to the point of feeling it was publicly presentable. To a certain extent it's thus out of step with or behind the trends. Crypt of the Necrodancer and Enter the Gungeon are both real-time Roguelikes that came out literally years after I originally wrote most of this post and among other points both embrace the full sensory experience a video game can deliver. If some specific statement feels like a 'no duh' or similar to you... that's probably why.

With all that out of the way, here's my interpretation:

Roguelikes are, above all else, resource management games, with a sub-component of risk management. In my view, much of what is common to Roguelikes follows from this.

Permadeath

In a resource management game, it must be possible to mismanage your resources, or else you don't have a resource management game. If players can simply reload an earlier save anytime they mismanage their resources, then there's no real point in making resource management a game mechanic, because players will simply abuse save mechanics to optimize that component without necessarily learning anything about how to better manage their resources. Instead of producing axioms about how to play the game, they will move through the game, reload, and use their resources in exactly the correct way for this specific scenario, with no guarantee they've gleaned an underlying principle to apply in future, somewhat different scenarios. So instead of learning to make a judgment call like 'this enemy is sufficiently dangerous to justify using two temporary booster items', they just reload the encounter and try things until something works.

Obviously, if your game is all about resource management, saying "well, it's OK for resource management to not really be a part of the game" is unacceptable. So, permadeath. If you can't learn to manage your resources in an intelligent manner, you die and have to start over with nothing, simple as that.

Randomness, generally

Combat in Roguelikes usually involves a substantial element of chance. The most common justification I see for this is that it adds 'excitement', but I don't think that's ever been the real point. Randomized damage, random chances to hit, and myriad other forms of randomness ensure that the player cannot employ overly-precise exploitation of their knowledge of the game space.

In other words, an enemy whose damage is "2d12" will, on average, do a little over 12 damage. This means most of the time they do roughly 12 damage per attack or turn (Ignoring the possibility of missing, for the moment), and so usually a single such enemy cannot kill a player who has 36 HP in two turns, and will take 3 turns. Thus, a player attempting to maximize their resources may be tempted to hold off on drinking a health restoring potion until after they've taken a 12 damage hit, based on their awareness that the enemy normally does about 12 damage... and then the enemy rolls high, does 24 damage, and the player dies. Or alternatively, a player may be of the firm conviction that they will kill the enemy before it has the chance to kill them, and thus not bother with drinking a potion, particularly in a game where you can rest off damage or otherwise restore HP at no or little cost... and this time the player lows roll damage overall, or the enemy high, or both, and the player dies to overconfidence.

This prevents the player from making overly precise decisions that will leave them with exactly one hit point, but cost them no long-term resources or fewer of those resources. If you're low on HP in a Roguelike, you should probably restore your health -or run. It's just not a valid choice to say, "well, I'll survive their next hit with 1 hit point and then kill them, so it's fine." That might happen, or they might miss you outright, or they might hit you for high damage and kill you, or they might reduce you to 1 hit point and then you miss and then they finish you off, and you just cannot be absolutely, precisely sure of the exact progression of a given encounter. This forces the player to make judicious choices about expending their resources (Or avoiding doing so), and denies knife's-edge shenanigans that are possible to do completely consistently within a less random system.

Random world generation

In any game where the world is fixed and predictable (ie most games), anybody who has played through the game already, or has a guide on hand, or has a friend that meets either of the conditions (Or they can just go to Gamefaqs) can husband their resources with full knowledge of what the future looks like. "I'm going to use up all of my missiles now, because the very next room will fully refill my missile stock, which I know in spite of this run having never been in the room in question." Or "I'll use this auto-kill object that I get only one of to defeat The Hardest Boss Of The Game, since I know for a fact that nothing else is a better use of the item." At that point the player isn't doing anything remotely like real-world resource management -real people have to give themselves room for the possibility of circumstances they cannot readily anticipate, or possibly cannot even imagine, placing an unexpected demand on their resources. People playing games with fixed worlds can distribute resources perfectly, based on their absurd knowledge of the entire world's state in the past, present, and future. Roguelikes thus randomly generate worlds and their contents, such that a player must, again, actually manage resources, because they don't actually know how much of a given thing they'll need, whether they'll need it, nor when they'll need it. They just know that it might be useful later, or it might be necessary to use it here and now to ensure there is a later.

As a concrete example most people are familiar with, in the original Pokemon Red/Blue/Yellow games, there's basically no reason to not use the Master Ball on Mewtwo when you encounter it. There isn't a better Pokemon to use the Master Ball on, and it doesn't matter how many times you play these games anew, this fact will not turn out to be untrue in a particular run. The problem of 'when do I use my one-of-a-kind Master Ball?' is a solved one, and thus individual players have no reason to learn anything new in regard to how to use their Master Ball.

Limited inventory space

In many games, a player can carry arbitrarily large amounts of several different kinds of objects, with none of these objects competing with each other, and sometimes some of them have no carrying limit. (Many games place no limit on how much money a player can carry, for instance, or the limit is defined by hardware limitations that are far in excess of realistic play's needs) This means a player has little or no need to manage their collection of stuff at all, as they never need make a decision like, "I want to carry more bombs, so I think I'll throw away some of my arrows to make room." You lose a layer of resource management if you can always hold onto every random, niche piece of junk on the expectation it might be useful someday, at no actual cost. Forcing the player to actually think about what is a priority and what isn't, what is liable to be relevant soon and what has long since stopped being useful forces the player to try to optimize their usage of their resources -carry the most beneficial things, discard the least useful things, 'waste' the value of some things that can be used now for a lesser benefit or carried and used in an emergency for a greater benefit (But you don't have the space to carry them that long, so you use them now), etc.

Finite-ness

If the player can expect to simply grind for anything and everything they might plausibly need to beat the game, after a certain point the player is not managing resources within the game. Rather, their ability to clear the game becomes dependent on their willingness to expend their real time into the game -or their willingness to invest time into designing a program to play the game for them, potentially. With an infinite amount of everything available so long as you're willing to put in the time, the only resource a player is 'managing' is their real time. The in-game resources become meaningless.

Many Roguelikes have a finite amount of stuff in the world, generally, or create scenarios of diminishing returns, or place a hard time limit on how long the game will go on before the world ends, or otherwise ensure the player has to actually, again, manage resources, rather than simply investing however much time they're willing to invest.

ASCII graphics

This is a bit of a complicated topic. I vehemently disagree with the idea that ASCII graphics have anything to do with roguelike-ness. You might as well argue that no platformer after the NES is a real platformer because they're not 8-bit like Super Mario Bros, which I doubt anybody would take seriously, even though I've absolutely seen people take the idea seriously when applying the principle to Roguelikes.

However, my suspicion is that ASCII graphics (Or more generally, simplified graphics) recur so frequently in Roguelikes -and not nearly as consistently in other genres- because a Roguelike is fundamentally friendly to a low-graphics approach. I don't mean that community expectations are friendly to ASCII Roguelikes (Though this is also true), but rather that the focus of a Roguelike's gameplay is centered away from the things that make graphics important.

You need good graphics when spatial relationships are key, and especially when spatial relationships have to be grasped as quickly as possible in as short a time period as possible. Fighting games have always had relatively high quality graphics because they're all about spatial relationships, and the action is fast. Roguelikes, even though they usually make spatial relationships matter, place a low priority on spatial relationships (Distance between the player and a given thing is often more important than any other spatial consideration, and then is usually less important than questions like, "How good is my magical sword?" or, "How high is my character's level?") and trend toward turn-based models, which further de-emphasizes the need for good graphics to rapidly convey large quantities of information. The player can, in fact, simply sit there and stare at the screen for 30 seconds if that's what it takes to understand what they're looking at, because it's turn-based.

You also need graphics when you're attempting to bombard the player with a flurry of information in which something essential is embedded but easily overlooked. Lower-quality graphics tend to make even minor oddities obvious, which makes it hard to hide clues. If you compare A Link to the Past to Ocarina of Time, they both have walls that can be destroyed by bombing them, and they both make bombable walls look different from non-bombable walls, but once you've identified the bombable wall sprite in A Link to the Past all future instances of that sprite are extremely obvious, whereas in Ocarina of Time even up close it's possible to overlook a noticeably different section of wall, in part because there's just so much information on the screen to keep track of, and it's not immediately obvious what is or isn't important.

Roguelikes don't deal with this. When Roguelikes want to hide something from the player, they either don't display it at all or they use a 'cheat'. For example, in Angband there are semi-invisible enemies whose map display icon is identical to the icon that represents a section of open floor, which makes them completely invisible in open spaces, but can cause the player to notice them if they walk over an item or a floor tile using a different icon. Roguelikes almost never expect the player to just notice something important amid all the noise -because the core of the gameplay doesn't center around how aware you are of your environment, it centers around managing your resources as best as you can.

Outside of these two cases -spatial relationships, particularly where time is limited, and hidden-in-plain-sight gameplay- graphics are just not that important to gameplay. Most games center heavily around spatial relationships, though, so most games emphasize graphics to some degree or another. Roguelikes are an exception to the first, and thus an exception to the second.

So, simple graphics. More is unnecessary. Potentially nice, but distinctly optional.

Turn-based

This is also a complicated topic.

A game doesn't need to be turn-based to be a Roguelike, but turn-based gameplay is more friendly to the primary focus of a Roguelike. Making a game real-time automatically shifts the focus, to at least some extent, toward processing what's going on in a timely manner and responding to it quickly and efficiently, and it's easy to end up minimizing other components of the game. Once a game is real-time, a player can die because they were distracted for a second, even though they've perfectly managed their resources.

There's a flipside to this -if the game rewards the player for becoming skillful at manipulating the game within the realm of being real-time, this can bypass the need for skillful resource management. If you can maneuver in real time to avoid enemy attacks and deliver your own from relative safety, you can largely bypass the need to use (ie manage) the resources you're meant to be managing, and indeed in many real-time games with resources to manage a sufficiently skilled player can go through the entire game without ever using a single item, such as in the 'Metroidvania' style Castlevania games. By shifting to turn-based gameplay and removing things like attacking and avoiding enemy attacks from the realm of physics in favor of dice rolls, a Roguelike ensures that the player's ability to avoid the resource management portion of the gameplay is constrained.

It is of course perfectly fine for bad play to reduce how far a player's resources go, with the inverse to that being that good play by definition extends how far their resources go, but making the game turn-based makes it possible to cap the benefits of this effect. In a turn-based system, bad play will involve taking a bunch of unnecessary hits that thus require burning more resources to undo, while good play will minimize, but not necessarily eliminate, damage taken from enemies. In real-time play, it's extremely likely that good play will eliminate entirely the need to expend resources.

Grid-based

To a certain extent, I suspect this largely comes back to technical convenience. It's just easy to make a grid-based game with discrete positions, easier than a lot of the alternatives.

To a certain extent, though, it comes back to clarity. If you can see tiles clearly, you can pull together information and work out that, for example, running for a door has pretty good odds of getting you killed in one situation if you don't use any of your limited supply of healing items, while in other situation it's actually completely safe to make a run for it. With a fuzzier system, this information becomes obscured, which makes it more difficult to make such judgment calls and drags attention away from the resource management. Suddenly a player who didn't heal enough while making a run for the door didn't die because they made a poor judgment call about how little they could expend on surviving, they died because their best understanding of the game's spatial relationships happened to not reflect reality due to ambiguity on the game's part. In concrete terms: a fuzzy system might have a situation where it looks like the player can get through the door in three turns, and in actuality it will take four turns, which is one too many for their planned resource expenditure. In a straightforward tile system, the mistake a player makes is almost certainly a misjudgment of resource allocation rather than basic gameplay elements being poorly-communicated.

Complexity

Resource management demands complexity to be a meaningful challenge. More precisely, it demands that the complexity render it unclear what an optimal solution looks like. Games that place tremendous demand on the player's ability to accurately control their character can make it completely clear what the player is intended to do because the difficulty isn't in identifying the intended solution, but rather is in implementing the intended solution. Landing a headshot on a moving target is hard -especially when the moving target is actively trying to avoid being shot. As such, it can be the case that 'shoot enemy in the head' is always the best solution -if you can pull it off.

Resource management is all about deciding whether it is optimal/sensible to expend a given resource in a given situation in a given way. (eg whether you should drink your potion, or just keep attacking and save the potion for later, or give it to Suzy The Tank so she can drink it) Actually implementing that decision is easy, and more importantly making the implementation hard is distracting from the point -if a Roguelike demanded you complete a quick-time-event anytime you wanted to use an item, or demanded you actually manipulate your character's arm into swinging just so to hit around a goblin's shield when you've decided to attack them, the emphasis would instantly shift away from resource management toward skill at these tasks... tasks that aren't resource management. It's irrelevant whether your methodology for how to spend your resources is as perfect as possible or not if the game demands you can pull off a timing minigame every time you want to expend a resource and you're not competent enough at the timing minigame.

There's also the flipside: imagine a game made it so that doing the timing minigame perfectly prevented you from using the resource at all. A player who can do this timing minigame perfectly, every time, is no longer managing resources at all.

Exploration and Discovery

To a certain extent this is a consequence of the random world generation, to a certain extent it's an important part of the system. If there isn't anything useful to find, it's not meaningful to talk about resources that need managing. A beat-em-up game doesn't need any pickups or other goodies to function -the phrase, "No man is an island," doesn't need to apply to a beat-em-up character. It's perfectly acceptable for a beat-em-up character to start the game with everything that matters and end the game exactly as they started it, because the point is that the player is supposed to learn how to manipulate their character for best effect.

I personally consider the exploration and discovery trend primarily a knock-off consequence of the core point of a Roguelike, rather than an essential part of it to be deliberately inculcated by Roguelikes.

Hack'n'Slash

I think this is a clunky way of trying to say something that really is genuinely important -Roguelikes keep the focus on you, as an individual, managing your own resources, with no support. If you bring friends into the equation, resource management takes a hit for the individual -it's fine to be incompetent at that if your allies can make up the difference. Similarly, the more the game rewards mastering the combat system per se, the less focus there is on managing resources. A meaningfully complex combat system rewards skill at the combat system per se, and this pulls the focus away from resource management.