Evolution of The Mud Tree

Greg Munt greg at uni-corn.demon.co.uk
Wed Aug 13 19:54:42 New Zealand Standard Time 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...

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