Game Development Reference
In-Depth Information
a 0. Ignoring the problem of having a bucket size of 0, we still have to deal with the
fact that five of our buckets are the same size again. We have lost all the subtlety of
the scores between 18.1 and 27.4 by compressing them into a bucket width of 1 each.
If we increase the coefficient to 10, our numbers now are a little more workable:
Name
Weapon
Score
Weight
Edge
%
Evil Genius
R/L
7.7
10.00
10.00
25.8
Boss Man
R/L
8.5
9.06
19.06
23.4
Baddie 3
R/L
18.1
4.25
23.31
11.0
Evilmeister
R/L
19.3
3.99
27.30
10.3
Evil Genius
M/G
22.6
3.41
30.71
8.8
Baddie 3
Shotgun
26.9
2.86
33.57
7.4
Baddie 3
M/G
27.4
2.81
36.38
7.3
Baddie 2
R/L
33.1
2.32
38.70
6.0
As we look at the weights for each option, we see that our buckets are a variety
of different sizes. The third and fourth end up with a rounded size of 4, and the
fifth, sixth, and seventh round to a size of 3, however; we still are losing some of our
fine shades of difference. In the original example where the eight scores were closer
together, the loss of detail would be even more pronounced.
Automatic Scaling
Thankfully, we don't have to guess what size would be an appropriate coefficient.
We can rewrite our weight equation to help us automatically scale our weights to a
reasonable granularity. It
does
involve one extra step, however.
To generate the weights above, we scaled everything relative to the lowest score.
That is, the lowest score was the anchor point of 1.0 (before the application of a co-
efficient). The other, higher scores generated smaller weights as a result. We had no
way of accounting for what the other scores were because we were using the single
score as our only frame of reference.
Because we are generating proportions of the whole that each option repre-
sents, we need to begin with what the
whole
looks like. If we sum the scores in our
list of options, we can then further calculate the proportion of the whole that each
individual score represents using the following formula:
