Cruelty scale

From IFWiki
Revision as of 15:19, 10 October 2017 by Zowayix (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

A rating system devised by Andrew Plotkin to measure how difficult a particular work of interactive fiction makes it for the player to progress past in-game obstacles. The classic scale has five ratings (Merciful, Polite, Tough, Nasty, and Cruel), with definitions and examples (see the References section) listed below:

Rating Definition Example 1 Example 2
Merciful Can never die or get stuck. The game is always beatable and no progress can ever be lost. The player passes by a key, then walks over a bridge to a locked door. The player can recross the bridge to pick up the missing key. There is a button labeled "Inorganic Vaporizer Ray". The game does not allow the player to press it, bringing up a message that it would cause her or him to lose all of her or his items.
Polite Can die, but cannot get stuck. Beatable as long as the player has at least one save (no matter where it is), but some progress may be lost if the player character dies and the most recent save is far back. The player passes by a key, then arrives at a bridge. The game warns the player that the bridge is unstable. If the player crosses (and sees the locked door), the bridge collapses. Either there is an undo option available, or some event causes the player to die (e.g. the player character may realize they have no way to proceed and automatically jump off the cliff that the bridge spanned). It is impossible for the player to save the game in a stuck situation and render the whole game unwinnable. There is a button labeled "Inorganic Vaporizer Ray". If the player presses it, their items vanish, along with their pacemaker, causing the player character to die. It is not possible to save in a stuck situation.
Tough Can get stuck, but this is obvious beforehand. Beatable by saving at obvious points. The player passes by a key, then arrives at a bridge. The game warns the player that the bridge is unstable. If the player crosses, the bridge falls and the player is stuck at the locked door without the key. Saving here would render the game unwinnable. Avoidable if the player saves upon seeing the bridge warning. If the player presses the button, their items vanish, making the game impossible to complete. Saving here renders the game unwinnable. Avoidable if the player saves upon reading the button's obviously dangerous label.
Nasty Can get stuck, but this is obvious afterward. Beatable by saving frequently/arbitrarily. The player passes by a key, then arrives at a bridge with no warning. If the player crosses, the bridge unpredictably falls and the player is stuck. Avoidable if the player had saved frequently/arbitrarily before crossing the bridge. It is obvious that saving after the bridge falls renders the game unwinnable, even though there is no warning beforehand. The button is unlabeled, but after pressing it, the game informs the player that their items are gone (or the player character abruptly realizes that their bag is much lighter, etc.). It is obvious that saving after this point renders the game unwinnable.
Cruel Can get stuck, and this is not obvious afterward. Beatable by saving arbitrarily to multiple files. The player passes by a key, then arrives at a bridge. If the player crosses and sees the locked door, a thief silently steals the key and the player is not informed. The player is stuck at this point, but it is not obvious and it is easy for the player to save after they are already stuck. The player must revert to a file where they can still see the key present. The button has no obvious effect. The player can only detect the effect of the button by obsessively checking their inventory. It is easy to save after pressing the button. The player must revert to a file where they still have their inventory.

See also: winning, losing, unwinnable, deadlock.

Limitations

  • Cruelty is only one element of a work's general difficulty. A mostly-easy work could earn a Nasty rating, and a very difficult one might be technically Merciful. (Design norms have shifted since the scale was proposed, making unwinnable states a less common concern and other aspects of difficulty more important.)
  • The scale has nothing to do with how often the player is likely to get stuck. (A huge game that is Cruel in one obscure situation and Merciful otherwise is classified as Cruel.)
  • The system was devised before UNDO or multiple-UNDO were standard expectations; the saving behaviour described in the explanation assumes that no UNDO is available. (Modern players expect to need saves considerably less than described; for instance, a Polite game doesn't need a save if you can UNDO at all.)
  • The distinctions between Polite, Tough and Nasty rely upon certain things being obvious to the player. Some will really be obvious to everyone (if the work ends in failure, everyone will agree it has become unwinnable); others are only obvious to some. Because of this, the distinction between Polite, Tough and Nasty games is not always clear, and has historically been subject to some debate.
  • Rating a game requires comprehensive knowledge of that work, which is not always possible in works with unpublished source code (and can be difficult to discern even if source is available).

Extensions

TVTropes has suggested three extensions to the ratings system, since removed from their source page. "Cruel" is reproduced here to distinguish it from the first extended rating:

Rating Definition Example 1 Example 2
Cruel A player realizing they are stuck has some clue as to where they went wrong, and a correct guess is immediately verifiable. Beatable by saving to multiple files, and which files to check can be narrowed down. The player may notice that they passed a key before and it is no longer there. If the player remembers this and has multiple save files, they can figure out that crossing the bridge and the key being stolen happened at the same time, and this is immediately provable on a future playthrough. A button that seems to do nothing is unlikely to actually do nothing in IF. If the player remembers this and has multiple save files, they can figure out that the button press and the inventory vanishing happened at the same time, and this is immediately provable on a future playthrough.
Evil A player realizing they are stuck has no clue where they went wrong, but a correct guess is still immediately verifiable. Beatable by saving to multiple files, but all of them must be searched through. The key is well-hidden, and the player is likely to not realize that they passed it. The player must obsessively check all of their save files for the missing key. However, if they know where the key is supposed to be, they can immediately prove that crossing the bridge is what causes it to be stolen. The button vaporizes all of the player's items and also opens the door to the next area. To actually proceed, the player must solve another non-obvious puzzle to disable the button's first function while keeping its second. The player cannot narrow down which save files contain the bad move and must obsessively check them all to figure out at which point their inventory vanished and what caused it. However, if they guess that the button was the cause, this is immediately provable on a future playthrough.
Hell A correct guess is not immediately verifiable. Almost certainly only beatable by consulting a walkthrough, as checking save files is not enough. Instead of the key being stolen, a future item far beyond the door is stolen instead. The player may cross the bridge, see the locked door, go back to retrieve the key, open the door, and render the game silently unwinnable but not provable until much later. Even if the player can tell that the item has been stolen (e.g. they arrive at the location of the future item and see a broken safe), they cannot readily figure out that the cause was crossing the much earlier bridge without the much earlier key. The button opens the door to the next area, but its vaporizer effect is delayed, happening dozens of turns later, a random number of turns later, or even one turn before the player needs each item. Even if the player obsessively checks their inventory every turn, they cannot readily figure out that the cause was the button, half of whose effects needed to be disabled. A save file in an unwinnable state is indistinguishable from a save file in a winnable state until much later, so it is very hard to prove that a guess is correct.
Beyond Hell/Ninth Circle of Hell Not even a walkthrough can prevent the game from becoming unwinnable. Likely literally unbeatable at least some of the time. (No known published IF works go this far on the rating scale.) In addition to obscure moves that are guaranteed to get future items stolen, other items in the game may be silently stolen at random times. There are multiple puzzles around the button, but only one actually disables it and the player only has the chance to try one puzzle. Which puzzle is the correct one is randomized and the randomization changes every time the game is saved or loaded. (As before, the player cannot tell whether the button has been properly disabled or not until dozens of turns after it has been pressed.)

References