[MUD-Dev] Balance
J C Lawrence
claw at kanga.nu
Wed Apr 4 23:08:21 CEST 2001
From:
http://sneezy.stanford.edu/balance.txt
--<cut>--
This document contains information pertaining to the gaming system
of Grimhaven (formerly SneezyMUD). I am writing it with three
audiences in mind (a coder of Grimhaven looking for specific
parameters in use, a player of Grimhaven looking to "see under the
hood", and a game designer from other muds looking for a "how-to"),
and am providing details that I feel are necessary to any one of the
three audiences. As such, aspects written for one group may go more
in depth than someone from another group needs, but realize I am
shooting for completeness.
Furthermore, I am assuming some basic understanding of mathematics
(mostly algebraic "solving for the unknowns"), statistics
(calculating averages), and RPG terminology (knowing what 2d6+3
means). If I lose anyone in the math, my apologies in advance.
==================
Before we start crunching numbers, it's appropriate that we first
understand exactly what we are attempting to create, and why. This
is done so that any system devised can be defended on logical
grounds. However, realize I use the term logical (and not
realistic) because what is being created is a simulation and not a
virtual-reality. It's nice to shoot for realism, but be warned that
compromising the gaming system in favor of reality leads to a
breakdown in the overall enjoyability of the game. In the final
analysis, remember to favor the conclusions of the gaming system
over the enticements of modeling reality better, or face the
consequences.
========================
What is Balance:
In one sense, balancing a mud is about insuring that the relative
advantages and disadvantages in a given decision are equalized. A
decision that leads to more advantage is said to be "over powered"
while one that has more disadvantaged is thought to be "under
powered". However, realize that when evaluating adv/disadv, it is
important to maintain perspective. It is entirely possible to
devise a balanced decision where one choice leads to immediate
rewards, but long term hardships, and the other is a more
even-keeled choice. It's useful to keep the "entire career" in mind
and not simply evaluate the instantaneous effect.
In another sense, balance is a state of equilibrium where both
players and NPCs are thought to be in synch, neither being evidently
stronger than the other. In this sort of balance, the outcome of
any given fight heavily depends on both luck and technique. Players
can't affect the random-number-generators, but the tactics they use
will generally skew the outcome of a balanced mud into their favor.
Furthermore, balance is also an intra-player concept in terms of
analyzing whether choices the individual player has to make are
even. At the simplest level, this can mean looking at racial and
class choices, but translates down into equipment choice, learning
paths, and a whole slew of other minor decisions.
======================
Why Balance?
As a game designer, we seek to have all aspects of the game
utilized. No coder wishes to develop a new aspect of the game that
no one wishes to play with. Where is the reward in that?
However, it also behooves coders to respect what went before. If
they add a new aspect of the game that is better than the
alternatives, players will shift to that (which is not fair to the
developer(s) of the original alternatives). Balance, in a sense, is
about not adding things that are better or worse, but about simply
extending the number of choices available.
It is a rare game that adds elements that are weaker than the
alternatives. Typically, new choices are over-powered because
either the coder has not centemplated balance concerns, or has opted
to ignore balance-concerns in favor of kudos and praise from a
grateful playerbase. It is the game designers duty to avoid such
situations, as it leads to one of three bad consequences.
Consequence 1: Realize an element is overpowered, and go in after
the fact to tame down the power to the "balanced state". This of
course leads to wide- spread complaints from the players that chose
that element (because it was better).
Consequence 2: Do nothing. Typically this is not a decision that is
made consciously, usually being the result of not being informed, or
of not having enough time to address the problem. The obvious
pitfall is that the longer such a state occurs, the more folks will
take the stronger option and the harder it will be to change it at a
later date.
Consequence 3: Redefine "balance" to take the strength of the new
element into account. Balance is simply an equilibrium state where
all things are equal. In some degree, nothing prevents a game
designer from enhancing all elements of a decision equally to
reachieve balance. However, this can only go so far in a gaming
system. Coders are limited by the size of their variables, by the
amount of data they can track, and by the speed of their hardware to
make all the necessary calculations. Also, realize that balance is
a concept with tremendous down-stream effects. In some regards, you
can simply redefine (upward) all other aspects, but this may not be
feasible to do in a timely manner. Do this often enough and I
guarantee you will run out of resources (available space, time, or
processing power).
=============
Game Design Methodology
Game Design is not a skill most people have naturally. While there
are many many many muds in existance, very few of them are actually
"designed". For the most part, the coders simply throw elements
together, making random tweaks and adjustments as needed, and listen
to feedback from the players. Some muds can be "successful" in
doing this, but realize that all they have managed to accomplish is
to achieve an equilibrium state without understanding why they have
the equilibrium they do, what the assumptions their game system
operates under (except in very vague terms), or what the
consequences of changing a given aspect will have on their
equilibrium. In short, they are only capable of stumbling forward
blindly, and can only safely add "bells and whistle" features
without seriously risking a complete breakdown of their equilibrium.
Most multiplayer games, and MUDs in particular are effectively
chaotic systems, in that a small change in one area can propogate
through the entire system and have dramatic effect in a wholly
unrelated aspect of the game. The more complex the MUD, the greater
the need for understanding the ramifications of any proposed change.
While the original DIKU was developed by a group of programmers,
most MUDs today are small enough that they can be maintained by a
single programmer. As time passes and MUDs get more involved, their
complexity will also grow and they will exceed the capacity for one
person to understand all aspects of the system. By that point, it
becomes paramount that the overall game design be laid down so that
new programmers can be added effectively, and that all can clearly
see how given subsystems interact with each other.
In devising the gaming system, it behooves us to start simply, and
add more elements as we progress. That is, while we eventually want
multiple classes and multiple races and a wide-variety of skills, we
are forced to start with a very basic system and get things working
at the basic level before we create an overly exotic system. Trying
to address too many variables at one time leads to burned out game
designers, so isolate the problem, start small and don't add new
elements until you are assured that the basic elements are working
correctly.
======================
Defining the Axioms:
The Axioms of a gaming system are those things that are fairly
arbitrary and a game designer is free to change at will. However,
once decided upon, other aspects of the game utilize the axioms so
the axioms effectively become locked (or if changed, cause massive
reworking on all the systems that made assumptions based on them).
Since we are starting simple, let's begin by setting the following AXIOMatic
properties.
The number of levels a PC may gain
HP growth of a PC
HP growth of an NPC
Damage formula for a NPC
More axioms are chosen later on and I will mark them as such by putting
(AXIOM) near them.
HP Growth is basically knowing how many hit points (HP) a given
creature will have as a function of their level. Most MUDs will
permit some fluxuation of HP, so it's only important to look at the
average number.
The damage formula for an NPC is how much damage a creature will
inflict (assuming all hits connect) in a given time frame (generally
a round). Most MUDs will break this down into a given number of
blows in a set amount of time and a given amount of damage per blow.
In my specific case, I chose
PC Lev : maximum of 50 levels
PC HP : 25 + 8*level
NPC HP : (1d8+11) * level HP = 15.5 * level HP (avg)
NPC dam: 1/1.1 dam/lev/rnd = 0.90909... dam/lev/rnd
Like I said, these are arbitrary values. In retrospect, PC HP I
feel ought to be higher (1500 HP max is a nicer round number), NPC
HP ought to be scaled up likewise. The damage curve is somewhat
problematic in that it yields 45 dam/rnd at L50 and players have a
limited amount of HP, but I suppose if you raised HP, this problem
would go away.
==================
Define the balance point (axiomatic)
To some degree, we are allowed to pick where we want the PC and NPC
combat to balance. To my mind, I feel that a Level X PC and a Level
X NPC ought to be roughly comparible, but this isn't necessarily
required.
While it is entirely possible to have some different algorhythm for
the balance point, it makes for more exotic and complex equations
(which we should try to avoid if possible). As such, it is probably
most practical to define a "fair fight" as being between two
like-leveled creatures.
==================
PC damage formula:
Let us first recognize that the length of time a creature can
survive in combat is governed by the number of hit points it has,
and the rate at which it is taking damage.
Furthermore, for a PC and an NPC to be balanced, they should kill
each other at roughly the same speed. We do want to weight it
slightly in the favor of the PC to avoid complaints.
This yields:
NPC HP / PC damage = PC HP / NPC damage
PC damage = NPC damage * NPC HP / PC HP
= (1/1.1 dam/rnd/lev) * (15.5 HP/lev) / (8 HP/lev)
= roughly 1.75 dam/lev/rnd
==================
Melee combat hit rates:
Melee combat is a battle involving just hitting (with or without a
weapon) back and forth (no skills, no spells, etc). It generally is
randomized slighly by having a certain degree of 'misses' occur.
It is useful to have a formula for what percentage of blows will hit
in a fair fight (axiom) and what the change in that percentage will
be as a function of level (axiom).
For our setup, I chose a base 60% hit rate with a +/-3% per level
delta. That is, an L10 vs an L10 would each hit 60% of the time.
An L11 would hit an L10 63% of the time, while the L10 would hit the
L11 57% of the time. An L15 v an L20 (5 lev difference) would yield
hit rates of 45% and 75% respectively.
In retrospect, it is good to keep the base rate as close to 50% as
possible and to keep the delta as small as possible. Large deltas
are expecially bad as they make a handful of level difference mean a
tremendous amount. For example, a 10 level difference becomes hit
rates of 30% and 90% which is VERY noticible.
As a further step, having some guaranteed success/failures on hits
makes some sense. Following AD&Ds lead (natural 20, natural 1),
there is a 5% chance of a hit/miss regardless of other factors, or
translating, rolls below 5% fail always, rolls above 95% hit always
(regardless of the level difference and delta). This is basically
the reason to shoot for a 50% rate, as otherwise it causes only one
of the combatants to be governed by this "only naturals"
arrangement. This is not that big a deal, and with a lower delta
value it would be even less of a concern.
==============================
Combat time:
Knowing the hit rate and the rounds to kill, we can achieve a
first-order approximation for the average duration of combat. That
is, the rounds to kill calculated above assumes every blow hits.
Tacking in a hit-rate lets us see what combat would really be like.
Recognize first that:
effective damage rate = max damage rate * hit rate
and therefore:
combat time = HP of victim / effective damage rate
= HP of victim / max damage rate * hit rate
= 15.5 HP/lev / 1.75 dam/lev/rnd / .60 (NPC alternative)
= 8 HP/lev / 0.9091 dam/lev/rnd / .60 (PC alternative)
= roughly 14.75 rounds
Our mud has had a long convention of tweaking the game speed so that
a round of combat was roughly 3 seconds long (axiom). This
translates into the average fair fight lasting 45 seconds total.
Realizing a 45 second combat time was fairly short (preferring more
on the order of 90 seconds), we can either go back to first
principals and start over (raising the HP formula, lowering damage
formula), or we can take the simple way out and introduce global
modifiers (either on all HP calculations, or on all damage
calculations). None of these options is more superior to the
others, and since I felt that players would notice a change in their
HP more than they might a change in damage, I opted to introduce a
global-damage modifier to help fine tune this variable.
After some back and forth, we wound up with a global damage modifier
of 0.75 on damage. Translating, that became a combat time of
roughly a minute for a fair fight.
================================
Offense and Defense:
While we determined base hit rates for melee combat above (level
based), it is useful to go the the next step and simply define these
as being more or less governed by a hitter's offense score vs a
defender's defense score. This translates into getting the hit rate
from offense-defense, and letting appropriate factors go into
determining an individuals offense and defense score.
Definition of offense and defense particulars are essentially
arbitrary but account for everything from level, armor, position,
skills, characteristics, etc.
As a first order process, its useful to translate level into offense
and defense. Then throw in other factors (pos, skill,
characteristics) as minor adjustments.
=======================
ARMOR:
As a final step of defining offense/defense, defining how armor
works as a function of level is critical and integrating this into
the setup is then possible. For example, a newbie player might have
500 points of armor, while your top of the line char has 2000 points
(linear progression in between) (AXIOM). This lets you derive
"defense" as a function of AC (and other factors) rather than of
level.
At the same time, it is a good idea to define how the points of
armor will be spread around. For instance, if I have 500 points of
armor total, how many do I get from my helm, from my shield, from my
suit, from my boot, etc. (AXIOM).
========================
sub-system: dual wielding
With all the above established, we have enough to create our first
subsystem. It may be assumed that a player is holding a weapon and
a shield and getting a certain number of hits per round, or using
two weapons getting double the hits but no shield.
We have established what percentage of AC of their total suit comes
from their shield (25% for us) and we can translate a loss of that
much AC into a new hit rate in a fair fight.
Assuming a newbie (500 points of armor) dual wields (no shield = 125
points lost) in a fair fight. In our derivation, we yielded 25
points of armor per level, so a 125 point loss is 5 levels
difference. This means the newbie hits 60% of time, and is hit
60+5*3 = 75% of time.
Single-wield fight:
inflict = 1.75 * 0.6 = 1.05 dam/lev/rnd
receive = 0.909 * 0.6 = 0.55 dam/lev/rnd
Dual wield fight:
receive = 0.909 * 0.75 = 0.682
For parity, I ought to inflict 1.05 * .682/.55 / (0.6 hit rate)
= 2.17 dam/lev/rnd
Assuming primary weapon is 1.75 dam/lev/rnd, this means I should
only get 25% of dam from second weapon for parity. That is, either
they get 1/4 the hits from second hand as primary, or the damage
from secondary is 1/4 what it would be from primary (or some
combination thereof).
Further studing the problem, if we assume non-newbie, they have more
total armor, but also pay more points of armor loss for no shield.
That translates into a higher received damage percentage (75+%) for
non-newbie in this case which, if you wanted to maintain parity,
would let the damage for dual wielding rise upwards.
For example, loss of a shield for a L25 (total armor = base +
lev*(amt/lev) = 500+25*25=1125) is 281 (1125 * .25) points of armor
or 11 (281 / 25) levels of AC yielding a hit rate of essentially 95%
(60% base + 3%/lev * 11 levs). The effective rate of damage becomes
0.864 (.909*.95) and parity is 2.75 (1.05 * .864 / .55 / .6) or
offhand can yield up to 58% ((2.75-1.75)/1.75) of its true damage
for parity.
Yielding more damage than what is calculated here makes dual
wielding more advantageous, yielding less makes carrying a shield
more advantageous. When devising the actual value, keep in mind
other strengths/weaknesses of shield vs weapon (rental cost, magic
effects from, etc) too.
As a final comment, it is also useful to keep in mind that dual
wielding and single wielding are different strategies for different
situations. A player that is hitting behind a tank needs not care
about AC at all. If dual and single are perfectly matched, players
will dual wield because it's dead even if they are tanking, and
there's no downside if they are not.
For these reasons, I opted to implement dual-wielding as being only
10% normal damage for the off hand, with skill use capable of
raising that figure up to 70%. The low base value encourages folks
away from dual wielding, while a high skill makes dual wielding very
attractive (even if tanking).
========================
Number of Hits
We have established that we desire 1.75 dam/lev/rnd, but we have yet
to determine how many hits make up a round. This is the equivalent
question as asking how much damage is inflicted per hit.
Realize, as a designer you only get to control one of these
equations, while the other is governed by decisions already made.
In our situation, we had a great deal of existing weaponry with
arbitrary values for "weapon damage" already assigned, and desired
not to have to convert. We were reasonably assured that the better
(higher dam) weapons were only acquirable later in a person's
career, so that a rough equation for weapon damage/level could be
arrived at.
It was useful for us to put an extra safety valve in place that
threw the arbitrary "weapon damage" into a function that factored in
such things as characteristics (strength dex), and skills to weed
out majorly flawed weapons and arrive at reasonable dam/lev/hit.
Ultimately, we settled on 1.75 dam/lev/hit as a nice round number,
which translated into 1.0 hit/rnd. Realize that off-hand
(dual-wield) hits should follow primary hits so that a person gets 1
hit with each hand per round. The discussion above on dual-wielding
insures that the damage from the offhand maintains balance.
===============
subsystem: Weapon Specialization
It was desirable for us to add weapon specialization, a skill, which
learned late in a person's career, raised the number of hits/rnd.
This creates a problem though in that if the hits/rnd increases, the
damage also increases. Either the damage/hit has to be lowered to
account for this, or the balance formula(s) have to adopt to the new
setup.
The first option is not really practical as it essentially means
that the best weapons in the game have to be attainable around the
point that specialization begins. Maintaining dam/lev/rnd is done
by mastering your specialization, not by acquiring a better weapon.
Player's like finding new and better equipment, so putting a check
on this was deemed a bad idea.
Which leaves option #2, letting the rest of the system account for
specialization. In theory, all that has to be done is insure that
the rounds to kill formula is maintained. That is
rnds to kill = mobs HP / PCs damage capacity
Since PCs damage has basically gone up, an equivalent rise in mob's
HP has to occur. As specialization was adding an extra hit (total
of 2) per round, this translated into raising mobs HP an equivalent
amount in the level range in question.
As our learning system makes it difficult to predict where a given
skill is learned, and how fast, this makes it problematic to predict
the outcome of such a change. For example, if we start giving mobs
the increased HP at a given level, and a player has not started
specializing by that time, they will effectively be behind the curve
when fighting at that level.
Furthermore, as specializing acts largely as a damage multiplier, it
means it can NOT be ignored as a skill learned by a player. As
such, the skill becomes a necessity rather than an optional path for
players which is not necessarily a good thing.
Lastly, a change to mobs HP will affect systems conceived later on,
but I will note them as we come to them.
While we acknowledge the consequences of having weapon
specialization operate in this fashion, we deem all these problems
as solvable and that weapon specialization can therefore be added.
We will have to address some of these consequences later on though.
==========================
Subsystem : chivalry
We choose to enhance mounted deikhan's fighting ability. We
essentially grant them a bonus to offense and defense when mounted
scaled by their learning in the chivalry skill which should counter
balance the loss of swings suffered by mounted combatants.
Riding attackers lose 1/3 of their melee attacks. In order to make
up for this, chivalry must either cause the deikhan to take 1/3 less
hits, or hit 3/2 times more often (or a combination thereof).
Because the base chance is 60%, hitting 3/2 as often would result in
a 90% rate of hitting (obscenely high). We opt to take only a
fraction of this and make the hit rate 70% instead (7/6 as often).
The remainder will be a bonus to their ability to defend themselves
while mounted. That is, the should gain a defensive bonus of 9/7.
The 9/7 defense bonus and 7/6 offensive bonus together make up for
losing 1/3 of attacks.
It seems intuitive that we arbitrarily choose to balance the penalty
and the chivalry bonus so the equilibrium point is at some
learnedness in chivalry LESS than max learning. Arbitrarily, we
settle on 75% learning being the point of equilibrium and scale the
effects up by 4/3 to see their full strength at max learning. That
is, a fully learned deikhan will get 2/9 (1/6*4/3) hit rate and a
12/7 defensive bonus.
As a normal creature blocks 40% of all blows in a fair fight, a
defensive bonus of 12/7 means they now block 68.6% of shots. Said
another way, full chivalry will yield a 73.3% chance of hitting in a
fair fight, and result in only being hit 31.4% of the time.
However, you must be mounted so you lose 1/3 of your normal combat
blows.
==========================
Fair Fights and mob difficulty:
Earlier, we mentioned that a fair fight was essentially a fight
between equal level player and mob. For the most part, this was
arbitrary, although it let us cancel out some factors nicely. As a
further argument for this arrangement, players typically decide what
to fight based on 'consider'. It is important from a game-balance
standpoint to give a fairly accurate interpretation to a player of
their chances. We would like to be able to say that two mobs of
equal "difficulty" consider the same.
This is somewhat impractical, as player's strategy and tactics often
lead them to attack mobs of one type and not of another (high AC,
low HP vs more balanced).
Likewise, a system that causes a player to think a mouse and a
dragon fight the same (consider the same) is poorly designed and
forces the player into trial&error methods of fighting. As a
necessary consequence, a means of exiting from trial&error fights
has to be added to avoid excessive funerals. Such muds are
characterized by non-reliable considers and highly prevalent use of
such things as recall scrolls. If the game is designed well,
players can make informed decisions about what to (and not to)
fight, and be held responsible for their actions (flee, but no
recall).
All of this leads to the conclusion that level and difficulty are
virtually synonomous.
I realize this flies in the face of some RPG'rs preconceptions like
a low-level mage ought to be weaker than a low-level warrior, but
these are arguments that can be relegated strictly to PCs. In the
NPC realm, if a mage NPC and a warrior NPC are dead-even difficulty
wise, it makes it easier for players if they consider the same. You
leave it to the PC to realize that the mage is equal to the warrior
because (fewer HP, more AC, higher damage spells) and to decide to,
or not to, fight it based on that.
=====================
Mob Experience:
It ought to be common sense that the more "difficult" a mob is to
kill, the more exp it ought to reward for killing it. Since we have
made difficulty and level synonomous, this simply ties exp in as
well.
Higher level, more difficult, more XP.
Additionally, muds that choose to follow the "mage mob should be
weaker than warrior mob of same level at low level" trend will have
a more difficult time in deriving useful XP formulas.
======================
Mob Difficulty and Real Level:
It is a fairly trivial task to make mobs fight each other, to make
enough fights between similar mobs occur to eliminate statistical
deviation, and to arrive at reasonable evaluations for relative
"difficulty".
By using such empiracle testing methods, you can make minor
adjustments in single variables and arrive at a resonable formula to
give mobs a value for XP.
In practice, I established a float which I called "real level".
Real level was made up of component parts (armor, damage capacity,
hit points, etc) and was constructed such that it roughly followed
the trends already established. That is, we have already determined
formulas for armor as a function of level, damage capacity for mobs
as a function of level, and HP for mobs as a function of level. It
reduces to a problem of figuring out what the relative weights for
each factor is. How important is AC given our combat system? How
important are a few extra HP? This is done somewhat arbitrarily,
but it useful to establish a function for determining "real level"
given a set of properties (HP, AC, etc).
As a final step, adding "class" to the mix should be done. For
example, how worthwhile are the special moves a mage NPC is able to
do versus the ones a warrior NPC is capable of? The only reasonable
way I found to test this was to take a warrior mob of level X,
change it to another class and fight it against mobs of various
levels, ultimately arriving at an fair-fight level. The difference
between the fair-fight level and X was the class-adjustment to
level, and in later calculations, this class-adjustment to level
would be factored into "real level". That is to say, if I take a
level warrior mob of "real level" equal to 15, change it to a mage,
and it can now fair-fight a warrior mob of "real level" 20, then the
class adjustment for mages at L15 is +5. If a mob's stats say it is
a L15 mob and it has a class of mage, the real level reported would
be 20. Or said another way, if you are fighting a L20 mage, you are
really combatting a mob with L15 stats (AC, HP, etc) plus the mage
special procedures.
The unfortunate downside to this method is that each class/level
combo has to be established, and for each, enough fights to
eliminate statistical deviations has to be done. This is VERY
time-consuming. Furthermore, changes to the special-procedure,
either improved AI, or more/less powerful effects, cause the data to
become suspect. I am not sure of a good way to avoid these problems
other than keeping an eye on what player's say is "good xp" and
seeing if perhaps too much is being rewarded for a given class.
========================
Mob XP curve shape
Once a formula for real level is settled upon, it is a necessary
progression to fix mob XP based on the "real level" calculation of
difficulty. While it might seem like it can be done axiomatically,
in fact, it can not!
In theory, a mob that is twice as tough ought to yield twice the XP.
If it doesn't, then folks will discover they can make more XP by
killing more of an easier creature. This is typically called
"plowing" whereby a player sweeps through a low-level zone killing
numerous easy critters for as much XP as would be rewarded by a
single tough mob. If it yields more than twice (the opposite case),
this basically becomes a grouping-mandatory mud where the best XP is
gotten by groups of players conquering single monsters that are
vastly higher level than they are.
Neither extreme is ideal. The former allows players to continually
fight but requires areas of numerous, similar-level creatures and
makes dying very difficult (you'd have to be nearly dead to begin
with to die to a lower level creature). The latter requires a large
player base with enough players to support the grouping dynamic, and
requires tactically skilled players to know how to fight effectively
as a group (rescuing, healing, etc).
Personally, I lean toward favoring the latter case, but only
marginally. A group, if it can be found, is nice, but should not be
mandatory, and as such I settled on a target value of double the
difficulty = 2.1 times the XP. Choose your own target value.
We are then left with a discussion of difficulty, but we have all
the tools we need already. We know hit rates and how the fluxuate
with level difference and we know how HP and damage fluxuate with
level.
Define a concept I call "doubling level" as that level over my own
where my combat time is 1/2 the combat time of the target. That is,
the point where I will die and my victim will be at 50% strength.
Recall that combat time is
victim's HP / my hit rate / my damage per round
This becomes a VERY ugly formula to solve and things stop cancelling
out nicely. What you will probably discover is that the doubling
level is a (ugly) function of level.
But wait, it gets worse. Knowing the doubling level, you then need
to achieve a formula that yields double the value in that period of
time. I hope you remember how logarhythms work, because you're
going to need them.
I am intentionally skipping the math, because for me it got
incredibly complicated, and I am pretty sure there would be flaws
which I don't care to contemplate. Suffice to say, with doubling
level a function of level, this makes the log stuff work out
horribly too. If someone wants to solve this problem for me, I wish
them luck, but I ultimately wound up letting boot time calculate a
table of doubling level for all levels, and using this to achieve a
percentage increase in xp per small increment in level, and finally
achieving xp per level by doing integral increments and summing
things up. It's ugly as heck, but no one ever said game design was
easy. With that said though, everything else became downhill.
While the actual values are quite different, it is useful (in later
calculations) to have a first order approximation for doubling
level. We can roughly say that doubling level at level L is L/10.
That is, a L44 is 2* harder then a L40, etc. This should only be
used to eyeball calculations for rough approximations though.
I suspect that if we worked backward, that is devise an easily
solvable equation for comparing combat times, and devise formulas
for each of the component parts (HP, hit rate, dam), we might wind
up with a better solution in the long run. I made no attempt to do
this, as existing criteria of our mud locked us in to a certain
setup that precluded this.
================
Kills for PC level:
Once mob XP is known, you can settle (AXIOM) on some arbitrary
values for number of kills to level. It's useful to keep in mind
how long you want it to take to achieve the end of the game when
devising these figures, but it's possible to tweak that so isn't a
critical consideration.
For our own purposes, we opted to make each level increasingly
difficult and more and more kills be required for each successive
level. The first few levels go reasonably fast with only 20 or so
kills necessary to level, while later levels require over 80
fair-fight kills.
It is important to recognize that the number of kills required to
gain a level determine how long it takes to achieve that level, and
in turn, affects how many hours the game will last for the average
player. We derived a formula above for how long the typical combat
would take. Since we set the system to use up most of their HP in
such a fair fight, we assume full regen per fight. We can thus make
some reasonable guesstimates about how much time passes for each
fight to occur (fight time + regen time). Scaling upward, we can
then achieve a theoretical minimum time for each level (assuming no
socialization, just sheer fight and regen). By summing these up, we
can arrive at a total time to achieve the max level. As a rule of
thumb, this theoretical number is rougly 25-40% of what it actually
takes players to make the highest level as they will "lose time"
chatting, reading, or just waiting for their favorite kill to repop.
No compelling argument leads me to say one system is better than
another in terms of number of kills to level, so if you choose to
make it a flat number of kills per level for all levels, so be it.
I don't believe I use this formula elsewhere, but just to document
what I chose to use:
kills to lev = 17 + 1.25 * lev
Since the major consequence of this formula is to control how long
the game takes, it is useful to introduce a global scale factor so
that it can be rathchetted up and down fairly easily. This scale
factor can either be made a part of the amount of XP a given mob
rewards or on the kills to level formula and will have the same net
effect.
============
PC XP curve shape:
Since you know the XP for a given mob at a given level, and you know
what level each PC is fighting for a "fair-fight", you have
established all the data you need to derive how much XP a PC needs
to accumulate to gain each level.
Or so it would seem...
Unfortunately, the use of doubling in the mob XP formula causes mob
XP to grow very large very quick. Even if you have L1 mobs yielding
only 1.00 XP, you probably wind up with high level mobs yielding
multi-million XP. Taking the sum when multiple kills are required
probably yields tremendously HUGE values! On a 32 bit machine, the
size of the largest unsigned int is a mere 4 billion or so.
Tweaking the system so you award reasonable XP at low level, without
blowing out the bounds of the MAXINT is somewhat a chore.
Furthermore, at very low levels, its quite possible that no XP is
awarded until the very end of a fight, where high-level fights award
gobs of XP each hit.
Fortunately, a solution exists. Converting XP to a float solves
both problems fairly nicely. You can award fraction amounts of XP
at low level per hit, and floats handle exponential values (1.0E+10)
nicely as well. Displaying XP as a float is semi-ugly, and awarding
fractional XP is also somewhat cheesy, but this is what the system
calls for unfortunately.
=======================
Effects of characteristics
Combat can be broken down into 5 areas of effect,
offense
defense
HP
number of hits
damage per hit
Thus far, we have assumed characters are pretty "average" in that we
have calculated what a typical value ought to be. We should now
allow for deviations from those typical values, but remember that
the advantages must be balanced by the disadvantages.
By tying stats (strength, dexterity, agility, speed, brawn) to the
above combat effects, we can accomplish this. For instance, having
higher than average speed might allow more hits per round. However,
the balance argument encourages us to develop counterweights to this
by having penalties in one (or more) of the other areas so that the
net effect is the same. More hits per round, but less damage per
hit. More likely to hit your opponent, but able to withstand less
damage. etc.
The first step in this process is assuring yourself that you can
accurately predict the "average" stat value. Depending on how a mud
sets up character generation, this may be easy or may be near
impossible (random stat generation). In my own case, stats vary
from 30 to 180 with 105 being the average.
It ought to go without saying that the average stat should have the
"typical" value we've been calculating. We are fairly free to
choose how much better we wish to make a maximized stat (AXIOM); in
my case I chose to make it 5/4 the typical value. The only caveat I
would offer is that the greater the value, the more importance is
placed on stats and the more noticible will be the effects of stats.
Consequently, a higher value will encourage the development and
acquisition of +stat equipment for players.
Having chosen the value for the max stat, the effect of a minimized
stat should be simply 1/x of that. That is, if 5/4 is my max, then
a min stat yields 4/5 the typical value.
Of course, this assumption assumes that to get one stat maximized,
another stat must be minimized (or 2 stats need to be reduced
heftily). It should go without saying that the "min" stat is really
that stat that you wind up penalizing yourself with in order to
achieve a maximized stat. Some MUDs I have seen operate technically
on a 3-18 system, but the average stat you see in play is 15, and
hardly anyone has less than a 12. Such poorly designed stat systems
leave the mud vulnerable to poor implementation in regards to the
effects of stats.
============
Characteristic specifics
It is fairly trivial to introduce stats effects in the area of hit
points and number of attacks. It is a simple multiplier on what is
mostly an integer (or floating point) number.
That is, maximized con yields 1.25 times the normal HP per level
gain (8), so a con of 180 would get 10 HP per level. While
minimized con yields 0.80 the typical value, or 6.4 HP per level
gain. A high speed creature might get 1.25 attacks per round
(assuming 1 hit per round is the norm) while a low speed gets a mere
0.80 hits per round (4 hits every 5 rounds).
The effects of damage are a bit more complex depending on the combat
system, but hopefully your system has the capacity to add a
multiplier of some sort in a convenient place. Maximized strength
thus leads to 1.25 times the typical damage (1.75 dam/lev/rnd) for
2.1875 dam/lev/rnd, whereas minimal strength leads to 1.4
dam/lev/rnd.
Offense and defense are slightly more awkward to figure out. We
want to cause the character to either hit 1.25 more often (offense =
dexterity), or be hit 1.25 more often (defense = agility). Assuming
a base hit rate of 60%, this means calulating the required change to
the offense and defense scores to achieve a hit rate of between 48%
(.6 * .8) and 75% (.6 * 1.25) for a fair fight.
========================
Skill Difficulty
As an initial step of devising skills, its useful to conceive a
skill's difficulty, and the effect of that difficulty on success
rate. This is mostly arbitrary (AXIOM).
Assuming a skill is between 0-100% learned, the success rate would be:
trivial difficulty: learn*100%
easy difficulty: learn*90%
normal difficulty: learn*80%
difficult difficulty: learn*70%
dangerous difficulty: learn*60%
That is to say, a 1/2 learned "difficult" skill would yield about a
35% success rate when used.
We should further factor in stats into this equation, allowing focus
to act as a multiplier. Maximized focus would give 1.25 times the
above value, while minimal focus would grant 0.80 times the above
value.
========================
Skill Damage
We start our analysis of skill damage with a review of melee damage.
Our typical setup generated 1.75 dam/lev/rnd and a base hit rate of
60% for an effective damage of 1.05 dam/lev/rnd from melee combat.
Arbitrarily, we decide that skills ought to add (roughly) an
additional 20% damage (AXIOM), or 0.20 dam/lev/rnd from skills for a
total damage capacity of 1.25 dam/lev/rnd.
Skills take a certain time period to execute, or a certain time
period must pass before another skill can be executed, so this is
converted to a number of combat rounds. Consequently, if a skill
takes 3 rounds to pull off, it ought to do 0.60 dam/lev (3 * .20).
Skills are focused on a certain level range, that is, kick is
typically a newbie skill, while bodyslam is a mid to high level
skill. It would not be good to have a newbie skill continue to do
0.60 dam/lev from level 1 through level 50 as this would ultimately
yield 30 dam kicks and a player would have no incentive to use or
learn any but the most basic skills. As a consequence, we should
use "lev" in these interpretations as the skill's level, and not
confuse it with the level of the actual user of the skill.
We know what discipline a skill is learned in, and we know how
advanced they must be in that discipline to learn the skills.
Furthermore, we know how quickly it is learned. The first two
factors help us determine a "min skill level". That is, if a skill
is in a basic discipline, we assume the basic discipline spans L1
through L30 (we settled on L30 as a round number where the basic
discipline is essentially completely learned, actual learning
varies), and treat specialized disciplines as covering L31-L50.
Thus a skill learned 50% of the way through a basic discipline is
said to have a minimum skill level of 15 (.50 * 30). A skill
learned 25% into an advanced discipline would have a min skill level
of 35 (30 + 0.25-(50-30)).
Knowing how fast the skill is learned lets us set the max skill
level. For example is learning starts at 50%, and goes up 10% every
point of learning in the discipline, the skill is completely learned
by 60% learning in the discipline. Similar to the min skill level,
this percentage is used to calculate a level. Hence for our
example, a 50/10 skill would have a max level of either 18 (.6 * 30)
or 42 (30 + .6 * 20) depending on which type of discipline, basic or
advanced, it was in.
Min level and max level give us a useful target window for the skill
and we can basically use the user's actual level, bounded by these
two values, and plugged into the actual formula to calculate skill
damage. Hence, a skill like kick (3 round skill) might yield min
level of 1, max level of 10. A L5 kicker would achieve 3 dam (0.20
dam/lev/rnd * 3 rnd * 5th lev). Since the max level on the skill is
10, kicking would never result in more than 6 damage (0.20 * 3 *
10), hence warrior-types would be compelled to learn more exotic
attacks in order to maximize their skill damage potential.
========================
Skill Damage system quirks
The first tweak we wish to add to the system is to allow
"specialization" in skills. That is, if a skill is learned in a
basic disc, training in a certain advanced disc helps "complete the
knowledge" about the basic skill. Such training ought to slightly
increase the damage of basic skills, and we can accomplish this by
letting specialization raise the values for min and max skill level.
Secondly, we ought to tweak the overall system for PCs and NPCs.
Recall that only PCs get 1.75 dam/lev/rnd, while NPCs are achieving
0.9091 dam/lev/rnd. Since we said that skills hould be 20% of
melee, this means that an NPC using a skill ought to scale the
damage by a factor of 0.9091/1.75 (roughly 1/2). The consequence of
not doing so means that skill damage makes up a MUCH larger
component of a NPCs damage capacity then it does for PCs, and as a
consequence, PCs are forced into adopting tactics that minimize NPC
skill use (bash, etc).
Also, low chance skills ought to be more powerful. Why use a skill
that has low success otherwise? As such, it makes sense to use the
skill difficulty rates (above) as a divisor. Thus a skill that has
an 80% success rate when fully learned, ought to yield 1.25 (100/80)
the damage as calculated by the formula. Furthermore, since a hard
skill has less chance of critical successes, and more chance of
critical failures, it is a good idea to counter this fact by edging
up the damage even further based on the skill success rate.
Saving throws add an additional twist. For the most part, a saving
throw (against the same level attacker) is a 50/50 proposition that
results in half damage being taken. All things being equal, that
would yield 75% of the damage we would otherwise expect. Since we
do not wish the expected damage to be lowered, we need to raise our
expectations to account for this 75% factor. As a result, skills
with a save (as indicated) should do about 4/3 the damage otherwise
calculated. When done this way, terms cancel nicely.
On a final note, skill damage is part of the player's damage
capacity. Recall from the specialization argument, that we have
opted to add a scale factor in place so that overall PC vs NPC
damage is increased. Therefore, this scale factor has to be present
in the skill damage formula as well.
========================
Skill Damage as loss of hits:
A variety of skills, spells, and prayers result in lost hits in the
victim rather than directly damaging the victim. It would be useful
to establish a conversion factor so that we may fairly evaluate how
many attacks to remove.
First, a PC is inflicting roughly 1.25 dam/lev/rnd (1.05 + 0.20) for
both melee and skill combat combined. An NPC is inflicting .5454
dam/lev/rnd (0.9 * .6) for melee, and gets .104 dam/lev/rnd for
skills (0.20 reduced by NPC factor of .9090/1.75) for a total dam of
0.65 dam/lev/rnd.
Skill damage thus represents 16% (.20/1.25) of a PC's total damage.
This corresponds to .104 dam/lev/rnd (.65 * .16) loss in mobs to
balance.
Thus, a skill that lags a mob should cost the mob .104 dam/lev/rnd.
One option is to simply take away a mob's ability to do specials for
an equivalent amount of time. That is, a skill that takes 3 rounds
to perform for the PC could take away the NPC's ability to do its
own special attacks for 3 rounds.
While this seems like a silly option, remember that some classes
have shifted melee damage, or combat effectiveness, into skill
damage. For example, if a warrior were to lose 3 rounds of skill
attacks in order to remove a mage's ability to cast for 3 rounds,
this would be a highly effective trade off.
The second alternative is to remove a certain number of melee hits
from the NPC. Since a full round of damage results in 0.5454
dam/lev/rnd and we want to remove .104 dam/lev/rnd, this corresponds
to a loss of 19% of the attacks for a single round. That is, a
skill that takes a PC 3 rounds to perform could prevent the mob from
swinging for 0.57 rounds (lose roughly 1/2 the attacks for the
round).
In practice, such a reduction of attacks is virtually
unnoticable. The loss of 0.57 rounds worth of hits is rarely more
than 1 or 2 total hits, which in the spam of battle is VERY
difficult to perceive. Since we already realized the first
alternative was most effective verse high-skill-damage classes, it
seems to make sense to make this second alternative most effective
for low-skill-damage (high-melee-damage) classes. Arbitrarily, we
increase the round lossage from 19% of hits/rnd per round of skill
lag to 40-50% instead. Thus, a skill taking 3 rounds to perform
should remove 1.2 rounds of melee damage.
Obviously, a skill could result in some combination of the above.
The 3 round skill could be 0.60 rounds of lost melee hits and 1.5
rounds of skill lockout (1/2 of each).
Another useful number to determine would be how many rounds of both
skills and combat could be lost if both were to be equal.
Recognizing that we wish to remove .104 dam/rnd/lev and that a NPC
inflicts .65 dam/rnd/lev total (skills and melee), we easily realize
that a skill ought to remove 0.16 rounds worth of attacks (.104/.65)
for each round of the skill if both are to be balanced. Because we
inflated some of the above numbers, we may as well inflate some of
these numbers as well and simply call it 0.2233 dam/lev/rnd so that
that "3 round skill" removes a nice even 0.67 rounds worth of melee
hits and adds 0.67 rounds of combat lock out.
As a final note on all of this discussion, the tweaks we made to
skill damage (above) ought to also be reflected in these
discussions. Most notably, this ought to reflect the skill's
difficulty so that if a skill is tough to perform, the amount of
lockout or number of rounds it causes to be lost can be scaled
upwards. However, we need NOT account for any inflation in damage
(weapon specialization argument) since this inflation would
basically be on both sides of the equation (PC and NPC damage
equally inflated) and thus cancels out.
========================
Classes
With all the basic systems in place for a "typical" player, we can
now start contemplating alterations based on such things as class.
For the most part, our typical player has had an emphasis on melee
combat over skill damage, and probably easily viewed as a "warrior
type".
Other classes can be conceived that shift the factors around. For
instance, some classes may shift melee damage to skill damage to
achieve the same overall damage capacity, while other classes may
decide to suffer lower than average defense (more chance of being
hit in fair fight) in order to increase HP. Provided the rounds to
kill formula is maintained, factors are entirely adjustable.
========================
Hit rate and Armor (class)
Arbitrarily, we decided to settle on some relative base hit rates
for the classes in question. Taking a higher hit rate allows a
class to achieve more benefits in other systems later on, and we had
to start somewhere.
Because of the way our system works, a higher hit rate is equivalent
to saying they will have less armor, which is OK given the class's
image. Since we have defined a delta on the hit rate as 3% per
level (60%+/-3%), and have acknowledged that armor goes up about 25
points per level (500 points newbie, 2000 points at L60, linear), we
have a useful conversion factor between hit chance and AC penalty.
As a final comment, we should differentiate between armor hit rate
and effective hit rate. Some classes will utilize spells and skills
to augment their actual AC. If we presume these bonuses are used by
the player, we shouldn't ignore that fact when setting benefits
later on. armor hit rate is then the hit rate suffered if wearing
equipment alone, while effective is that rate achieved from
equipment plus skill useage.
Warrior:
effective rate of 60%
full benefit of armor
no skill use employed
mage:
effective rate of 69%
armor rate of 90%
armor penalty of 250 points of AC
spells can yield 175 points of AC
cleric:
effective rate of 69%
armor rate of 81%
armor penalty of 175 points of AC
spells can yield 100 points of AC
thief:
effective rate of 75%
armor penalty of 125 points of AC
deikhan:
effective rate of 60%
armor rate of 69%
armor penalty of 75 points of AC
spells can yield 75 points of AC
ranger:
effective rate of 60%
armor rate of 69%
armor penalty of 75 points of AC
spells can yield 75 points of AC
monk:
effective rate of 78%
armor rate of 90%
armor penalty of 250 points of AC
skills can yield 100 points of AC
This effectively means that the equipment a given non-warrior class
wears should be worse (AC-wise) than the armor for a warrior of the
same level. The overall intent is to insure that non-warriors lack
the proper amount of AC from their equipment. The method by which
this is achieved is arbitrary. Possibilities include:
1.) Rating equipment for the "level" of AC it provides, and
restricting a player of given class/level combo from wearing
overpowered stuff.
2.) Adjusting rental costs such that overall AC, class and level
are all taken into account.
It was found to be useful to phase the armor penalty in otherwise
newbies suffered a HUGE hit. The other benefit of this is that all
newbies can wear the same armor, although warriors are able to trade
out of it earlier. This has the consequence of making the skill
benefit phase in with level as well. The specifics of how these two
things are accomplished is arbitrary.
=======================
Hit points (class)
Another potential place a class may take a penalty is in the number
of HP it gains per level. This is another piece of the rounds to
kill formula, so is fair game. The values used here are arbitrary
(AXIOM).
The average HP gain by class:
mage : 5
cleric : 6
warrior: 8
thief : 6
deikhan: 6.5
ranger : 7
monk : 7.5
=======================
Damage capacity (class)
We now have enough information to fix the final aspect of the rounds
to kill formula into place. We are basically attempting to make
dam*hp/hitrate
a constant for all classes.
We have the values already for warrior. Damage capacity is 1.25
dam/lev/rnd. HP gain is 8 HP/lev, and hitrate is 60%. Ignoring the
units, this becomes
1.25 * 8 / .6 = 16.67
We can then reverse the process and solve for damage capacity for
other classes. Damage capacity is
16.8 * hitrate / HP
mage : 16.67 * .69 / 5 = 2.3
cleric : 16.67 * .69 / 6 = 1.9167
thief : 16.67 * .75 / 6 = 2.0833
deikhan: 16.67 * .60 / 6.5 = 1.5385
ranger : 16.67 * .60 / 7 = 1.4286
monk : 16.67 * .78 / 7.5 = 1.7333
We will assume that melee combat amounts to 1.05 dam/lev/rnd always.
Or said another way, we do NOT assume damage from melee combat is
lessened based on class.
However, we will assume that certain classes are "engaged" rather
than swinging full time. That is, certain classes will go a number
of rounds without being in melee, and we model this by discounting
the allotment of melee damage we assume they do. As a result, we
presume:
(arbitrary AXIOM)
warrior: 1.05 from melee
mage : 0.25 (melee only when mana runs out)
cleric : 0.25 (melee only when mana runs out)
thief : 1.05
deikhan: 0.90 (may engage from time to time)
ranger : 0.90 (may engage from time to time)
monk : 1.50
By subtracting from the total capacity, we get the dam/lev/rnd we
ought to get from skills alone to maintain balance.
warrior: 1.2500 - 1.05 = 0.200
mage : 2.3000 - 0.25 = 2.050
cleric : 1.9167 - 0.25 = 1.667
thief : 2.0833 - 1.05 = 1.033
deikhan: 1.5385 - 0.90 = 0.639
ranger : 1.4286 - 0.90 = 0.529
monk : 1.7333 - 1.50 = 0.233 Note different melee dam
A seemingly silly consequence occurs though. A skill that is shared
by multiple classes, like kick, will do a class-based amount of
damage. That is, a deikhan kick will do 3* the damage of a warrior
kick simply because that is what the system calls for. Reality
suffers at the hands of the gaming system once again.
========================
Monk melee combat
We arbitrarily have decided to conceive monk combat different from
the "typical" setup designed above. Specifically, monks should get
"obscene melee damage" from barehands with an increasing number of
hits as they go up in level. Historically, we have allowed monks to
hit as many as 5 times a round at L50 so this is a good target value
to shoot for.
The constraint we face is that we want monk damage to yield 1.50
dam/lev/rnd and to be made up of a certain number of hits per round
(level based) and a certain damage per hit (also level based).
Factoring in the base hit rate, this yields a potential damage of
2.5 (1.5 / .6) dam/lev/rnd.
I settled on making monk's number of hits follow a curve of
5/7 * sqrt(level)
shape in order to both make it level based, and yield the desired
value of 5 hits per round at L50.
This has the effect of making barehand damage follow the curve of
7/2 * sqrt(level)
in order to also make it level based and to yield the 2.5
dam/lev/rnd outcome we desire.
We make similar corrections to the above as we did for the typical
cases, letting high speed increase the number of hits, and letting
strength and dexterity play a roll in achieving extra damage
capacity.
Furthermore, we acknowledge the conclusion reached in the
specialization argument, and introduce the scaling factor that is
needed for PC vs NPC damage into the formula for barehand damage.
This ultimately doubles monk barehand damage.
Since we are really looking for skill-based damage and number of
attacks, we must migrate the formulas above to be related to skills
rather than level. This is fairly trivial as we have already made
arguments about how skill's learning tracks with level previously.
We model number of hits as tracking with the barehand proficieciency
and specialization skills. Essentially, barehand prof will yield
the equivalent of L30 for the number of hits curve. Barehand
specialization takes over for the L31-L50 portion of the curve.
Damage is slightly more complicated as we desire it to come entirely
from the kubo skill. We allow kubo (located in a basic discipline)
to cover them from L1-L30 on the barehand damage formula, and we use
kubo's specialized discipline (meditation) to cover the L31-L50
range.
====================
Subsystem: oomlat
We further need to recognize that monks need both hands free in
order to get their full number of attacks. Obviously, this prevents
them from carrying a shield. Lack of the shield translates into a
significant AC penalty.
We thus contrive a "skill" whose chief purpose is to give a monk the
AC benefit that would be awarded by carrying a shield.
As we have already noted, a shield represents 25% of the entire AC
for a suit of armor. If we make the skill yield 33% more AC than
what they really have on, this ought to bring them up to full
strength. (4/3 * 75% = 100%). Or, at the very least, we should
acknowledge that a 1/3 multiplier is the break-even point.
Since the skill is learned in a basic-discipline, but fairly slowly,
we should expect that a monk is really suffering a penalty for the
first 20-30 levels or slow while they slowly learn this skill. To
counter balance this, we ought to make a fully learned monk have a
slight advantage, so we should set the multiplier to, arbitrarily,
2/5 for maxed skill learnedness. Assuming a linear function, with
2/5 as the multiplier at 100% learning, we obtain the breakeven
point of 1/3 at 83% learning (1/3 / 2/5 * 100%).
As a final note, since monks are receiving this AC from a skill
rather than the shield, we will need to make allowances for this
fact later in the economic considerations.
====================
Subsystem: blur
The concept of monks also conceived of letting them occasionally get
double their normal number of attacks based on learning in the blur
skill. Since the skill is part of an advanced specialization, this
is only a relavant factor in the L31-L50 range.
We will arbitrarily settle on blur occuring 5% of the time. This is
effectively saying that 5% of the time, they will get double the
attacks, or 5% of the time, they get 100% more (double the) damage,
or, they get 5% more damage from blur.
In order to balance this, we need to lower either their base damage
rate or their number of attacks slightly to maintain the rate of
killing formula. We are technically free to do either one, but
since we only want this to apply in the L31-L50 range, I opted to
make the penalty apply to kubo-specialization's effect on damage.
Recall that this has a formula of 7/2 * sqrt(level). We are trying
to counter a 5% bonus, so we want our penalty to be 1/1.05 =
(roughly) 95.24%. Solving for level, this yields that we want a
value for level that is 90.703% (.9524 * .9524).
We could choose to apply this .907 factor to all calculations
regarding level in the above formula, however, this would be VERY
nasty since blur doesn't kick in until the advanced specializations
(L31+ roughly). So, we add an extra degree of complexity, and try
to find a multiplier for kubo specialization alone that roughly
approximates the above .907 factor.
At L50, we want to be conceiving ourselves as really L45.35 (50 *
.907). Since barehand proficiency amounts to 30 levels, this means
that barehand spec should be at most, 15.35 levels (rather than 20).
Therefore, the effects of barehand spec should be multiplied by
76.76% (15.35 / 20) to achieve our desired goals.
It should be noted that this process yields learning-dependant
numbers. For example, specialization of 50% (L40 formerly)
translates to L36.28 desired (40 * .907) or a multiplier of 62.8%
rather than 76.76%. Specialization of 25% (L35) ultimately yields a
multiplier of only 34.9%. We will ignore this fact, and use the
highest (76.76%) multiplier.
So bottom line we yield a 5% chance of doubling the number of
attacks, but cut the effect of kubo-specialization by 23.24% to
counter it.
As a final step, blur should probably be tweaked so that it occurs
based on learning. Max blur should yield the 5% rate we devised,
but blur will occur less often based on the actual learning. Seeing
that we acknowledged above that lower learnings ought to get lower
multipliers, but decided to ignore that fact and give higher dam
than the formulas suggest instead. By lessening the chance of blur
occuring in this manner for such situations, harmony is restored for
the most part.
=================
Econ 101:
Many of the elements we introduce for the gaming system are actually
controlled by elements of the economy. It is important to realize
that unless the economy works correctly, these controls can not be
expected to have the correct results. That is to say, if we use
rent as a means to limit equipment (AC, etc), this will only work if
rent is balanced the way we expect it to be.
The most obvious aspects of the economy is the talen market.
Knowing the relative rate of gain and loss for players is vital to
understanding what they are able to afford, and in turn, the
boundaries of their economic capability.
To that end, we should collect data on what is happening
macroscopically in the market. Isolating what elements of the
economy exist (rent, repair, hospital, income, gambling, transfers,
shops, commodities, etc) is the first step, followed by figuring out
how much money is spent in each of those areas is the second.
>From there, we should be able to progress to establishing desired
target goals for the economy (how fast do we want players to
accumulate wealth, what percentage of a person's expense should be
spent on item repair, etc). This in turn leads us to the
development of feedback loops by which we can gear the overall
economy toward our desired goals, and to make things self
correcting.
What is important here is that the data collected be averaged over
all players and over a significant enough period of time. We do not
want to have a system based on one overly-greedy (or thrifty)
player, nor do we want to have the effect of changes be very
noticible.
However, we should avoid making too many class-specific or
level-specific modifications. We do not wish to have players
performing certain events based on class or level based criteria in
general. For example, if a newbie received a better price when
selling an item to a shop, this would encourage the creation of
shopping-characters which would be counter productive.
========
Economy: overall:
One of the largest problems facing most muds is their overall
economy.
Provide too little wealth, and players are forced to cut corners and
to constantly be on gold-runs to the detriment of pasttimes like
exploration and experimentation. In the short run, players will
look for lucrative areas that allow them the greatest reward in
order to maximize their wealth.
On the other hand, provide too much gold and the economy goes into
rapid inflation. If there is too much gold chasing too few
products, the price goes up. The consequence is typically the
promotion of an "auction" environment where all items (of reasonable
quality) are sold at auction to other players rather than utilizing
the on-line shops. While auctions in itself are not bad, recognize
that it is an indication that item's true value is not accurately
predicted by the gaming system, and that assumptions made about the
economy are probably flawed.
Clearly, some middle ground is desired, and it probably better to
err slightly in the favor of a overly generous economy than an
overly restrictive one. As we have devised a way to track overall
gold accumulation, we simply need to pick an arbitrary target value
for "inflation". I chose 5% for no particular reason (AXIOM).
We can then watch the overall talen flow. Use basic accounting
mechanisms to evaluate whether the net flow is positive or negative.
Recognize that the largest element of this setup is probably the
"income" portion which is made up of talens looted directly from
corpses. By introducing a scale factor to the number of talens a
mob will generate, we can adjust the income, and in turn, control
the overall economy. It is then a reasonably easy exercise to cause
self-correction by having the gaming system periodically evaluate
the net flow and increase or decrease the scale factor automatically
as it crosses various thresholds.
===============
Economy: Shops:
Shops are probably one of the larger aspects of any mud's
economy. Furthermore, while most elements of an economy are either
strictly sources of income, or drains to take money out of the
system, shops do both. Player's will sell excess booty to raise
money, and buy necessities for continued adventuring as well.
>From a realistic standpoint, shops exist to make money, thus the
overall flow ought to be in the favor of the shopkeeper.
These two facts together lead to the conclusion that shops ought to
be making a slight profit, i.e., they ought to serve as a slight
economic drain.
The creators of DIKU went a long way to setting this event up for us
by adding the need for shop-items that are one-way only (e.g. food)
in that they are bought more often then they are sold.
Additionally, they added the concept of profit ratios to the shop
files to insure that a transaction would favor the shops (buying and
selling the same item leads to gain in money for the shop).
However, this is not quite enough.
Realizing that money flows in and out of shops fairly freely, and
that we want shops to making a slight amount of money, we can
introduce yet another scale factor to accomplish this. It is
simplest to place this scale factor on the buying side of the
equation so that the price a shop pays a PC when it buys a good from
the PC (PC sells) is scaled by it. In the same way we auto-correct
the overall income factor, we can do the same for the shop factor.
This has the effect of keeping the selling price a shop has for an
item constant, but tweaks what they are willing to pay to buy it
from a player based on the overall trend in the economy.
===================
Rent Credit:
As we have already factored the amount of AC a PC may have into the
balance equations, some mechanism for ensuring that PCs follow the
system we have devised needs to be put into place. While the
end-goal is simply to insure that AC can be reasonably predicted as
a function of level, the specific mechanism to accomplish this is at
the game designer's discretion. While charging rent for equipment
is somewhat unpalatable, it remains one of the simplest ways to
achieve this goal.
What we must do then, is to set the economy up such that it
encourages the selection of equipment with properties that we
expect. The "rent" concept as presented in original DIKU simply had
items become increasingly expensive as they got better in quality.
This is a worthwhile concept to keep, but it also means that higher
level players need to gain massive amounts of gold to meet their
daily costs. The first downside of such a system is that it forces
massive quantities of gold to be made available (which tends to be
somewhat destabilizing to the economy), and furthermore, short of
going entirely naked, a player must acquire enough money each and
every day to meet this demand.
How much better would it be if we simply established a "credit"
system that allowed the "appropriate gear" to be rented for free. A
player could acquire gear better than their level of course, but
would be forced to pay for the privledge by shelling out the
difference for what they own compared to what we would want them to
own. This has the effect of setting up a system where we do not
expect rental costs to be charged, except for players that have
opted to acquire and use gear above and beyond their level.
However, it places onto the game designer the requirement that the
rent credit be established such that the price of "appropriate gear"
be fully accounted for.
===============
Armor Costs:
The single largest component of a player's equipment costs is most
likely their armor. Our system has made assumptions about AC versus
level which we have already established as being
armor = 500 + 25 * level
so this is the first thing that needs to be addressed.
We ought first to distribute these points of armor around to the
various body locations so that each piece of equipment provided a
small portion of the total AC. Arbitrarily, the following was
settled upon:
head: 7% wrist(x2): 2%
neck: 4% hands(x2): 3%
body: 15% finger(x2): 1%
back: 7% legs(x2): 5%
waiste: 8% feet(x2): 2%
arms(x2): 4% shield: 25%
These numbers were largely established based on where we felt
"durable armor" could most likely be found. It's obviously weighted
more heavily toward the torso and head region.
Furthermore, our combat system has defined how often certain body
slots get "targetted" with blows. That is, what percentage of all
blows land on a given body slot. Those percentages are:
head: 7% wrist(x2): 3%
neck: 4% hands(x2): 3%
body: 26% finger(x2): 1%
back: 10% legs(x2): 3%
waiste: 5% feet(x2): 2%
arms(x2): 5% hold(x2): 7%
It should be noted that both "hold" slots are fair targets for being
hit by an opponent. These values are obviously more heavily
weighted toward the body locations that would do the most damage
(slots where a hit takes off HP rather than limb health).
A "paired" item, like pants, would have the AC benefit of both leg
slots (10%) and would suffer a hit any time either leg was hit (6%
rate).
An item has a random chance of damaging each time it is hit, and
ideally, a "suit of armor" (where all the pieces are geared for the
same level) ought to damage at roughly the same rate so that repair
can be synchronized. This effectively means that for a given suit
of armor, the structure points are in the same ratio as the chance
of the slots being hit. For simplicity, I will talk about structure
as being the structure of the "body slot" where the structure of
other slots is merely
body_slot_struct * sqrt (slot percent / body slot percent)
That is, if the body armor has struct 30, the glove ought to have
struct of
30 * sqrt(.03/.26) = 10.19.
Since we want PCs to consider both how much AC it provides, as well
as how much damage it needs as factors, we must account for both the
AC and the struct in the overall price of a piece of equipment.
Arbitrarily, let's now settle that structure ought to follow the
trend of
struct_body_piece = 30 + 1.1 * level
Since we know we would like players to overall have (500 + 25*level)
points of armor, have struct of (30 + 1.1*level) for the body piece,
and we know how to both distribute the AC and struct to other pieces
now, for a given piece of equipment, we are able to calculate the
"AC-level" and the "structure-level" for a given piece of equipment.
That is, given a piece of equipment worn on a specific slot, the AC
of that piece translates into it being of level "AC-level" while the
structure it possesses would make it appropriate for
"structure-level" gear.
Next, establish the overall "armor level" as some weighted average
of "AC level" and "structure level". Since in our combat system, AC
is VERY important, I chose to make the "armor level" be 3 parts "AC
level" to 1 part "structure level".
Again arbitrarily, we devise some reasonable algorhythm for how we
would like items to be priced. Realize that this formula will
determine the scope of the overall economy (how valuable is a single
gold piece, is 1 million coins a lot or a little at high level), so
use a little common sense. For us, we chose to plot level to price
via
price = level * max(level, 20) * 150
This price is spread over all the pieces, so that the above formula is the
price of an entire suit of armor at that level.
As an example, a suit of L10 armor will sell for 30000 (10 * 20 *
150). Of that 30K, 7.5K is due to the structure (1 part), and 22.5K
is due to the armor (3 parts). The 7.5K structure price is spread
to the various pieces based on the chance each slot has of being
hit. The 22.5K armor price is spread based on how much armor each
slot provides. The body slot for example has a 26% chance of being
hit and gives 15% of the AC. Thus, it ought to cost .26*7.5 +
.15*22.5 = 5325 coins.
=====================
Weapon Pricing
Because a player may dual wield, they have the option of using
either a weapon and a shield, or two weapons. Since we have made
arguments previously that the effect of the two is roughly the same,
we should weight the two choices economically about the same. That
is, the price of a weapon at a given level ought to be the same as
the price of the shield at a given level.
Shields provide 25% of the AC, and are hit 7% of the time. For a
given suit, the shield represents 20.5% ((.07*1 + .25*3)/4) of the
price of the suit. Since we have a formula for the price of armor,
we use the same one for the price of weapons.
weapon price = level * max(level, 20) * 150 * .205
weapon price = level * max(level, 20) * 30.75
We have established how much damage a character should inflict per
hit per level, so we simply need to reverse this and derive a
"damage level" or the level as generated by the amount of damage a
weapon does.
A "structure level" can also be created. At this point, we can
fairly arbitrarily plot weapon structure to level as
structure = 10 * level*1.5
Since we want struct to scale up to about 100 around L60, this works
OK.
A "sharpness level" should also be created. Treat "sharpness" as a
generic term for "quality" where a sharper sword is better, but a
sharper hammer is also better.
sharpness = 10 * level*1.5
This formula was established as we also want quality to go up to
about 100 near L60 or so.
The worth of a weapon is basically how much damage it does, how
often I have to fix it, and how often I need to "sharpen" in.
Arbitrarily, I weight these as 6 parts damage, 3 parts repair, and 1
part sharpening. This permits me to turn the component levels
(damage, sharpness, structure) into an overall level, and plug that
level into the price formula.
===================
Pricing: weapons (2-handed)
Recall that when setting up the dual-wielding system, we adjusted
damage for the off hand. Since another alternative would be to use
a single 2H weapon, we will need to determine where 2H weapons
equate to a 1H variety.
Damage of the off-hand weapon is essentially 10% that of the primary
weapon, unless the dual-wield skill comes into play. This value was
set such that using 2 weapons would be discouraged without the
appropriate skill highly learned.
Naively, we will move forward on the basis of letting a 2H weapon
inflict this extra 10% damage. Thus, the damageLevel formula needs
to add a 1.1 factor in for 2H weapons.
It should be noted that this system doesn't work perfectly because
of other quirks in the system. For example, weapon specialization
adds another full attack with the primary hand. If using a 2H
weapon, a specialized person would get 2.0 attacks with a 1.1 damage
weapon for 2.2 total damage. If dual wielding, it would be 2.0
primary attacks at 1.0 damage, and 1.0 secondary attacks at 0.1
damage, for a total of 2.1 damage. The 2H weapon is slightly better
than wielding 2 1H weapons in the specialized case. However, since
the 10% figure was put in to encourage shield use over dual wielding
without the skill, the above example just shows that a specialized
person merely suffers less of a penalty (but still definitely a
penalty) when opting for a 2H weapon over shield-use.
Other factors like berserking or speed-adjustments effectively
cancel out and a 2H weapon vs 2 1H weapons are equivalent.
Specialization plus these other factors also has some skewing toward
the 2H weapon, but the effects are not better than specialization
alone.
We can generalize here and say that a change that gives a bonus to
one hand stronger than the other will skew the results of 1 2H
weapon vs 2 1H weapons. Things that favor the primary hand will
encourage a 2H weapon to be used, while if the secondary hand is
favored, then individual 1H weapons will be better. However, this
boost in power is not enough to overcome the penalty imposed during
the dual-wielding system development, thus constructing 2H weapons
in this manner does not alter the balance being striven for.
========================
Pricing: +tohit
It would be useful to know what the relative value of +tohit (thaco)
is. This ought to be possilbe as we have already calculated the
economic value for AC, and we ought to be able to make some
conversions between the two concepts.
We have previously recognized that 25 points of AC represents 1
"level" worth of gear. Our combat formulas have established that
each +1 tohit is the equivalent of fighting at the level of a
creature +1 levels over my own. Thus, adding +1 tohit is the same
as if my victim lost 25 points of armor.
The overall price of a suit of equipment is given by:
price = level * max(level, 20) * 150
Of this, AC represents 3 parts of a total of 4.
AC price = level * max(level, 20) * 150 * 3/4
Since +1 thaco is the same as dropping level by 1, the price of this
thaco benefit ought to be
thaco price = level * max(level, 20) * 450 / 4 -
(level-1) * max( level-1, 20) * 450/4
We should regard "level" in these equations as the item's level, so
that a sword we think is L20 has a consistent price for the magical
thaco regardless of the level of the user of the weapon.
To give some idea of numbers:
L50 item: +1 thaco = 11137.5 talens
L40 item: +1 thaco = 8887.5 talens
L30 item: +1 thaco = 6637.5 talens
L25 item: +1 thaco = 5512.5 talens
L22 item: +1 thaco = 4837.5 talens
L21 item: +1 thaco = 4612.5 talens
L20 item: +1 thaco = 2250 talens
L15 item: +1 thaco = 2250 talens
L10 item: +1 thaco = 2250 talens
L5 item: +1 thaco = 2250 talens
========================
Economy: NPC wealth
Since we are making the assumption that mages will be casting
essentially full time, we must make appropriate allowance for their
use of components.
First, it is useful to establish how much money a given NPC will
have. This should in someway be related to the pricing formulas we
established for equipment. That is, since we have stated that
appropriate equipment pricing follows:
level * max(20, level) * 150
We can set the wealth a given NPC carries as:
level * level * 1.5
We should note two qualities of this formula. First, it follows the
same overall trend (lev^2) as the equipment pricing making it scale
nicely. This is a feature that should be maintained for all
economic concerns or what will happen is that at certain levels, it
is easier (harder) to do some things than others. For example, if
pricing follows a X^2 curve, but NPC wealth were to follow a linear
(X^1) curve, this would mean it would be easier to obtain the wealth
at low level than at high level. Conversely, an X^3 shape makes
high level easier than low level. All in all, they ought to have
the same shape.
Secondly, the wealth formula is MUCH smaller than the equipment
pricing formula. Recall that we have already given out credit
appropriate for a player's level, and we have set the economy up so
that it tries to drain almost all of the money it adds to the
economy. What we are able to infer is that we do not want excess
cash in the economy, nor do we want players using excessively
high-powered gear. By making the price of gear to be fairly
expensive in comparison to what a typical player needs to rent a
full suit of gear, we limit the ability of players to exceed the
desired goals.
========================
Pricing: components
In the skills-damage system, we have established that we wish mages
to be able to cast full time. Thus, it is essential that we make
appropriate allowances to do so.
We have established that the typical fights will last roughly 14.75
rounds, but we made a correction (of 0.75) to global-damage to make
it take the duration we wished. This translates to the average
fight lasting 19.66 (14.75 / 0.75) rounds. For simplicity, let's
call it 20.
Obviously, mages also need to cast a few defensive spells prior to
combat, and having some extra capacity for casting utility spells
ought to be built in as well. Let's be slightly generous, and
simply say that a mage needs to cast about 50 rounds of spells per
fight. In truth, I do not expect that a mage would truly be casting
50 rounds worth of spells per fight, but it does need to be padded
adequately that a mage does not use up all the wealth they gain from
fighting on paying for components.
Since we will assume that a player is casting spells of their own
level against mobs of their own level (high level mages cast high
level offensive spells against high level mobs), we can roughly
assume that the level of the spell being cast and essentially equate
all the various levels involved.
Since we have established a mob's wealth as 1.5 * L^2, we can
combine the formulas to obtain
component cost per round of casting = 1.5 * L^2 / 50
= 0.03 * L^2
Thus, if a spell is thought to be 10th level and takes 3 rounds to
cast, it ought to have a cost of 9 (.03 * 10^2 * 3) per cast. Since
components typically permit multiple casts via numerous charges,
remember to take charges into account.
We can use the level determiner that was apllied in the skills
formula for determining the "level" of a spell. This will make sure
that a simple spell like globe will be determined as a L5 (or so)
spell, even if cast by a high level mage.
Lastly, since casting is expected, let's factor in an allowance for
the cost of components into a mage's rent credit. A mage will need
a great deal of components to get ahead and it is not realistic to
think that a mage will not carry a large quantity of "excess"
components. Arbitrarily, assume that a mage will need about 20
kills worth of excess components, and remember that rent cost is 50%
of the price, thus
rent credit = 20 kills * (1.5 * L^2 gold/kill) * 50% rent
= 15 * L^2
This seems adequate, and it should also be noted that this allotment
roughly makes up for the rent credit penalty that is built in for
desiring lower AC/struct on mage's equipment. This should not be
viewed as something that was desired, but simply something that
happened based on decisions made.
========================
Symbol Stress:
In a similar fashion to how mages use components, clerics are
required to possess holy symbols. For the most part, this is merely
for flavor, but we should not dismiss the economic constraints this
allows us to introduce to a class that is in all likelihood never
tanks and is widely viewed as merely a support class.
Let's first conceptualize a concept of "stress" that represents how
powerful a given prayer is. This stress is applied to the symbol
such that each invokation consumes a small piece of the symbol, and
ultimately burns up the symbol requiring the cleric to replace it.
A symbol should be rated for the amount of total stress it can go
through before bursting, and its price ought to be based on this
rating. Given this relationship exists, this means that stress
ought to follow the curve that we gave to NPC wealth and go up as
level * level. If price were to be a simple linear function of
max-strength, then there would be an incentive to use many, small
symbols rather than a single large one.
For simplicity, let's establish that a single round of casting of a
prayer of given "level" costs "level * level" strength. Thus, a
3-round prayer will burn 3*level*level strength.
prayer stress = rounds_to_cast * level * level
Similar to the mage arguments made, let's assume a given fight
requires a total of 50 rounds of casting for the cleric and
furthermore, let's design symbols as lasting about 10 fights before
bursting. This says
total symbol stress = 500 * level * level
Obviously, this translates into symbols possessing anywhere from 500
total strength at L1, to 1.8 million for a L60 symbol. Quite a
spread, but realize this has the effect that any spell, no matter
how small, will drain a small amount from a symbol, while large
spells will totally overwhelm the power of a weak symbol.
========================
Pricing: symbols
Since a single fight provides 1.5 * lev^2 wealth and a symbol lasts
for 10 fights, a symbol ought to cost:
symbol price = 15 * level * level
Combining formulas, we can now establish symbol price based on the
total strength of the symbol.
symbol price = 15 * total symbol stress / 500
= 0.03 * total symbol stress
Since attuning the symbol is also a factor, we must split this price
between the actual cost of the symbol, and the cost of attuning.
For historical reasons, this has been a 50/50 split. Thus the
actual price of a symbol ought to be:
= 0.015 * total symbol stress
And attuning cost an aditional:
= 0.015 * total symbol stress
========================
Rent Credit: symbols
As we want PC clerics to be casting, we need to allot them some rent
credit to cover their symbol. Unlike mages, clerics do not need to
carry a large number of symbols. The idea is not to have them
carrying small symbols to cast small prayers, but to use a single
symbol for all their praying and let the code handle how much is
burned up with each invokation. However, a cleric without a symbol
is worthless, so give them at least enough allowance that they can
obtain a backup symbol as the one they are using gets low on
strength. Thus, let's grant credit for 1.5 symbols which translates
into:
rent credit = 1.5 symbols * (7.5 * level * level gold/symbol) * 50% for rent
= 5.625 * level * level
Since we gave them credit for 1.5 symbols, and each symbol is good
for 10 fights, then a cleric ought to be able to go 15 fights
between buying symbols. Recall that we were very generous in the
number of rounds of praying per fight (50) and if a cleric was more
economical in prayers/fight, this could easily be stretched out
better. Thus, establishing 15 as the number of fights between
buying symbols, we should regard this as a worst-case scenario and
probably expect that it would truthfully be 20-25 in practice.
========================
Pricing: holy water
An additional wrinkle is that clerics can attune their own symbol.
Attuning the symbol themself ought to be slightly cheaper than
paying for attuning, so we set the price of attuning in this manner
at 67% the cost of paying for attuning. That is:
self-attuning cost = 0.010 * total symbol stress
Self attuning is done by applying a certain amount of holy water to
the symbol during the task. Obviously, a larger symbol should take
more water, so we should attempt to obtain a per-ounce-holy-water
cost that yields the above self-attuning cost. As an additional
consideration, each pulse uses a single ounce of holy water, so we
need to make attuning go reasonably quickly.
The symbol stress formula was given as:
symbol stress = 500 * level * level = 500 * L^2
symbol price = 0.015 * stress = 7.5 * L^2
self-attuning cost = 0.01 * 500 * L^2 = 5 * L^2
If we set the number of ounces of holy water needed based on the
symbol price, we can do something like:
number of ounces needed = .01 * symbol price
= 0.075 * L^2
Dividing the self-attuning cost by the number of ounces needed
yields
cost per ounce = 5 * L^2 / 0.075 * L^2 = 66.67
========================
Economy: Repair
With the economy as devised above, we expect that rent essentially
drains nothing from the economy (if it does, then folks are using
more powerful gear than we intended). This leaves hospital, repair
and shops as the chief means of pulling money out of the economy.
Since we previously noted that shops add to, as well as drain from
the economy, and that overall shops drain "slightly" more than they
add, this leaves repair and hospital. Almost everything a hospital
can do, a cleric can do as well, so we ought to have repair be the
vast majority of the economic drain in our system.
However, realistically, we can not have the cost of repair for a
single item fluxuate. Why would it cost 100 gold to repair a given
item one time, and 200 the next? In the real world we would call
that getting ripped off, and that wouldn't be exactly the sort of
realism we would want in our system. However, what we can do is
adjust the rate at which damage occurs, and thus the frequency with
which damage needs to be repaired. Thus, to drain more money from
the economy via repair, increase the damage rate, and vice-versa.
The upshot of this is that we insert the effect of the global
modifier for repair on the economy into the item damage rate.
Since NPC wealth essentially goes up as level^2, and the money
gained by killing NPCs is the chief source of money for PCs, we can
deduce that players will gain money roughly as level^2. Since we
want the amount spent on repair as a percentage of the entire
expenses a player is forced to pay to be relatively constant, this
means that the expense for repairs should also increase as level^2.
As we have constructed a given piece of equipment's price based
largely on the rent credit formula, an item's value roughly
increases as level^2 as well.
Combining all this knowledge, we conclude that items need to damage
at roughly the same rate over all levels. That is to say, if a L10
PC in L10 gear fights a L10 mob, their equipment should (percentage
wise) be just as banged up as if a L40 PC in L40 gear had fought a
L40 mob.
>From a strictly realistic point of view, item damage ought to be
determined by a combination of how hard the given hit is, how sharp
(or well targetted) the hit is, how well built the item being hit
is, and how susceptible the material of the item being hit is to the
given style of attack. That is, damage, weapon quality, item
structure and susceptibility.
Damage inflicted increases linearly with level. Potentially, it
could be as much as .9090 dam/lev/rnd, but with the hit rate
reducing the number of blows that land, some damage being absorbed
by the armor, and creatures hitting multiple times in a round, we
should probably assume damage to be about 0.25 dam/lev/hit.
Weapon quality, also known as sharpness, has also been set up to
increase linarly with level. Since we are essentially worried about
NPCs hitting PCs in this discussion, we should also note that NPCs
chiefly hit bare-handed and that they use fairly well known attack
types. For the bare-hand case, "quality" of a given attack type is
a known, fixed value that is not level dependant. A L10 mob that
smashes has the same quality as a L50 mob that smashes.
Item structure increases linearly with level.
Susceptability however, is presently a flat rate. That is to say,
the chance of "leather" being damaged by "a cut" is a fixed value.
This rate doesn't change regardless if its soft-leather vs a
training-sword, or power-leather vs a dragon's claw.
The upshot here is that quality (for the NPC vs PC case) and
susceptability are not level dependant. We can tie these two
factors together, and factor in the economy tweak to yield a flat
rate "does it get damaged" chance. Provided that the chance (sans
global tweak) is fairly high, the global tweaker should adjust to
make it so that this rate fits into the desired economy properly.
Since damage and structure both increase with level, and we want the
repair rate to be constant over all levels, we should have damage
determine how many points of structure are removed each time the
item damages.
Finally, we let the "max repair cost" (repairing an item from 0 to
max) be based on the items true cost (some fraction thereof). As
noted, this makes it follow the desired L^2 formula.
--<cut>--
--
J C Lawrence claw at kanga.nu
---------(*) http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
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