[MUD-Dev] Re: Influential muds

[Dan Root]

> "Koster, Raph" wrote:
> 
> > Do any MUSHes actually have storytelling capabilities? What exactly IS
> > storytelling capability in a mud? Can you define a feature set?
> 
> The lack of support for powerplayers?  Perhaps the admins are less
> technically oriented, and thus do more to encourage non-powergaming?=20
> There must be a reason for why the more technically oriented mudbases
> (LP) to a large degree are oriented towards powergaming (or programming
> even). Of course, it could also be attributed to historical progress.
> 
> With very little experience with MUSHes I would then postulate the
> following feature set:

Speaking as someone who has run several MUSHes in the past, I'll take a
stab at defining a more technically oriented feature set.

For the most part the easiest way to describe a MUSH is to take an original
TinyMUD and add a user-accessable programming.

Game objects are split into 4 categories, much like TinyMUD, rooms,
players, exits, and the generic 'things'.  Each object contains a set of
fairly standard attributes (name, description, date of creation, etc) and
then a series of user defined attributes.  

There is also a fairly large set of 'trigger' attributes that the server
may call when certain actions are performed.  For example 3 attributes
related exit are 'exit', 'oexit', and 'aexit', which are used to describe
the messages that are shown when a player or object uses that exit.

Additionally, there is a moderately rich set of semantics for being able to
create automated objects which interact with their environment.  Responding
to events in a room (says and emotes), being given money, and other
conditions can all be set up to perform actions.

In a MUSH-derivative, unlike MUCKs (another branch from TinyMUD), the
programming language used to perform these actions is actually the same
language the user enters commands in, for the most part.  The language does
have the rather unfortunate side-effect of reading like bad line-noise for
anything more complicated than a direct alias.  An example from a system
that emulates 'channels', wrapped for posting's sake:

&COMMAND_CHANLIST Channel System=$@Chanlist *:@switch
[words(v(chan_%0))]=0,{@pemit %#=That doesn't appear to be a
channel.},{@switch  u(FUNC_CAN,%#)=0,{@pemit %#=Permission Denied.},{@pemit
%#=Characters on the %0
%%Channel:%r%r[sort([iter(get(parent(me)/chan_%0_list),[name(##)])])]}}

Generally all users can use the programming language to create personal
objects and rooms.  Overall, MUSHes work best in scenarios where there are
lots of unique objects that do 'nifty' things, but hold next to no support
for traditional 'mobile' monsters and equipment.  This is one of the
reasons they get used for heavy RP-based servers.

There isn't much 'hardcode' that enforces storytelling, though there are a
fair number of available softcode packages that make very aspects of doing
online role-playing easier.

And now to address Ola's points about the more social aspects of MUD vs
MUSH.

> - branding: MUSH has been established as a storytelling "trademark",
>             and they invest a lot of energy into distinguishing it
>             from the MUD label in their marketing and propaganda
>             efforts. ("it is not a MUD it is a MUSH")

Very true.  For reasons I never really understood, most MUSHers will insist
they don't play 'MUDs'.  There's a general attitude that anyone who likes
to play more hack-n-slash oriented games is obviously a socially stunted
14-year old who would torture animals in real life, given the chance.

> - powergaming unfriendly: powergamers disrupt roleplayers ability to
>             immerse. The branding has also established MUSHEs as a
>             boring type of MUD to powergamers which further keeps
>             the powergaming factor low.

More or less true.  Since there's usually no concept of levels, 
anyone can make whatever equipment they want and there's no hardcoded
combat system, you can't powergame that way.  MUSHes have their own brand
of powergamers, different from traditional muds, who tend to do things like
force role-playing situtations through creative abuse of emotes.  Trying to
force another player's hands by declaring what their character's actions
are is common:

  Bubba emotes:
  > Bubba swings his dagger and kills Fred, who just dropped his sheild.

Another common MUSH powergaming tactic is to create objects which allow you
more ability than you should have.  Objects which transmit or record remote
(possibly in private areas) conversations, devices which allow players to
teleport to areas they shouldn't be able to, etc.


> - low tech factor: part of the branding which might appeal to
>             storytelling focused admins.

I think this falls more into the following point.  It's possible to extend
a MUSH in non-trivial ways with nothing but the programming language,
though it requires psychotropic drugs to write the code :)

> - established paradigm: a priori (upfront) expectations might be
>             more like=F8y satisfied when a "musher" tries a new MUSH
>             than when he tries a random non-MUSH. Thus they might
>             be able to circulate the users within their own brand.

This is definitely true.  In fact, even with in the social and role-playing
oriented games, there is this sort of prejudicing.  MUSHers generally won't
play MUCKs, and vice versa, even though they have an approximately similar
set of features.

	-DaR
--
/* Dan Root   -   XTEA cipher */  static unsigned D=0x9E3779B9,l=0xC6EF3720,s;
/* t=64bit text, k=128bit key */  #define m(x,y) ((x<<4^x>>5)+(x^s)+k[s>>y&3])
void enc(int*t,int*k){for(s=0;s!=+l;){t[0]+=m(t[1],0);s+=D;t[1]+=m(t[0],11);}}
void dec(int*t,int*k){for(s=-l;s==0;){t[1]-=m(t[0],11);s-=D;t[0]-=m(t[1],0);}}


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