NetHack 4 homepage | NetHack 4 blog | ATOM feed

Strategy headroom in roguelikes

Tags: roguelike strategy balance | Mon Jul 7 06:53:24 UTC 2014 | Written by Alex Smith

This is a blog post I've been meaning to write for a while. I frequently see the same mistakes made in discussions about roguelike balance, where people are asking for things that are incompatible with each other. Here's my attempt to explain the issue of roguelike balance as I see it, via giving a method of describing how a roguelike is balanced: its strategy headroom. (This concept applies to other game genres too, but I'll focus on roguelikes here, because it's likely less interesting in other contexts.)

The basic idea is this. Suppose your character comes up against some situation in a game where they have multiple options for which strategy they're going to take. An obvious example is character creation: I can play a spellcasting character, or a melee character, or maybe a hybrid, in the vast majority of roguelikes, and most roguelikes allow this choice to be made at character creation. This is going, at least for a while, to affect what options are open to my character in combat. In NetHack, for instance, playing as a Samurai, I have an excellent weapon for the start of the game (a katana); playing as a Wizard, I have an inferior option (a quaterstaff), but I also have the ability to cast 'force bolt' on occasion and defeat dangerous enemies that way. One of these choices is going to give me a better chance at winning the game. The question is not "which choice is it", but "how much difference does it make to my victory chances which option I pick?".

There are two possible extremes for the scale here. One is "no matter who you are or which choice you make, it won't affect your odds of winning the game". There are two ways to look at this situation. One is that the game is "perfectly balanced" with respect to character creation. The other is that the choice is entirely meaningless; if nobody gains an advantage from either choice, then either success or failure has nothing to do with the skill of the player, or else the various options play so similarly that the choice is entirely cosmetic. This situation has a very high headroom; the player can mess around with their strategy at will without any risk of the game limiting their experimentation.

The other extreme is "one of these choices will guarantee you victory; the other will guarantee you are defeated". This is definitely a meaningful choice, now! However, it can be seen as unsatisfactory for other reasons: the choice is meaningful, but it's a false choice, in that only one option is reasonable to take. An unspoiled player may pick the wrong one, and lose, if the choice is not well-signposted. Or a player might want to pick one choice (because it fits in more with how they want to play the game, for instance), but be forced to take the other in order to have a chance of success. This situation has zero headroom; a player must follow the path that the game dictates for them in order to have any chance of survival.

There are plenty of other situations where players have to make this sort of choice. Suppose that I decided that I preferred to play a spellcaster this game, than a melee character, but a few rooms after starting, I found some otherwise highly desirable armour but that blocked spellcasting. A typical example in NetHack would be a dwarvish mithril-coat, which is in fact often found by early-game wizards, meaning that this situation is far from hypothetical. Many NetHack players would recommend me to wear the armour, at least if all I wanted to do was to win the game; an early-game wizard benefits more from the defensive boost than they hurt from the lack of access to their meagre spell selection (in NetHack, at least; other games may be different). Many players would refuse, however; after having made the decision to play a spellcaster, changing to a bad melee character would not really fit in with the way they wanted to play the game. Game designers have to make a choice here: do they want their players to have to wear the armour in order to get a good win rate, or should the game forgive this sort of technically suboptimal choice? This really plays into the distinction between low and high strategy headroom.

High headroom versus low headroom

So, knowing what strategy headroom is, we can look at some standard requests that players make in roguelikes. None of these requests are inherently implausible, and they all seem reasonable on the face of it. However, many of them are requests for higher headroom, and many are requests for lower headroom. It's not going to be possible to keep all these people happy at once:

"The game's strategy should not be dependent on spoilers." This is a request to increase the headroom, because it is equivalent to "strategic choices where one option gives much higher survival chances than the other should be eliminated". Note that this is about strategic spoilers, such as "stop training skill X at level Y, taking it higher than that is not useful", or "weapon type A is just better than weapon type B"; not tactical spoilers such as "item Q does R, except in circumstances S where it does T instead". A similar sentiment includes the desire to remove "newbie traps" where a strategic option looks viable, but actually isn't. Roguelikes with a lot of headroom generally do quite well on this basis. For instance, NetHack (which has very high headroom) is generally considered to be highly dependent on spoilers, but it isn't highly dependent on strategic spoilers; there actually isn't much to say about NetHack strategy in terms of which choices will best help you win the game, because in nearly all strategic cases, any choice will work. There's a joke entry how_to_ascend in the spoilerbot for the most popular NetHack server, nethack.alt.org, which describes pretty much all the strategic steps in the game in one line. Compare this to something like Rogue, where strategic advice is generally pretty complex; the Rog-o-matic bot could win almost any winnable game of Rogue because it had so much information about the game programmed in (the bot equivalent of "fully spoiled"), but most human players do much worse. NetHack's spoiler dependence can be seen as being of the tactical kind. Most deaths due to lack of spoilage are due to not knowing what a monster or an item or a terrain feature can do (and will if you let it). At least these kinds of spoiler dependency are relatively easy to fix; in NetHack 4, I've added a database of basic information about items (although it needs a better UI for accessing it), and plan to do the same for monsters.

"When making strategic decisions, the best choice should depend on the character's situation." This is a request to reduce headroom, in that it requires that there should be a best choice to make at all. It's mathematically equivalent to "strategic choices where the better option does not depend on the details of the character should be eliminated". This point, combined with the previous point, gives rise to one of the classic contradictions in roguelike design, given that we have two very similar-looking sentiments that contradict each other: "The game should not contain decisions where an inexperienced player might make the wrong choice due to being insufficiently spoiled on the game's strategy." "The game should not contain decisions where the correct choice is independent of the current situation of the character." These can be seen to be contradictory, when rephrased like this: "For each decision a player must make in the absence of guidance from the game, there is no 'wrong' option." "For each decision a player must make in the absence of guidance from the game, which option is the 'wrong' option will depend on the situation that their character is in." And thus, it is important for roguelike developers to be clear on which set of decisions (if either) they want to eliminate! Otherwise, you will end up with all the decisions in the game being made automatically by the game, for fear that a player might choose the wrong one.

"If I want to play a «insert noun here», the game should let me do that." This is definitely a request for higher headroom; just insert any noun that happens to correspond to something that's a definite suboptimal strategy in the game.

"Win rate should be mainly determined by player skill." This is a request for lower headroom: high-headroom games allow inferior players to make a number of inferior choices and still win, which means that win rate among the game's better players becomes dependent not on how good they are, but on how hard they are trying to win.

Classifying roguelikes in terms of headroom

A long time ago, in the early history of roguelikes, there were two major roguelike "families", typically known as "hacks" (after Hack and/or NetHack) and "bands" (after Angband), and mostly dependent on whether the roguelike was initially inspired by Hack or Moria. Coming into the field of roguelikes more recently (probably around 2008), I found that this classification had mostly broken down, and strategy headroom gives us an insight as to why.

The thing is, that NetHack and Angband are both high-headroom games. In NetHack, the focus is on ensuring that players can play the game the way they want to, using features such as wishes, a variety of escape mechanisms, and enough interactions between items that there is normally some way to achieve whatever you want. I'm less familiar with Angband, but I know that it's possible to play the game in a very safe way (as seen, for instance, by the Angband Borg), and that most Angband players choose not to, which are likewise signs of a high headroom. (In general, the non-persistent levels of the original Angband, combined with its weak clock, mean that there's nothing really to prevent players from grinding any generatable item, if they really want to; choosing not to do so is a sensible choice, but it's just one valid option among many. This is not true of many later games based on the Angband engine.)

If someone's roguelike world were just NetHack and Angband, the distinctions between them would have to be made on fairly superficial grounds. The truth is, that these games are more similar to each other than many other roguelikes. Angband's levels can be infinitely regenerated. NetHack's can't, but randomly-generating items on the ground also drop as monster deathdrops, and after the first few dungeon levels, monsters generate fast enough and drop food fast enough that NetHack has no relevant clocks but the (very very slow) extinction clock, so you can farm almost indefinitely even without the use of any particular exploit. (Roguelike-playing bots are a good example of this. The Angband Borg had a policy of never moving on to a new depth until it already had all the items it needed to guarantee survival there; this is, obviously, very slow, but computers don't get bored. Meanwhile, saiph, a NetHack bot, got stuck in a delicatessen once, and rest of the level was entirely full of monsters by the time she eventually starved to death; if it hadn't been for the chokepoint that was the reason she'd got stuck in the first place, she could likely have survived on the level almost indefinitely.)

However, this is no longer a world of just NetHack and Angband, and so we have many other choices to look at. Where, on a scale from Angband to NetHack, do we place DCSS (commonly known as "Crawl", but the original Crawl was somewhat different strategically)? Or Brogue? Or some of the newer "roguelikelikes" such as FTL?

The answer is, that all those games lie way, way off the NetHack end of the entire scale; they're all much more different from NetHack or Angband than NetHack and Angband are from each other. DCSS has a classic low-headroom tendency of nerfing or removing effects that are generally useful to almost all characters; for instance, it intentionally has very few to no high-quality escape items. In Brogue, if you want to play a particular character, you're going to have to resort to start-scumming; the items you need to build, say, a casting character won't always generate. In FTL, which upgrades for your ship are sensible largely depends on what items you find; deciding that you're going to choose a particular pattern of upgrades from the outset of the game would make it much harder.

And, of course, the hack/band distinction was in trouble when it started, simply due to the existence of Rogue, which is by definition the original roguelike. Is it like NetHack, or like Angband? The answer is "no". Perhaps the clearest sign of this is that the game is often unwinnable because not enough resources are generated to survive to the end; this means that it is also sometimes winnable only with perfect play, because the player is so tight on resources that a single mistake would leave them unable to finish.

Instead, I propose "high-headroom" versus "low-headroom" as a more meaningful way to classify roguelikes. We can have NetHack and Angband at one end, and Brogue and Rogue at the other. (Incidentally, this is why I often recommend Brogue to players who ask me about which roguelike to play, even though I like NetHack to the extent that I'm trying to unofficially maintain it; if it's clear to me that a player wants a low-headroom game, NetHack is not going to be a good recommendation for them, so I may as well recommend a good low-headroom game for them.)

Consequences of a high-headroom game

Maintaining NetHack 4 has left me in a good position to understand the implications of a game with high headroom, because NetHack is one of those games. In fact, this is arguably the reason that I originally started AceHack, one of NetHack 4's predecessors, rather than contributing to another variant; I felt that the variants that made more radical changes to the gameplay were making mistakes in the way that they went about rebalancing the game, in a way that I couldn't quite put into words at the time. I can put it into words now, though: the reason I dislike many changes made in SporkHack and UnNetHack is that they reduce the headroom of the game without sufficient compensation. In SporkHack, if you want a good weapon, you sacfest at an altar; most of the methods of obtaining good weapons have been removed, but not that one. UnNetHack doesn't have anything quite as glaring, but its limitations on wishing mean that players are forced into more traditional (i.e. less resource-intensive) ascension kits, reducing variety in the game, because weirder strategies are too resource-intensive. (Incidentally, Slash'EM does not suffer from this sort of problem specifically; its problems are entirely different.)

Still, though, even though I dislike this sort of change, many other players like them; and if someone asks me for a NetHack variant with changes made to the game balance, fewer exploits, or the like, I won't hesitate to recommend DynaHack or UnNetHack. Having a higher or lower headroom is not necessarily a good or bad thing. A good practical example is that NetHack has lost many players to DCSS over the last 10 years or so, and the players that I talk to about the issue mostly give headroom-related reasons for the change.

There are several advantages that low-headroom games, which is what leads players to search such games out, and which can equivalently be seen as issues with high-headroom games. I'd like to look at these issues, and ways to mitigate them:

In a high-headroom game, the game is going to be easy for an experienced player who is trying to win. This is pretty much unavoidable. As a result, high-level players often end up getting bored of the game; if you're trying to play as safely as possible (which is standard roguelike tactics), you are going to have uneventful games most or all of the time. What sort of solutions exist to this issue? The NetHack community's standard response to this is that of challenge runs, which have the purpose of effectively consuming some of the headroom in the game, making the remaining options more sensitive to player skill. This has a big advantage over making the game generally more difficult; the exact nature of the resulting game can be more specific to the player, and so adjust to the difficulty and playstyle that that player wants (and there's nothing preventing someone changing from one challenge run to some very different challenge run when they work out the strategy for the way they were playing beforehand).

The above is a special case of a more general issue: players often feel forced into tactics that they consider unfun. I've often heard stories along the lines of "NetHack gets tedious when you pick up and sell all the junk armour dropped by monsters" or "I like NetHack, but I spend hours sorting out my inventory". Both of these strategies will arguably increase a player's victory rate by some marginal percentage, with lots of zeroes after the decimal point. They aren't going to help much in NetHack, where victory is likely for a good player even without going to such extremes. We can see this as a symptom of low-headroom play in a high-headroom game. Imagine a game where if you don't sell all the loot dropped by monsters, you won't be able to afford an item that subsequently becomes vital to your survival. (It isn't hard to imagine; many non-roguelike RPGs work like that.) Suddenly, the "clean dungeon policy" looks less like a pointless diversion, and more like a strategy that everyone should be using to win the game. These players tend to request that things like item selling should be removed from the game, because they don't enjoy using them, and yet they feel like they should be doing anything they can to increase their chances. The problem with fixing this issue is that it's one of psychology and player perception. To many NetHack players, the solution to, say, "pudding farming is boring" is "well, don't pudding farm, then; the game is entirely winnable without it". For players whose minds don't work like that, some other solution must be found. One solution that seems to have been reasonably effective in the past is that of public ridicule. A new player's first ascension is unlikely to be criticised, but after someone posts five or six wins through pudding farming, the standard community response is likely to be "sure, now go do it without farming and maybe we'll be impressed". I originally thought that this was just a standard flamewar about how to play the game, but I'm beginning to suspect it has another purpose: of encouraging players to look for enjoyable methods of playing the game, rather than feeling forced into the less enjoyable methods. After all, pudding farming is a famously tedious strategy. I actually recently spoke to a player who enjoys pudding farming; they do exist. Interestingly, nobody else in the conversation particularly seemed to mind the fact that they were farming; the attitude in the community very much seems to be designed to discourage boring play among players who are bored by it, rather than to prevent players enjoying the game in the way they want to enjoy it. The case of pudding farming, at least, is relatively easy to deal with. In addition to the social stigma, I've added a counter in NetHack 4 that counts the number of puddings that a player splits, visible in the game dumplog. This way, the game itself is giving a subtle hint that maybe this isn't the most enjoyable way to play, yet not cutting off the options of people who genuinely enjoy doing that. Other cases are harder to deal with. In particular, the whole stashing and inventory management subgame is something that eventually turns many players off NetHack because they feel obliged to participate in it, and yet don't enjoy doing it; and yet there's no real stigma attached to stashing at the moment. (For what it's worth, I once did a "one screenful of inventory" ascension, and didn't find any particular difficulty with doing so; all that that requires is a willingness to abandon items you're probably never going to use anyway. Inventory management in NetHack has just as much headroom as everything else.) This is a problem I'd very much like to find solutions to, but it's not clear what I can do to fix things in the game itself, rather than in the community at large. (Removing inventory management is the obvious solution, but also an incorrect one; the correct solution to "some players are playing the game like its headroom is lower than it is" is not "lower the headroom", because then you have a problem of "some players are playing the game like its headroom is higher than it is", and likely a larger one in terms of the number of players involved.)

Another problem of a high-headroom game is that all games are going to look the same unless you intentionally try to make them look different. Players naturally form habits, and have rules of thumb that they use to decide how to resolve choices based on their previous games; and a high-headroom game gives players no real incentive to avoid this behaviour. The behaviour is not necessarily even a harmful one; for instance, my minimalist valkyrie games are largely similar to each other, but I don't mind that (especially as minimalist games are so tight on resources that there's a fair chance I'll die late on in the game), and as long as I enjoy playing the game like that and it doesn't hurt other player's enjoyment, there's no need to consider it a problem. However, there is a problem here, and it's that the randomness in low-headroom roguelikes is responsible for much of their replay value, and high-headroom roguelikes don't have that. Once everything that happens in the game is something that's happened before, half the nature of a roguelike as a roguelike is lost, together with one of the huge advantages of the genre. And players are unlikely to go out of their way to make games different from each other. This is what's responsible for such sentiments as "NetHack is only interesting when things go wrong". (Also, why helping another player play is often more enjoyable for experienced players than playing the game themselves.) At least this problem is one that can reasonably be resolved by the game itself, although so far, most NetHack variants (including mine) aren't really attacking it. The key observation is that because the game is high-headroom, it's reasonably safe to experiment with ways of making different games play out more differently to each other (although care must be taken to ensure that there's actually a decent variety of solutions available to the problems you pose, for fear of creating problems which require particular solutions and thus reduce the variety in the game, rather than increase it). I have several ideas along these lines; most likely, some of them will work and some of them won't. Trying some of them out in the more experimental variants would be an interesting idea. (One attempted solution that already exists in NetHack is that of bones levels; the idea is that situations that have already killed a character are more likely to be interesting, and to require creative solutions. Sadly, this doesn't seem to actually work out in practice, because a large proportion of deaths in NetHack are due to typos or stupidity. It may be interesting to see what bones levels are typically like in NetHack 4, which makes typo deaths harder; perhaps the interface improvements will have a nice side effect of fixing the balance issues with bones. Perhaps this is just wishful thinking, though.)

Consequences of a low-headroom game

There are many challenges with high-headroom games that lead players to seek out, or at least to think they want, lower-headroom alternatives. So what sort of things can go wrong as the headroom reduces?

In high-headroom games, players have to create their own replay value via intentionally seeking out different playstyles and paths to victory. Low-headroom games force the issue via forcing players down particular paths, but this has its own problem: now the game is lacking in replay value because you have to go with the choice the game gives you, even if it's one you don't enjoy or one you've tried too many times before. (Or you fail to identify the path the game is sending you down, and die as a result; this is also frustrating, because for a player unspoiled on strategy, it feels like they died to something that they couldn't have known about.) One effective solution to this has been found by the Brogue community: the massive, almost industrial-scale, use of startscumming. In NetHack, if you want to play a particular sort of character, you pick the most appropriate class at character creation, seek out the items you want, maybe wish for a couple. In Brogue, if you want to play a particular sort of character, you get a computer program to search through random number generator seeds until the items required by your build idea generate on the first few dungeon levels. This behaviour, while rejected by most roguelike communities, has become accepted in Brogue to the extent that the game now ships with information on generated items in the first few seeds, specifically for the purpose of making startscumming easier (and with the acknowledgement that many players may prefer not to use it).

Unlike high-headroom games, low-headroom games are very sensitive to small changes in balance. If you fix an exploit or nerf a strategy that's useful for almost all characters, the headroom drops. If the headroom is too low, the game is frustrating to play as it requires prescience or even omniscience to win. It is worth looking at some (non-roguelike, typically puzzle-based) zero-headroom games with permadeath to see how they deal with this problem: the standard solution is to remove all hidden knowledge from the game, giving all the information a player needs up-front so that they can work out a solution before making any irreversible decisions. Interestingly, I don't know of any roguelikes based on this principle, but there doesn't seem to be any fundamental reason why one couldn't exist, so I'd expect that one probably does and I just don't know about it; maybe a 7DRL? I guess one problem comes down to defining "roguelike"; there are definitely procedurally-generated puzzle games (e.g. the Solitaire family of games), and some of them don't allow saving or undoing and thus effectively have permadeath, but most people would not consider these to be roguelikes even though they hit most of the key points in the definition. A good example of what can go wrong here is Brogue 1.7.3. In Brogue 1.7.2, a widely recognised issue was that allies were too powerful; unlike almost every other aspect of Brogue strategy (which requires spending part of your limited supply scrolls of enchantment to enhance a particular area of your character's capabilities), allies became stronger based on a different resource (exploration) and thus could be employed orthogonally to other strategies with no opportunity cost. In 1.7.3, allies were changed to work on the same enchantment-based scale as everything else; this is generally an improvement to the game, because having to depend on one specific strategy that's always the same is not what roguelike players are generally looking for. The result was that suddenly, many builds ceased to be viable, leaving only a few reliable ways to win the game (which typically wouldn't generate). The ideal for a low-headroom game is that it forces you down a particular path to victory, that varies each game. If the path that the game "wants" you to take doesn't work half the time, though, there's a problem. How can game designers avoid this issue? The important thing is to take notice of when you're making the game harder (even in apparently uncontroversial ways such as removing an exploit), and make changes to compensate. Otherwise, your high-headroom games will become low-headroom, and your low-headroom games will become negative-headroom and thus unwinnable. Brogue didn't end up hitting quite this extreme, as it happens; but it's a cautionary tale of a "near miss".

Earlier, I was talking about how in high-headroom games, many players end up feeling forced into taking tedious or unfun paths in order to gain advantages they don't really need. In low-headroom games that do not take a lot of care, the problem is actual rather than psychological; rather than merely feeling that they are forced to take such measures, players can actually be forced to take such measures to have a chance of survival. If you enjoy some methods of playing a game but not others, a low-headroom game is going to disappoint you whenever it forces you onto a path you dislike. In order to avoid this problem, game designers have to identify all the parts of the game that might seem tedious to one or more players, and either eliminate or automate them. This is very hard to do in practice, and may even be impossible (if you want to avoid ending up with an entirely automated game). For instance, I personally find it unenjoyable to see a threat in a roguelike, then leave the area, go round it, and never confront it again, at least if doing so does not require much thought. (It's another matter if there's some risk in doing so, or if it causes a loss of resources and the monster will nonetheless have to be faced eventually, so that it cannot be pursued indefnitely.) If this is a standard tactic for dealing with monsters in a roguelike (as it often is), and a low headroom forces me to pursue it to have a reasonable chance of winning, I'm not going to enjoy playing it. This might be (and probably is) just an idiosyncrasy of the way I play, but the point is that there are hugely many players, each of which enjoys or fails to enjoy different things. A low-headroom game will thus alienate some proportion of players no matter what it does; and the more varied the game, the more players will be alienated. But a roguelike without much variety is problematic in another way. The only solution I know to this is to acknowledge that you're not going to be able to keep everyone happy. The fact that your game isn't high-headroom is going to upset some players as it is, so there are already players who aren't going to enjoy your game; just focus on pleasing the players who like the way your game typically plays out, because you can't accommodate everyone at once. Then you can eliminate behaviours that they don't enjoy being forced into from your game (while remembering to make the game otherwise easier to compensate!).

Thinking about headroom

Finally, here's a list of questions for aspiring roguelike developers to help them focus on what their game is about. This post has hopefully highlighted why it's impossible to keep everyone happy, and why some apparently reasonable about when creating a new game, to help you focus on the philosophy. These questions don't have right answers, in general. But I feel that for any particular roguelike you design, you should know what the answer is.