[MUD-Dev] Re: darkness/visibility

Travis S. Casey efindel at io.com
Tue Jul 21 13:38:20 CEST 1998


On Tue, 21 Jul 1998, J C Lawrence wrote:
> Travis S Casey<efindel at io.com> wrote:

> > Coming from pencil-and-paper games, I'm used to having the
> > distinction exist -- indeed, when you allow a single player to run
> > multiple characters, or have the same character being used by
> > different players at different times, it becomes a *necessary*
> > distinction.  
> 
> I actively question and even deny its necessity for MUDs if the game
> is designed with the point in mind.  
> 
> I actively encourage multi-playing as well as mutli-charring.  Given
> that a single human may be controlling a single character (or more
> than one) eacho of which in turn is controlling any number of seperate
> bodies in possibly widely seperated locations, the line between the
> visible manifestations of characters and their logical definition is
> blurred to the point of non-existence.

Note, however, that I said *characters*, not *bodies*.  I've run many
paper games where a single character controlled multiple bodies, or where
multiple characters were sharing a body; thus, I fully understand how this
can work.

If one character is controlling multiple bodies, of course those bodies
can act as if they had central control.  But when two separate characters
are supposed to be controlling two separate bodies, if those bodies act as
if they had central control, then either (a) there should be an in-game
reason why those characters are able to coordinate so well, or (b) the
characters are using out-of-game channels to coordinate in a way that they
should not be able to, by the logic of the game world.

The paradigm I gave includes your idea of having characters who control
multiple bodies and who can swap them about; indeed, I've done this myself
in paper games.

> > However, I don't believe that characters should be capable of
> > complex behaviors without their players; only the most basic, most
> > needed protective reactions.
> 
> <nod>  This skirts about the issue I failed to define above:
> 
>   Does the character in the game have any existance outside of the
> human controlling him, or is it a direct robot mapping of the human?
> 
> ie to RP or not to RP?  Is the character you, even an interpreted you,
> or is it someone you are playing ala an actor?
> 
> For me my characters are me, sometimes an interpreted me, sometimes a
> very carefully presented me (mind fucks), but always in essence me.
> Everything I know and can do anywhere in the game my characters
> instantly know and can use, and there is no distinction between them
> and me.

Of course, you've said many times before that you have no interest in RP.
To drop into the lingo of rec.games.frp.advocacy for a moment, from a
gamist perspective, your way of doing things works; however, from either
an RP or a simulationist perspective, you would be breaking the rules.

There's nothing inherently wrong with a purely gamist setup, but I
personally find it unsatisfying, and I think many of the others on this
list would as well.

> > When/if we get AI programs that can parse and understand normal
> > human "speech" (using quotes here since, in this case, we're talking
> > about typed text rather than real speech), a lot of new avenues will
> > be opened up for muds.  Until then, we're forced to either ignore
> > the problems or seek for kludges to work around them.
> 
> <shrug> As initially commented, as a function of my play style I don't
> see this as a problem, but as a feature of the way such games operate.

Since I come from the paper RPG world, I see it as the biggest problem.
In a paper RPG< the gamemaster *is* the user interface for the players --
and a good GM is an incredibly good interface.  There's nothing on
computers that can remotely approach what a good GM can do for a game.

--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_) 






More information about the mud-dev-archive mailing list