The Veins of the Earth design document


Design goals

1) To create a roguelike; a roguelike being a computer game having the following features:

  • Permadeath – the character pays for the player’s mistakes; restoring games is impossible
  • Turn-based – it is your knowledge and tactics which decides the difference between success and failure, not the speed of your reactions
  • Random generation – most elements of the game, called ‚entities’, are mostly procedurally generated. This includes maps, monsters, items.
  • Discovery mechanics – due to the high randomization, the player must discover anew what a given monster or item can do
  • Single command set – all commands can be easily accessed and remain the same regardless of the circumstances

2) To create a game which is easily modifiable and extendable

3) To create a game based on the Open Game License. Note that this does not mean adhering slavishly to the content of the System Reference Document nor that of Incursion [which has been declared OGL by its creator]. Original, aka. homebrew elements may be introduced.  The content covered by the Open Game License allows for great customization of one’s character, not being limited to attributes and a class/race combination.

Setting

The game is set in a vast underground world, represented as an infinite dungeon.

Action

The player will be able to undertake multiple actions, usually making use of items. Survival will require both conservation of resources and movement. Stalling will be penalized.

Objective

The character must survive as long as possible. There is no definite endgame.

Graphics

The entities (monsters, items) are represented as ASCII symbols set against a colored map. Certain symbols on map might denote special tiles, such as chasms, moss, water, lava, which have special effects, good or bad.

The player & monsters’ field of vision is also represented on the map, with darkvision being darker than normal light and the tint being progressively darker the further the tile is from the player.

The engine supports an eventual addition of tiles, should a contributor wish so.

Gameplay

 

The player can attack monsters in various ways. Melee attacks are made via ‚bumping’, or moving into a monster’s tile. Ranged combat works similar to spells, in that a player selects a button on the hotbar and clicks on the target.

Score will be granted for the depth reached after a certain number of turns has passed, therefore discouraging level-dipping, and the number of monsters killed. After descending down stairs, there should be no immediately available stairs up. There should be several stairs up and down on a given level.

The levels should be semi-persistent, discouraging scumming but reducing total randomness. They should be generated using pre-set rooms of various shapes and sizes.

A level may contain a shop, that is a friendly entity in a secure room. A player may sell or buy equipment in a shop, using money gained at start or found in the dungeon.

The game should not become focused on inventory management, for which reason containers (some of them of virtually unlimited volume) will be implemented. The number of items the player can carry will be limited by his Strength score, however.

The player should be rewarded for multiple actions, suited to different playstyles. Specifically, XP should be awarded for:

  • killing monsters
  • spotting a new monster for the first time
  • disarming traps
  • identifying items
  • stealthing past a monster
  • descending to a lower level

In addition to XP, the player should be awarded achievements for certain things, such as achieving a high character level, descending deep into a dungeon, defeating a very powerful enemy, narrowly avoiding death, surviving for a long time.

Achievements should enable the player to create more powerful characters in the future.

The player should be able to chat with friendly or neutral entities; the state of friendly or neutral being dependent on the player and the entity’s alignment.

The player should be able to use his skills to interact with his environment, including but not limited to:

  • finding and disarming traps
  • hiding from monsters
  • identifying equipment
  • becoming aware of monsters (Listen or Spot)
  • walking over dangerous tiles without suffering penalties (using Balance)
  • threatening neutral creatures (causing them to do what he wishes on success or turning hostile on failure)
  • threatening friendly creatures (turning neutral on failure)
  • haggling with shopkeepers (using Diplomacy and/or Bluff)
  • gaining up to 2 allies (using Diplomacy) note that the player should be able to influence an ally’s level-ups and equipment

The player moves from one part (‚level’) to the other via entities called ‚stairs’ (the name derives from the fact that the movement is usually up-down). His progress is marked as depth aka ‚dungeon level’, with tougher monsters appearing the deeper he is. The stairs need not necessarily change the dungeon level, they might lead to another level on the same depth, or they might skip some dungeon levels.

The player should be clearly informed of everything that pertains to him, including:

  • attack rolls
  • skill tests
  • the effects of a given skill/spell/stat
  • being encumbered
  • being hungry/thirsty
  • the passage of time
  • whether the monster is stronger than him
  • what factors influence his stats

 

 

The game will adhere to the System Reference Document, with the following changes/notes:

  • initiative will not be implemented
  • combat system is to be as close to the System Reference Document
  • player character and monsters work off the same rules; monsters can also have levels in classes
  • spellbooks and magic system works per System Reference Document (there is no mana)
  • paladin class will not be implemented
  • every class should provide worthwhile class features every 2 levels
  • healing spells should heal a percentage of the character’s total hp, not just a fixed amount (to avoid the ‚chugging a boatload of potions’ effect at higher levels)
  • every skill implemented should be useful
  • every race should have a favored class, granting a bonus
  • 3 classes max are allowed
  • 2 prestige classes max
  • excessive optimization should be discouraged
  • all stats should be useful. the concept of ‚dump stat’ should not exist
  • the Luck stat should influence item drops and monster strength and most other statistics

Dodaj komentarz

Filed under English, Essay, Roguelike

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s