A Classic Roguelike

Note: For around 4 years (2014 to 2017), this was my attempt to try to differentiate between roguelites and “real” roguelikes. I have since replaced this view with my Traditional Roguelike interpretation.

by Slash, priest of the Temple of the Roguelike, 2014

“What is a roguelike?” is a long-standing question with no single answer; there are many perspectives you could apply to understand what “roguelike” refers to, starting from strictly historical ascendance, passing through aesthetics or even focusing on a single feature such as procedural content or permanent death.

For a long time, I have refrained from proposing a single definition and instead tried to evaluate the “roguelikeness” of a game. I did this to open the possibilities of experimentation outside the bounds of the classics, but the world has changed.

Over the years there has been a resurgence of the term “roguelike”, where it has been applied to games that differ so much from the originals that the term is losing its meaning every time.


Having that in mind, I have decided to share my own interpretation of what I call a Classic Roguelike, with the sole intention of preserving the original nature and identity of the genre; this doesn’t mean roguetemple is only intended to cover the development of classic roguelikes; we are equally interested in games that utilize some of the mechanics from roguelikes and complement them with other genres.

The most important perspective for me when considering if a game is a roguelike is its game design features. Note however that my interpretation is not limited to the features of the original “Rogue”, nor am I listing all of its features to be required; this list is derived from my experience over the years on what makes a roguelike, i.e. which features from the good old roguelikes are critical to conserving the spirit of the genre.

So, for a game to be considered a Classic Roguelike by this interpretation, it should comply with ALL of the following features:

  • Turn-based: The player interacts in turns; for every turn, the player gets to decide what action to take. After he decides the game simulates the turns for the rest of the entities in the game world and them prompts the player back for action. The player can pass its turn but it’s done manually as an explicit action.
  • Grid-based: (Which could be implied from being “Turn-based”) There is an underlying orthogonal or hexagonal grid where the entities of the world are placed. Movement occurs from one cell to another adjacent cell.
  • Permanent Failure: Encouraging the player to take responsibility for the risks he takes. Games can be persisted to support interrupted play sessions but players cannot reload a game for the sake of experimenting or to “retry” a fight or seek a better outcome on a random event.
  • Procedural environments: Most of the game world is generated by the game for every new gameplay session. This is meant to encourage replayability and complements permanent failure.
  • Random conflict outcomes: The main conflict action between entities in the game (commonly, attacking an enemy or casting a spell) has a random outcome. For example, for most of the times, you can’t know for certain in advance how many hitpoints your attack will reduce from the enemy (Although the player has a reference range and variability that should allow him to make tactical choices).
  • Inventory: There are items the player can pick up and use and inventory space is limited, the player should decide strategically what items are best to keep to survive and win the game.
  • Single Character: The player is represented by a single character inside the game world.

Use this interpretation at your own risk. Some games could be considered roguelikes and don’t have all these features.

18 thoughts on “A Classic Roguelike

  1. We agree with your assessment of those things that make a game “roguelike” — which is why we are keeping them even in a virtual reality setting! RogueVR is going to try to stay as true as possible to the classic…

    Having said that, there are some quirks/differences in 3D and VR that would make some of the original features far too limited. For example, if you constrict movement to completely grid-based, it takes you out of the experience. Also, you shouldn’t have to press spacebar or similar to do a “wait” action. We are considering implementing a “hybrid turn-based” approach, in which all player — and enemy — actions happen on “turns”, but those turns have a time limit (if you don’t make your action quickly enough, it is considered a “pass” or “wait” turn)

    You can check out more at http://www.virtualrogue.com


  2. regarding tile-based: I’m surprised that hex tiles are allowed in this definition; did any classic roguelikes feature hex grids? although, on further thinking, can you restrict movement between sqaures tiles in such a way that the square grid is topologically identical to a hex grid? and if so, why stop there? what if a game uses a weirder graph? (and isn’t a dungeon already a “weirder graph”??) I guess I’m wondering if the topology of the game’s world really matters at all…

    also, does the single character requirement rule out Dwarf Fortress’s Dwarf Fortress mode? or what about roguelikes which feature pets? some offer more or less control over those pets. what’s the line between that being single-character or multi-character? (and does that really make or break roguelikeness?)


  3. i think that “luckbased”, but also “no win without learning (learning curve)” should also be mentioned in a definition for a roguelike.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s