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

[Travis Casey]

Brian Price <blprice at bedford.net> wrote:
>It is amazing to me how untactfully I can manage to state ideas and
>opinions at times.  Hopefully this thread can generate some useful
>ideas in spite of my poor choice of words.
>
>> From:          "Travis Casey" <efindel at polaris.net>
>> Brian Price <blprice at bedford.net> wrote:

><snip example of my lack of tact>
>>
>> As someone who has often championed such systems, and who has helped
>> to implement several of them, I have to take exception to this
>> 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.
>
>To a point I agree with you, however... in general basic training of
>some sort is required to gain an initial level of competency in a
>given skill.   After some time spent actually using the skills, one
>may profit from advanced training in the skill.  Likewise after a
>period of using the skill at the more advanced level, one might be
>able to recieve 'masters' level training, allowing one to progress
>eventually to mastery of the skill.

Basic training in skills is usually assumed in a guild or class based
system.  In pure skill systems, IMHO training should be available, and
should be quite valuable at low skill levels.  As skill levels go up,
however, characters should have a harder time finding trainers who can
still help them, and the price for training (not necessarily a monetary
price) should go up.

For some skills, getting some basic training is a true necessity, since
failure can carry harsh consequences.  No one in their right mind would
want to learn the basics of defusing bombs by trial and error with live
bombs, for example.  :-)

>A poorly trained cook will _not_ get better at cooking by doing it
>(my gf is a prime example here), there must be in addition to
>practice, a desire and a conscious effort to advance in the art.

I'd say that these are also assumed for player characters.  This might
not be a valid assumption for all characters, but I think it should hold
often enough that we can ignore exceptions.

>While I suppose in some exceptional case a chef might go from
>flipping burgers in a fast food joint to becoming a world-renowned
>chef by sheer practice, this would not be the normal case by any
>means.  Of course, we all know that training alone does not suffice
>either, I'd bet we all know of individuals who have completed some
>course of training, barely passing, and never achieved any degree of
>success in the trained skill.  (Such individuals do tend to become
>managers however :) j/k).

Well, one question is in how you divide up skills.  For example, one
could simply have a "cooking" skill, or you could divide it up into
"short-order cook", "baking", "barbecueing", "haute cuisine", etc.  Thus,
our hypothetical burger-flipper might become a very good short-order cook,
but will never become a world-renowned chef, since that would require a
high skill in haute cuisine.  Of course, few muds will probably want to
divide cooking into this many skills -- but many muds might want to divide
up combat skills into, say, "short slashing sword", "short thrusting sword",
"medium slashing sword", etc.

>> 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
>
>Actually the implementation on SWmud (for reasons you detail below)
>is one of the better implementations of that general idea that I've
>seen.  My main exposure to skill systems has been from Diku/Merc/Rom.

Thanks.  :-)

>> 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!
>
>Yep, couldn't agree more.  However I'm in favor of light-wieght
>solutions to these types of problems.

IMHO, this *is* a light-weight solution... it would require a bit of coding,
but once it's been done once, it should be useable for any skill which has
this quality.

[cuts made]

>>     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.
>
>While a very interesting and seemingly (at first glance anyways) a
>realistic solution, implementing this in a mud would (I think) be a
>rather involved task.. ie. a heavyweight solution.

I don't think it would be very involved... however, it would require a good
deal of permanent storage, if characters have very long lives.  I wasn't
thinking of this as an actual suggestion, though, just mentioning it as an
interesting and related note.

>In many cases, in order to 'play the game' a certain level of
>proficiency in some skills is pretty much required.  All skill
>systems I have seen implemented to date (granted a narrow subset)
>have all had the fatal flaw of being imbedded in a game system that
>rewarded the 'powergamer'.   Every player I have observed on such
>muds (unless just plain clueless newbies that never stuck with the
>game) all engaged in spamming of one sort or another to increase
>skill levels to a certain point.  I have adopted a playing style on
>such muds which incorporates skill improvement efforts into leveling
>efforts and even manage to solve a few quests/explore a bit in the
>process, still in many cases, I'm reduced to useless spamming to
>increase skills to a competitive level.

I agree.  Implementing some of the ideas I discussed to make blindly
reusing skills have low returns should go a long way towards solving
this problem.

>Having gone this far, even though it is somewhat off topic, I'd be
>remiss if I did not present an alternative, lightwieght, solution.

Well, IMHO, the solutions I've proposed aren't truly "heavyweight."
I don't mind spending a large amount of time thinking about and
implementing a solution to a problem, as long as it's something that
will only need to be done once.  I think the biggest problem we had on
SWmud was that there wasn't a single system for advancing skills -- it
was pretty much left up to the writers of the individual skills when they
should advance and how much they should rise each time the skill was
advanced.  Thus, fixing problems required tweaking individual skills --
and didn't help any other skills which had the same problem.

A single system for advancing skills, with a few options for different
"types" of skills, would allow easier fixes to related groups of skills,
and would reduce the chance that an inexperienced skill designer could mess
up.

As usual, the most important thing is playtesting; on SW, our skill system
was tacked on late in our original playtesting stage, and many problems
weren't noted until after the mud was open.  Individual problems have been
tweaked since then, but no one's had the ambition to do a basic redesign
of the skill system.

A sudden thought for skill systems -- something that might be useful to keep
is a running record of how often different skills are used -- for example,
you might want to keep the number of times/day that each skill is used.
This
information could then be used to adjust advancement rates.  This could even
be done automatically by the skill code, although you'd probably want to set
limits on how much and/or how fast the advancement rate can be adjusted.
This
would help prevent scenarios where a skill is given a high rate of
advancement
per use because it's thought that it won't be used much, and then turns out
to be used more than was expected.

A mildly sadistic system might be to do these adjustments on a character-by-
character basis -- thus, those who try to advance faster by "spamming"
skills
would have their advancement per use decreased to where they advance no
faster,
or maybe even slower, than they would if they only used the skill when it's
truly needed!

>First, the premise I'm operating under is:
>   A.  No levels
>   B.  No classes per se (may use careers which give bonuses or
>        penalties to certain skills).
>   C.  The object of the game is to develop one's character and
>        over a period of time gain power and influence thru play.
>   D.  The gaining of and training in a skill implies that the
>        character percieves a need for, and will use, the skill.
>
>The lightweight solution is then:
>   A.  Each level of skill mastery requires training.
>   B.  Training requires an expenditure of experience points,
>         game play time, and money.
>   C.  Higher levels of training cost ever increasing amounts of B.
>   D.  Training requires an instructor, an instructor must be
>         located in order to train.  (instructor could be an object
>         in some cases though this requires additional considerations)
>   E.  The more rare a skill, and the higher the level of training
>         offered by the instructor, the harder it is to find and
>         costlier it is to reach said instructor.
>
>There are quite a number of variations on the above theme that I will
>likely implement but that is the general 'look and feel' of the
>system I propose as a lightweight solution.  It is modeled to a
>degree upon a modified paper Traveller rpg system I've had a number
>of years experience with.  Such a system has a degree of realism
>built in, is easy and low cost to implement, and generates a number
>of game-play situations similar to quests.

It does, however, require continuing implementation -- each time a new
skill is added, trainers have to be added for it.  Further, the "harder
to find" part for finding high-level instructors may be hard to implement,
and gives more incentive for players to "cheat" by sharing locations of
instructors.
--
      |\      _,,,---,,_        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