Implement a new method on Position that evaluates whether the active color can castle
on a given wing of the board. Then, implement making a castling move in the position.
Make a new Wing enum in the core crate to specify kingside or queenside. Replace the
Castle enum from the board crate with this one. This caused a lot of churn...
Along the way fix a bunch of tests.
Note: there's still no way to actually make a castling move in explorer.
Rework sight.rs and add a new module, movement.rs, to calculate piece sight and
movement. I discovered during this process that "sight" and "movement" are different
because pawns (in particular) can move in ways that don't follow their sight lines.
The routines in the movement module account for this, but also pass through to the
sight routines for other pieces.
- Break out the actual routines into file-private helper functions
- Declare traits for each piece type that call the corresponding helper function
- Implement these traits on PlacedPiece
The sight routines changed slightly such that they include the player's own pieces
in the resulting BitBoard. The tests neeeded to be updated to account for this.
Well… all the tests except the Peter Ellis Jones tests.
Pass around whole EnPassant types instead of pulling out just the e.p. square.
Make sure that Castling moves have their target and origin squares populated.
Add a color field to the Castle move style to make this possible.
Replace Position's en_passant_target_square() and en_passant_capture_square()
with a single en_passant() method that returns a new EnPassant struct that has
the target and capture squares for the en passant move.
Build Position::sight_of_piece() and ::is_king_in_check() for cfg(test) only.
Expand the doc comment for ::king_danger() slightly.
Remove an unused Rank import.
# Conflicts:
# position/src/position/position.rs
The pawn move generator only generated pushes for white pawns.
The is_king_in_check returned an inverted flag.
MoveSet needed a couple more validation methods: can_move_to_square and can_castle.
The MakeMoveBuilder also needed a little more move validation using the above methods.
Use CheckingPieces to determine which and how many pieces check the king.
- If there are no checks, proceed with move generation as normal.
- If there is one checking piece, calculate push and capture masks and use those
to generate legal moves.
- If there are more than one checking pieces, the only legal moves are king
moves. Indicate this by setting the push and capture masks to EMPTY.
Add an origin square argument to its one method ::ray_to_square(). Pushing this
implementation down a layer means I don't have to care about the color of the
piece.
Position::default specifies the defaults for all field. Then, ::new() and
::starting() can use ..Default::default() in their implementations to avoid
having to specify empty values for all the internal structures.
This trait declares ray_to_square() which should return a BitBoard representing
a ray from a Square to another Square. The ray should include the target Square.
PlacedPiece implements this trait.
