[DGD] Damage Weapons and Stuff (Math and Code)

[Stephen Schmidt]

On Sun, 1 Jun 2003, Noah Gibbs wrote:
> A large
> standard deviation would feel more like a single die
> (more like a uniform random variable) than with many
> dice (more like a gaussian, which is what you're
> literally using here).

Actually, even a large standard deviation will be
noticably non-uniform, since it has a (small) chance
of producing results very far from the mean value,
which players will notice. The normal distribution
function is unbounded. This implementation looks
like it's bounded at 3 standard deviations, but
that's still real different from a uniform distribution,
which (if standard 0-1) has a standard deviation of
only about 1/3 its width. (I can't remember the
exact number offhand. I could be wrong, but not way
wrong).

>   Your system can't actually mimic a uniform random
> distribution, but it can sorta feel like it.  Fair
> enough.  You can always add that back manually with
> getrand() if you feel like you've lost something.

I would think it would be best to have both uniform
and normal distributions available (or, as I discuss
in my other note, uniform and logistic).

> This seems like a lot of effort to go through to
> control these things, but it's certainly statistically
> rigorous.

True, although the algorithm as given produces only
discrete values, rather than continuous ones, due to
the discrete nature of the lookup table. For some
applications that would be a major drawback, but for
this application, probably not. You can always increase
the number of elements in the lookup table, at the expense
of increasing the running time of the algorithm (though
switching to the logistic distribution is a better way
to solve both problems, since the logistic function would
be continuous down to the limit of machine precision).

>   If I was going to worry about the quality of your
> results (as opposed to the speed of the algorithm,
> which is somewhat questionable),

It'll be pretty slow if you need to access this often.
If you have the traditional LPMud combat system, with
one attack be each party coming every 2 seconds, then
ask yourself how many participants you expect to be
in combat at any given time, how many random number
calculations per attack, multiply those, divide by 2,
and that's the number of times per second this has to
run. If you intend to have a reasonably large and
reasonable combat-intensive game, speed may be a real
problem here.

> If you have a look at a book like Numerical
> Recipes, it'll tell you a lot about why you shouldn't
> generally trust other people's random number
> algorithms, and why there are enough different kinds
> of random number generators that it's worth building
> your own decent hand-tuned one.

My understanding (I did some research on this issue in
graduate school, not a lot) is that most UNIX random
number generators are pretty trustworthy, certainly
for applications like this. One generally needs only
build one's own random number generator if one is
doing seriously numerical computation (bootstrapping
statistical results, conducting computer simulations
of colliding galaxies, that sort of thing).

> ... I've never personally looked at how DGD
> does its random numbers.

I haven't either, but I would guess it just passes the
task off to the system's random number generator. Dworkin?

> So I may be talking out of an inappopriate orofice here.

I wouldn't put it quite that way :)  but I don't think
any serious problems would arise from using the DGD random
number generator.

>   As far as a quick speed boost goes:  you're
> currently just using a binary search.  You could try
> making an estimate of how far off you are instead, and
> try to go that far between a and c for your next b
> value.  That would wind up taking fewer iterations in
> almost all cases.

It will, but since the normal distribution doesn't have
a closed form solution, it doesn't have analytic derivatives
either. You'll need to have a second lookup table for the
derivatives to implement a Newton's method search, and
that probably kills the speed gain. Switching to logistic
or something else with a closed-form solution is better.

Steve


_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd