# [MUD-Dev] Damage and Stuff (Math and Code)

Ben Chambers bjchamb at bellsouth.net
Sun Jun 1 14:43:17 New Zealand Standard Time 2003

```Does this idea sound plausible?

The damage of weapons are specified by giving the mean and the
standard deviation.  The skills and other aspects of the character
can modify these. For example, if a player is more skilled and
dealing damaging blows, it would increase the mean.  If he can do
more damage, but it is riskier the mean and standard deviation are
increased.  If he is being really careful aiming accurately, his
standard deviation may be decreased but the mean may change as well.
An example of the standard deviation code is presented below (it is
written in C++ for testing purposes, but I would translate it into
LPC for use in a MUD):

double l[310] = {
.5000, .5040, .5080, .5120, .5160, .5199, .5239, .5279, .5319, .5359,
.5398, .5438, .5478, .5517, .5557, .5596, .5636, .5675, .5714, .5753,
.5793, .5832, .5871, .5910, .5948, .5987, .6026, .6064, .6103, .6141,
.6179, .6217, .6255, .6293, .6331, .6368, .6406, .6443, .6480, .6517,
.6554, .6591, .6628, .6664, .6700, .6736, .6772, .6808, .6844, .6879,
.6915, .6950, .6985, .7019, .7054, .7088, .7123, .7157, .7190, .7224,
.7257, .7291, .7324, .7357, .7389, .7422, .7454, .7486, .7517, .7549,
.7580, .7611, .7642, .7673, .7704, .7734, .7764, .7794, .7823, .7852,
.7881, .7910, .7939, .7967, .7995, .8023, .8051, .8078, .8106, .8133,
.8159, .8186, .8212, .8238, .8264, .8289, .8315, .8340, .8365, .8389,
.8413, .8438, .8461, .8485, .8508, .8531, .8554, .8577, .8599, .8621,
.8643, .8665, .8686, .8708, .8729, .8749, .8770, .8790, .8810, .8830,
.8849, .8869, .8888, .8907, .8925, .8944, .8962, .8980, .8997, .9015,
.9032, .9049, .9066, .9082, .9099, .9115, .9131, .9147, .9162, .9177,
.9192, .9207, .9222, .9236, .9251, .9265, .9279, .9292, .9306, .9319,
.9332, .9345, .9357, .9370, .9382, .8394, .9406, .9418, .9429, .9441,
.9452, .9463, .9474, .9484, .9495, .9505, .9515, .9525, .9535, .9545,
.9554, .9534, .9573, .9582, .9591, .9599, .9608, .9616, .9625, .9633,
.9641, .9649, .9656, .9664, .9671, .9678, .9686, .9693, .9699, .9706,
.9713, .9719, .9726, .9732, .9738, .9744, .9750, .9756, .9761, .9767,
.9772, .9778, .9783, .9788, .9793, .9798, .9803, .9808, .9812, .9817,
.9821, .9826, .9830, .9834, .9838, .9842, .9846, .9850, .9854, .9857,
.9861, .9864, .9868, .9871, .9875, .9878, .9881, .9884, .9887, .9890,
.9893, .9896, .9898, .9901, .9904, .9906, .9909, .9911, .9913, .9916,
.9918, .9920, .9922, .9925, .9927, .9929, .9931, .9932, .9934, .9936,
.9938, .9940, .9941, .9943, .9945, .9946, .9948, .9949, .9951, .9952,
.9953, .9955, .9956, .9957, .9959, .9960, .9961, .9962, .9963, .9964,
.9965, .9966, .9967, .9968, .9969, .9970, .9971, .9972, .9973, .9974,
.9974, .9975, .9976, .9977, .9977, .9978, .9979, .9979, .9980, .9981,
.9981, .9982, .9982, .9983, .9984, .9984, .9985, .9985, .9986, .9986,
.9987, .9987, .9987, .9988, .9988, .9989, .9989, .9989, .9990, .9990 };

int lookup(double x);

double invNorm(double x)
{
if (x < .5) return -invNorm(1 - x);
int n;
n = lookup(x);
return ((double)((int)(n / 10)) / 10) + ((double)(n % 10) / 100);
}

int lookup(double x)
{
int a, b, c;
a = 0;
c = 309;
while (c - a > 1) {
b = (a + c) / 2;
if (x == l[b]) return b;
else if (x < l[b]) c = b;
else a = b;
}
return (abs(x - l[a]) < abs(x - l[c]) ? a : c);
}

double damage(double mean, double stdDev)
{
return mean + (invNorm(getRand()) * stdDev);
}

The way this works is it has a list of the area under the normal
density curve.  It uses this table to look up the inverse normal
using binary search.  This will always be a number in the range -3
to 3 corresponding to how many standard deviations above or below
the mean the specified probability is.  If you aren't familiar with
it, the standard density curve is one where stuff closer to the mean
is more likely to occur than stuff farther from the mean.  The
random number generated by getRand is in the range 0 to 1, with 4
digits of precision.  How would this work as far as speed?  Does it
even make sense to do something like this?  Any ideas for improving
this algorithm?
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev

```