I have not worked on my chess engine in over a year. I had other, more important, priorities. In the last year, my wife and I bought a new home closer to the city, sold our old home, moved (*), started new jobs in the summer, and ran the Chicago Marathon in the autumn. The little free time I had for hobby programming I spent on general interest projects, not on MadChess. I’m especially proud of Leaderless Replication, an essay I published on my general programming blog, ErikTheCoder.
Lately I’ve had time to do some chess programming. I added piece mobility evaluation to MadChess 3.0 Beta. This particular evaluation feature really demonstrates the benefits of bitboards over mailbox board representation. I can calculate the mobility of knights, bishops, rooks, and queens essentially for free- that is, with no negative impact on performance. I do not need to generate any moves or scan any piece arrays (along ranks, files, or diagonals). I simply lookup pseudo-legal candidate moves (not checked for move legality, i.e. does move expose own king to check?) via the
PrecalculatedMoves class (for sliding pieces) and move bit masks (for knights). Then lookup piece mobility scores in two arrays per piece type (middlegame and endgame) based on the number of moves available to the piece. Each piece mobility array is calculated at engine startup using a non-linear formula. The piece mobility scores are centered so the average number of moves is assigned zero score, less than average is assigned a negative score, and more than average is assigned a positive score. I tuned piece mobility configuration parameters against a database of about 54,000 Grandmaster games using the particle swarm algorithm I discussed in a previous blog post.
The following code calculates a mobility score for each piece on the board. By scoring mobility per piece, and not simply based on the total count of moves per side, the chess engine is encouraged to develop all of its pieces and cramp the position of its opponent.
It references the following code which determines the pseudo-legal candidate moves of each piece on the board, returned as a bit mask (where a 1 indicates a “to” square).
The above code references the following configuration parameters.
I changed source control from a local Subversion repository to a public GitHub repository. So that’s why the revision in the title of this post is a hash (used by GitHub) instead of an integer (used by Subversion) seen in my earlier posts about MadChess 3.0 Beta.
This code increased the playing strength of MadChess 3.0 Beta by 62 ELO.
|Piece Mobility||Evaluation||2020 Feb 01||5c5d4fc||282||2391||+62|
|Passed Pawns||Evaluation||2018 Dec 27||103||279||2329||+119|
|Staged Move Generation||Search||2018 Dec 15||93||275||2210||+39|
|History Heuristics||Search||2018 Dec 03||84||275||2171||+28|
|Eval Param Tuning||Evaluation||2018 Nov 24||75||272||2143||+47|
Material and Piece Location
|Baseline||2018 Nov 08||58||269||2096||0|
- GitHub commit (hash) or Subversion source code revision (integer)
- Win At Chess position test, 3 seconds per position
- Bullet chess, 2 min / game + 1 sec / move
(*) I know most people consider this one event: moving to a new home. However, because the sale, purchase, and move happened on three separate days over one month; and we had to purchase our new home before selling our old one (causing some anxiety and stress), it felt like three separate events.