[MUD-Dev] fwd [MUD-DEV] Re: Room descriptions, was Re: Roleplaying
alexb at internetcds.com
Sun Apr 26 00:27:58 New Zealand Standard Time 1998
FORWARDED From rec.games.mud.admin
From: Richard Woolcock <KaVir at dial.pipex.comNOSPAM>
Date: Saturday, April 25, 1998 3:23 PM
Subject: Re: Room descriptions, was Re: Roleplaying
>Lisa Bjerre wrote:
>> In article <6hqa7h$lmt at corn.cso.niu.edu>,
>> morphis at niuhep.physics.niu.edu wrote:
>> > So yes, the default should be general impressions, the babble, the
>> > of smells, the jostling, the rows of stalls ...
>> > Most specifics are of no interest to you, the challenge (we are
>> > in a challenge aren't we?) is to figure out what is of interest. The
>> > challenge to the writers is to make that possible and to emulate real
>> > so that most of the time when some heavily armed bozo starts walking
>> > the square toward you you notice it. (unless you are seriously
>> > in haggling down the price of breakfast...)
>> Can you clarify how you see this done on a MUD? Since the part of the
>> discussion I entered was in short wether to write in a roomdesc "The
>> crowded" or to put in all the mobs that would make the room crowded, I
>> understand from this post what would be your view on this.
>Well there are many ways to do it. Here are three:
>1) Generate a single mob called 'a crowd of citizens', that have a flag
> making them impossible to attack. The description of the crowd can be
> literally what you would see when looking into the crowd. This is the
> easiest way, and it sucks.
>2) Write a form of the 'combine' code to work for people with a 'citizen'
> similar to that used for objects in Merc. Depending how many people
> in the room, you should see "a couple of citizens stand here", "a small
> of people stand here"...etc..."a huge crowd of people jostle you
> In the 'look' code, the parameter 'crowd' could list every single
> non-combine format. This is probably the best way out of the three I
> suggested, its easy to implement, but could get spammy with lots of
>3) Write a form of mob-joining code, similar to the object-joining used in
> The result would be a single mob, called "a crowd" or whatever, which
> spit out individuals as needed (ie if you attack the crowd, one of the
> in it would get split off from the crowd mob for you to fight). This
> most efficient of the ways I have described, but will be difficult to
> working properly (primarily making the parts of the crowd still act
>The crowd should exclude 'special' people (such as that huge giant walking
>you with a big axe). My favourite way would probably be 2, as it would
>viewer to determine which people were insignificant.
Had similar thoughts about player and player/npc adventuring parties. Our
system creates a party object when the leader (a player with suitable
leadership and other skills) announces the formation of group. This party
is for all intents and purposes another player, (it is added to the
character database). This "character" had certain default characteristics
which make it interesting. It derives it stats and some skills from the
characters who join the party. It inherits excess cargo capacity from the
characters as well as other things. This party is moved through the world
by the leader. The leader can issue a few party commands as well as have
full control over his own character. Players in the party have full control
over their character but a using a movement command will automatically
remove them from the party (after a warning message is overridden).
Messages which target the "Party" character are shown to all members of the
Because of the shared strength and pooling of skills this "meta character"
is quite useful compared to the powers of its members. The party can
portage a small boat, haul logs for building a stockade and other feats
impossible for even the most capable individual. Of course, each player
controls his on character in combat, takes damage, changs weapons, etc.
I'm sure this has been done before, but here is the new (?) wrinkle: What
if a given leader's party character was not deleted when the leader
disbanded the party? What if the party "character" continued its existance.
The party could gain experience, fame, auras and other characteristics.
While the the meta character would not actually perform any actions, it
would provide bonuses for anyone in it. The RP justification would be the
leader's ability to coordinate the team around him (or her) to get the job
done. When you fight along side Cyrano, you are a better swordman. When you
slink with the grey mouser, you are a better slinker, and so on. It also
represents the parties ability to improve the plans of even a skilled
The party character would be represented by a standard, sash, pendant or
some other object. It would only have value to and could only be wielded by
the leader character. When you viewed the party you would see a description
written by the leader (or generated by the server if the leader declines to
enter the text). It might say: You see a party of hearty adventurers led by
a powerful elf carrying a green standard with a red diagonal slash. Click
on the party and you are presented with a short display of the members
which can in turn be drilled down to detailed view of each member.
Now, if your dealing with the green-red group in the past had led to
problems, it might be time to run!
As the party (or members of the party) performed actions, the same
mechanism which improves individual skills would work (at a reduced level)
on the party stats. Take the ambush skill. Since the ambush is assumed to
being organized by the person in the group with the highest ambush skill,
that skill is used to calculate the success. A successful ambush has the
possibility of increasing the lead ambusher's skill as well as the parties
skill. All party skills start at 0 and are used as adds to party-based
attempts. So a party with an ambush skill of 7 would simply add 7 to the
score of the character leading the ambush. Of course, it is also possible
that characters in the party without the ambush skill could gain an initial
value in this skill if they participate in enough of them. But that is a
subject for another post.
I have roughed out some code I will add to my server in the second round of
improvements unless some wiser head persuades me as to the goofiness of
MUD-Dev: Advancing an unrealised future.
More information about the MUD-Dev