Definition Of A Roguelike

So I have been happily working on my #1GAM Jam game for the last few days. In my mind I have been “calling” it a Rogulike. But, is it really a Roguelike? Let’s find out.

According to Rogue Temple, to be considered a Classic Roguelike, the game must have the following;

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.

Check. My game is completely turn based, in fact it plays more like a board game sometimes.

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 close cell.

Kind of. The game IS grid based, but there is no traditional movement in the Roguelike sense. The player enters Rooms of the dungeon, automatically, and then decisions are made. In fact, one could almost say that each room in the Dungeon is a Grid tile in the overall Level that the player is in. So, I think my game embraces the Spirit of this rule, but does not follow it exactly.

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.

Check. From the beginning I wanted this to be an all or nothing game. That is why I have designed the loot items to be very generic, and something that the player might need to use. There is a very limited amount of Items that will increase the Players abilities, and the ones that are in the Game are more like Powerups, instead of Item you normally see in a Roguelike. The Game will remeber where you were so you can pickup where you left off, but you wont be able to Load it over and over again. There is nothing Persistent about the Dungeon levels that are created, each one is different.

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.

Check. In this case, I take this to the next level as every Room is randomly generated as the Player progresses through the Dungeon. Many of the Rooms will look similar, and the layout for each Room is exactly the same (four doors each). This is a game about surviving long enough to exit the Dungeon on the 20th level. Not a Game about finding as much gold and loot as possible.

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 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).

Check. Each attack by the Player has some randomness to it. Although the Player can reduce the range of failure by having a higher experience level from the Enemy, or by having special Items that might give small advantages.

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.

Check. This is actually a Core element of the game. The Player will only have a few inventory slots available (not sure how many yet), and must choose which ones to keep. If you are not carrying the right item when a Monster has one, you will be penalized, and your chance of success in combat is reduced.

Single Character: The player is represented by a single character inside the game world.

Check. Although I have toyed with the idea of having a Companion or Pet with the Player to give her additional ways to defeat Monsters.

There are other interpretations for Rogulike’s, like The Berlin Interpretation, the Roguetemple’s original Roguelikeness Criteria and the Roguebasin definition. These one’s are more detailed, and also specify that the Game be a Hack n’ Slash. Even though my Game does not feel like a HnS, you certainly do Kill a lot of Monsters.

So, after reading all of these, I am pretty confident that my Game fit’s the mold for a Classic Roguelike game. Now, let’s just hope it lives up to the definition.


Comments powered by Disqus