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.