[MUD-Dev] Re: Introductions and descriptions

[Adam Wiggins]

[Derrick Jones:]
> On Wed, 26 Nov 1997, Adam Wiggins wrote:
> > Better yet, use seeded randoms.  Thus it's still a roll, it's just always
> > the same for a given object.
> > For instance, in this case, use the object id of the toadstool plus
> > the object id of the character as your seed.  You roll, from 0 to 100,
> > a 74 (maybe adding in some 'bonus' for the type of toadstool).  As long
> > as that particular character's 'shrooms skill is below 74, they won't
> > recognize the mushroom.  Once they reach 74, they always recognize
> > it.  Now, a different character might recognize it at 68, and another
> > at 77 - giving you a bit of randomness without making looking at the
> > room twenty times useful.
> > This can be used quite effectively for sneaking, hiding, any sort of
> > lore skill, picking locks, whatever that you want to be a little random
> > without being spammable (ie, typing sneak over and over until your
> > buddy tells you you're sneaking).
> 
> So, when the character first encounters the mushroom, the character checks
> to see if he can identify it.  (if skill > rand(0,100) + difficulty). The
> game then remembers the result of rand() and stores it with the character
> for each type of mushroom.  What is gained from this as apposed keeping
> track of object recognition?  Certainly not memory, as you have to
> remember the roll, which is larger than a single bit (recognized/not
> recognized) for each object.  

No, no, no!  That was my whole point above.  You don't have to store
*anything*.  They keyword above is 'seeded'.  Here's some example
code, which might make it clearer than my description.

   PObject character, mushroom;
   int roll, skill;

   seed_random((character->ObjID() << 16) | (mushroom->ObjID() & 0xffff));

   roll = random(0, 100) + difficulty;
   skill = character->Skill("shrooms");

   if (skill >= roll)
      return "a poisonous mushroom";
   else if (skill >= (roll >> 1))
      return "a dubious-looking mushroom";
   
   return "a tasty-looking mushroom";


Anyhow that's just off the top of my head, but we had something like
this on a mud I worked on.  You don't *store* anything - you're taking
advantage of the pseudo-random routines being completely predictable as
long as the seed is identical.

We also had an inline which generated a random value based on the
x, y, z position of the character, their object id, and an extra
paramater.  This was used for all sorts of stealth attempts, ie:

   sneak_roll = seeded_random(character, SNEAK_CONSTANT);
   hide_roll = seeded_random(character, HIDE_CONSTANT);

> Or if you simply determine the rand() call from PC and object stats
> (idnums) then you've picked which objects the player can and cannot
> identify from the point of creation.  Then the characters true probability
> of success for a given event is predetermined to be either 1 or 0.  Then
> you'll have PC's saying  "Sorry guys, I can't sneak in this room...meet me
> two rooms west...I always sneak there.".

If you do it correctly, it works like this:
"Hrm, I tried to sneak into the dragon's lair once before - I got nailed,
hard.  My skill has gone up since then though...we'll see."
The idea is to make it slightly random without making it silly (a
master thief has a chance of failing to sneak through a room he always
sneaks through..).  Since we also affect the sneak rolls by the amount
of concealment in the room, the size of the person sneaking, the size
of the observer, the amount of light in the room, and a few other
factors, it's rarely a very fixed value.  It, however, a value that
players can hope to make an estimated guess about.  "Sure, I can sneak
past that minotaur - they are a big and stupid, and I can sneak through
that room pretty well."
Of course - this is another thing I forgot to mention about the
stealth skills - whether you get 'seen' or not is not a boolean value.
Some characters may see you sneaking (if they were paying special
attention to you, if they are highly perceptive, if they are good at
stealth themselves, if they are your size of smaller) and others may
completely miss it (they're in the middle of combat, they are twice your
size, they have poor vision in low-light conditions, they have low
perception and stealth abilities, etc).  This is especially fun for
pick-pocketing - one character does not notice themselves being
pick-pocketed, but a character nearby does.  That character can choose
to warn the victim of the crime, or can just keep it to themselves.
Also, none of these skills have boolean outcomes.  For instance, while
stealing (which is best done when combined with some other type of
physical contact, such as a big hug or a slap on the back), you can
try to go for the object, but then decide its too risky (they saw you
moving that way) and stop at the last moment; you can go for the object
but they notice and you fail; you can go for the object and get it, but
they notice; or you can go for the object and they don't notice at all.
The messages for the in-between values of success usually look like
"You notice Bubba eyeing your dagger" or "Bubba seems to run his hand
across your dagger hilt, but jerks back as he notices you watching."
Of course - and here's the best part - characters with a high paranoia
(via their player settings, or better yet, through drugs their character
has been taking) they may get stray "Bob seems to be eyeing your dagger"
messages when Bob didn't do anything.  Zany fun ensues.

> I don't like 'skill spamming' either, but simply giving characters a 0% or
> 100% success rate can't be the answer.  Perhaps not letting characters

I don't like skill spamming, because I think any game which benefits
me as the player by doing simple actions over and over again with no
variation is boring and poorly designed.  So any game I design I'm
quite careful to avoid this sort of thing.  I'd much rather make
it a very simple boolean value than an unpredictable value which you
can 'figure out' by running in and out of the room or typing look twenty
times.
If the random stuff I mentioned above is still not random enough for
you, try tossing in the mud date (day of the year, that is).  That will
make it change pretty often, but rarely while the character is in the
room.

> re-attempt a failure for a given amount of time.  For example, if Boffo
> fails to identify the mushroom, add the mushroom identification to a list
> of recent failed skill attempts, and each time Boffo attempts a skill,
> loop through this list to see if the skill has been failed recently.  If
> the failure is listed, simply assign a 0% chance of success.

Yes, this is a reasonable option.  At the time I started working on the
mud above we were running on a 486/33 with 4 megs of ram, so anything
which could help me avoid large lists of invisible data was considered
a serious boon.  I just liked the way that the pseudo-randoms worked
so well that I started using them everywhere, even long after ram was
no longer a concern.  For one thing - as a player I hate making 'stupid'
failures.  Ie, I've picked a given lock a hundred times in the career
of my character, but I just happened to fail this one time, so now I
have to sit around and wait for three mud hours for the skill failure to
wear off, or worse, go running around attempting to use other skills for
a while to purge the failure.  This seems sort of like me sitting down
to write a program and 'failing' to write a working for() loop.  If I
went, "Oh great, I might as well go home now, because I'm not going to
be able to accomplish that particular for loop for the rest of the day"
I'd be pretty annoyed.  Skills in a game are no different.
So I'd sy if you were going to use the method above (storing recent
values) you'd need to a) store the ROLL, not the failure and b) make
difficulty take a big part in the roll and randomness less of a part.
This way master lockpickers have a very small (preferably non-existant)
of picking a simple lock.

> So if Boffo walks back and forth passing the mushroom repeatedly, then she
> won't 'suddenly' recognize the item.  If she passes another a week later,
> however, she has a normal chance of identifying it (looking at mushroom
> with a clear mind/different lighting/whatever).  The problem occurs when a
> character does recognize the mushroom.  Should we just rely on the player
> to remember that the mushroom they saw in the forest is poisonous?  Or is
> this a place where I should 'bite the bullet' when it comes to memory and
> keep a table of recognized items?  I like to think(from personal
> experience as a player) that the player can remember that the 'strange
> mushroom growing on the forest floor' is really the 'deadly viper
> toadstool' if they are showed both strings at some point...

Nods, that's a problem.  I like the pseudo-random method because it
solves two problems at once - you _always_ remember something once
identified (given the same conditions - you might fail in low light,
or if your skill decays), and it takes 0 bytes of storage.