[MUD-Dev] UI Issues: Anti-scripting techniques

[Adam Wiggins]

[Travis:]
> Brian Price <blprice at bedford.net> wrote:
> comment.  :-)  The basic idea behind such a system is that a character
> should be able to get better at a skill by practicing it.  This is
> quite realistic, and, ideally, should lead to players being better
> able to define their characters and should encourage roleplaying.
> Quite simply, a warrior *should* get better at fighting by fighting,
> a thief *should* get better at stealing by stealing, and a chef *should*
> get better at cooking by cooking.
> 
> The problem, IMHO, is not in the concept, but in the implementation.
> I think Brian's talking about the implementation of this idea that he's
> seen on SWmud, so I'm going to talk specifically about that implementation
> and its problems.  Hopefully some of this will still be helpful to others
> implementing such systems -- sort of a warning about what I'd change if
> I could do it over.
> 
> 1 - There are many cases where it's possible to attempt to use a skill,
>     and thereby advance it, when the character simply shouldn't be able
>     to.  The best example of this is hiding -- on SWmud, any character who
>     can hide can try to hide at any time, and gets advancement in the
>     hiding skill for it.  A more logical implementation would only test
>     the skill, and therefore allow for advancement, when there was a chance
>     that someone would notice you -- after all, it's hard to improve a skill
>     with no feedback about whether you're doing it right!

Yup.  This is something that gives a lot of people trouble when they first
play Arctic.  They assume that by typing sneak or hide over and over, they
can raise those skills.  This is not true at all, of course.  The best way to
learn hide is to find a heavily populated area and try to hide for a long time.
The best way to learn to sneak is to sneak around town, since lots of perceptive
people are going to have a chance to notice you.  Early on you may never manage
to sneak or hide very well at all, but you still learn from your failures.
Later on it becomes damn near impossible to learn your skill by just doing it
around town, but by successfully hiding against very 'high level' mobiles,
especially aggressive ones, you can still learn.

>     In some cases, this is due to a lack of reality in other parts of the
>     game.  For example, a player who wants his/her character to get better
>     at lockpicking can simply find a lock and try to pick it over and over,
>     locking it after each success.  In many places, this would be prevented
>     if there were patrols in the area or alarms attached to the lock --
>     realistically, one shouldn't be able to simply sit in the middle of a
>     military base and work on picking a lock without having to worry about
>     being discovered.  This leads into the next point...
> 2.  One shouldn't be allowed to indefinitely repeat the exact same attempt
>     and keep learning from it.  In the example with the lock, there's only
>     so much one can learn about lockpicking from one lock -- after one or
>     two successful attempts, the character should have to move on to another
>     lock to learn more.

Arctic keeps track of what your character does.  Learning to lockpick on
Arctic involves cruising around to every town or fort in the game (there are
quite a few of both) to try your hand at picking their locks.  This is,
actually, just an extension of their combat regulartor, which keeps track of
what NPCs you kill frequently.  You learn very little from fighting against
NPCs you fight all the time, which prompts players to explore, just in the hopes
of finding someone new to fight, and thereby getting a chance to learn their
weapons skills and such.  I rather boggled at how they managed to store
all this info for their playerbase which hangs out around 15,000 when they
came up 6 years ago (given technology at the time), but now it seems much less
impressive.  At any rate, it works very well.  Once you realize how things
work, you have a lot of motivation to explore.  While playing a thief I
don't remember anything quite as gratifying as locating a new trap that I
hadn't tried to disarm before, particularly if it was a tough one.

>     The Arduin paper RPG has a wonderful concept which is related to this.
>     In it, once a character has succeeded or failed at a particular task,
>     that character doesn't need to roll for it again unless circumstances
>     change in a way that will lower or raise (respectively) his/her chance
>     of success.  For example, if a thief fails to pick a lock, he/she will
>     fail on any subsequent attempt to pick that lock until circumstances
>     change in his/her favor (e.g., the thief gets better at picking locks,
>     obtains a better set of lockpicks, or can spend significantly more time
>     trying).  In general, this only applies to long-term actions, not to
>     "instant" actions -- for example, it doesn't apply to hit rolls in
>     combat.

Very nice - player friendly as well as being a good way to limit scripting.

> 3.  Difficulty should play a role -- if something is so easy that it can
>     be done automatically, or nearly so, the character shouldn't learn
>     anything by doing it.  To give a few examples, a skilled programmer
>     won't learn anything by writing yet another implementation of a
>     bubble sort, calculus teacher isn't going to learn anything about
>     math while balancing a checkbook, and Bobby Fischer isn't going to
>     learn anything about chess by playing me.  :-)

And this is what we use.  Thus, fighting the same sorts of things over and
over should eventually cease to help you, since your skill will advance past
theirs.  Unless they learn as quickly as you...

> 4.  Lastly, characters should start out reasonably competent in their
>     skills and the players should know that.  There's much less
>     incentive for a player to raise a skill which has a 40% chance of
>     success than one that has a 1% chance of success, and the time spent
>     also seems less rewarding -- moving from 1% to 10% seems like a huge
>     difference, but 40% to 49% is less exciting.

IMO on a scale of 1 to 100, 0 to 20 should mean you suck and actually
fail most of the time, 20 through 50 should mean you're competent but not
anything special, 50 through 80 means you're really good, and 80+ means
you are a true master.  Arctic suffers from this quite a bit.  Anything
up to an 'average' rating usually means you totally blow, and can barely
do it at all.  This is annoying because it takes quite a while to get
any skill up to average, even if you know what you're doing.  I feel that
it shouldn't take long to get a skill usable (ie, being able to swim or ride
a bike) but getting from there to being a master (swiming the english channel
or riding in the tour de france) should be a serious endevour.

>     On SWmud, we made a mistake that relates to this -- we show character's
>     skill levels as a percentage of how much they can learn, as opposed to
>     a chance of success.  Several things factor into chance of success on
>     SWmud -- a base chance of success, score in a related ability, whether
>     the guild which gets the skill is your primary guild, and, lastly, a
>     learned ability with the skill.  Hence, a character with "0%" listed
>     for a skill may actually have a 40% chance of success -- and a character
>     with "100%" listed might only have an 80% chance of success.  "0%" means
>     only that the character has no learned ability with the skill, and
> "100%"
>     means only that the character has reached the maximum score in the
>     learned portion of the skill.

Yup.  We ommit the % since it's misleading in this way.  A rating of 30
is essentially average; most people think of 50 or even 75 as being average
when you rate it by percentage.

> >I believe that by carefully examining the game constructs used in a
> >mud design, one can eliminate much, if not all, of the incentive and
> >opportunity for scripting.  In my opinion, this results in a better
> >game.  After all, ask yourself this question: "Why is the player
> >scripting this process?".  In many cases the answer is exceedingly
> >obvious: "Because it is mind-numbingly boring and adds nothing to
> >gameplay."   Granted, pk/combat scripting is another issue and will
> >likely still require solutions such as presented in the first and
> >second attack discussions.
> 
> I'd submit that something can add to the *game* without adding to
> *gameplay*.
> Also, boredom doesn't seem to be a part of it, from my point of view -- I
> think it would be much more interesting to actually *play* the game instead
> of mindlessly focusing on simply raising one or two skills as fast as one
> can.  IMHO, many scripters are simply looking for an advantage -- a way to
> advance more quickly than the other players can by "playing" either faster
> or more often.

Well, speaking for myself, I have scripted many things on muds.  All of
them were things that I thought were mind-numbingly boring, but that I had
to do in order to continue my advancement.  IMO a good desing rules out the
need or desire for scripting.  If there are a given set of actions that
I need to repeat on a regular basis without any variation, it should be
automated.  If it is not, I will automate it myself.  It's that simple.
For example: if creating a healing potion means getting a flask and two herbs
from my pack, mixing the herbs and enchanting the potion, without variation -
I will eventually automate it.  (If I have to do it enough.)  If it means
analyzing the person's wound, deciding which herbs I need, going and finding
them, grinding them up just so, making a potion for internal wounds or a
salve for external, applying the concoction in different ways to the wounded
area, watching the effects on the flesh after the concoction is applied..
then it's difficult and unproductive for me to automate it, plus I won't want
to, so I won't.