The moves command writes all possible moves to the terminal.
Move the previous implementation of the moves command, which marked squares that
a piece could move to, to a 'movement' command.
A generator that yields moves for all pieces on the board. This generator combines
the shape-specific move generators developed in prior commits into a single
iterator that yields all moves.
Implement FusedIterator for all generators so AllPiecesMoveGenerator can avoid
doing a bunch of extra work once each iterator has yielded None.
The make_move tests were trying to access the last capture piece directly from a
slice of captures pieces (implementation prior to CapturesList). Implement
CapturesList::last() to return an Option<&Piece> and use it in the tests.
Implement a move generator that emits moves for the king(s) of a particular color.
There will, of course, only ever be one king per side in any valid board, but
this iterator can (in theory) handle multiple kings on the board. This iterator
is almost entirely copypasta of the SliderMoveGenerator. The major difference is
castling.
Castle moves are emitted by a helper CastleIterator type. This struct collects
information about whether the given color can castle on each side of the board
and then emits moves for each side, if indicated.
Do some light refactoring of the castle-related methods on Board to accommodate
this move generator. Remove the dependency on internal state and rename the
"can_castle" method to color_can_castle.
In order to facilitate creating castling moves without relying on Board, remove
the origin and target squares from the encoded castling move. Code that makes
a castling move already looks up castling parameters to move the king and rook to
the right squares, so encoding those squares was redundant. This change
necessitated some updates to position.
Lastly, bring in a handful of unit tests courtesy of Claude. Apparently, it's my
new best coding friend. 🙃
This generator produces moves for slider pieces: bishops, rooks, and queens. All
of these pieces behave identically, though with different sets of rays that
emanate from the origin square. Claude helped me significantly with the
implementation and unit testing. All the unit tests that took advantage of Claude
for implementation are marked as such with an _ai_claude suffix to the test name.
One unique aspect of this move generator that Claude suggested to me was to use
loop { } instead of a recursive call to next() when the internal iterators expire.
I may try to port this to the other move generators in the future.
To support this move generator, implement a Slider enum in core that represents
one of the three slider pieces.
Add Board::bishops(), Board::rooks() and Board::queens() to return BitBoards of
those pieces. These are analogous to the pawns() and knights() methods that return
their corresponding pieces.
Also in the board create, replace the separate sight method implementations with
a macro. These are all the same, but with a different sight method called under
the hood.
Finally, derive Clone and Debug for the bit_scanner types.
ply! implements a small DSL for writing moves in code using a natural-ish
algebraic notation.
assert_move_list! takes a generator and an expected list of moves and asserts
that they're equal. This macro is mostly a copy from one I wrote earlier in the
position crate.
Add another sub-iterator to the PawnMoveGenerator that produces promotion pushes
or capture moves (depending on move_type) when a pawn moves to the back rank.
Also implement en passant moves.
Fix a bug in the Left and Right captures branches where the wrong neighbors used
to calculate origin squares.
Add a whole bunch of tests. Still missing several cases though.
Board::find_pieces returns a BitBoard for all the pieces matching the given Piece.
Board::enemies returns a BitBoard of all the enemy pieces of a given Color.
Board::pawns returns a BitBoard of all the pawns of a given Color.
I used Claude to help me figure this out. First time using AI for coding. It was
actually rather helpful!
Calculate BitBoards representing the various kinds of pawn moves when the move
generator is created, and then iterate through them.
En passant still isn't implemented here. This code has not been tested yet either.
This argument allows computing the neighbor n squares away along the direction.
Technically, squares n>1 are not neighbors… but this is a convenient calculation.
Let BitBoard::rank and BitBoard::file take a Rank and File directly, instead of a
u8 by reference. And then make the Rank/File::as_index const and return a value
rather than a reference.
All this allows you to convert between Rank, File, and BitBoard at compile tile
(i.e. as a const method) rather than needing to do runtime stuff.
Create a new MoveRecord struct that tracks the move (aka ply) and irreversible
board properties. This should make it easier to unmake moves in the future.
New convention: active_color_ methods operate on the active color of the Board.
Methods without that prefix take a color parameter and operate on that.
Refactor opposing_sight to do this.
- Ensure you cannot move a pawn to the last rank without a promotion move.
- Ensure a pawn cannot make an illegal move, and that the board state remains
as it was before the move was attempted.
Add white castling for both wings. Found some bugs in how king sight is computed
while writing these.
In order for the king to perform the castle, the Movement bitboard needs to return
the two squares the king can castle to. That means anytime movement is calculated
for the king, the (relatively expensive) castling evaluation needs to happen.
Write two new helper static functions to create a Move for castling and promotion
moves. Since structs cannot have any functions with the same name, the two methods
that return properties related to those moves (Move::castle and Move::promotion)
need to be renamed. They're now called Move::castle_wing and Move::promotion_shape.
Implement making double push and promotion moves. Then write several tests to
exercise these. Add convenient static functions to the Move struct to build moves
quickly, without using the Builder.
Add a is_promotable_rank() method to Rank to check that a rank can be used for
promotion moves.
The tests found and fixed a bug in pawn movement where the en passant square was
being discarded when deciding whether an e.p. move can be made.
- Add a captures list to the Position struct
- Implement ToFenStr
- Update the imports list, which has been sorely out-of-date in the tree for many commits now.
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.
Implement thiserror::Error for a bunch of error types, and remove string errors
from the implementation of the command handler in explorer.
Clean up parsing of basic types all over the place.
Update Cargo files to include thiserror and anyhow.
