Evolution of The Mud Tree
Greg Munt
greg at uni-corn.demon.co.uk
Wed Aug 13 19:54:42 CEST 1997
On Sun, 3 Aug 1997, Martin Keegan wrote:
> BTW - can someone post the "Evolution" section of my paper to the list so
> that it can be kicked around? (I'm not too brilliant at including text in
> this thing)
My RGMA post made me remember about this. Here it is...
--cut--
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 or try any other sort. [22]
Partially as a result of this, users tend to form communities which
congregate 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
deleterious 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 unpopular,[23] 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.
Bartle's tree (1990) listed approximately fifty systems. Ten of these
were actually genetic families of muds (AberMUD, TinyMUSH, TinyMOO,
UberMUD, 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 considerably more flexible than
those they have replaced.
--cut--
-------------------------------------------------------------------------------
"I want to be imp on a MU*!!! Where do I get the code for CircleMUD???"
"I have great ideas for a new mud, but if I use stock code I'll be flamed."
These are the two extremes. Can the pro-scratchers go too far?
More information about the mud-dev-archive
mailing list