[MUD-Dev] Re: skill system

J C Lawrence claw at under.engr.sgi.com
Tue Jun 9 18:36:11 New Zealand Standard Time 1998


On Thu, 4 Jun 1998 01:18:32 -0700 
John Bertoglio<alexb at internetcds.com> wrote:

> From: J C Lawrence <claw at under.engr.sgi.com> 

>> On Thu, 28 May 1998 08:11:12 -0400 Andrew C M
>> McClintock<andrewm at tiger.hsc.edu> wrote:

>> The following really isn't in response to your post directly, just
>> me maundering about the area and noting things I stumble across:

I seem to be doing this a lot lately.

>> My general view of game features is that they must do one of three
>> things:
>> 
>> 1) Provide a game-world goal for players to achieve.
>> 
>> 2) Provide a game-world problem for players to solve.
>> 
>> 3) Solve a game-world problem for players.
>> 
>> This is based on the definition of a game as being comprised of
>> goals, barriers, and freedoms.

> Before I respond to the post, I think it is necessary to narrow the
> definition of skills and examine the other elements at work
> here. Much of what goes into a world building system is designed to
> answer one simple question: "If I try to do this will I be
> sucessful?". 

Agreed.  This was one of the brunts of my text.  It actually is a
curious form of interface transparency, and utterly vital.  Users
must, at some level, be able to predict the likely effects and results
of their actions.

Too much prediction and you have no game (excess freedom, not enough
barriers).  Too little prediction, and you have no game (excessive
barriers, few freedoms).

> Specific skills are just a part of this equation. I
> would suggest that there are several elements which affect a
> character's ability to accomplish goals in a game world. These are
> often found in paper RPG systems.

Most of what you write following this I have no problem with, or much
comment on.  It is (attributes/talents/skills) however one particular
model among a great many possibilities.  For instance my model is
moderately different: skills/probability/attributes, with my concept
of probability fields only partially mapping to your concept of
talents (FWIW I have no concept or model equivalent to talents,
and instead debase the entire area into what you call attributes).
Curiously enough however my probability fields seem reasonably close
to what you seem to be doing with "quirks and flaws", except that I go 
positive and negative.

> Skills: Skills represent a more formal approach to problem
> solving. I do not have a skill in the C programming language. I have
> the attributes required (I think), I have the talent (I can program
> in other languages and learn new things quickly), I even have
> related skills...but I really couldn't (at this moment) compile a 20
> line program with any chance it would run. No skill. Leave me alone
> in a room with a book and a compiler, I will develop some ability
> with C. I am still not a C programmer. If given the task: "Write a
> program for this embedded controller in C.", I will probably fail at
> this point. If the task was "Write a program which will print 'Hello
> World' to the console", I could probably succeed. Of course, I might
> have been able to guess my way to success as well without any study
> given the ease of the task. Given enough study and practical
> application, I could at some point raise my head up high and say I
> am a C programmer. A some point (in game terms), my skill level
> could reach a point where virtually any task was possible. However,
> doing that would cause my growth in other areas to stop and would
> require resources (cases of Diet Coke).  That is why many people
> with a 456 level C programming skill have a .4 skill level in
> general social behavior. Perhaps leveling off at about 87 would have
> been a better idea.

You appear to be assuming a flat (or at least linear) skill model, as
vs a tree or a web.  Have you read Legend's skill tree document?

Think drops of ink: skills bleed over into other skills whicha re in
turn variations of and reflections of other skills.  Little exists in
isolation.

>> Skill webs primarily provide problems for players, especially as
>> contrssted to their prior simplistic model of levels where skills
>> came automatically with level progress.
>> 
>> The primary problem is in gaining the necessary skills, a possible
>> secondary problem is in maintaining the required skill sets for a
>> particular play style.  A presumably unintentional secondary
>> problem is in determining what skills sets are required for a
>> particular problem or play style.

> The creation of player archtypes which can be controlled by new and
> old players will give enough insight into the process. The skill set
> possesed by the npc character is exposed to its controler. Note that
> the specific numbers for success are not exposed. You take a skilled
> fencer into battle.  You discover this guy kick butt with multiple,
> lightly armored opponents.  You examine his STR and DEX, see he has
> a talent in Combat Arts. You notice he has a minor talent in
> Acrobatics and Athletics. You see basic combat skills, light armor
> wearing and a mastery of the foil and eppe...etc. Now, you know from
> running this guy that he is a good fighter. You don't know how well
> he would do trying to brew a vat of beer, since you don't see any
> grounding in specific skills or talents. If you try, you will
> probably fail.

Interesting idea, but one which requires exposing both the fact of,
and the structure of the skill system.  I'm rather well convinced that
that is a Bad Idea for the reasons I dicussed later.

>> This last point seems the nastiest, and comes in two flavours:
>> 
>> 1) Should the fact of, or the structure of the skill web be exposed
>> to players?

> If the nature of the skill web is stored in a mathmatical matrix in
> the server, it will become common knowledge whether directly exposed
> or not.  

True.  However we are all well familiar with the spread of myths and
contorted understandings on MUDs.  Players come up with the most
curious concepts for how things work or accomplished internally
(something that should be encouraged?).

> There are all kinds of cool things you can do to mask it,
> however. Example: Everybody "knows" that the monastary on the
> mountain will take one character at a time to train as a Quack-Foo
> fighter (a partically potent form of martial arts). Everybody
> "knows" the character *must* have a grounding in the basic Foo
> fighting skill (which is rare but still easier to come by). What
> nobody "knows" except the server is that once in a while a person
> fitting the right attribute/talent profile will be invited to
> study. This might be controled by the phases of the moon, the
> calendar of feast days, a lack of a current student or just dumb
> luck.

Precisely.

>> 2) If it is exposed, how do players determine what skills are
>> required?

> Again, the word will get out. Some things are obvious. If the
> command [SEARCH FOR WATER] is understood, players will try it. If
> the skill of Water Witching is learnable, one would assume this
> would make ones chances of finding a suitable well higher.

You are assuming that a player has an ability to train in a stated
skill or skill area.  I'm not.  I map skill improvements directly to
use, observation, and education.  There is no equivalent of a TRAIN
command, or a LEARN SKILL command.  Education is by side-effect, and
is opaque to the users.  If they read a book and see text on their
screen describing, say, water dowsing, I bump up with water dowsing
skills and possibly their water probability fields,  Similarly if they 
go about dowsing, or watch others going about dowsing.  I have no
concept for "tell my character to go learn about XXX".

>> Making the answers to #A vague (large granularity) dones't solve
>> the problem, it mrely makes the answers unreliable and largely
>> useless.

> Make them accurate but only within the players ability to
> perceive. This mean that, in general, by the time a fighter can
> accurately assess his opponents, he won't need to in most
> cases. Opponent identification is an action. It is governed by
> attributes, talents and specific skills. An ace swordman might
> notice a potential opponent had the moves of an expert swordsman (I
> don't know how, ask a swordsman) so would be reported an estimate of
> the sword skill. Most people would have a reasonable estimate of a
> persons strength, but would miss the knuckle scarring of an expert
> brawler...etc.

I statistics reports relatively, but for yourself (ie your character), 
and for the other characters you query.  Loosely, any statistic is
relative to a weighted average of all the other instances of that
statistic you have met in the recent past, with a heavier weight given 
to exceptional values in the more distant past.  The cannonical joke
of which is:

  > stats
  Strength: 150
  > l
  Bubba picks up a huge boulder with one hand and crushes it to 
  sand on his head.
  > stats
  Strength: 25
  > l
  A leaf flutters off the tree above and smashes Boffo to the ground.
  Boffo is stuck under the leaf and can't move.
  > stats
  Strength: 65

Nothing changed except for his perception of strength.

The attempt is to model a form of self-image as weighted against
perception.  Most delightfully stat reports react to illusions as if
they were real.  The leaf above may well have been illusory, or Boffo
may well have been play-acting to purposefully delude your
perceptions. 

>> q) What are my chances of being able to accomplish XXX?

> You guess or ask. As before, by the time the answer the world gives
> you is accurate, you will already know the answer because of
> experience.

BTW:  This was SHADE's approach.  As you gained levels, various
actions succeeded more often.  All actions were possible by all levels 
however (they added newbie exclusions later).  Example:

  All players could SUMMON other players, however the probability of
your SUMMON command succeeding was a function of your level.  A newbie 
character might hit success one time in 30.  A higher level might
succeed at 70% of his summons.

That was the only exposure of the level gains (other than increased HP
and strength).  

>> IV) What are the impacts on my game play and game style for
>> maintaining those skills at those levels (eg spend 90% of time
>> maintaing skill sets for 10% "play" time)?

> Skill mainntence should not be an major issue. Skill improvement
> should be.  Finding ways (and places and teachers and situations )
> to improve skills should be important.

This of course assumes that there are always skills that can be
improved in a character (with presumably minimal loss or effect in
other skills), and that the fact of other available skills, or even
what skills the character does or does not have is exposed.

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...




More information about the MUD-Dev mailing list