[MUD-Dev] Re: Info about different skill systems

Nathan F Yospe yospe at hawaii.edu
Mon Jan 4 10:38:17 New Zealand Daylight Time 1999

On Sun, 3 Jan 1999, Emil Eifrem wrote:

:At 09:25 AM 1/3/99 , Nathan F Yospe wrote:
:>As the guy who coined "Skill Web" I ought to answer this one. There will
:>be more info if you cross ref my name on your search, but, for now... it
:>would be unfair to just dangle that in front of you and not add anything
:>new. So... another informational post. 

:Thanks. :) 

:I wanted to cross reference 'skill web' with your name and 'skill tree'
:with Raph Koster (or with JCL since I think the original message about
:skill trees was posted by JCL before Mr Koster joined the list) but the
:lack of boolean operators (that I could find at least) in the search engine
:stopped me. Doing it by hand feels kinda, eh, wasteful of time.

Really? ISTR booleans... did JCL yank that?

:>The primary approach is as follows: I define a set of attributes, with a


:Wow. Lots of good information, lots of for me new terminology and lots of
:lack-of-line-breaks. Ok, let's see what I can make of this.

*grin* You should see my usenet posts. I've been known to go for over 60
lines without pausing for breath or a carriage return anywhere but after
the 75th column. It's a terrible addiction...

:>The primary approach is as follows: I define a set of attributes, [snip]
:>attributes link to other attributes, and are documented quite
:>extensively. They should almost never be added. 

:What kind of attributes do you have? It seems to me like you have largely
:avoided broad attributes such as 'Constitution' and 'Dexterity,' and I get
:the image that you have quite a lot of fairly detailed attributes for your

Yes. I do have the braod attributes... they are used to compensate where
the model is inadequate, by linking attributes with no obvious definable
connections, but notable practical ones. Examples of this are attention,
which supersets (with feedback) all perceptions, focus, tolerance, basic 
patience, and skills like crafting... not because it fit the prime model 
at the begining, but because it corrected for inconsistancies in several
characters. Carelessness in one thing becomes contagious to others. :) 
But, I do have over 500 attributes defined in my prototype so far... and
that's probably going to get a lot bigger. Plus the attributes that each
skill specifies, which adds at least another 500. Each individual has to 
run on a table of attributes that does a markoff for each skill changed,
to stop any endless loop improvements or decrements to looped attributes
and skills. With the security risk, this computation *has* to be done by
the server. The result? This is my biggest bottleneck, and I need either
to speed it up or compress its memory footprint. The best so far is this
threshhold cascade scheme that keeps updates from propogating until they
hit the arbitrary significance threshhold, at which point they propagate 
for one link. Like that sloped quarters game in casinos and arcades, the
first spillover tends to set off a cascade, hence my name for it.

:You speak further down about monodirectional weighted links between
:attributes. Could you or someone else elaborate a little more on weighted
:links? Please excuse my ignorance, but I'm afraid I'm not familiar with the
:concept of weighted relationships. I know it's basic and I've seen it
:mentioned quite a few times, but it's nonetheless a blank field in my
:computer vocabulary. :(

A weighted link modifies the other end by a percentage of a modification
made to the feeding end. A bidirectional weighted link means object A is 
proportional to B so B proportional to A. A monodirectional link means A
proportional to B but B not necessarily proportional to A.

:>The character object the
:>characters all inherit from has attributes associated with it, as do the
:>components of its body. 

:Cool. So loosing an arm or a leg will make attributes that depend on that
:bodypart suffer. We have that too, but it's almost hard-coded and not as
:elegant a design.

Somehow, these sort of things seem to just fall out of abstracting basic
properties. A lot of it followed an effort to just "Think Different", as
a certain high-publicity gramatical error says.

:>Skills are defined by requirements (environmental, basic,
:>hosted) and multiple skills may cover a single task (IE, flight is quite
:>different for a Trae'laec or a *Hzzt* Swarm), with requirements adding a
:>filter on the basic list. 

:This confuses me. So the requirements are only a help for the parser -- in
:this case used as a filter to help the parser decide which skill to use?
:Where would simple combat skills such as 'parry' or 'dodge' fit? 'Hunt'?
:What would their requirements be?

Parry would have requirements... efforts to parry without them would get
treated as a typo by the client, unless there were no other obvious ways
to interpret it. Parry, however, is an action. Failing to find *any* way
to parry with current resources would cause a search for other ways that
a character might perform the action... failing that, an attempt to do a
thing you cannot will be performed... This is done both by client and by

:And *who* is coming up with these names? A random-character output program?
:Still, it's no worse than the name of Jon Leonard's mud. :)

They are names for alien races in the world that I created for my first,
Rom based, mud, and will recreate for this new server.

:>All skills attemptable by a species are listed
:>for an individual of that species, and attempts to execute a command for
:>which no listed skill exists will begin checking the primary skills list
:>for the gameworld. This might be changed in the future. I can't see much
:>point in allowing a human to attempt to, say, Fazz in a Humanx universe.

:Ok, so if it doesn't find a neat match in the requirement filtered list of
:skills, it looks in the primary list for the game world. Is your server
:generic, so it can be customizable for different types of worlds. Otherwise
:I don't quite understand the purpose of the gameworld-dependant skills list.

Yeah, it's reasonably generic, though far less than most here.

:I'm not even gonna comment on Fazz and Humanx. ;)

Alan Dean Foster's Flinx and Commonwealth novels. Human and Thranx, with
the fazz sense being a motion detection capacity of Thranx.

:>Likewise, a single skill may cover multiple tasks. As a skill can have a
:>series of derivatives with similar requirements (inheritance model) with
:>other, nonderived skills using the same attributes, skills may be honed,
:>or at least improved, by related activities. 

:Ok, so there's basically no way to grow better at skills. Using a skill
:will only improve one attribute (or more), which in turn will grant you a
:higher value in skills affected by that attribute. Interesting.

Which does make you better at that skill, ultimately.

:>Skills link to verbs, or to exitential verbs.

:What's an exitential verb?

Sitting... essentially, it is something continuously monitored, like the
current set of sensory perception checks running, etc.

:Thanks for the info so far, your system is definitely very different from
:most I've seen. I wish I could compare it with a neural net design and see
:the similarities, but my knowledge and confidence in AI programming in
:general and neural nets in particular is unfortunately shaky at best.

I've removed most of the neural nets from the server. The clientside bit
still uses two big ones...

Nathan F. Yospe - Born in the year of the tiger, riding it forever after
University of Hawaii at Manoa, Dept of Physics, second year senior (joy)
(On Call) Associate Algorithm Developer, Textron Systems Corp, Maui Ops.
yospe#hawaii.edu http://www2.hawaii.edu/~yospe Non commercial email only

More information about the MUD-Dev mailing list