Tofiks v1.0.0. is finally here.
It's almost a year since I put down the first few lines of code down that would later become a chess engine. A weak chess engine but after a week of work it was still a bit magical seeing a few lines starting to play a game that I have a weak grasp of myself. There have been many technical challenges and challenges in terms of solving chess. Recently I have felt that more and more pieces are falling in their place and I see less bugs and crashes or just bizarre moves. So I decided to make it official and release Tofiks v1.0.0
- Magic Bitboard move generator
- MVV-LVA move ordering. In Alpha-beta checking the best moves is crucial. Ordering captures according to Most Valuable Victim - Least Valuable Aggressor is a very good heuristic.
- Killer heuristic. Simply checking moves that worked in a similar position if they work in the current position is a good idea. Sometimes a position has several good moves and the move order can be changed around unless there is a very sharp tactical line. It can help checking on such moves to create AB cutoffs.
- Principal Variation Search. Same as AB search but tries to validate the PV by establishing the upper and lower bounds and confirming that the PV we are looking at is in fact the best line.
- Null move pruning. If passing a move and giving the opposition a free move and the opposition still hates the position then the branch is so bad for opposition that the opponent would not choose to play into it and it can be dropped.
- Transposition table. Storing and retrieving evaluations of positions and if the position repeats by transposition it does not need to be searched again but the result can be returned from the stored value.
- Quiescence search. At the end of the primary search function we enter a quiescence search where we no longer try to find the very best moves but simply take the tension out of a tactical position.
- Draw detection - repetition, 50-move rule and insufficient material
- Piece-Square-Table evaluation for early game and endgame. Instead of letting the engine figure out all the best play on its own, provide it with some guidance in terms of what pieces are good on what squares.
- Pawn structure evaluation. Connected, doubled, isolated, protected and advancement are all aspects the engine tries to evaluate.
- King safety-activity evaluation. King activity and safety are pretty much diagonally opposed but early and midgame you want your king safe and by the endgame you need it to come out and get his hands dirty.
- Piece specific evaluation
- PolyGlot opening book support. The engine can use its own internal book or let the GUI handle it (in this case the lichess-bot client). I have written some libraries that can dig through games and compose a book from them. The current book is abased Lichess open DB records from 4 different months. Taking games that ended in mate and were not bullet and played by players with rating above 2300.
Big Mission Accomplished party? Of course not there are still many aspects that need work. In particular:
- The move generator could probably be optimized for more performance.
- I am not quite happy with how the Hash table works. Increasing the table size I would expect to see better performance but it seems to have very little effect to none.
- I cam across a mate in 11. And different engines were put to task in solving that. The numbers presented there were humiliating. Both in raw performance and also the number of nodes it took other engines to crack it. So I need plenty of extensions and reductions to ensure I can find better moves with less nodes.
- PST optimizations- well for a lack of a better word - I just pulled them out of my ass. I guess the technical term would be 'empirical' but certainly some more data driven approach would benefit them.
- I am also slowly learning of NN principles and might later see if adding some NNUE evaluation could help.