A Classification of Muds

Martin Keegan
Grandmaster Data Services Ltd
Cambridge, U.K.
[email protected]
May 29, 2013

Abstract
Muds have evolved into many varied forms since their creation
in 1979. The Internet has facilitated the distribution of both mud
software and ideas, and accelerated the pace of mud development.
Today, most muds are derived from publicly available software. Muds
derived from the same software will exhibit similarities which may
be used to deduce which muds are related. This paper presents a
breakdown of The Mud Tree, and offers a classification system based
on the type of world modelled by a mud.

1 Introduction
In the mid 1980s, most muds were either dial-up systems, or existed on
proprietary (i.e. non-Internet) networks. Playing most muds involved con-
necting with a modem to an online service such as Compuserve or Micronet,
and paying a telephone company, the proprietary network or the mud (and
possibly all three) for access. When Bartle (1990) conducted the first sys-
tematic description of muds and mud types, his classification reflected the
preponderance of the proprietary networks which existed before the spread
of the Internet in the early 1990s.
Those new to mudding may notice that there are strong similarities be-
tween certain muds, and weaker relationships between others. Between some

1
muds there is seemingly no relationship at all. However, this paper will
demonstrate that almost all muds are related to one of two original sources.
This paper examines two methods for classifying mud systems. One, the
“genealogical” classification (dealt with in Section 3), is based on the fact
that most muds were created from ideas and/or software borrowed from ear-
lier muds and thus bear a family resemblance to their parents. The second,
“typological”, method groups muds together according to certain character-
istics — what the muds are, rather than how they came to be that way. This
is investigated in Section 6.
A substantial proportion of the relational information in this paper was
gathered as part of “The Mud Tree”. The Mud Tree was a diagram of the
inheritance relationships between muds (inspired by a diagram showing the
inheritance relationships between Indo-European languages), which I posted
to Usenet newsgroups such as rec.games.mud.misc as a request for more
information. The Mud Tree was first posted in March 1996, and reposted a
number of times in 1996 and 1997 incorporating new material and revisions.
1

2 Background
2.1 Historical Information
Written as part of an attempt to sell MUD2 to British Telecom, Bartle’s
(1990) paper concentrated almost exclusively on commercial muds. Since
then, the growth of the Internet has encouraged the expansion and evolution
of muds into many different forms, by reducing the costs of both playing and
running them. It has also given muds international reach and brought an
influx of users from a range of backgrounds wider than the mainly academic
communities who played the early muds. No reliable statistical data is avail-
able concerning the total number of users; I take fifty thousand as a ballpark
figure for the number of people regularly playing muds today. At the time of
writing there are approximately 800 muds listed as being publicly available
on the Internet. Internet muds now constitute the vast majority of muds,
the older dialup (modem) muds now largely extinct.
1
Versions of the tree are available from the author, and may also be found on the
DejaNews Usenet archive.

2
 Until the release of the software for games like AberMUD and Monster
in 1988, there normally existed only a single publicly available copy of each
mud. The release of the source code for AberMUD prompted the creation
not merely of several other muds using the AberMUD server software, but
also of many imitators, such as LPMud, TinyMUD, DikuMUD and DUM. 2
Instead of a “virtual community” coming into being on a mud, communities
now sprang up based around families of muds — there was a DikuMUD
community, a TinyMUD community, and so on. Muds which were similar
naturally attracted similar sorts of user, and these users would often play
several muds of the same type, forming communities which spanned multiple
(but similar) muds.

2.2 Difficulties with Research

One of the problems faced by researchers in this area, despite the relatively
abundant historical evidence available, is that some mud authors and users
have a habit of disguising or denying the origins and influences of their muds,
for political or commercial reasons. This practice may manifest itself in the
renaming of the server to make it appear that it was entirely written by the
administrators, or the removal of the credits and licensing information. The
converse of this phenomenon, authors claiming that other muds are derived
from theirs, is also prevalent.
Another difficulty is that a portion of mudding history has been lost as
the memories of mud creators and users have faded. Some of these muds
did have an influence on mud development — texts on mud history (Various
, 1990) wistfully recount a “nameless mud” from which Aspnes borrowed
the use of the " symbol as an abbreviation for “say”. Further complication
is introduced by “apocryphal muds”, which in all likelihood never actually
existed outside the imaginations of those who claim to have authored or
played them.3
2
Taken together, muds based on DikuMUD, TinyMUD and LPMud software account
for well over half the muds now available.
3
For example, muds which were said to have been run using software which was not
available at the time the muds were claimed to have been played.

3
3 Genealogical classification
A simple classification of muds may be made on the basis of the server soft-
ware 4 used to run them. In general, this software is freely available and
anyone with sufficient resources (network connectivity, time, programming
knowledge etc) may use it to run a mud. Muds created using the same soft-
ware will have many features in common — an individual mud’s distinctive
flavour will spring from what modifications the mud’s administrators choose
to make to the software. Given that most mud server software was influenced
by, inspired by or derived from that of previous muds, it is possible to create
a “family tree” of relationships between mud server types, extending (in the
case of most server software) back to Trubshaw and Bartle’s MUD1.
There are two distinct mechanisms by which a mud or mud type may
inherit features from previous muds (its “parents” or “ancestors”, as it were).
Using biological organisms as an analogy, I name these mechanisms “genetic
inheritance” (using the code of previous muds) and “grafting” (using the ideas
of other muds). Genetic inheritance can be seen as the natural evolution of
a system’s DNA (or software, for our purposes); Firstly, a programmer may
take the software for a mud and rewrite large sections of it, rereleasing it to
the public (and generally renaming it too). The resultant software will have
many similarities with the parent, and will usually be subject to a superset
of the parent’s licensing restrictions. For example, all Merc muds have (or
should have) the original DikuMUD license and credits present, and generally
look and feel relatively similar to original DikuMUD.
Grafting, on the other hand, is like taking a branch of a tree and attach-
ing it to a different tree altogether. In muds, grafting takes place when a
programmer copies, for instance, a combat system from another mud, reim-
plementing it in his or her own code. Either the ideas and features are
added to an existing system, or form the basis of a new one. The creators
of Diku and DUM saw AberMUD and wanted to write their own versions,
incorporating the good ideas and omitting the rest.5 . They had access to the
AberMUD code, but decided to write their own.
The closer the genetic relationship between two muds, the more features
they are likely to have in common. Many cosmetic features (the initial con-
4
The term “software” is used here to mean the programs and data required for running
a mud, and includes the database of a mud’s world.
5
Indeed, Christer Holgersson (DUM author), wrote “I liked AberMUD but not the
code.” – DUMII documentation

4
nection sequence, the formatting of text with prompts, punctuation and spac-
ing, the commandline parser etc) are often similar if not identical between
muds of the same or closely related types, and may be used by experienced
mudders to determine what type a mud is in cases where this is in doubt or
contention. In the case of some types of mud software, large sections of the
database may also be held in common.

3.1 Determining Inheritance

Knowledge of the strength of the similarities between related muds can in
theory enable us to deduce the inheritance relationships between almost all
of them. Such an approach to classification is necessary in disciplines such
as palaeontology, where there is but limited skeletal evidence from which
to extrapolate. With muds, however, the wealth and recency of information
available has enabled us to use the simpler methods of contacting the authors,
and gathering historical material from the Web, ftp sites, and Usenet news.
The more usual taxonomic systems take one or more characteristics of
an entity and classify on those properties. Such a classification is under-
taken in Section 6, and considered alongside other typological classification
criteria. Genealogical classification is best represented by a “family tree”
demonstrating which muds inherit portions of software from which others.

4 Building the Tree

Prior to the widespread release of muds in source-code form, muds were
generally created from scratch (MUD1, Scepter) or by large-scale grafting of
ideas. Bartle’s MUD spawned a stable of “Essex muds”, all using the Bartle
and Trubshaw code, chief amongst which were MUD1 itself and MIST. Alan
Cox took the ideas of MUD1 and wrote AberMUD in 1988, releasing the code
to the ’Net community. Likewise, the authors of Mordor adapted ideas from
Scepter of Goth for their publicly distributed (in 1993) mud server software.
The release in source-code form permitted genetic evolution to take place,
and “families” of mud server types sprang up around the descendents of
AberMUD. These families constitute the majority of muds today.6
6
It must also be observed that families whose source code was not as widely distributed
(DUM, YAMud) do not contain many muds, relative to the larger families.

5
 The following mud servers were grafted from version 3 of AberMUD: LP-
Mud, DUM, Diku and TinyMUD7 . These developments took place between
1988 and 1990. Since 1990, most mud evolution has been by the genetic
mechanism. DUM was rewritten to make DUMII. TinyMUD and DikuMUD
spawned myriad rewrites. LP was grafted from both AberMUD and Tiny-
MUD. Grafting henceforth only took place on a limited scale, within families.
The separation of mudding into separate communities based around server
code families discouraged the flow of ideas between the different groups.
A basic tree detailing these developments could be drawn as follows:

Essex MUDs
: Scepter
: :
Early AberMUD :
| : :
| : :
| : :
AberMUD +=+===+====+======+ :
| : : : : :
| Diku DUM : Tiny :
Dirt | : : Mordor
DUMII +==>+<=+
:
LP

In this tree (and those below), double lines (consisting of colons and
equal signs) denote grafting, and single lines genetic inheritance. The lines
connecting Early AberMUD, AberMUD and Dirt therefore represent genetic
mutation; Dirt is therefore the only extant major family genetically related
to AberMUD. 8
7
I list TinyMUD here because all sources except TinyMUD’s author insist (some in
quite strong terms) that TinyMUD was influenced by (if not derived from) AberMUD
8
Sources: LPMud FAQ, DikuMUD FAQ, DUMII internal documentation, “Mud His-
tory”, personal communication (1996 & 1997) with Richard Bartle, Alan Cox, Jim Asp-

6
5 Subtrees
Let us now examine the families in more detail.

5.1 The Diku family

Muds of the Diku family are likely to resemble each other more strongly than
members of other families resemble each other. This is largely because Diku
muds, moreso than other types, are distributed as fully working games, with
prewritten worlds, rather than as platforms upon which one must expend
much effort to create a passable system. Whether this is a strength or a
weakness is largely a political question beyond the scope of this paper.
One interesting effect of the distribution method is that Diku muds have
a much stronger sense of a common culture, rooted in a combination of Norse
mythology and Dungeons & Dragons. Many of the more common regions of
Diku muds are well known to experienced players, and have even spawned
parodies. Diku muds are therefore well suited to cater to players who prefer
to be able to assume a passing acquaintance with a mud before playing it in
earnest.

DikuMUD
|
+---------+------+-------+------+
| | | | |
Silly Pirate Copper Vie Circle
| |
DaleMUD Merc
|
+----+-----+-----+-----+
| | | | |
ROM Ack Envy Smaug NiMUD
| |
+---+----+ Mythran
| |
Oblivion Ember
nes, Brooke Paul, George Reese, Alex Fletcher, Christer Holgersson, Elizabeth Reid, Dan
Koepke, Alec Muffett

7
 9

5.2 The LP family (drivers and mudlibs)

LP muds are more complicated to classify as they consist of two layers, a
“driver” and a “mudlib”. The driver is responsible for handling the low-level
management of the game – network connections and interpreting LPC (the
internal language of LP muds), and so on. The mudlib, written in LPC,
defines the mud’s “look and feel” — it contains the parser, the database, the
command set and the cosmetic features. Some mudlibs may be used with
more than one driver. The drivers are only dealt with here for historical
interest.
Due to the inherent flexibility of LP muds, it is possible to write almost
any type of mud in it (not to mention web servers), whereas most other server
software varieties heavily favour a particular type of game (Dikus favour a
gradually restocking, combat-based game with limited building ability). This
hinders attempts at typological classification as undertaken in Section 6.

5.2.1 LP drivers

LP v1
|
+---+---+
| |
DGD LPMUD 2.4.5
|
+---------+-----------+
| | |
UriMUD LPMud 3.0 Shattered
| Worlds
|
+-----------+---+------------+
| | |
CD (LPMud) LPMud 3.1.2 LPMud 3.1.2-DR
9
Sources: DikuMUD FAQ, the source code for Merc, Circle, NiMUD, Pirate, Copper
and Silly, personal communication (1996 & 1997) from Dan Koepke, Alex Fletcher, Kane
Dudgeon and Erwin Andreasen

8
 | |
LPMud 3.2 (Amylaar) MudOS (LPMud)

5.2.2 LP mudlibs
Developments in the drivers for LP muds (indicated in square brackets) in-
fluenced the evolution of the individual mudlibs.10

[MudOS]
:
+===============+==============+
: :
TMI-1 [MudOS v20]
| : :
+----+ +=+=========+ : [LPMud 2.4.5]
| : : : :
TMI-2 Discworld Nightmare : :
| : : :
+---+ : +====+=====+ :
| : : | :
Foundation Nightmare IV Lima
11

5.3 The Tiny family

TinyMUD was heavily influenced by Monster, a VMS game written by Rich
Skrenta, by the IRC version of Wumpus and by AberMUD.

TinyMUD
|
+---------+--------+---------+--------+-----+
10
LP also inspired Ogham, a seldom-used mud server by Neil Robertson, author of the
NUTS talker system.
11
Sources: The LPMud Timeline (George Reese, 1995-1996), The LPMud FAQ, personal
communication (1996 & 1997) and Usenet articles (1996) from Tim Hollebeek and George
Reese

9
 | | | | | |
TinyMOO UberMUD | TinyMUCK Teeny SMUG
| : : : | : | :
| +==+==+ +======+=======+ | PerlMUD
| : | |
LambdaMOO CoolMUD TinyMUSH |
: | | |
ColdMUD +-------+-----+--+ |
| | | : | |
Cold MUSE PennMUSH : TinyMAGE
| | :
MARE +--+==+
|
MUX

N.B.: TinyMOO and TinyMUSH are often known as MOO and MUSH re-
spectively.
12

5.4 The Mordor family

Scepter
:
:
Quest for
Mordor
|
+-----+-----+
| |
Chalacyn |
Nights Isengard
|
Mordor
(public releases)

12
Sources: personal communication (1996 & 1997) with Jim Aspnes, Jennifer Smith,
Alan Schwartz, Chris Lawrence, and Elizabeth Reid

10
 Notes: Chalacyn Nights and Isengard are single muds, rather than fami-
lies.
13

5.5 The AberMUD Family

MUD1 MIST
: :
+====+====+
:
:
AberMUD
|
Lance AberMUD3
: |
: +-----+------+
: | |
AberMUD5 AberMUD4
|
Dirt
|
+----+----+
| |
Dyrt idirt
Notes: AberMUD4 was written by Richard Salz during a year when Alan
Cox was away from the Internet. AberMUD5 is by Cox, and incorporates
ideas from Lance, written by Leon Thrane, another AberMUD coder.
14

5.6 Miscellaneous muds

There exists a handful of miscellaneous muds not classified genetically. The
lineages of commercial systems such as Avalon, Shades and Terris are noto-
riously controversial, as commercial muds’ owners and their detractors can
13
Sources: Usenet posts by Brooke Paul (1997) and personal communication from the
same (1996)
14
Sources: YAMA documentation, personal communication (1996 & 1997) with Alan
Cox and Anna Eklund

11
have public relations or financial interests in the systems’ perceived origins.
Other notable muds which are not members of the aforementioned families
include Gemstone III, and Island.
This paper concerns itself almost exclusively with text-based muds, as
opposed to text-based talkers or graphical muds. The number of graphical
muds is now increasing steadily, yet no source code for them is publicly
available, so large families are yet to form.
For further information on miscellaneous muds, see The Mud Tree or
contact the author by email.

5.7 Other influences on the Tree

Some of the personal email I received in relation to the Tree cited actual
programming languages (like C and LPC) as parents of muds, in addition to
other muds (personal communication from Brandon Gillespie, 1996). Cer-
tainly, in cases such as LPs, TinyMOO, UberMUD, and Cold, the mud’s
internal language is the dominant and defining feature. In contrast, the
bulletin-board systems in the early days of JANET15 were also mentioned
(personal communication from Alec Muffett, 1996), as were “talkers” and
single-user adventures like Zork and Colossal Cave. Coincidentally, since be-
ginning work on The Mud Tree, I discovered not only Bartle’s 1990 tree but
also a tree charting the evolution of versions of the Colossal Cave program.

6 Typological Classification
Comparing muds with other systems capable of evolution, we find that the
mechanisms by which muds evolve make their evolution more like that of
languages than species of animals or families of humans. Some mud types
are formed from the combination of other mud types: such convergence can
occur with languages16 . Similarly, intermarriage is possible between members
of the same human family. However, by definition, different species cannot
in general produce offspring, or in the few instances where they can, the
offspring are infertile17 . Muds, languages and human families are capable
15
The UK’s academic computer network
16
For example, English has been heavily influenced by Norman French
17
mules and tigons, for example. Were the offspring fertile, the parents could not have
been separate species in the first place.

12
of recombinative generation; species are not. In addition, new muds and
languages can be created without any direct influence from others18 ; families
and species cannot spontaneously spring into existence without forebears.
To build a workable taxonomy for classifying a group of entities, it is nec-
essary to have a means of measuring their differences and similarities. Aris-
totle’s system of taxonomy chose one characteristic of an organism for classi-
fying species into families, and the Swedish taxonomist Linnaeus adopted a
similar approach in the eighteenth century. The result of such approaches was
that species with little in common other than the characteristic selected for
examination would be grouped together, and similar species which differed
in this respect were kept apart. At the beginning of the nineteenth century,
Cuvier and de Candolle devised systems which examined many characteris-
tics and weighted them appropriately. This methodology forms the basis of
the taxonomy system used by botanists and zoologists today.
Until now, typological classification of muds has primarily been carried
out using a single discriminating criterion, which separated muds into two
groups, “social-oriented” and “combat-oriented”. Whereas an obvious dis-
tinction does exist between such muds, this distinction served only to sep-
arate TinyMUD and its derivatives from all other muds. The subconscious
tendency to take as one’s characteristics for classification those features of
one’s favourite mud type which most distinguish it from all others is quite
strong, and may well be responsible for the stressing of a “disk-based” ver-
sus “memory-based” division in documents such as The MUD FAQ and The
MUD Timeline (both written by users of the first memory-based muds) or the
frequent mention of “gender pronoun substitution” in Bartle (1990). Pavel
Curtis, who was involved in the creation of TinyMOO, enumerated criteria
which a system must meet to be called a mud. He asserted that muds must
be capable of self-modification and not be “goal oriented”:

A MUD is not goal-oriented; it has no beginning or end, no ’score’,

and no notion of ’winning’ or ’success’. In short, even though
user of MUDs are commonly called players, a MUD isn’t a really
a game at all.
A MUD is extensible from within; a user can add new objects to
the database
18
There are many synthetic languages in existence today; not all of them follow Es-
peranto in clearly drawing on other languages for vocabulary and structure

13
 This definition of muds is not used in this paper as it disqualifies most
non-TinyMUDs! By using a single discriminating criterion, the shortcomings
of Aristotle’s and Linnaeus’ taxonomies were repeated.
The characteristics I have chosen for classifying muds involve an exami-
nation of aspects of a mud’s world. They are:

1. The degree to which the mud permits modification of its world by users
and administrators, and

2. How the mud’s world replenishes itself.

These features I regard as more fundamental than what sort of users a mud
attracts or any consideration of its low-level mechanics or cosmetic gram-
matical features. Similarly, the “skills-based” versus “experience” distinction
sometimes made (concerning how personal advancement occurs in the mud)
is not particularly useful, as a substantial proportion of muds don’t involve
personal advancement.

6.1 Self Modification

Some muds (such as TinyMUD and its derivatives) permit users to build
new rooms and objects on a grand scale; indeed one might even call this
their raison d’être. Others restrict this significantly, or do not possess such
a feature. In the first TinyMUD, all users could build new locations and
objects (though the means of easily removing them had not been created!).
LP muds permit high-ranking characters (usually called wizards) to create
and destroy parts of the mud world.
On the more traditional Dikus and Abermuds, no such facility existed.19
Acquiring the permission to create new parts of the mud did not require
months of dedication on the early TinyMUDs. On other systems, the ability
to modify the mud world may be restricted to the highest levels of the mud
administration — or it may not even be possible from within the mud.
What is critical for the purpose of classification is whether the permission
to “build” is available to anyone, may be earned through playing, or must
be conferred by the actions of an administrator.
19
“OLC” (online creation) is however now gaining in popularity on Dikus.

14
6.2 Resetting
In real life, once something is dead, it stays dead. If the population of a
village is wiped out, the same villagers do not magically reappear hours later.
In muds stressing competition between users, where resources are depleted
through killing and plunder, the dead non-playing characters (NPCs), the
food which has been eaten, the ale drunk, and the shattered shields and
broken spears must all be replenished, otherwise the mud will quickly become
stagnant when all the resources are used up. Finding a realistic method of
replenishing the resources in a mud world is a great challenge, since by its
very nature the process cannot hope to be realistic. Muds in the 1980s tended
to favour what I call the “Groundhog Day”20 system: periodically, the game
undergoes a “reset” (either initiated by the users or the system itself), where
all the elements of the mud’s world (excluding the users) are reset to some
predefined state. Users retained only their scores, knowledge and experience
when entering the newly recreated world. 21 . The main alternative to this
system, favoured by Dikus and LPs, is one of continuous restocking of the
world. Once an entity is destroyed, a replacement will shortly be created
in its place. In muds oriented towards building and socialising rather than
competition and combat, the world may not need to be reset at all. (If it did,
this would be counter-productive were it to destroy the users’ creations.)

6.3 Using these characteristics to classify

It is possible to grade each of these characteristics (modification and replen-
ishment) on a scale. For the reset characteristic, the range is from no resetting
at all, through gradual restocking, to Groundhog Day muds. The degree to
which building is allowed is easier to scale: Does the mud allow absolutely
anyone to build (“Full building”)? Most users (“Unrestricted building”)? A
few users? Only users appointed by the administrators? Just the wizards
(“restricted building”)? No-one (“no building”)?
Muds derived from the same software will tend to have nearly identical
reset and building characteristics, so plotting the set of, say, all AberMUDs
on a diagram whose axes represent these characteristics will produce a cloud
concentrated in the “Groundhog Day, no building” corner. In fact, this corner
20
After the film of the same name, in which the protagonist is condemned to repeat one
day of his life forever.
21
This system was favoured by AberMUD, DUM, Mundi, Island and YAMud

15
is quite crowded, as it must also accommodate MUD1, DUMII, Island, and
YAMud. This area has been marked as containing “AberMUD” and “DUM”
on the figure.
figure1.gif goes here
The figure above attempts to give a rough outline of the relative positions
of some of the major mud types, and should be taken as nothing more than an
approximation. In particular, LPMuds and UberMUDs are probably capable
of emulating the behaviour of most of the others on the figure. However, in
general, they occupy the positions indicated.
Muds types which are more closely related in these two characteristics
will appear closer together on the figure. Though one might assume there
to be an inverse relationship between the amount of building and resetting
in a mud (or “creation” and “destruction”) the characteristics are not com-
pletely interdependent. Obviously, muds where anyone may add objects to
the database are not likely to involve the competitive point-scoring typi-
cal of “destruction” muds, lest users create themselves immensely powerful
weapons and valuable treasure, and muds where there is no building or reset-
ting are quite rare — Federation II was one such. Instead of creating and/or
consuming resources, users redistributed their resources through trade.
The origin of the “social versus combat” distinction may be seen in the
figure — muds where resources are consumed through battle and plunder
(and which hence require resetting) attract a different sort of person from
that attracted by muds which revolve around creation of complex scenarios,
either through programming and building, or role-playing. The Socialisers
and Explorers in Bartle (1996) are attracted to muds in the TinyMUD mould,
and that the Achievers and Killers are drawn to Dikus and AberMUDs.

7 Mud Survival and Further Evolution of the

Tree
Learning to play a new mud requires an expenditure of effort — first-time
users of a mud must familiarise themselves with a set of commands, much
of the mud world, wrestle with the mud’s parser and so on. The amount
of effort necessary (and hence, presumably, the time necessary) decreases if
users are already familiar with similar muds. Over time this often generates
a preference for one particular type of mud, if not a blanket refusal to play

16
or try any other sort. 22
Partially as a result of this, users tend to form communities which con-
gregate on muds of the same type. They may be able to bring pressure to
bear on mud coders to make their muds resemble other muds their users
frequent. Assuming coders are interested in the size of their userbase, it is
in their muds’ interests to conform.
The much greater number of muds in existence (compared with previous
populations) requires muds to compete for users. This gives the users more
influence — they are now “consumers” or “customers” of the mud. A dele-
terious effect of this new-found muscle is that users may use it to pressure
admins to reduce the amount of effort required for playing (making the mud
“easier”). Groundhog Day resets are unpopular23 , and the ability to build
is popular. This trend ought to propel muds towards the TinyMUD corner
of the Figure, and some evidence for it may be found. In addition to the
above example of reset abolition, we may observe the rise of Online Creation
(OLC), which is gaining popularity in DikuMUDs.
Muds from larger families (by which I mean muds using the same server
software as many others) will be able to attract more users than muds from
smaller families. Users leaving a mud to start their own will prefer to use the
same software as their previous mud, or a similar variety.
The effect of this tendency of families of muds to develop along the same
lines is that innovation is discouraged, and conformity promoted, decreasing
the overall diversity of mudding, Instead of continuous diversification (a tree
with many branches and subtrees) within the families of muds this tendency
affects, we can expect reconvergence (mud types “merging” through grafting)
and for few of the branches of each family’s tree to bear descendents (of the
fifteen DikuMUD descendents listed in this paper, only five have descendents
of their own).
Should this enforced conformity lead to stagnation, mud authors may turn
their backs on genetic evolution and revert to grafting or implementing their
ideas from scratch. Of course, in order to ensure that their muds can gain
sufficient users to be viable, the authors would have to publish their source
code to enable the creation of more copies of their muds. The diversity of
the overall system will be restored, and genetic evolution may begin again.
22
Many Usenet posts requesting addresses of muds contain a (sometimes strongly
worded) preference for server type
23
An AberMUD called Asylum even advertises that it has abolished them

17
 Bartle’s tree (1990) listed approximately fifty systems. Ten of these were
actually genetic families of muds (AberMUD, TinyMUSH, TinyMOO, Uber-
MUD, DUMII, SMUG, YAMA), around thirty were individual muds (most
of them related to MUD1 by grafting, and most constituted single-member
“families”), and a further ten were other miscellaneous mud-like systems.
Were his list rewritten today, it would contain a mere handful of individual
systems (MUD2, Avalon, Gemstone III, Terris) and large sections on the six
families: TinyMUD, LPMud, Diku, AberMUD, Mordor, and DUMII. This
represents a significant decrease in the overall diversity of mudding, though
the new muds (especially the LPs and some forms of TinyMUD) are consid-
erably more flexible than those they have replaced.

8 Conclusions
The motivation for this paper was to provide an explanation of the manner
in which muds are related and how they have evolved.
The Tree has grown over time, with new layers of muds being added at
the bottom. This will doubtless continue, and this paper has suggested how
this might happen.
It was argued that muds whose source code is readily accessible have a
better survival chance than those which don’t. It is no coincidence that the
almost all muds today are descended from the first publicly available muds
written for Unix in C.
Using two characteristics for typological classification is an improvement
– there are other valid discriminating criteria, though many give misleading
results.
Further research areas suggested by this paper include the creation of
an experimental mud system with Groundhog Day resets and unrestricted
building, and assess its stability. The author would also be interested in
the results of an investigation into the geographic distribution of muds —
whether the more libertarian TinyMUD is more popular in America, whereas
some mud server types seem to be confined to Europe.
The Mud Tree is a demonstration of the evolution of non-biological sys-
tems. Muds can be thought of as composite entities, comprising both a
virtual world and the people who inhabit it. The communities the people
form, which span multiple mud systems, affect the evolution of muds. Mud
evolution is different from the evolution other sorts of entity, as extra mech-

18
anisms are involved.

Acknowledgement
The author would like to thank Dan Koepke, Richard Bartle and Alastair
Fischer for their assistance in developing the idea of The Mud Tree.

References
• Bartle, R. (1996). Hearts, Clubs, Diamonds, Spades: Players who suit
MUDs. Available: http://journal.tinymush.org/~jomr/v1n1/bartle.html

• Bartle, R. A. (1990). Interactive Multi-Player Computer Games. MUSE

Ltd, Colchester, Essex, UK.
Available: ftp://parcftp.xerox.com/pub/MOO/papers/mudreport.txt

• Burka, L.P. (1995). The MUDline.

Available: http://www.opensite.com.br/random/servicos/muds/mudline.html

• Curtis, P. & Nichols, D.A. (1993). MUDs Grow Up: Social Virtual
Reality in the Real World.
Available: http://www.oise.on.ca/~jnolan/muds/about_muds/mudsgrowup.

• Curtis, P. (1995). Talking with Dinos.

Available: http://vesta.physics.ucla.edu/~smolin/
lambda/laws_and_history/thesisw.html.

• Reid, E. (1994). Cultural Formations in Text-Based Virtual Realities.

Available: http://www.ee.mu.oz.au/papers/emr/cult-form.html

• Reese, G. (1994 - 1997). LPMud FAQ.

Available: http://www.imaginary.com/LPMud/lpmud_faq.html

• Reese, G. (1995 - 1997). LPMud Timeline.

Available: http://www.imaginary.com/LPMud/timeline.html

• Smith, J.D. (1993 - 1997). The MUD FAQ.

Available: http://www.cs.okstate.edu/~jds/mudfaq-p1.html

• Various authors (1990). Early MUD History.

Available: http://www.ludd.luth.se/mud/aber/mud-history.html

19
 Much of the information in this paper was drawn from personal commu-
nication with the following: Richard Bartle, Alan Cox, George Reese, Dan
Koepke, Chris Lawrence, Tim Hollebeek, Jennifer Smith, Andrew Cowan,
Michael Lawrie, Alec Muffett, Christer Holgersson, Jim Aspnes, Alan Schwartz,
Alex Fletcher, Neil Robertson, Anna Eklund, Brandon Gillespie, Dave Austin,
Orjan Stromberg, Brooke Paul, Ed Carroll, Erwin Andreasen and Kane Dud-
geon. Copies of these communications may be obtained from the author
subject to the consent of the correspondent.
The Mud Tree is available at
http://camelot.cyburbia.net.au/~martin/cgi-bin/mud_tree.cgi

20