[MUD-Dev] Re: Introductions and descriptions

Matt Chatterley root at mpc.dyn.ml.org
Wed Nov 19 09:08:11 CET 1997


On Tue, 18 Nov 1997, Richard Woolcock wrote:

> Matt Chatterley wrote:
> [snip]
> > > Description is currently determined by gender and age - so you might be
> > > 'a handsome elderly gentleman' or a 'pretty young teenage girl', etc.
> > > However, to get around the problem of 'silly names', each player gets a
> > > random first and surname when they connect (over 100 first names for
> > > each gender and almost 1000 surnames means duplicates are unlikely).
> > 
> > Now this, is a VERY interesting twist! Does the player get to choose a
> > 'connection' or 'account' name to log in under, and then have the 'game
> > name' assigned, or is the 'game name' synonymous(sp?) with the 'account'
> > name?
> 
> The name is purely random, and is seperate from their 'login name'.  I am
> using the login name as the person's 'Soul name', which is permanent, and
> the other name as their 'body name', which will change when they die, just
> as soon as I get my pseudo-perm-death coded (its almost finished).  When
> you die, you will keep your Soul points, which represent all exp every
> earned.  When you log back and create your new 'body', you keep a number
> of exp equal to 100% of the first 100, 90% of the second 100, etc, down
> to 10% of all exp over 900.  In addition, I am planning on putting in extra
> creation options for players who have a number of soul points over certain
> levels.  This could be very interesting for people who want to 'sell their
> soul' for power...

This is a very interesting way to tie things in, although I'm not sure I'd
choose to do this (given your *theme* however, it seems very appropriate -
will you tie in the 'special' character types to these soul points,
somehow? Or will all your players be special, rather than mortal?)

The idea of giving an acct name (chosen), and then assigning character
names is a good one to enforce certain things, but perhaps do two things:

1. Allow players an appeal to change the name if they really do have a
better idea (for instance, a culturally suitable name you did not consider
in your master list).

2. Set up probabilities of occurance for each name, rather than making it
arr[random(sizeof(arr))] or something to that effect - this way you would
have more Johns than Naseems, which is probably realistic. ;)
 
[Snip]

> > This is good too - its starting to pull the concept of 'introductions'
> > away from the very static thing that it tends to be, into something far
> > more dynamic and more involved in the game. How are you coping with 'out
> > of character' communications and such? Eg: Who lists, tells, and such?
> 
> The 'who' list and 'tells' show your login name (or 'soul name').

Makes sense to me. Presumably all other 'out of character information'
dealing commands will also relate to this, muchly like they might in a
unix environment - finger, and suchlike.
 
[Snip]

> > This is another interesting area actually, and the first point I'd keep in
> > mind, is that if you are aiming at a very rp-centric game, fully automated
> > descriptions are probably a bad idea (note: for the benefit of anyone in
> > the audience, rp-centric mainly refers to Tiny-derivs, but could
> > technically be anything. Most tiny-derivs have player-written descs, but I
> > know at least one which does not).
> > 
> > With this auto-desc in an RP environment, you take away the player's
> > freedom to embelish upon his character, and risk 'identical copies'
> > cropping up unless you do it very well. Even then, there are probably
> > going to be circumstances when the player will wish to add small details
> > to his description, which the code cannot account for without being
> > 'overridden' in some way - for instance, the colour of makeup (although
> > you could have *useable* makeup to change this of course).
> > 
> > One way around this is to give the player some control over elements of
> > the description, or the power to write a short addendum to the description
> > itself (one or two personal paragraphs).
> 
> I understand what you are saying.  I am mainly concerned over player-abuse.
> Besides, the mud is not as strictly roleplay as - for example - a MUSH.  It
> IS World of Darkness based, and thus I want to concentrate on a more 
> roleplaying theme (rather than combat), but more than anything I am trying
> to make it as automated as possible.  Think of it as more of a rpg/simulation.

Yeah. The elements of such RP games, and their necessity versus their
abusability (and ways to limit the former without ruining potential), is
something of a pet subject - one I've dealt with inside two games so far,
and am tackling in a third.

I'd classify this as something like an adventure game (highly automated
rp-capable environment?), roughly similar to what I want - something more
complex technically speaking than either h/s or rp alone, but subscribing
wholly to neither style.

There can be no doubt in your mind that if players can speficially set
something with absolutely no checks and guards, it *will be abused* at
some point or other. To what extent, and how severe this abuse will be
really does depend, and only time will tell (although you could probably
make a good guess). This leaves you with three options:

1. Remove the players control, or restrict it in enough ways to minimise
abuse, or to make it *look* is if they have full control, while you
exercise total power over *what* they control.

2. Put some form of administrator between the players self-adjustments,
and their access to the game itself (some sort of 'approval process' for
new characters).

3. Rely on players to report other players who abuse the system.

Lets face facts firstly, and say that ideally 3 would work, but this being
our world, it probably won't. 2 is quite a common approach, BUT is
probably not consistant with the sort of environment that you wish to
create, and is also something I despise doing in any environment (but
sometimes find necessary within 'hardcore rp' circles, where a misinformed
player can ruin their own enjoyment, and that of many others, and these
must be informed so that they can approach things from the right
direction).

This leaves us with option 1. Which in our case (description augmentation)
might mean that rather than having a small text buffer to fill up, the
player can select a list of words or phrases, and compose them with the
assistance of the game systems, into a description. Consider it giving
them full control over a small jigsaw puzzle - they may be in the drivers
seat, but you're the one who gives them the pieces.
 
> > In a less rp-centric (I shall refer to them hereon as 'adventure' games,
> > on the strength of my previous 'types of game' speech/es, and on the basis
> > that h/s games will probably not care much about descriptions) adventure
> > games, the player-written addendum is probably not needed, and you can
> > probably feel free to automate more, since players are not into such
> > *intense* characterisation.
> > 
> > Firstly, consider what you might modify the description based on. Some
> > possible elements are: Hair/eye/skin colours, Height, weight/mass, build
> > (we will determine this from strength/dexterity statistics in my
> > examples), overall attractiveness (charisma), clothing (outer layer only).
> 
> I do have eye/hair colour, as well as hair length and a choice of verb for
> both hair and eyes - however this is only used in the 'look at' description.
> I was considering working on some form of 'priority' to pull out features in
> order to create a short description.  I mean, you don't want to see:

I overlooked hair length. :)
 
> A tall, ugly fat man with a bushy black beard, bald head, piercing blue eyes,
> heavily tanned skin dressed in expensive clothes says 'hello'.

Right, this is simply too verbose for most players. I personally am
capable (no boast, just a fact) of reading a screen of text in a few
seconds, and retaining most of the content - many, many, many people read
FAR slower than me, something of which I have to be repeatedly reminded,
because my messages for various minor game events tend to stray on the
verbose side of things. It also gives you far too much information, unless
your character is penomenally informative.
 
> However it would be nice if it picked for example 'fat' and 'piercing blue eyes'
> (your characters most outstanding two features) and displayed:
> 
> A fat man with piercing blue eyes says 'hello'.

This is good - certainly do it this way with prioritising, so that not
everyone is "A [size] [gender] with [colour] eyes."
 
> Even my system at the moment (appearance+age) creates some interesting 
> interaction between players that I hadn't accounted for.  For example, when a
> very young character logged on, everyone started calling him 'boy' (hey, whats
> your name, boy?), whilst an ugly player got severely taunted.  The male 
> characters also paid a lot of attention when 'a stunningly gorgeous young
> woman' logged on...I think this itself could really start encouraging people
> to roleplay without them even realising it.

This is quite interesting.. perhaps some sort of psychological effect. At
any rate, it is definitely possible for the environment to have a huge
effect on rp-ability of the game. Cue interesting spiel on rp games:

Many mush-based games, which are intended as 'rp' games (in varying senses
of the word), pick themes which are wholly unsuited to rp - the very
nature of the theme, and the environment which is created around it (the
entire attitude of the game is theme-dependant, believe it or not,
although it does modulate with the people around, and so forth).

Star (W/T)rek is unsuitable for a theme, because of several things,
including the volume of its popularity (although god only knows why
rational people would wish to do this - personal bigotry against the
series henceforth laid aside). There are also a number of shaky areas in
the theme (for instance, the way by which transporter technology functions
precludes the possibility of persons having a 'metaphysical soul' in the
sense often intended), least of all areas of technology which cannot be
explained.

Also, conflict is what makes life interesting (in its many forms), and the
only *real* conflict in the Trek theme is between different races. Many of
the other challenges arise from spontaneous problems, and would have to be
very carefully pre-arranged, or handled by a stonkingly complex system.
Humans (and other friendly races) are usually very nice to each other, and
so forth, as if 'bad attitude' has almost been genetically bred out of the
species.

Babylon 5 is far more interesting (although still flawed!) because its
characters are far more 'real' and bicker amongst themselves (NB: please
noone refer to any B5 plots after mid S4, since you guys in the US
have seen a lot more of the show than I have). For instance, there is a
major and rather devastating betrayal of what might be considered the
'hero' by a 'fallen friend' (cue tragic mythologies).

Battlestar Galactica is also the theme for a game I know of, and is also
flawed.

What do these games have in common, other than being SciFi in nature?

They are also all very combatative! ST features conflicts of a violent and
rather fatal nature between various empires at times, B5 has featured
several wars, both public and concealed, and BSG was set in a refugee
context. This provides strong distractions from characterisation and
roleplay which can be quite harmful to new and old players alike.

By this notion, are there any good themes, or is something wrong with the
'non-automated' approach taken by many games? Personally I am either
minimalistic (very little code, very little built, because the game is
really just a social construct between the players), or the other extreme
(very heavy automation, and suchlike).

[Snip]

> It is still a lot better than what I have at the moment.  Don't forget to
> add wounds to the description though ;)

Forgot about that. :P

Regards,
	-Matt Chatterley
	http://user.itl.net/~neddy/index.html
"I shall never believe that God plays dice with the world." -Einstein




More information about the mud-dev-archive mailing list