[MUD-Dev] Thoughts on Classless systems
Raph Koster
rkoster at austin.rr.com
Tue Jul 25 20:17:26 CEST 2000
> -----Original Message-----
> From: mud-dev-admin at kanga.nu
> [mailto:mud-dev-admin at kanga.nu]On Behalf Of
> Ryan P.
> Sent: Tuesday, July 25, 2000 3:29 PM
> To: mud-dev at kanga.nu
> Subject: Re: [MUD-Dev] Thoughts on Classless systems
>
>
> At 01:59 PM 7/23/00 -0400, Travis Casey wrote:
> [big snip]
> >The Palladium RPGs have an interesting idea -- skills that raise
> >stats. For example, a character can take a "bodybuilding" skill to
> >raise his/her strength.
> >
>
> A slightly modified version: What if regular skills (not
> specific stat-
> raisers) raised their primary stats. Perhaps casting lots of wizard
> spells would raise a character's intellect, or doing a lot of sword
> fighting would raise their strength. However, with this system, a
> skill decay would be *required* due to the possibility of super
> powerful characters. Has anyone tried something similar to this
> before?
Yes, UO did it. I suppose a recap of UO's system might be in order since so
much of this thread seems to touch on similar things.
UO had 40-odd skills, all stored internally as 0-1000 values, displayed to
users as a percentage with a decimal point. There were very few cases of
"treeing" in the skill system--it was largely flat. There were three
attributes, strength, dexterity, and intelligence, with each skill having a
weighting in terms of how much it depended on each of the three, expressed
as percentages (eg, a skill might be 80% str, 10% dex and 10% int, and so
on).
Every player had access to try any skill. Success rolls were generally
speaking a roll against the player's value in that skill, modified by the
difficulty of the task, and also modified by the player's stats. In that
same hypothetical skill, having high strength helped the roll more than
having high dex.
Each time a skill was tested, it had a chance of going up if you succeeded,
said chance reduced by how high the value was, and increased by the
difficulty that was attempted (you'd learn more if you succeeded at
something really hard, and you'd stop learning if you did stuff that was too
easy for you). There was a maximum of 700 points to distribute between the
40-odd skills. When you reached the cap, another skill (it was supposed to
be your least used one) would have to drop by the corresponding amount. This
proved to be very difficult to manage, so eventually players were given the
ability to choose which skills they wanted to have go first in decay and
which sksills they wanted to have rise and which they didn't want to have a
chance of rising.
Since different skills could be tested at different rates, a table of ratios
was kept which tracked the number of tests of all skills relative to a
baseline usage level. The chance of advancement was then modified by that
ratio, so that all skills had the same advancement rate across the entire
population base. Severe problems resulted here because of capping the ratios
at top and bottom, which effectively broke the system. In addition, because
there was not a high level of confidence in this table, there was also the
ability to manually override advancement curves. Of course, the presence of
these manual overrides meant that we never got to see the system actually
work. :) Eventually the table was removed because it was vulnerable to
macroing, which distorted the ratios badly in a feedback loop as players
macroed more, pushing the ratio, making it slwoer, so it demanded macroing
to advance, ad nauseum.
Macroing was eventually alsmot entirely eliminated as factor by using fixed
random seeds plus the current skill level plus the date on the success
rolls, making it impossible to succeed at something you had failed at until
you advanced elsewhere or waited a day.
Stats increased when the skills went up, in the proportions dictated by the
skill's data. Some skills (so called "lore" skills, which did not consume
resources) were set to never advance stats. Stats were tracked on a simple
0-100 scale.
Major issues with the system: no treeing of skills, so there was no
specialization. Arguably, too short an advancement cycle. Still too big a
disparity between novices and advanced players. The skill cap was probably
twice what it shoud have been, or else the number of skills should have
doubled. Ability to control yoru advancement should have been there from the
beginning. The table of ratios should have been given a fair shake--it might
well have worked with the anti-macroing countermeasure in place. And too
many of the skills encompassed too many abilities (eg, all of magic's 64
spells were still handled by 1 skill, making it relatively easy to pick up).
-Raph
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list