[MUD-Dev] Re: Mud websites
Travis S. Casey
efindel at io.com
Wed Jun 17 07:49:47 New Zealand Standard Time 1998
On Sunday, 14 June 98, Matt wrote:
> On Tue, 9 Jun 1998, Travis S. Casey wrote:
>> On Tue, 9 Jun 1998, Greg Munt wrote:
>> > How important are they? How relevant are they to telnet-only games?
>> > (Particularly to stock muds, where all or most of its features are known by
>> > almost all of its players.)
>> Never assume that. Almost everyone I know who muds started on a stock or
>> semi-stock mud (since they're so dang common), and, of course, they didn't
>> know much about the mud to start with.
> I think what Greg means is more 'muds that begin and end stock' - where
> they grab stock code, put it online, put up a webpage, and purport to have
> 'massively modified' code (changing those entry screens is /hard/ work,
> remember). A lot of games start out stock and then evolve, at least enough
> to be vaguely interesting, too.
That's what I understood him to mean by "stock", which is why I
qualified it with "or semi-stock". By semi-stock, I mean muds which
never vary far from the stock base they came from -- e.g., only adding
new areas or replacing the stock areas instead of actually changing
the way the mud works, or only making superficial modifications such
as adding a few new races and classes.
Such muds are close enough to stock that someone familiar with the
stock base they arose from wouldn't need most of the help -- but a new
player will still need it.
>> I've found that muds are like a lot of computer systems -- users beliefs
>> about them are a mishmash of truth, things remembered from similar systems
>> that aren't quite true on this one, rumors, and superstitions. Players
>> usually lear the practial end of the mud fairly well, but they're often
>> way off base about how things work on a deeper level, which can cause
>> misunderstandings between players and admins.
> Interesting way of putting it, I like the notion, and it's pretty true,
> too. Rumours certainly circulate amoung the 'lower levels' of a
> development team - I've had creators/builders ask me how to operate <x>
> feature, when the only discussion of <x> was a recent administrative
> decision to add it eventually, and so forth. This doesn't happen too often
> - - after a couple of months I decided that everyone should just get a say
> in all design issues, and threw it to a mailing list made public to the
> staff, with the clear statement that I retain a casting vote.
Yep... I've seen the same phenomenon on SWmud, and we came up with the
same solution -- discussing design issues where all the
creators/builders could see what was going on, instead of where only
the higher-ups could see it.
I've also seen it work in another way -- SWmud was originally based on
the Nightmare mudlib, and many of the early changes and additions that
we made were poorly documented (indeed, much of the base mudlib was
poorly documented). Creators usually learned how to use features by
copying the code of others who had used them... who themselves had
often copied it from examples. Thus, people used features that they
only dimly understood.
Compounding it all is the often-seen tendency not to want to admit not
knowing something... or to know something, but to not want to take the
time to properly explain it (which itself is the reason behind poor
documentation!) Further, much of the code people copied from was old,
and used interfaces to objects which had been deprecated, or didn't
take advantage of new features which would have greatly simplified the
In my last couple of active years at SWmud, I put myself in charge of
documenting the new and changed features of our code, along with those
that had been poorly documented in the original. Thus, I encountered
all these problems, and many more besides.
I think my strangest experience was coming across someone else's
explanation of code that I'd originally written. I'd hacked together
an elevator for an area I was doing, which I'd given someone else
permission to copy, and helped that person modify it. That person's
area was more popular than mine, and that coder went off the active
list... so other people, not knowing about my elevator, copied the old
code to use in their areas. While this was going on, I'd improved my
original elevator a couple of times, working out simpler logic and
modularizing it better so I could use it in other places later.
Later, I came across someone explaining my old elevator hack on the
wizard's channel... having gotten a third- or fourth-generation copy
of it from somewhere, and been asked by another person to explain how
to use it. It was... entertaining, to say the least. That led to my
famous "how to build elevators" post, which launched my career of
documenting the mud.
>> Well, it's not a mud, but feel free to take a look at the website I'm
>> starting for my new PBEM game (it's not open, so please don't ask to
>> join... I'll just have to say no):
> PBeM games have /a lot/ in similar with muds in many ways, just they have
> a lot more direction, and (in my opinion) greatly reduced (not restricted)
> interactivity. They also seem to attract the same sorts of people. Any
> thoughts on why?
Sure... to toss off a couple of random ideas:
- they both attract people who like role-playing games (at least, in
the loose sense of the term, if not in the narrow sense)
- both are restricted to people who have Internet access, and are
more likely to be engaged in by Internet "old-timers" (i.e., those
who came along before the WWW). This, in turn, means that they're
more likely to come from a higher income group, to have been to/be
in college, etc. Also, technical professionals (especially
computer professionals) are over-represented.
- they both tend to attract people who are interested in reading
fantasy and science-fiction. Heck, they both tend to attract people
who are interested in *reading*, which is becoming increasingly
|\ _,,,---,,_ Travis S. Casey <efindel at io.com>
ZZzz /,`.-'`' -. ;-;;,_ No one agrees with me. Not even me.
|,4- ) )-,_..;\ ( `'-'
More information about the MUD-Dev