[MUD-Dev] Combat systems
kylotan at kylotan.eidosnet.co.uk
Sat Dec 11 16:51:19 New Zealand Daylight Time 1999
From: Neil Edwards <neiled at clara.net>
Sent: Saturday, December 11, 1999 11:18 AM
> At the moment my to-hit formula uses the profiency of the weapon
> (which can be an infintite number) the dexterity (max of 20) of the
> attacker and the health of the attacker (to add some fatigue factor)
> This gives a percentage chance of the player actually hitting the
> victim. As you can see if you graph it with proficiency the variable
> that at first there is a big gradient and then after about prof level 50
> there is a relatively small increase as each level is reached. I
> wanted this because I think it will give new players a chance.
After proficiency passes 4 or 5, an increase of 1 pt in proficiency is less
profitable than an increase of 1 pt in dexterity. You say proficiency is
technically unlimited, but what kind of range of values, and mean value, do
you expect to see here? How quickly would a player reach that point where it
would be better for them to gain a point of dexterity than to increase their
proficiency? If dexterity points are easier to increase than proficiency
points, there will be little point in a player increasing proficiency much
past 4 or 5 until their dexterity is maxed out. After all, increasing
dexterity would bring a much quicker and more obvious reward. However, if
proficiency points are easier to come by than dexterity, or if dexterity is
impossible/very difficult to increase, then the players with low dexterity
(determined in character creation, I'd assume?) have a massive disadvantage
from the start. The fact that proficiency increases swiftly will not help
those with 8 dexterity, who hit half as often as an equivalent player of 16
dexterity. The same question therefore goes for dexterity - what kind of
range and mean values do you expect here? Too much variance in dexterity
will lead to an imbalance, making proficiency almost irrelevant in 90% of
Maybe this is what you want :) I don't know.
Regarding the health/constitution thing - I assume this would be equivalent
to (current hit points / maximum hit points) in an AD&D type system? I use
something similar, but I use (1 - sqr(current/maximum)) so that the effects
are not pronounced until the character has started taking serious wounding.
This is to try and ensure that, at least early on in most battles, the skill
of the combatants is the main factor, rather than current health.
> My defensive formula uses the defensive proficieny of the defender,
> the dexterity of the defender the armour class of the defender, the
> health of the defender and also the percentage hit chance of the
> attacker. This allows for lucky blows by an attacker to be knocked
> away with someone of a much higer defensive skill.
> (health/constituition)(.5)) / (tohit%)
My comments on the ratio of proficiency importance to dexterity importance,
and the health issue also apply here, obviously.
> My damage formula is pretty poor (not that the others are any
> good) and uses the strengths of the attacker and defender and the
> armour class of the defender
> (attacker - defender)*((100-armourClass)/100)
> and gives a hp value to be removed from the defender.
One problem with using the original attack and defence scores in the final
damage calculations is that it emphasises the imbalance between the 2
combatants. In a battle where 1 is better than the other, not only will that
more skilful character be hitting more often, but they'll be hitting harder
too. Obviously a degree of this is realistic - but too much of this, and it
can make things harder to balance. For instance, changing part of your
attack formula will now have implications on the damage dealt. Fixing one
problem in the system may now break another. Therefore, you -may- want to
remove the (attacker-defender) variable from your damage formula for now, at
least until you finalise the attack and defence formulae - then when that is
done, if you still feel your damage formula needs to be influenced by
relative skill, add it back in and tweak it to suit.
> I really sent them in so that people will pick them to pieces and
> allow me to make better ones. I think this is the stage to do it
> rather then after I implement it in the mud. So please send in any
> comments, they'll be much appreciated.
No problem. But: it's been a while since I did much in the way of
mathematics, so maybe some of the more educated people on this list will be
able to go into more detail, or point out any mistakes I made :)
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev