jacobgardner / chessai Goto Github PK

A pawn when hitting the end of the board, may choose to promote to any piece (excluding king and pawn). So technically this move should create a board for each of these other pieces.

I think it would be useless to generate a rook or bishop over a queen, but a knight may be useful, so our move generator should create 2 boards for each promotion (1 queen and 1 knight)

This is a complex operation that should not be done during normal board generation, but is expected when in situation where we're generating SAN.

Things needed before calling this done.

• There's a lot of raw bit manipulation that we can probably turn into inline functions that hide the implementation details
• En Passant
• Pulling out more common code into separate functions
• A few more debug_asserts for invariants.
• En Passant

Until we actually get profiling data we don't know if forcing inlining is actually better

We'll want API docs at some point and we'll want to enforce that through CI.

Some notes before I abandoned the initial implementation to get it working quickly.

        // if file > rank, above the diagonal
        // if above diagonal: 8 - (file - rank) = row #
        // if below diagonal: rank - file = row #
        // if file == rank => row = 0
        //
        //  if above the diagonal, indicies are from
        //      8 - row #  to 8
        //  if below the diagonal, indicies are from
        //      0 to 8 - row #

Manually building boards for comparison is too tedious. Let's build something like react snapshot testing instead.

With the std::error trait stuff changes we may not need failure any more. (Especially since failure is going to change in response to it).

Rook, Bishop, Knight, Queen, and probably king will all generate moves in more or less the same way. We should probably create a trait that requires each piece to implement generate_piece_moves() so that we can reduce the duplicated code.

A test at chess-lib/tests/rook_move_generation.rs

will generate a snapshot file at chess-lib/chess-lib/tests/__snapshots__/rook_move_generation.rs.snap

instead of placing it in a __snapshots__ folder in the same directory. I believe this is because of multiple workspaces.

Multithreading yo!

Right now for all notation we specify the piece type, the rank/file of the original space and the rank/file of the destination space, whether it was a capture, promotion, en-passant, or castling. Some of this information is redundant given the previous board state. For example, if two rooks can reach the same space and one moves there, It is common to only specify the rank or file of the rook that moved (I forget which is a higher priority). If only one piece of that type can reach the space, neither the rank or file are specified.

This is how standard algebraic notation works and should probably be followed

Crates:

• BitBoard
• ChessBoard
• MiniMax
• MinMax for ChessBoard

Bin:

• Standalone Server
• chess.com API hookup