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

[Travis Casey]

Brian Price <blprice at bedford.net> wrote:

>I had a rather long and involved response to this but I'll sum it up
>simply;  in reality very little skill improvement occurs during the
>normal exercise of a skill.  Rapid improvement comes about through
>training.  A fully realistic model would undertake to merge both
>cases.  However, given the long time periods involved for gradual
>improvement through normal exercise of a skill, in the design of a
>playable and implementable game, I'd much prefer to sidestep the
>gradual improvement altogether.

It should be noted, though, that most muds don't seek to imitate reality --
they seek to imitate a genre of literature, normally the swords-and-sorcery
subset of the fantasy genre.  Within this literary environment, the greatest
swordsmen, wizards, etc., aren't those who have spent their time learning
from others -- they are those who have gone out and actually *done* those
things.


>> >     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.
>
>Yes, but at what cost?  Unfortunately muds are resource limited, some
>muds have to be rebooted every few days to be playable, others
>require greater and greater payments to site providers as they
>outstrip the memory space allotted.  The more data that is tied up in
>skill tracking, the more code that is tied up in patching game flaws,
>the less that is available for objects, mobs, areas, and code that
>makes the game itself better.

I wasn't suggesting that this should actually be done on a mud, which is
why I noted it as "a wonderful concept which is related to this" and
not as a solution.

>Beyond that, I'm not at all certain that such a system is realistic.
>Just because I pick a lock once doesn't mean that the next time I try
>I don't break a pick or fail due to a case of the jitters

If you have the jitters, then circumstances have changed since the last
time you tried to pick the lock.

>A skilled programmer will learn by embarking on a course of
>self-improvement, experimentation, advanced courses, etc.  I doubt
>any learn much about the art of programming from hammering yet
>another customer spec into submission.  A calculus teacher is very
>unlikely to learn much of anything from teaching calculus past his
>probationary period, if said teacher is to advance in his knowledge
>of calculus, he or she would have to attend fewer union meetings and
>embark upon a course of study and/or experimentation.  Where chess is
>concerned, you don't learn much playing the game once you've mastered
>the basics.  You learn by analyzing past games, studying the moves of
>the masters, and experimenting with alternatives to played games at
>various points.

It should be noted as well that all of these are primarily mental pursuits,
where the line between "studying" and "doing" is much more hazy than with
physical pursuits.  IMHO, someone who is taking classes in a purely mental
activity *is* "doing" that activity -- and, if the teacher is good, will be
doing it right at the "sweet spot" for advancement which is just above
his/her current level of skill.

For physical activities, though, things are different -- reading books about
fencing will help you a little, but the only way to become a truly great
fencer
is practice.  Of course, a good "learning experience" for a physical skill
will
also include a practical component in addition to the theoretical one.

Going beyond sports, there are some things that you can only learn through
actual practice, and not the "safety" practice of a class or sport -- for
example, the English Masters of Defence, who taught swordfighting in the
1600's, noted that students who were moving into real swordfighting for the
first time were almost invariably poor at defending their heads -- because
the head was not a legal target in practice.  To overcome this, they
required
candidates for the highest ranks to fight "no rules" with live blades
against
all comers of the rank they were trying for.  Students were often killed or
maimed in these fights, and most of the Masters of the highest rank had only
one eye left.

>> 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.
>
>I'd much rather see: basic skill level - you no longer require
>training wheels.  Medium skill level - you can reliably shift gears
>and have a good idea when to be in what gear.  Advanced skill level -
>you can pace yourself to cover as much ground as possible in a given
>period of time.  Master skill level - you can specify and make use of
>custom designed bicycles which enhance your performance.

To me, starting out "reasonably competent" means simply that the character
should be able to take on tasks that the player will actually find
interesting.  I *hate* "newbie areas" in which the characters are regularly
defeated by squirrels, chipmunks, etc.  Is there a point to such areas other
than humiliating the players?  IMHO, the low levels should be more like
D&D's
low levels, with characters fighting goblins, kobolds, skeletons, and other
opponents that they can actually feel some pride in defeating.

>I'm against numeric displays of anytype except where they represent
>something that could be realistically measured on some scale within
>the game.  In most cases I believe they lead directly to power gaming
>attempts and indirectly to scripting/spamming.  If you simply must
>use a gradual improvement % based skill system, I believe that using
>incompetent for 01-10, barely competent for 11-20, etc. would give
>the necessary feedback to the player while doing much to hide any
>gains from spamming or scripting, reducing the incentive as it were.

I like using numbers -- they're easy to display and understand, where
many "descriptive" systems use adjectives where it can be hard to tell
which is better.  Also, since Arabic numerals are used in many languages,
they make it easier for players who aren't native English speakers.

However, there's no reason my the numbers displayed have to be the actual
numbers that the mud uses internally.  The players might be shown their
skills on a 0 to 10 scale, for example, even though the mud internally uses
a 0 to 100 scale.
--
      |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
     |,4-  ) )-,_..;\ (  `'-'        rec.games.design FAQ:
    '---''(_/--'  `-'\_)      http://www.io.com/~efindel/design.html