Imoria

From RogueBasin
Jump to navigation Jump to search
Imoria
Defunct Game
Developer see article
Theme Tolkien
Influences Moria
Released 1989 (4.8)
Updated 2003 Aug 20 (4.85.22)
Licensing free
P. Language Pascal, C
Platforms VMS, Linux
Interface ASCII
Game Length 50+ levels
[{{{site}}} Official site of Imoria]

The Imoria variant of Moria was made at University of Washington and written in VMS Pascal. The credits list: Kenneth Case, Mary Conner, Robert DeLoura, Dan Flye, Todd Gardiner, Dave Jungck, Andy Walker, and Dean Yasuda.

It included:

  • water levels
  • expanded town, with random buildings and encounters
  • quests
  • trading post (multi-user feature)
  • increased difficulty

Plot

The goal of Imoria was always the same: descend to level 50 (or greater) and defeat the Balrog. This was an incredibly difficult task, on par with successfully returning the Amulet of Yendor to your god in the classic roguelike Nethack.

Dungeon Levels

Imoria featured randomly-regenerated dungeon levels. Unlike persistent dungeon games such as Nethack, players were faced with a fresh dungeon each time they ascended or descended to a given dungeon depth. For this reason, scrolls of magic mapping and detect traps were much sought items, as they enabled a player to more quickly ascend or descent by quickly locating stairways. The only exception to this rule was town level, which was freshly generated for each new game but then remained fixed for the duration of the game. Theoretically, the dungeon went infinitely far down, although below level 50 the difficulty was constant. As with most roguelikes, monsters got tougher and treasures got better as you go lower down.

Character Races and Classes

Imoria implemented a large number of player character classes and subclasses, modeled largely on the player classes in Second-edition AD&D. These included, among others, fighters, wizards, thieves, druids, bards, and monks. Different player classes had noticeably different abilities, including hit-dice per level, melee ability, spell availability, armor allowances, and the like. Most classes had access to a guild hall, where they could buy class-specific items and obtain special services. Players of the wrong class were not allowed to enter a different class's guild. The thieves' guild had the additional property of being secret; its doorway was the '#' character, which was also used for walls, so thief characters had to search around in town until they found their guild hall, then remember where it was.

Players could further select from a variety of races for their character, including human, elf, half-elf, half-orc, dwarf, and some exotic ones such as dryad. Certain races were, as in AD&D, more suited to the skills of particular classes. Elves made the best wizards, dryads made the best druids, humans were good for basically anything, and so forth. Accordingly, different races had biases in their stats toward the classes they favored. Elves got extra dexterity, dryads got extra charisma, et cetera.

Character Stats

Character creation was through random dice-rolls, much as in 2nd edition AD&D, but with a few twists. Characters had the same basic six stats--strength, dexterity, constitution, wisdom, intelligence, and charisma--as in AD&D, but unlike AD&D, all six stats ranged from a low value of 3 to a high of 18/100. Further, at the time players started the game, they were allowed to specify minimum desired values for each stat; the game would randomly generate several thousand characters in this fashion, stopping when one was found that met the minimums. However, if the minimums were not met before a certain (fairly large) number of attempts, you were stuck with whatever one of those random characters best fit your desired minimums. This would, at first, seem to have been a recipe for buffed-up starting characters; why wouldn't players simply ask for minimums of 18 (or 18/100) for everything, and keep starting new games until they got what they wanted? Certainly they could, except in practice most players didn't. CPU time on the University of Washington VAX mainframes, where Imoria was hosted, was metered. Accounts got a fixed amount of CPU per week, and if you went over your CPU quota your account became "load leveled", causing everything--including your games--to run at a lower priority than other tasks on the system. Imoria's heavy use of random number generation during character creation could, if abused, easily trigger this effect, making a player's real-time experience of the game sluggish and much less fun to play. In practice, people specified high stat minimums only for the stats that mattered to the class they wanted to play, and took reasonable average values for everything else. This worked well to create characters that were well suited to the classes of interest, without being over-balanced. Stats mattered because they affected a character's ability to use magic items, cast magic spells, play instruments (bards), as well as engage in ordinary melee.

Monsters

Imoria included a vast array of monsters and items. Monsters supported a wide range of capabilities, including multiple melee attacks (claw/claw/bite), magic attacks (Ancient Dragon monsters, in particular, cast a large number of spells against the player), varying speeds (how many turns-per-melee round the monster got to take, versus the player), invisibility, teleport ability, teleport player-to-monster, walking through walls, and even psionics. The Balrog himself made use of all of these.

Items

Items included many types of weapons (melee and ranged, one-handed and two handed), armors (which were wearable in a variety of armor slots on the character's body), magic items including rings, scrolls, potions, staves, and wands, spell books, prayer books, and even musical instruments. Additionally, weapons and armor could be enchanted with ordinary plusses (or minuses) to-hit, to-damage, and to-AC. In this regard, Imoria deviated from AD&D, which uses a single value to augment both a weapon's ability to hit and its damage rating. Internally, weapons, armor, and magic items used a unified system for specifying magical abilities based on a pair of 32-bit bitmasks specifying abilities such as "detect traps" and spell-effects from the game's arsenal of spells. Further, Imoria included a "wizard mode" (not to be confused with the Wizard character class), where game administrators could enter a special item-editor mode and create one-off items out of raw bitmasks. Although originally intended as a playtesting and debugging tool, when the Trading Post feature was added, these one-off items became highly sought after because they could be exchanged from one player to another.

Money and Commerce

Imoria featured a fairly complicated money and purchase system. The money system had four different types of money: copper, silver, gold, and mithril pieces, in a .01 : .1 : 1 : 5 ratio. That is, a mithril piece was worth 5 gold, and so forth. All money weighed the same amount per piece, however, so for higher level characters copper and silver pieces were often not worth picking up, as they added too much encumberance value for their worth. The town level also had a bank which allowed players to exchange between money types, for a small fee. Items in town-level stores were always denominated in gold pieces, but the asking price was for suckers. If you were in a hurry you could pay list price, but more often than not players would take advantage of the haggling system to bargain with the shopkeeper. Expert hagglers could often obtain goods for slightly more than half the list price, but there was a danger: making an offer that the shopkeeper considered insultingly low could get you kicked out of the shop for a period of time.

Food

Like Nethack, Imoria also featured a food-and-starvation system, which was the bane of many players. Low level character starvation was common (although not as common as death-by-monster). High level characters rarely starved, because they had ready access to the town, through scrolls of town portal or similar magic artifacts, and could always teleport home for lunch, as it were. However, high level characters still commonly starved to death because of Imoria's speed system. Rings of speed (incredibly rare and highly prized items that doubled a player's turns-per-round) had a quadratic effect on the amount of food a player needed. Encumberance also affected how much food a player needed. Thus, a highly encumbered character wearing two rings of speed could require four or more times as much food as normal, and often players would forget to notice their hunger level until it was too late.

Summary

In total, Imoria was, for its day, a cutting edge roguelike. Although the end-goal was always the same, its extensive feature set created multiple play styles for players to explore and enjoy. Its inter-player trading post, in the pre-internet days, was a crude precursor to the massively multiplayer games in favor today. Although it has been over two decades since Imoria's creation, this author still remembers the pulse of adrenaline at walking my @-sign into a dungeon room only to be confronted by a menacing capital-D, or worse, capital-B.

The Balrog teleports you. The Balrog hits you. The Balrog hits you. The Balrog casts a spell. You feel confused! --more--

ICMoria: C for Linux port

In 1998 Steve Kertes ported the Imoria Pascal source code to C for Linux (Slackware and RedHat), with the first public release on July 26, 1998 (4.85.5), and the last release on August 20, 2003 (4.85.22).

The source code can be downloaded from https://github.com/dungeons-of-moria/icmoria.

(Note -- You will probably need to revert to gcc 3.x (no later) and change the "gcc" line of the two Makefiles to "gcc-3.x." It also requires curses.h, which is part of curses-dev. You may have trouble with the "mtwist" library unless you recomment the Makefile to use the second option. README has more information. But it does work!)