[MUD-Dev] Character skill distribution and trade-offs
Ron Gabbard
rgabbard at swbell.net
Fri May 31 10:10:11 CEST 2002
One thing I've been working on that the discussion on 'soloability
and grouping dynamics' brought to the forefront was the nature of
character skill distribution. Whether the MUD is designed with
'classes' or 'skills', most have a trade-off where a character can
learn/acquire X skill but this necessarily means that they can't
have Y skill (or can be proficient at one or the other). In a
perfect world, the trade-offs would be such that no matter what
decisions the player made (within reason) in developing their
character, the player would end up with a character skillset that is
similar in overall efficacy to every other character. The end
result would be that there is no obvious 'template' for individual
character development or 'groups'.
I would be interested in hearing what methods people have used in
determining character development trade-offs... or if a skill should
be in the game world at all.
I've been working with a model built off of the basic
(Mob_Health)/(Character_DPS) and (Character_Health)/(Mob_DPS) where
DPS is damage_per_second and the equation with the highest result
would typically win the battle. Of course, this is the base (and
most simplistic) form of the equation. The next assumption I made
was that the two equations should yield similar results if the AI
played both sides. Thus, it would be the player's use of the
available skills that determined the outcome in an 'even-con'
battle.
The next step was to outline every proposed 'martial' skills in
terms of how it influenced these equations, e.g., spells that
increase the weapon's DPS, constitution debuffs that lower
Mob_Health, etc. Then I plugged in the various skills I was
planning on making available to see their overall impact on the
'battle'.
I found that almost every proposed skill could be tweaked in
effectiveness in such a way that the overall nature of the encounter
isn't changed, the skill was still viable, and the skill was still
worth the trade-off required to acquire it. The two exceptions to
this was the 'mesmerization-type' skill,where a player could
temporarily disable mobiles in a multi-mob versus multi-character
encounter, and 'healing' (to a lesser degree), where one character
could effectively increase the Character_Health of another based on
the mobiles' actions. (It's like being able to look at the cards
passed to me before passing my cards at the beginning of each hand
in a game of Spades).
'Mesmerization' just wreaked havoc on my model as every encounter
that included this as a character skill was turned into a single_mob
vs. character_group battle reducing overall Mob_DPS by (#_Mobs -
1)/(#_Mobs) and dramatically increasing Character_Health as players
could 'recover' during battle. The choice is then to either
increase Mob_Health and Mob_DPS so that the modified encounter is
still a challenge, allow this skill to be the 'optimizer' skill such
that any group that had this skill would have very little risk, or
just not include it in my game world.
Two of the three options above led to 'template' groups (unless the
skill was extremely prevalent across character development models.
In which case, why have it at all as the same effect could be
achieved by removing all the multi-mob encounters?)
The ramifications of 'mesmerization' actually went even deeper as
the DPS I had planned for 'magic' in relation to 'melee' damage had
to be reduced to maintain the challenge of the encounter and offset
the ability to recover during battle. In addition, those characters
with lower health and/or defense became paperdolls in the option
where mobs are 'beefed up' to offset the effect of 'mesmerization'.
Anyhow, that was what I found. I was just wondering if someone else
had a better or different process/model for evaluating character
skills and developing trade-offs.
Cheers,
Ron
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list