[MUD-Dev] mud vs. mush membership

Matthew Mihaly diablo at best.com
Tue Jul 27 23:36:49 CEST 1999


On Tue, 27 Jul 1999, Caliban Tiresias Darklock wrote:

> 
> But "player" is a term of some dispute. If I log into some MUD and idle for
> three hours before logging off, am I a player? If I log in several
> characters, am I several players? If I log in once a month for an hour, am
> I a player? You can't rely on a WHO listing to tell you how many players a
> game has. Some MUDs have a large number of players who do virtually
> nothing. Some MUSHes have playerbases which may only consist of about 200
> people all told, but EVERY player is actively involved in the furtherance
> of the game -- defining plots, interacting with others, building businesses
> and locations, writing code. I don't think logons or player records are an
> accurate representation of the "success" of a game. 


Well, when you have thousands of _paying_ players online at once, I'd term
you an unqualified success. Presumably, in order to pay to play a mud, you
have to think it's better than anything similar you can get for free. So
having tens of thousands of paying players says quite a bit about the
success of the game. Yes, advertising certainly plays a large role in
things, but nevertheless, size=success, imho. It's not the only definition
of success, but it's certainly one of them.

> 
> In my experience, MUSH players tend to be much, much more involved in the
> actual operation of the game. Does this make them better players? I don't
> think so. (I *like* them more than I do MUD players, but they're not
> *better*.) I think the inherent competition aspect of MUDs makes it
> tempting for builders to sneak in advantages and secrets, whereas MUSHes
> tend to operate much more on what you do than on what you have. As they
> say, it is trivial for the civilised man to act like a beast, but next to
> impossible for the beast to act like a civilised man; if you're a jerk, you
> can conceal this fact indefinitely on a GoP MUD, but you won't hide very
> long at all on a more interpersonal game. 

Yes, I agree with this. Simple size makes intimate player involvement with
the actual operation of things much more difficult. 


> I've always viewed the difference between a MUD and a MUSH as the
> difference between a movie and a soap opera. After you play a MUD for a
> while, it gets old and stale, sort of like watching a movie over and over.
> But a MUSH tends to go on forever, always changing, sometimes so much that
> a week or two without logging in is almost like starting over. It doesn't
> really have much to do with the codebase, just with the focus of the game.
> MUDs are defined by areas; MUSHes are defined by players. Look at how they
> advertise: MUDs talk about classes and races. MUSHes talk about settings
> and situations.

I would agree that this is generally the case, but MUDs are NOT defined by
areas. Stock muds are, because the only way they can differeniate
themselves without a lot of effort is by making new areas (and if they
were willing to put a lot of effort in from the get-go, they'd not  have
used stock code in the first place). Stock muds are also inherently going
to focus on areas, because they are mainly just about bashing. That
doesn't mean MUDs are about bashing, or about areas. We definitely have
on-going plots, though they are generally not as all-encompassing as in a
good MUSH. A good MUSH will have better "soap opera-ness" than us, but we
also have a whole range of other things. I think that MUDs can happily mix
on-goine and encompassing story lines in with other things. Furthermore,
by focussing on player vs. player things (primarily economics and
politics), you get an inherently ever-changing environment. For instance,
one of the focuses of many of the players right now is a big debate about
the leadership of the Druids guild. Tempers are building, and factions are
rallying together, trying to disband the current leadership. There's no
reason you can't have this sort of thing in muds. Stock muds are, however,
relics of Zork-thinking. They took a one-player game, and just added more
players to it, instead of redesigning the basic focus to be multi-player.

> 
> I would venture to say that in order for a MUD to remain exciting, you
> would have to have a constant build and modify process going on. In other
> words, areas should change. Constantly. It would probably be a good idea to
> have several people whose entire job is to modify the areas based on what's
> going on in there. If a lot of low-level players are dying in the same
> general areas, chances are you need some sort of buffer. If a lot of
> high-level players are hanging around in the same general areas, chances
> are the mobs should be tougher there. MUDs rarely react to their
> playerbase; MUSHes tend to react to it all the time. If this sort of
> reactive environment is seen as a net positive, the administration should
> endeavor to provide it. 

Well, this assumes that all you do in a MUD is run around bashing
monsters.

> 
> On the down side, a MUD with fifty thousand players doesn't really make it
> easy to monitor this sort of thing. After a certain point, you just don't
> normally have effective tools available for administrative statistics; on a
> MUSH, maybe three to five people will die at most in any given day. On a
> MUD, you have thousands of deaths. There just isn't any really effective
> way to monitor what's going on in the average MUD. Perhaps it would be
> useful to have some sort of statistical tool which could keep track of new
> characters, short logons, idle deletions, character death, character level
> advancement, etc... listing who did what in what room of what area.
> Patterns would start to emerge, displaying potential problems or
> concentration areas.

Yes, that would be a nightmare. Happily (or unhappily maybe), most of us
will never have to worry about having 50,000 players.

--matt




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev




More information about the mud-dev-archive mailing list