I’m up to my chops in evaluation code. As I’ve said in previous posts the engines I’ve written in the past have had basic evaluation function. I want Maverick to be different. I’m using a number of good resources to inspire me. The first is a book by Hans Berliner The System: A World Champion’s Approach to Chess, which takes quite a quantitative approach to chess. I’ve found it invaluable and would recommend it to any chess programmer.
As I’m writing the code I can’t help but feel the enormity of the domain space of a chess evaluation function. Firstly there are the values I give to each element. For example in the middelgame, is a pawn on g4 worth more or less than a pawn on f4? The pawn on f4 is probably worth more, but how much more – is it 2 centi pawns or 10 centi pawns? I’ve got to make these decision for all six piece types in the middle-game and endgame. And then there is the values I assign for a double pawn on h2 or e4? The task is truly enormous. Secondly there is complexity due to what I choose to evaluate and how I go about doing so.
This all reinforces the idea of a solid testing framework. I also recent read an interview with Robert Houdart. Of course I would expect Robert to test Houdini but I was struck by him playing 100,000 games per day! That’s a lot of games. This impressed upon me the need to create a testing setup (when Maverick starts to play chess). Testing was also one of the things Fabian used to rocket Fruit up the rating lists back in 2005. Once I get Maverick playing chess I must make it my objective to be 100% test driven.