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

[Noah Gibbs]

--- Ben Chambers <bjchamb at bellsouth.net> wrote:
> Does this idea sound plausible?

  Your basic idea is plausible.  Basically you're
controlling the equivalent of whether your
distribution "feels" like 3d6 or 5d4, or whether it
"feels" like 1d20, but you know that.  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).

  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.

  The system could certainly be workable overall. 
This seems like a lot of effort to go through to
control these things, but it's certainly statistically
rigorous.  In fact, it's practically statistically
transparent -- any tactics sites that may spring up
around your game will have an easy time of it since
they can use all the same classical statistical
analysis that you do.  You may consider that either
good or bad.

> An example of the standard
> deviation code is presented
> below

  Overall, looks decent.  You *really* need more
documentation.

  I can see how lookup() works -- it just finds the
offset in the l[] array (better variable names
please!) and returns it.

  The division at the end of invNorm() seems really
obfuscated here.  Are you just dividing the offset by
100, effectively?  An offset like 305 seems like it
would still turn into 3.05, and that's still in excess
of 3 (which you claim is the largest available number
of standard deviations).  So I'm missing something, or
you are.

>    return ((double)((int)(n / 10)) / 10) +
> ((double)(n % 10) / 100);

  Here we go.  This is the section I'm calling
obfuscated.

> 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.

  There are actually a lot of curves where that's
true, but the one you have here looks pretty much like
a Gaussian.  Especially since you call its inverse
function an "inverse normal", and a Gaussian curve
also gets called a "normal curve".

> The random number generated by getRand is in the
> range 0 to 1, with 4 digits of 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), this is where I'd
look.  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.

  With that said, combat results don't need to be all
*that* random, you're working in an interpreted
language, and I've never personally looked at how DGD
does its random numbers.  So I may be talking out of
an inappopriate orofice here.

  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.  Sort of a bargain-rate Newton's
Method for this, since I think Newton's Method itself
would work indifferently on a Gaussian.


=====
------
noah_gibbs at yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd