This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Side Mask


You might still consider splitting the evaluations up into seperate
functionss that return a normalized value for all units.  It could be
used for any of the worth calculations.  Although with multiplicative
factors, the range 0 to 64 might be better.

For example you could have a table, u_speed_worth, for every unit type,
and populate it by finding the fastest unit, and multiplying every
unit's speed by 64, and dividing by the spped of the fastest unit.  So
if you had 4 unit types, with speeds of 1, 2, 3, and 4, they would have
entries of 16, 32, 48, and 64.  The nice thing about normalizing is that
gives you a realative number, rather than an absolute number.  If
sombody added a unit with a spped of 16 to the mix, then the relative
values would change to 4, 8, 12, 16, and 64.  The fastest (or greatest
range, or least costly to produce, ...) would always have a value of 64.

I'd still think a set of weights would give you some flexibilty to
tinker with the evaluations without having to change code, and would let
game designers tinker with the AI without having to change code.  I'd
normalize the weights, to keep the factors from climbing too high, but
that's just a prefernce.

I have a preference for additivemixes, but that's muostly because I've
found it a little more flexible for combining disjoint properties into a
final score in surveys and such.




-----Original Message-----

From:	Hans Ronne [mailto:hronne@pp.sbbs.se]

Sent:	Tue 23-Jul-02 13:12

To:	Stanley Sutton

Cc:	xconq7@sources.redhat.com

Subject:	Re: Side Mask


>Currently, the side mask set operation is defined as:

>

>#define add_side_to_set(side,mask) ((mask) | (1 << ((side) ? (side)->id

>: 0)))

>

>It would seem to be better to define it as:

>

>#define add_side_to_set(side,mask) ((mask) | ((side)?(1 << (side)->id)
:

>0)))

>

>since that would not modify the mask if the side pointer is null, where

>the current definition would set the 0'th (or 31st depending on how you

>number the bits) bit if the side mask is null.  If the side id can be 0

>(which I haven't dug through the code to find out), side 0 or a null

>poiter would set the same bit.  The remove side from mask would need a

>similar correction.



The indepside (which always exists even if it has no units) has side id
0.

All these checks for null side pointers are remnants from the time when

independent units did not have a side at all. So you had to check if a
unit

had a side before dereferencing it. This is no longer so, every unit has
a

side. So I don't think the problem with a null side being passed to this

macro would ever occur. But I will check to make sure.



Hans



Hans Ronne



hronne@pp.sbbs.se












Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]