[MUD-Dev] Re: CGDC, a summary

[Adam Wiggins]

On Mon, 18 May 1998, Koster, Raph wrote:
> On Sunday, May 17, 1998 10:16 PM Travis S. Casey [SMTP:efindel at io.com]
> > This is the primary reason why I favor learn-by-using-based skill
> > systems.  In such a system, players are free to define their own goals
> > (at least, as far as character advancement goes), and the means of
> > achieving those goals to is to exercise the skill in question.
> > future.
> 
> And now those who made those choices are sorta in backlash against it.
> Quite aside from the difficulty of balancing a skill-based system (as
> opposed to a class-based system, and yes, there are many half-and-half
> systems that can be designed) it's the usage part that is problematic.
> It led to a lot of sitting and macroing, and the advancement rates for
> differing skill are hellish to balance out.

My friend showed me a client for UO that uses screen positions and
compares on pixel colors to automate things like spellcasting and
character healing.  I suppose it's a sign of success that someone would
put that much work into trying to "cheat" :)

> A couple of issues/approaches/etc
> * What UO did: each time a skill test is done, chance of increase,
> weighted by an advancement table (UO actually tries to generate said
> table based on skill usage frequency)

I must say I was somewhat underwhelmed by UO's skill advacement.  You guys
seemed to manage to avoid using standard devices to limit macroing which I
thought were cannon by now.  (Was this done on purpose, or just due to
time constraints?)
For instance...learning to hide by just standing in a room pounding the
hide key over and over?  Not only is that easy to macro, but it begs it,
since it's not fun.  Normally a skill like hide gets a chance to go up
when someone tries to find you, not when you just crouch in a corner by
yourself.

> * Make it time based--skills must achieve a certain minimum number of
> tallies in a given span of time, and learning takes place after that
> span of time

This is a good one.  Set up properly, it means that using a skill ten
times or one hundred times in the course of an hour results in the same
advancement, making macroing absolutely pointless.  I believe the first
effective use of this was made by RuneQuest.

A good example: while playing on YaMUD (a from-scratch, classless,
skill-based mud that never gained much popularity) my friend and I decided
to try to learn up our languages the "hard" way (ie, not going to the
language teacher) in order to save money.  So we'd spam each other
speaking in our native language trying to get the skills up.  We quickly
figured out that you only got once chance per minute (or so, I don't know
how long the time period was) to learn the skill, and after that
(regardless of whether your skill went up or not) you couldn't learn again
until a minute had passed.  So we took to throwing odd phrases out here
and there in different languages every so often.  Not only was this more
fun, but it made sense and prevented spam-bot learning.

> * Put in a traditional "practice points" system or something to serve as
> barrier of entry

YaMud had no classes or levels, but it did have experience in the form of
skill points.  You 'spent' these skill points at a teacher to raise your
skill.  In addition, there were limits to how much a skill could go up
either exclusively at a teacher or exclusively on your own.  You had to
use a mix of both practicing the skill and training at a teacher to have
it go up properly.
Although not very "realistic" (I'm starting to dislike using that word),
this is probably one of the easier ways to balance overall skill learning,
since it's a number that is directly tunable.  Most of the parameters for
skill system have somewhat indirect effects on the system as a whole,
making them difficult to tune easily.  Legend has one of the simpler but
most effective skill point systems I've seen: one skill point per level,
with each level costing a certain amount of experience.

Our skill system, which I've described before, is rather complex (although
not probably not nearly as much so as Nathan's skill web).  Besides
involving several hundred skills organized into a tree and assigned
difficulty, we store several values for each skill - specifically three,
one for your 'potential', one for your actual skill, and a time value
(when that skill was last learned, and when it was last used).
I'm extremely happy with it, but our testing has been limited to brief
alphas with a few (like, a dozen) of our friends, so it's certainly hasn't
had any real stress testing.

> * You've got the nasty "atrophy problem" too--players hate losing skill
> points, but a usage based system implies eventually maxing out in
> everything. Either this or some form of "skills in opposition" table or
> something encourages specialization and doesn' t preclude later change
> of character emphasis (which we have found to be popular).

Yes.  It's always better to set things up so that they seem less limiting,
even if they really are. :)

I've heard some highly amusing stories about the effects of your skill
system.  My favorite was probably the "lute of death": since someone using
a skill near you gave a small chance to learn, a few strums of a lute near
a skill-maxed mage could increase his musicianship a few points, thus
sending his hard-earned thaumaturgy skills spiraling downwards...

Skill based systems are very cool and as a player I much prefer them, but
they are quite difficult to balance.  IMO Legend did a very good job, but
it had the advantage of simplicity and the fact that it was under less
"stress" due to a much smaller playerbase.

Adam


--
MUD-Dev: Advancing an unrealised future.