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.
Encapsulate castling rights within a small module. Castle provides the API to the
rest of the board package. Rights encodes the castling rights for each player.
Parameters defines castling parameters for each player.
This makes Position immutable, even if declared mut. I think this will also make
it easier to build positions going forward.
Moving to a PieceBitBoards struct also required a lot of places that return owned
BitBoards to return refs. This is basically fine except for adding a few more &
here and there.
This was a huge refactoring project. All the move generators and a bunch of
BitBoard stuff needed to be updated.
The Builder enables cleanly building a BitBoard out of squares.
The macro lets you create a BitBoard from a simple list of coordinates:
bitboard!(A1, B2, C3, D4, …)
Add a new Sight trait, implemented by PlacedPiece. The implementation of this
trait produces a BitBoard representing the squares visible to the placed piece.
- ASCIIDisplay → format a type using ASCII only characters
- UnicodeDisplay → format a type using any Unicode characters
- FENDisplay → format a type for inclusion in a FEN string
This macro implements a tiny DSL for creating Pieces and PlacedPieces.
"White King" → Piece::new(Color::White, Shape::King)
"White King on E4" → PlacedPiece::new(Piece::new(Color::White, Shape::King), Square::E4)
Move position.rs to the position module and create a mod.rs.
Do the same for bitboard.rs in the bitboard modules.
Export Color, Piece, Position, and Square and use crate::Thing directly instead of referring to the symbol in the nested modules.
