| | Class | Description |
|---|
| | AStarNodeBoard |
It is a similar of bitboard struct,and every cell representation a star node. |
| | BitBoard |
Pros and Cons of Using BitBoard Flags:
Pros:
Efficient: Very small storage space to hold a lot of information.
Efficient: Ultra-fast (actually fastest possible) for making programmatic decisions,
especially when looking for combinations of attributes or options.
Efficient: Concise storage means fast data transfer.
Extensible: New code does not "break" old code. |
| | BitVectors |
the implementation would look something like this:
//offline
var n:uint = objects.length;
var bv:BitVector = new BitVector( null, n ( n - 1 ) / 2 );
//test
function handleCollision( minObj:CollidableObject, maxObj:CollidableObject ) : void
{
var bit:uint = minObj.index ( 2 n - minObj.index - 3 ) / 2 + maxObj.index - 1;
if( !bv.getBit( bit ) ){
//test for collision
bv.setBit( bit, true );
}
}
|
| | GraphBoard |
This graphic board providing the graph data struct and searchable functions;
|
| | NumberBoard |
The numbers in this array are labels on the winnable n-in-a-row areas of the board.
This is useful so that when a piece is dropped into an arbitrary board position,
the algorithm can determine very quickly which n-in-a-row areas have become more likely destined for a win for the player,
and, as importantly, which n-in-a-row areas are no longer possibilities for the opposing player. |
| | ZobristHashTable |
These old hashes defined my requirements:
The keys are unaligned variable-length byte arrays.
Sometimes keys are several such arrays.
Sometimes a set of independent hash functions were required.
Average key lengths ranged from 8 bytes to 200 bytes.
Keys might be character strings, numbers, bit-arrays, or weirder things.
Table sizes could be anything, including powers of 2.
The hash must be faster than the old one.
The hash must do a good job. |
