5. Reviews - Rest of the World.

5.1 British Legends.

Name: British Legends
Importance: 3
Author(s) Roy Trubshaw, Richard Bartle
Location: CompuServe
Pricing Structure $12.50/hour plus $9.40/hour for UK players

Brief Description:
Archetypal MUA.

Historical Notes:
The original MUD1 MUA, with modifications for the American market. Launched on CompuServe in mid-1987, but the core of it dates back to early 1980. The name-change was because CompuServe thought "MUD" sounded unattractive.

Review:
British Legends (or simply BL) is the American name for MUD1, the very first MUA and the one from which nearly all others are descended. Despite its age, BL still compares well against many other MUAs, especially those available in the USA. Almost every feature present in MUAs, from wizzes to mobiles and most of the vocabulary, comes from this game (although, technically speaking, BL is MUD version 3B, a late modification of version 3A; it is 3A, or Essex MUD, which is properly considered as the root of other MUAs).

Although it is now dated, BL is still fun to play, continues to attract new players, and is well managed. Its atmosphere is good, and its players generally responsible (40% are female - the highest published ratio of any MUA).

The MUDDL interpreter that underlies BL is hardwired for a fantasy style world, and is limited in the complexity of commands it allows to be defined. Objects, rooms, mobiles and players are all stored using different internal formats, which makes the writing of generic routines difficult. Room descriptions take no account of whether the player is able to detect the sensations listed, so it's possible to "hear" sounds when you're deafened and not hear them when you're blinded. However, the system is still capable of being expanded in certain directions - the "act" command, for example, was taken from MUD2.

Despite its simplicity, BL's parser is remarkably robust and user-friendly - better than MUD2's, in fact. The game's depth is average, although its breadth still beats that of most MUAs (on account of its age - over the years, just about everything has been tried in it).

Perhaps the worst thing about BL is the fact that there is a 7-second delay between the processing of commands. This condition was imposed by CompuServe - BL works asynchronously, and is thus normally one of the fastest MUAs, even though the DECsystem 10/20 hardware upon which it runs is hopelessly out of date now. In the UK, a 7-second delay in a commercial game would be intolerable - 4 seconds is about the limit - yet since CompuServe impose similar constraints on all their multi-player games, the USA market is presently conditioned to accept such artificial limitations.

Due to its age and the size of the CompuServe user base, BL is the single most-played MUA in the world.

Summary:
Evergreen MUA which started off the whole industry. It looks its age when compared to the newer commercial MUAs, but is still surprisingly sophisticated in places. A classic.

Quotes:

"The initial attitude of the Americans was to be politely sceptical that any games software from the UK could be worthy of their attention. But once they saw the program running on their system they could hardly believe their eyes. So far as I know, this is the first British program ever to be taken by CompuServe."

"British Legends is better suited to the occasional user [than is Gemstone], with its simpler entrance requirements and a universe small enough to enable most players to get around adequately by memory."

"The kinder, gentler [than Gemstone] British Legends makes a quick command summary available, along with some rather general hints."

"Solving a puzzle for the first time is the most exciting part of the game."

"Adding a multi-user environment to the basic adventure game adds a whole new dimension."

"The first time I found myself in the swamp, a character called Monkey came up to talk and scared me so much that I immediately quit the game. I didn't know it was another person. I thought it was a monster about to destroy me!"

"Todd Carter is 22, a computer addict from Miami who was left blind by a gunshot wound in high school. On CompuServe, he called himself Blinddog when he played an adventure game called "British Legends". He was so hooked on the game that he dropped about $8,000 in on-line charges playing it."

"Not only are the wizards and witches helpful to novices, but many mortals also can show a kind word or gesture. Make friends!"

"British Legends is the most-played multi-user adventure game in the world." The Observer

5.2 Gemstone III.

Name: Gemstone III
Importance: 2
Author(s) ? (Simutronics Corp.)
Location: GEnie
Pricing Structure $35/hour 8am - 6pm $5/hour 6pm - 8am (no UK access point)

Brief Description:
Multi-user adventure game, fantasy setting.

Historical Notes:
One of the few MUAs developed independently of MUD1.

Review:
Like MUD1, Gemstone III was inspired by SUAs. However, despite this separation from the mainstream of MUA development, Gemstone III is nevertheless uncannily similar in many areas, particularly in its basic "search for treasure, get points, go up levels and become a wizard" attitude; levels and wizdom were never a part of early SUAs.

Gemstone III is primarily a role-playing game, which makes it popular among Americans. To this end, it requires that people beginning the game flesh out their persona by choosing between various personality characteristics, races, occupations, and many other details right down to eye colour. Few of these have any real bearing on gameplay, but they do make new players think they're getting value for money.

The game has a 25,000 word manual, which must be downloaded and read because there is no on-line help while playing. This, and the barrage of persona-defining questions at the beginning, combine to make Gemstone III very daunting for all new players except those in whom a thick rulebook induces excitement.

There are many rooms in Gemstone III, including streets and shops. As with the rest of the game, it seems that size is regarded as the most important facet, and that detail must be provided whatever the cost and no matter how irrelevant it is. It's the classic role-playing problem: whether to provide a loose framework in which players can develop personae their own way, or a tight one where players' options are limited by strictures imposed by the game dependent on the role they have chosen. MUD1's descendents tend to favour the freedom of the former; Gemstone III comes down heavily in favour of the latter, and in this respect is more akin to Island of Kesmai.

Summary:
An interesting MUA, but one which requires a certain doggedness on the part of its players to stay the course. Not a game for dabblers, socialisers or fun-seekers.

Quotes:

"Gemstone is the one for people who want to escape reality and really get into playing a role in an incredibly complex world."

"The sheer number of options involved in getting started can be so intimidating that a simplified setup process is also provided."

"In my roamings through Gemstone, I never saw the same place twice. Drawing a map is definitely necessary to navigate effectively." PC Magazine

5.3 Other Commercial MUAs.

As in the last subsection of the section on UK MUAs, the MUAs presented here are known to exist; however so little information is available concerning them that no detailed reviews or summaries are given.

Name: Kyrandia
Location: Galacticomm Bulletin Boards

Brief Description:
A basic multi-user adventure game. Notes: Bundled with the Galacticomm Bulletin Board system. These are expandable MSDOS machines intended for commercial, multi-user conferencing and the like.
Quotes

"A version of Kyrandia is reachable via US Minitel at "ALLA". I've yet to meet anybody in it, so usage seems light. And at $0.20/minute, exploring the world is very expensive."

Name: Quest for Magic
Location: Galacticomm Bulletin Boards

Brief Description:
A basic multi-user adventure game. Notes: See Kyrandia.

Quotes:

"A multi-user, interactive text adventure game."

Name: Scepter
Author(s) Alan Klietz
Location: none

Brief Description:
A multi-user adventure game, fantasy setting. Notes: A game called Milieu was written in the early 1980's under Multi-Pascal for a CDC Cyber used by high-school students in Minnesota for educational purposes. Klietz ported it to an IBM XT in 1983, and renamed it Scepter of Goth. Klietz later wrote a MUA called Screenplay, which incorporated building, using an interpreted command language reputedly more powerful than those available on the InterNet today.

Scepter was influenced by AD&D-style role-playing, and incorporated many of the ideas concerning character classes and skills presently gaining popularity in commercial UK MUAs like Avalon. Combat was blow-by-blow, and multiple identical objects were numbered (the same approach taken by MUD2).

Scepter was sold to a company called InterPlay in Virginia, which licensed out the software but was liquidated after its executives were charged with tax evasion. The game was sold off to creditors, and is no longer available.

Although many players loved the game, Scepter earned a reputation for enforcing artificial friendliness among its players, with ruthless consequences for "troublemakers". Thus, all sparks of originality were snuffed out, but the game worked well for people who didn't "misbehave".

Quotes:

"Scepter had the best atmosphere of any multi-user game I've player."

"In Scepter, you just offer an item for sale several times to get an idea of the price, then sell it when you hit the maximum again. Nobody I knew in Scepter ever bartered. They just took the first offer. They had better things to do with their time."

5.4 AberMUD.

Name: AberMUD
Importance: 1
Author(s) Alan Cox ("Anarchy"), Jim Finnis, Leon Thrane, Richard Acott, Rich Salz, Brian Preble ("Rassilon")
Location: InterNet ArkMUD engr.uark.edu ButlerMUD butler.tds.kth.se HackeMUD bass.vsect.chalmers.se IlliniMUD speedy.cs.uiuc.edu TempleMUD monet.ocis.temple.edu The Underground mole,ai.mit.edu

Brief Description:
Standard MUD1 clone.

Historical Notes:
Cox was a player of MUD1 who wrote AberMUD while a student at the University of Wales, Aberystwyth. The code was made generally available, and was enhanced and added to by several people, most notably Salz; Preble is the present AberMUG co-ordinator. A commercial version of the game has been running on Connect since 1989.

Review:
AberMUD was written in 1987 in B for a Honeywell £66 mainframe under GCOS3/TSS. Its first scenario was not a serious effort; its second scenario is the one in present use.

In 1988, AberMUD was ported to Unix and converted to C. Version 3.7.14 was distributed on JANet and InterNet, and regular updates by the original authors continued until version 3.9.8. The present version is 3.12.5, but version 3.9.8 spawned a rogue 4.9.8 clone which, among other things, has combat messages ripped out of MUD1. This is the version which became most popular on InterNet. Despite its poor design and implementation (eg. communication via shared files), AberMUD became the first widely-available MUA on InterNet, and most of the games presently being written by academics are descended from it.

The game itself is not particularly special, being a poor MUD1 lookalike in the Shades mould. There are 10 levels, scaled slightly lower than is common, and with fights scoring relatively higher than treasure. Treasure is converted into points by dropping it in a sacrificial pit in a church, ie. as MUD1's swamp.

There is no "sleep" command to restore stamina after a fight; instead, stamina is recovered automatically over time. This is something MUD1 did not have; although MUD2 does, AberMUD's rate of stamina replenishment is much quicker.

AberMUD lacks polish, despite its commercial standing and its erstwhile popularity (now waning, as it's regarded as a CPU hogger). There are missing full stops, spurious full stops, inconsistencies in uses of commas, and the room descriptions are convoluted and ambiguous. Objects and rooms are placed together without reference to description clashes, eg. snow on the ground, rain in the air and a rainbow in the sky, all at the same time.

Abbreviations in AberMUD are not catered for very well - the common "l" ("look") and "x" ("exits") commands are missing, for example. The game is also deficient in other commands - no "act" or equivalent, and apparently only cardinal directions plus "up" and "down". The game needs to be reset occasionally, but doesn't do so automatically: an explicit "reset" command is necessary.

Although fights play a big part in AberMUD, they are not well implemented, initially being of "the ghoul hits you" variety. This may explain why many of the game's descendents eschew fighting altogether.

Summary:
A simple MUA that makes other InterNet MUA-writers think they have less to do to become world class than is actually the case.

Quotes:

"The main reason for writing it was because the system manager said it wasn't possible on the Honeywell."

"It now seems to have found a home at St. Olaf University, where a few dedicated hackers are keeping it alive despite its general grunginess."

"The combat text has been greatly improved. ... InterNet versions now offer more MUD-like multi-line messages."

"I do have one fairly major quibble, and that is the lack of information and help text within the game."

"AberMUD has a sort of similar concept to LPMUD (kill the monsters and such until you become a wizard), but that's about the end of the surface similarity. LPMUD is designed to be easily extended from within the game. Once you become a wizard, you work on developing new sections of the game, and a list is kept of which wizards' sections are most popular. AberMUD can only be modified by changing the source data files and recompiling, and even then is far from easy (I know, I've done it...)."

Most of these MUDs have been eliminated in the US because of the network traffic they cause."

"The best version on the InterNet was in Sweden, and people in the US would play it but put up with the link problems which would regularly disconnect them."

"A problem with AberMUD, and to some extent LPMUD, is that people with slower links are severely penalised. Especially on some AberMUDs where the wizards require everyone to go back to the church before resetting, people with slow links have no chance."

"AberMUG is a fairly 'standard' game in its setting and in its general feel, so existing MUGgers should feel at home - although I did find the absence of several abbreviations to be annoying."

"I wasn't too amused at the way people seem to have lost the original AberMUD license, broken it in several places, and even included copyright material from other games systems (MUD1) in it."

"AberMUG is a multi-user adventure game in the traditional mould."

5.5 LPMUD.

Name: LPMUD
Importance: 1
Author(s) Lars Pensjö
Location: InterNet BATMAN batman.hut.fi Boiling MUD frey.nu.oz.au ClubMUD milton.u.washington.edu Crossroads civeng.ua.oz.au Darker Realms worf.tamu.edu Dartmouth LP melchior.dartmouth.edu DEATHMUD gauss.nmsu.edu DeepTrouble MUD krikand.iesd.auc.dk End of the Line ucrmath.ucr.edu GENESIS milou.cd.chalmers.se GhostMUD beowulf.acc.stolaf.edu NannyMUD nanny.lysator.liu.se NLD MUD chaos.utexas.edu Phoenix galjas.cs.vu.nl Sanctuary j.ms.uky.edu Small Systems calvin.nmsu.edu Sun MUD einstein.mpccl.ksu.edu Thieve's World uokmax.ecn.uoknor.edu Third World hardy.u.washington.edu UCSB-GEOG LPMUD sherlock.geog.ucsb.edu U Maine LPMUD mud.umcs.maine.edu Vision watnxt2.ucr.edu WARHAMMER MUD watnxt3.ucr.edu World of Mizar mizar.dosc.uu.se

Brief Description:
Standard MUD1 clone with object creation.

Historical Notes:
Pensjö obtained the source for AberMUD, didn't like it, so wrote his own MUA instead at Gothenburg in Sweden. It was distributed to other Unix sites across InterNet. Late 1989, some American players modified the code themselves (despite regular updates and technical support by Pensjö), and the two LPMUDs diverged. Several attempts to reconcile the European and American sources is now under way, such as one being programmed by Duncan Howard (a former MUD1 arch-wiz).

Review:
LPMUD (named after its author) is one of the more popular MUAs on InterNet, certainly in terms of the number of sites that run it. Although immediately descended from AberMUD, copies of MUD1 were sent to Sweden in the early 80's, prompting some activity in the MUA area by the locals; there was a project possibly already under way at Linköping to develop a MUA called Asgaard, which eventually petered out but left a body of programmers with experience in MUAs. It seems likely that the lessons and ideas that emerged from this effort may have had an indirect influence on Pensjö.

LPMUD plays as a good MUD1 clone until wiz level is reached. At that point, it allows players to create their own permanent rooms, objects, mobiles and (even) commands. The game's interpreter will accept input in a C-like, object-oriented language called LPC, and will save all creations across resets (unlike MUD2). It was the first InterNet MUA with this facility built in (although there is a good measure of cross-fertilisation with TinyMUD), and is thus often credited with inventing the idea; actually, most good first-attempt interpreters can handle it (second-attempt interpreters generally take their input preprocessed by a database compiler, for speed).

Because each LPMUD has rooms created by its players, the different sites on InterNet will all be different; a common core of rooms is linked to a network of new ones. However, room complexes are often copied between different LPMUDs, so the difference is not as great as it might be.

Resets in LPMUD are rolling. Initially, one object was reset every 3 seconds, but this meant that the more objects that were added, the longer the period between resets. Now, objects are only reset in a room when a player enters that room - a form of lazy evaluation. This works well, but it has the disadvantage of only working for very simple puzzles that involve objects' changing locations, rather than their changing other properties.

In LPMUDs, it's only a question of time before a player makes wiz. The only penalty for death is being subjected to a time-consuming sequence where the deceased is taken to a room and meets Death incarnate. Higher-level players even get a scar from this that they can show to their friends. Recently a quest system (similar to MUD2 tasks) has been added to make sure players know something about the game before reaching wiz, but performing such quests is not particularly dangerous to personae.

LPMUD has experimental bots programmed in LPC and running internal to the game. These are therefore more properly referred to as mobiles, but this term has not found favour in InterNet MUAs since most of them don't cater for such sophisticated objects. LPMUD has a client, LPTalk.

Versions of the European LPMUD are distributed regularly, and improving the system is an ongoing project programmed by Pensjö. There are some features which need changes to the LPMUD interpreter before they'll work, for example players' properties are hard-coded and transient ones cannot be saved to disc. However, with its excellent support and dedicated players, LPMUD will doubtless be around for some considerable time yet. Despite this, most LPMUDs are based in Europe - American systems managers seem less ready to tolerate CPU-intensive MUAs than their European counterparts, and prefer light users like TinyMUD and its descendents.

Summary:
An average MUA with object creation added on top. Not as prone to criticism as the freer creation-based games (if, indeed, games they are) like TinyMUD, but still causing the usual problems of atmosphere, editorial control and overall ownership that would dog a commercial version of the software.

Quotes:

"Only wizards can create new objects and rooms. By limiting creation like this, the feeling of chaos that one is prone to encounter on Tiny-type games is reduced."

"LPMUD: Lots of programming available. Mainly an adventure setup where you are trying to advance in level by solving puzzles and killing wandering monsters. This gives users a 'carrot' to chase (becoming a wizard) and could keep them in the game easier."

"One of the advantages that I see with LPMUD is that objects are continually being reset. There is one object reset every 3 seconds or so, so that an object will come back every 15 minutes or so. Therefore, a lot of people have the chance to explore and see things."

"Some rooms have been taken from AberMUD, but the game is user-extendable."

"The bad news about LPMUD is that the programming language is very C-like, and that comes back to the problem of whether your players know C... They might not be willing to learn a language just for the game. Of course, the same applies to TinyMUCK."

"This [extensibility] introduced a considerable level of depth into the choices open to wizards, and brought some new problems too."

"On LP there is massive amounts of building, because after making wizard the whole point of the game is to have most people visit your area. So, wizards build their areas to attract people, and if a wizard has crappy building, nobody visits. Therefore, the wizard is forced to make his building that much better."

"Strangely enough, the LPMUDs are closer to what the original TinyMUDs were: people wandering around, exploring. Eventually, people start building their own domains for people to explore. Granted, only wizards can build, but in a way that's good, since it really stops the casual builder who builds two or three items then wanders off never to build again."

"Semi-recently, quests were added as a feature of LPMUD. A certain number (or all) of the quests must be solved before advancing to wizardry. Most quests involve puzzle-solving and exploring (and most have some hack and slash involved too). Suddenly, LPMUD did not guarantee wizardry just by serving your tour of duty as a player - thinking was involved."

"The rate of new wizards on Genesis [the first LPMUD] is ten per week, and Genesis is already crowded (186 of level 20 and above...)."

"LPs are something worth checking. Think: 3,000+ rooms, 30+ players, running 24 hours - and not arousing the [system owners'] administration. These provide some challenge to the player - not to mention wizards and gods, it's just a pity their efforts mainly are used in building new rooms, not to make interesting events for players."

5.6 TinyMUD.

Name: TinyMUD
Importance: 1
Author(s) Jim Aspnes
Location: InterNet DragonMUD naucse.cse.nau.edu Eden unicorn.wwu.edu FantaMUD sage.cc.purdue.edu Islandia II apex.yorku.ca MuseumMUD fuzine.mt.cs.cmu.edu TinyMUD Classic planck.physics.purdue.edu TinyWorld banyan.ssc.gov

Brief Description:
Object creation and inter-player communication.

Historical Notes:
TinyMUD was prompted by a 1989 discussion on InterNet, and drew on LPMUD to abstract an idealised notion of what made MUAs important. It rapidly spread across InterNet, due mainly to its small size and low CPU requirements. Aspnes' own TinyMUD was closed down when he grew tired of it.

Review:
The MUD in TinyMUD stands for "Multi-User Dimension." There is some debate as to whether the system is a game. It was certainly written as a game, with the idea that players collect 'pennies' which they then spend on building new rooms. Pennies were either left lying around, or obtained by dropping objects in a pit. Combat is possible, just, but it's generally discouraged for fear of frightening off players. Everything else is very, very basic - even gender pronoun substitution wasn't handled in the original.

This adventuring aspect of TinyMUD rapidly disappeared. Objects were created with huge values, and soon players could get as many pennies as they wanted. This meant they spent all their time either building rooms or socialising with other players. The key point about TinyMUD is that anyone can build rooms. All they need to connect their creations to the rest of the room network is the co-operation of an existing player who doesn't mind linking a free exit with one in the new complex. Whether this is topographically correct is immaterial, as is the quality or quantity of rooms so joined together.

TinyMUD's creative capacities are strictly limited to only basic objects, rooms and exits. Complex actions cannot be defined, only room-related puzzles (eg. hidden doors, missing keys, mazes). Programmers found this frustrating, which is why the TinyMUD sources were rapidly torn apart and put back together with more powerful facilities at builders' disposal, eg. in TinyMUCK and TinyMUSH.

There are wizzes in TinyMUDs, of a sort. Really, they're little better than sysops, although they do have some authority over building and can remove or modify rooms. Game management is very difficult, however, since anyone, friend or foe, has full powers to add new rooms whether they have the slightest idea of what they're doing or not. This ensures that the only atmosphere a game possesses is that due to its players, and that any pretensions of consistency or depth swiftly disappear. Sadly, most people are not good room-describers (in the same way that most people aren't good novellists), and thus, although the quantity of rooms in a TinyMUD can be fantastically large, the quality is generally very low.

TinyMUD has several clients written for it - most of which work with all its descendents - and half a dozen or so bots. Some of these bots are tightly coupled to the program, able to dispense pennies etc., and thus are prone to causing crashes.

Ardent TinyMUD players see their game as the pinnacle of achievement for MUAs. At the bottom end of the evolutionary scale are CB chatline programs; next come systems with rooms, allowing local conversations and some degree of privacy; higher up, basic commands like "who" and "look" are present; higher still are games, with objects, more sophisticated commands, and rooms linked together so that they can be perceived as a complete structure; most sophisticated of all are the systems that allow the user to create rooms, objects, and complete scenarios "limited only by the imagination of the builder".

This evolutionary view of things completely misses the point: in order for room-creation to be worth anything, there has to be a user: commodities are valueless if they cannot be sold. TinyMUDs have no-one using the products of creation, and are therefore little more than chatlines with rooms as conversation pieces. They're no more games than would be an illustrated on-line discussion of amateur artists' latest masterpieces. TinyMUDs are indeed limited only by the imagination of the builder - with heavy emphasis on the word "limited".

TinyMUDs have a short lifespan, and operate like slash-and-burn agriculture: once a site has been farmed by a TinyMUD, thousands of players have been either hooked on TinyMUDs or put off all MUAs forever. The addicts will choose another site elsewhere, the rest are effectively lost.

As an example, consider two related TinyMUDs, Islandia and BloodMUD. They had the same seed, but grew in opposite directions. The fact that they are both regarded as "classic" TinyMUDs gives testimony to the ephemerality of such MUAs on InterNet.

Islandia began as recently as January 1990. By its close in November 1990, it was regarded as a "tradition" among TinyMUD users. It had as its core a 1000-object (ie. rooms, exits and portable objects) database called TinyBASE. This was put on general release to make the task of starting up a TinyMUD from scratch easier.

Islandia started at Berkeley, but was moved to different sites as it increased in size. It was constantly added to, and grew to be huge. In the month of October, it had 1,503 players (from a total of 3,271) and 14,900 rooms - a phenomenal size for a MUA. However, of those 14,900 rooms, only 7,503 were used that month...

Islandia was a friendly place, with friendly people, and famed for its many beautifully designed rooms. Its maintainers scoured the database removing useless or incomplete creations, trying to keep it to a manageable size and reasonably consistent. However, they finally decided to take the system down simply because, despite their efforts, it had grown too large; besides, they were wearying of trying to trim the database in the face of its relentless growth towards full capacity.

The maintainers also felt that the game was too old. People were using the system as a means to annoy others, which was taken as a sign of decay. Since TinyMUDs offer no facilities for game management, this fate eventually befalls all such programs, except in the case where being nasty is the whole point of playing.

Such was indeed the case with BloodMUD. The TinyBASE database was taken as a starting point, and developed along themes of blood, violence and sleaze. Rooms were deliberately corrupted by other players, with special attention giving to vandalising TinyBASE. BloodMUD was a reaction to the "nice" atmosphere that pervaded Islandia - and was a lot more fun to play. It finally disappeared when the database was accidentally deleted, but by then it had sunk into depravity.

By giving game-writing powers to anyone and everyone, it was hoped that TinyMUD would be a means of promoting individual expression and group interaction. It was a brave attempt, but it didn't work. Instead, TinyMUD has probably done more harm than good, at least in the short term, with many American academics growing up holding narrow views of what constitutes a MUA. On a commercial network, a game like TinyMUD would rapidly burn up as soon as it acquired a modest user base.

Summary:
TinyMUD is not so much a MUA as a forum for conversation where participants have pinned short pieces of prose on the wall for the benefit of anyone with the inclination to read them. If this kind of MUA gets a strong hold in the USA, it could set the industry back several years.

Quotes:

"TinyMUD isn't a MUD in the classical sense of the term; it isn't a game. In TinyMUD, all people can really do is create things and interact with others. It has built up a considerable following, and today is perhaps the most popular MUD on the InterNet."

"TinyMUD was written as a game. Jim Aspnes did not go 'Gee, I think I will create a social environment that will replace reality and have dozens of kids fail out of school because they are so addicted by this game.'"

"The *primary* value of TinyMUD is as an experiment in computer-mediated social interaction."

"TinyMUD: mainly social. Little programming available in objects, false exits and fail messages being the main programmability. It's simple, but could get boring."

"Combat, adventuring, levels etc. are not part of this game. It is possible that you could add these features to the game, seeing as the whole TinyM* series is notably more flexible (and consequently less well defined as a gaming system) than any other I've seen."

"One thing which draws people to TinyMUD is the dynamic room/object creation, but AberMUD would *never* allow *everyone* to create things. There is also a problem that AberMUD is a *much* more complex program than I think TinyMUD will ever get to. Dynamic room creation in an object-oriented type game is very hard to implement because the game requires many more flags and such than TinyMUD."

"With many people allowed to build freely, you get problems with non-finished parts of the world and parts that are totally different in character from the rest of the game. Walking from a fantasy castle to an SF setting or finding a large joystick in the centre of the castle may be fun the first couple of times, but it kills the atmosphere."

"I have personally received pages from people who're sorry that Islandia has to go and would like us to keep it going."

"BloodMUD was a fun place, near anarchy, as close as one could get. People did horrible things and generally broke MUD taboos whenever possible. It was not a MUD for socialisation or exquisite building, it was a MUD for being nasty and killing. ... In short, it was an excellent place."

"I put the kill command in when I was still assuming ... it would be difficult to detect disconnects. It was called 'kill' as a joke - and I assumed that putting a 100p charge on it would keep people from using it very often."

"Eventually they [TinyMUDs] are going to get too big for their servers, no matter how large they already are. ... Smaller MUDs are at the low part of the exponential growth curve, and have a great deal more life ahead."

"If you have a big MUD with 10,000 rooms and things enough to keep you happy 'til doomsday, the players won't look for them. After the initial fun wears off, they stop playing and start chatting, never to play again."

"Nobody pays attention to building on Tiny*s, except for newbies occasionally, but they're lowly peons and soon grow out of it anyway. So nobody builds there."

"I came across a room with an intriguing name. When I looked, I saw "dir1 dir2 dir3 dir4 dir5". After typing "dir1" I was then presented with another list of about 35 names (trying the other directions, I was presented with similar sized lists of different names). I picked one name and typed it in, and was suddenly taken into someone's domain. The size of each domain was limited only by the owner's imagination and the number of pennies they had available. When it dawned on me that each room behind the numbered portals were actually links to created kingdoms and the like, the sheer enormity of the game took my breath away."

5.7 TinyMUCK.

Name: TinyMUCK
Importance: 2
Author(s) Stephen White, "Lachesis"
Location: InterNet Brigadoon dante.cs.uiuc.edu CAMUCK flounder.berkeley.edu FurryMUCK hobbes.catt.ncsu.edu MbongoMUCK mbongo.ucsd.edu MedMUCK thesis2.hsch.utexas.edu Pegasus l_cae05.icaen.uiowa.edu QuartzPARADISE quartz.rutgers.edu TinyHORNS bashful.cc.utexas.edu

Brief Description:
TinyMUD with better building.

Historical Notes:
Version 1.0 was written by White, however he has left the project and there is now a programming team developing the system, headed by "Lachesis".

Review:
TinyMUCK is a version of TinyMUD that has been drastically modified to make building more powerful and controllable. Players need to have the "mucker" bit set by a wizard, which enables them to "muck about" with the game. Thus, visitors and casual players are denied the ability to wreak havoc (although if they really want to, there's little to stop them once granted the mucker bit). TinyMUCK is very popular, and people starting up their own MUA these days usually choose it in preference to TinyMUD.

The big difference between TinyMUCK and TinyMUD is programmability. TinyMUD provides users with very basic creation facilities, but TinyMUCK has its own interpreted programming language, TinyMUF ("Multi-User Forth"). This is flexible and powerful, but has a reputation of being difficult to use.

TinyMUF (or just MUF) is basically the same as Forth, with a few new library routines. It has three types of constant: integer, string and database reference (an index into the database that is unique to every game object). The language is stack-based, with library routines that operate on the stack (eg. + pops off two elements, and pushes back their sum). Variables are static, and there are functions to set and fetch them; variables' names (addresses) need to be dereferenced to obtain the values they hold. MUF has a limited "if-then" construct, but no "if-then-else". The game-specific library routines do things like print a string on someone's screen. There is some protection offered to players' creations in that "important" properties of objects cannot be modified except by their creator.

To make programming easier, there is an on-line, line-oriented editor built in. Source code is stored, which means tried-and-tested creations can be moved easily to other TinyMUCKs. MUF programs tend to be longer than in most MUAs - a simple slot machine (gambling pennies) is, for example, around 150 lines long. TinyMUCK can read TinyMUD databases, but not vice-versa.

TinyMUCK comes with plenty of documentation, and compared to other building-oriented MUAs on InterNet looks rather attractive. It works, and it can perform many powerful tricks. Its problem is that the people doing the building have little experience of a thorough, well-written MUA. The best example of this comes from TinyMUCK's own advertisement on InterNet: under the headline "Can *your* MUD do this?" was a short transcript of a TinyMUCK session where the player created a "camera" object, took a "photograph" of another object with it, and then "projected" back the image. This is genuinely impressive, except the photograph was of a red rose "with the fragrance of spring". This lack of attention to detail ensures that unless there is strict quality-control from above, any MUA which allows arbitrary, unchecked additions to its database is going to suffer severe problems maintaining overall depth.

Summary:
TinyMUCK is a decided improvement on TinyMUD, but it's really just one short step on the long road back to LPMUD-like MUAs. The sooner programmers of TinyMUD derivatives realise this, the better.

Quotes:

"Why wait for 'more powerful' MUDs when you can have all this?"

"TinyMUCK 2.0 is better documented than any other MUD in public distribution."

5.8 TinyMUSH.

Name: TinyMUSH
Importance: 2
Author(s) Larry Foard
Location: InterNet Sanctuary valkyrie.ecn.uoknor.edu TinyCWRU solarium.scl.cwru.edu TinyMUSH sigh.berkeley.edu TinyTIM grape.ecs.clarkson.edu ToonMUSH uokmax.ecn.uoknor.edu TwinPeaks corona.ecn.uoknor.edu

Brief Description:
TinyMUD with modifications.

Historical Notes:
Another approach by the Berkeley group to making TinyMUD usable.

Review:
TinyMUSH is an enhancement to TinyMUD that is easier for beginners to use than is TinyMUCK, but which irritates trained programmers. It differs from TinyMUD primarily in that it provides daemons that can be programmed to fire when an event occurs. This is similar to an AI technique, production systems, however in TinyMUSH the production rules are called V-functions. They are short pieces of code that provide a means of storing, changing and displaying information. Some fields are expected for all objects, such as what happens when it is dropped, killed, or listened to.

Recognising that in enormous databases players rarely bump into each other by accident, and that normal travel between rooms can involve a string of thirty or more directions, TinyMUSH has more liberal teleportation rules than TinyMUD, enabling players to materialise in other players' creations without permission.

TinyMUSH does have one kind of object that may be of general applicability in MUAs - the puppet. This is an item that can relay information to players. Example uses in a fantasy setting would be a crystal ball or a magic-user's familiar. Although some of the advanced UK MUAs have similar objects, most do not.

TinyMUSH is a nice idea, and the notion that one small change can cause great changes to occur elsewhere in the database is attractive. However, programming this kind of system and controlling the interactions between daemons is a nightmare even if there's only one programmer: with lots of people programming objects, it will soon be virtually impossible for anyone to predict the effects of actions or figure out the cause of some change. The problem goes away if the changes that daemons can make are limited, but then so does all the power.

A version of TinyMUSH runs on a public-access bulletin board in Toronto.

Summary:
A worthy attempt, but, inevitably, destined for obscurity.

Quotes:

"When a user does X to Y, the MUSH can be programmed to fire off all kinds of small 'programs'. I use quotes, because these aren't so much programs as one-line attachments to object Y. Qualities maybe."

5.9 TinyMOO.

Name: TinyMOO
Importance: 3
Author(s) Stephen White
Location: Internet belch.berkeley.edu

Brief Description:
TinyMUD with better building.

Historical Notes:
MOO stands for "MUD, Object-Oriented". TinyMOO is an enhancement to TinyMUD, written in 1990. White also wrote the original TinyMUCK.

Review:
The main difference between TinyMOO and TinyMUD is that it transfers the power to create objects away from the system administrators and towards the players who are builders.

Objects are implemented in a simple, C-like language, and can easily be specialised (so that even non-programmers can create). This is achieved by a class hierarchy and an inheritance (ie. object-oriented) approach.

TinyMOO is not yet distributed publicly.

Summary:
Another attempt to make TinyMUD safer, TinyMOO is basically a means of allowing people to share a programming experience, chat a little, and do nothing else.

Quotes:

"The current version is stable, however I'm in this bad habit of tinkering and tinkering with it without releasing it."

5.10 UberMUD.

Name: UberMUD
Importance: 3
Author(s) Marcus Ranum ("Jerry_Cornelius")
Location: none

Brief Description:
An experiment in MUA building language design.

Historical Notes:
Began as a project to improve on TinyMUD. It was written from scratch, and generated a lot of interest - Ranum was willing to give every idea a hearing. A mailing list was established to organise messages between interested parties, and when UberMUD was completed the mailing list enlarged its brief and stayed on. So far, most of the discussions on it still concern UberMUD, however. The Uber part of its name comes from the German, as in Übermensch.

Review:
UberMUD was conceived as an alternative to TinyMUD, with much improved building facilities. It incorporated many ideas, some of which were clearly ridiculous but others of which showed sufficient promise to be included in many post-UberMUD InterNet MUAs. In particular, its system of protecting objects from misuse by others (using a form of permission inheritance) looks like making an impact.

The UberMUD language - U - was low-level, a cross between Forth and C (Forth semantics, C syntax). There were no predefined data structures, as everything was implemented directly in U, nothing hard-wired. Objects were atomic entities to which properties could be attached; that meant that things like inheritance had to be implemented in U (MUD2's MUDDLE language, which has the same overall aims as U, has inheritance built in automatically: this helps with function matching). U's only predetermined factor was the order in which programming-language objects were searched to find code to execute: verb first, noun second, player third.

Despite all the ideas that were included in UberMUD, some simple things were left out (gender pronoun substitution being the most glaring omission). It had the capacity to implement them, but no-one put them in. The mistake made was to believe that by having a flexible implementation language that allows pretty much anything to be phrased in it, everything necessary actually would be phrased in it. Definition languages have to be either specific (ie. with much assumed, but able to guide a new programmer in database design) or general (ie. assuming nothing except that the programmer knows what is to be programmed).

Nowadays, UberMUD is maintained as the focus for discussions on MUAs in general, but it has signally failed thus far to widen the topic of discussion beyond UberMUD itself.

Summary:
UberMUD is available as a teaching tool for people wishing to write their own MUAs, but proved too cumbersome itself to use in practice.

Quotes:

"The author seems to have mostly lost interest now that the code is finished. Today, the code is used more as an example of what can be done with MUDs than an actual production system."

"UberMUD has implemented the biggest advance of all. It requires you to write the code on your local machine and upload it to the game, thereby automatically saving a copy that can be uploaded onto a second machine just as easily."

"The Ubermud mailing list is now, more generally, called mudwiz. It has expanded its mandate to include wizards from all MUDs, not just Uber."

"I'm pretty much tired of working on it, and don't plan on doing much more with it than I have (I wanted to prove it could be done, mostly)."

5.11 Other InterNet MUAs.

The MUAs here are either one-off systems not on proper public release, or vapourware. Suspected spoof MUAs (eg. CoreMUD) have been omitted. Name: Cthulhu
Author(s) Bill Burdick, Mitch Adler, Roy Riggs

Historical Notes:
The first version was written in Spring 1988 in C by Riggs. It was essentially just a souped-up TinyMUD. In autumn 1988, the game was rewritten in a version of object-oriented Lisp. Spring 1989 saw the first version of Mob, the game's database definition language; this was based on Objective C, and was scrapped. The second version of Mob came out Autumn 1989, based on Smalltalk and written in Lisp. The game itself was written in Mob shortly afterwards; the Mob interpreter was rewritten again in Spring 1990, using C. The game was scheduled for release Summer 1990.

Review:
If Cthulhu, or whatever it is eventually called, delivers all it promises it will roughly on a level with a slightly above average UK MUA. Nevertheless, this is good going to say that the programming team has no access to these games for ideas (except the rather obsolete AberMUD), and has developed its system from scratch.

Cthulhu supposedly has intelligent mobiles, weapons, armour, clothing, spells and glowing objects. There is some depth insofar as containers are concerned, since they can have a rigid (box) or floppy (bag) shape, however there is nothing similar to MUD2's transparency, for example, and the containers have no lids. There is a powerful form of "attach" available, although granting this to ordinary players is perhaps rather foolhardy on the designers' part.

There is an on-line system for room building, with players having control only over their own creations. This appears primarily to be because such functions are de rigeur on InterNet MUAs these days.

The wish-list of things on the drawing board includes many standard-issue features from the better UK MUAs. Using "look" to see in another room, and printing text messages modulo a player's ability to sense what they contain is nothing new in the MUA industry. Nevertheless, if such seemingly "advanced" features gained a foothold on InterNet MUAs, it may hasten the day when the vacuous TinyMUD-like MUAs are abandoned and more traditional games replace them.

Summary:
Sounds good, but as yet unseen.

Quotes:

"We can't sell anything written on a Purdue machine. We haven't been giving out any sources either. Basically, we are too dissatisfied with the old stuff to release it to the public eye, and none of the new stuff is finished yet."

Name: DUM II
Author(s)
Location: InterNet AdaDUM II legolas.cs.umu.se

Brief Description:
LPMUD-like MUA with no on-line building. Notes: DUM II is something of a reaction to the unrestricted, unchecked building possible in TinyMUD and, to a lesser extent, LPMUD. All wizzes have privileges to build, however they may only submit their designs to the game's maintainers ("gods"). These people write any necessary code, make modifications for consistency, and consult with the designer if they feel their suggestions need significant change or are inappropriate. New areas are then thoroughly playtested before being opened.

This form of editorial control is, perhaps, the best way to ensure that room-building progresses naturally, and linearly over time. Its main disadvantage is that the gods may not have the time required to deal with every submission speedily or fairly, and they need to be skilled programmers. Some players may also be tempted to take advantage of them.

Quotes:

"This [gods editing suggestions], and the fact that zones are not opened until play-tested, makes the general quality of zones and puzzles high."

Name: MIDgaard
Author(s) Andrew Plotkin

Brief Description:
A shell of a MUA, meant for complex building.

Historical Notes:
Finished in Spring 1990, due to go up in the Summer but so far nowhere to be seen. Designed to be run as a commercial system.

Review:
MIDgaard is a basically empty game, like TinyMUD, with the intention that players add to it themselves. It is object-oriented with an extensible classification system, and its power lies in the ability of players to program objects.

The game has nothing substantial built in - no spells, combat, persona details or the like. This sort of thing is up to the game builders to implement. The game is reported to have a tight security system that ensures the zones people build are distinct from one another and cannot be spoiled by other builders. This implies that objects created by one builder cannot be used in someone else's zone, although any game running under those conditions would be infuriating to play.

MIDgaard's authors are obviously pleased with their game, since they hope to run it commercially (charging around $20/month flat fee - this is comparable to commercial UK MUAs). Object creation, as it uses limited hardware resources (disc space etc.), will be surcharged.

However, MIDgaard's rationale is fundamentally flawed. The authors think that because they have a game which compares well with TinyMUD, it will attract players in the real world. However, as has been noted elsewhere, room building is not really an interesting or fruitful thing for people to do - TinyMUD's success is entirely down to the fact that it allows people to communicate over a distance while being less of a CPU hog than systems that do it a whole lot better. If MIDgaard's programmers think they can sell a simple chatline under the guise of its being a game, they are in for a tragic surprise.

Summary:
Over-rated, and also behind the times.

Quotes:

"Since the maintainers of MIDgaard will be employed by MIDgaard, we will have great motivation to keep things running smoothly, and make interesting stuff."

Name: PennMUD
Author(s) Charles Hannum ("MycroftXXX"), Michael Barthelemy ("Edheler"), David Singh ("Cyric"), Al Catalfamo ("Satan"), and 10 others

Brief Description:
On-line AD&D.

Historical Notes:
PennMUD took the InterNet world by storm in Spring 1990, when its incredible design was announced. After a flurry of scepticism, which PennMUD's promoters answered in disparaging tones that alienated them from the rest of the InterNet MUA community, they took umbrage and clamped up. Nothing has been heard of them since, except that the authors are no longer at the university (Pennsylvania).

Review:
Take the AD&D handbooks, enumerate all the ideas without considering their implementation, and you'll end up with a fair approximation to PennMUD (also called NeXTMUD on occasion). Detail was everything (but, for the most part, unnecessary).

There were to be 7 basic character classes, 6 different races, 9 basic statistics, an unspecified number of languages, spells with verbal and physical components, a game divided into "days" of 4 hours real-time duration, encumbrance affecting speed of movement, a currency with exchange rates for different coin types, a barter system, wet/dry and temperature factors for rooms, rolling resets, objects saved when you quit (with periodic persona file searches to return "special" objects that stayed out of play too long), vehicles, and several towns. Object creation was to be available, by extending the level system beyond god (ie. wiz). And this list just scratches the surface.

Not all proposals were completely unimplementable or totally undesirable, but most were. One neat idea that may work in existing MUAs is limiting the number of objects that can be seen in a dark room depending on the intensity of the persona's light source.

PennMUD combined all the worst things from MUAs with the worst things from games like Island of Kesmai. Fortunately, its specification team was so ambitious that it will be many years before anything as complex as PennMUD becomes publicly available. By then, traditional MUAs will hopefully have a strong enough toehold that when large, multinational games companies enter the field they will not ignore the hidden-depth, freestyle MUAs in favour of the explicit-bells-and-whistles role-playing monsters.

Summary:
Archetypal vapourware. All impossible design, and no substance whatsoever. The worst is, even if it had been written it wouldn't have been much fun to play due to the fearsome constraints it would have imposed in the name of role-playing.

Quotes:

"We are still working on the god/demigod commands and do not have a list made up as of yet. If you can think of any commands that you would like to see implemented at these levels, please note me on them with a full description of the command."

"To keep the game moving, you might consider dilating time for rest and movement commands. The amount of realism that is lost is not nearly as important as the amount of boredom that is alleviated."

Name: SMUG
Author(s) Jim Aspnes Notes: SMUG (Small Multi-User Game) was written by Aspnes as a would-be successor to his own TinyMUD. The primary goal was to include a programming language that ran at a high speed, but which was safely accessible to all players. The language includes an inheritance hierarchy, but has fewer tools in general than either TinyMUCK or LPMUD.

The project ground to a halt in mid-1990, so Aspnes recently made the sources available as ideas material for other MUA writers.

Quotes:

"A secondary goal was to show that you didn't have to have 15,000 lines of code to do this."

Name: VAXMUD

Brief Description:
Standard MUD1 clone.

Historical Notes:
Written in 1987 by students at Strathclyde University, and distributed in binary form only. It is still being added to. Notes: VAXMUD is written in Fortran, and runs only on VAX VMS systems. The scenario it comes with is hard to customise, and the fact that source code is unavailable makes it doubly unpopular.

The game saves objects carried when a player quits, a practice which in general can lead to games being tied up for some considerable time.

Name: YAMA
Author(s) Alan Cox ("Anarchy")

Brief Description:
A program for writing MUAs.

Historical Notes:
Alan Cox's latest project, based on his experience in writing AberMUD. Notes: YAMA is intended to be used for writing MUAs, and in that sense it is more properly described as a database definition language plus interpreter than a game itself. It was written to be fast, efficient and powerful. It is also reputedly difficult to learn. It is player-extensible, however its programmability in this respect is not as good as, say, LPMUD.

YAMA is presently in beta-test.

Quotes:

"It has been aptly described as an assembly language for MUDs."

"It is a game in the spirit of the original MUD; TinyMUD players need not apply."