5. Reviews -- Rest of the World

  1. AberMUD
  2. LPMUD
  3. TinyMUD
  4. TinyMUCK
  5. TinyMUSH
  6. TinyMOO
  7. UberMUD
  8. Other Internet MUAs

See also commercial MUDs in the rest of the world.

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.


AberMUD was written in 1987 in B for a Honeywell L66 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.


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


"The main reason for writing it was because the system manager said it wasn't possible on the Honeywell."
-- Alan Cox [author]
"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."
-- Bill Wisner [player]
"The combat text has been greatly improved. ... Internet versions now offer more MUD-like multi-line messages."
-- Comms Plus! [magazine]
"I do have one fairly major quibble, and that is the lack of information and help text within the game."
-- Comms Plus! [magazine]
"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...)."
-- Jim Seidman [player]

Most of these MUDs have been eliminated in the US because of the network traffic they cause."
-- Philip Cutone III [player]
"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."
-- Comms Plus! [magazine]
"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."
-- Jim Seidman [player]
"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."
-- Comms Plus! [magazine]
"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."
-- Alan Cox [author]
"AberMUG is a multi-user adventure game in the traditional mould."
-- Connect [promotional material]


Importance: 1
Author(s): Lars Pensjo
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

Pensjo 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 Pensjo), and the two LPMUDs diverged. Several attempts to reconcile the European and American sources are now under way, such as one being programmed by Duncan Howard (a former MUD1 arch-wiz).

Jim Seidman contacted me with some comments on the above, which are included below -- Eddy Carroll ]

"I happened to be the 'American player' who started the divergence. It's really inaccurate to suggest that Lars was updating the code during that period. On the contrary, he was off doing his compulsory military service, and didn't even have Internet access for a year. I knew Lars pretty well, and I can tell you that while he would have loved to continue working on LPMUD, it simply wasn't an option. After he completed his military service he continued work on LPMUD, but at that point the "-A" (for American) series of versions were already well established. Since Lars had been away from the code, the American versions had a wide variety of bug fixes and enhancements that he had to catch up with.

This was all long ago, and it may be that not many people care anymore. It was just a little disturbing to read the suggestion that I had caused this divergence when Lars was actively working on it, when in fact I was trying to increase the popularity of LPMUD while Lars was in the military."
-- Jim Seidman, 29 March 2005


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 Linkoping 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 Pensjo.

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


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.


"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."
-- Comms Plus! [magazine]
"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."
-- Glenn Crocker [player]
"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."
-- Jim Seidman [player]
"Some rooms have been taken from AberMUD, but the game is user-extendable."
-- Comms Plus! [magazine]
"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."
-- Jim Seidman [player]
"This [extensibility] introduced a considerable level of depth into the choices open to wizards, and brought some new problems too."
-- Bill Wisner [player]
"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."
-- Patrick Wetmore [player]
"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."
-- Martin Terman [player]
"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."
-- Darin Johnson [player]
"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...)."
-- Bertil Jonell [player]
"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."
-- Esa Kankaanpaa [player]

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.


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.


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.


"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."
-- Bill Wisner [player]
"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.'"
-- Edwin Huang [player]
"The primary value of TinyMUD is as an experiment in computer-mediated social interaction."
-- Michael Mauldin [Julia author]
"TinyMUD: mainly social. Little programming available in objects, false exits and fail messages being the main programmability. It's simple, but could get boring."
-- Glenn Crocker [player]
"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."
-- Duncan Howard [MUD1 arch-wiz]
"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."
-- Michael Barthelemy [player]
"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."
-- Jorgen Holmberg [player]
"I have personally received pages from people who're sorry that Islandia has to go and would like us to keep it going."
-- Conrad Wong [Islandia maintainer]
"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."
-- Martin Terman [player]
"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."
-- Jim Aspnes [author]
"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."
-- Conrad Wong [Islandia maintainer]
"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."
-- Jorgen Holmberg [player]
"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."
-- Patrick Wetmore [player]
"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."
-- Comms Plus! [magazine]

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


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.


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.


"Why wait for 'more powerful' MUDs when you can have all this?"
-- TinyMUCK 2.0 [promotional material]
"TinyMUCK 2.0 is better documented than any other MUD in public distribution."
-- TinyMUCK 2.0 [promotional material]

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.


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.


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


"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."
-- Duncan Howard [MUD1 arch-wiz]

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.


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.


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.


"The current version is stable, however I'm in this bad habit of tinkering and tinkering with it without releasing it."
-- Stephen White [author]

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


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.


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


"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."
-- Bill Wisner [player]
"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."
-- Lauren Burka [player]
"The Ubermud mailing list is now, more generally, called mudwiz. It has expanded its mandate to include wizards from all MUDs, not just Uber."
-- Clay Luther [mudwiz postmaster]
"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)."
-- Marcus Ranum [author]

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.


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.

"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."
-- Roy Riggs [author]


Location: 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.

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


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.

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


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.

"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."
-- Michael Barthelemy [project designer]
"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."
-- Andrew Thomas [would-be player]


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.

"A secondary goal was to show that you didn't have to have 15,000 lines of code to do this."
-- Jim Aspnes [author]


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.


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.

"It has been aptly described as an assembly language for MUDs."
-- Bill Wisner [playtester]
"It is a game in the spirit of the original MUD; TinyMUD players need not apply."
-- Bill Wisner [playtester]

HTML conversion by Eddy Carroll (ecarroll@iol.ie)