My little program ( Fun Chess ) plays OK at the moment but looses against many 1900+ players when they sacrifice material and go for it's king. The program happily believes it's doing fine until it finally realises that there's just no escape from mate.
I've tried evaluating the king safety bu just looking whether it's castled, the nearby pawn structure and how squares around the king are attacked or defended but this doesn't seem to be enough as the human player sacrificed a rook and a knight to eventually get mate.
I believe I have a few options:
Raise the scoring on the existing safety routines. The problem here is that this will make the other evaluations seem insignificant ie why bother getting a protected passed pawn if it can add another minor piece to it's impregnable castle fortress.
I then looked at gathering safety info while doing the search ie if the opponents queen is moved near our king then score that badly. If the queen is taken then score that well. Checks bad. Mates worse etc etc. I tried putting in what I thought was moderate evaluation scores but found these scores were upsetting the whole scoring system.
Currently thinking about just counting the number of checks or mates that are found in any given search. If it exceeds a certain number then use the king safety evaluation function.
Essentially I'm trying anything that comes into my head. Any suggestions?
PS I'm hoping that when I have a better king safety evaluation then I might break the 2000 ELO barrier. Other options I've thought about adding include null moves, fractional extensions, hash positions and lazy evaluations. Any idea which of these might give most bang for the buck (or most ELO for hours coding)?
mike_bike_kite wrote:
I believe I have a few options:
Raise the scoring on the existing safety routines. The problem here is that this will make the other evaluations seem insignificant ie why bother getting a protected passed pawn if it can add another minor piece to it's impregnable castle fortress.
I then looked at gathering safety info while doing the search ie if the opponents queen is moved near our king then score that badly. If the queen is taken then score that well. Checks bad. Mates worse etc etc. I tried putting in what I thought was moderate evaluation scores but found these scores were upsetting the whole scoring system.
Currently thinking about just counting the number of checks or mates that are found in any given search. If it exceeds a certain number then use the king safety evaluation function.
Essentially I'm trying anything that comes into my head. Any suggestions?
I would consider Ed Schröder's writeup to be essential background reading.
That approach comes down to looking for a number of features, like missing pawn shields, number of attackers and type of attackers, number of defenders etc. These features are assigned a weight and for each feature you find, you increase an index variable. In the end, you use this index in a lookup table to find the king safety score.
There are other approaches though, so don't feel compelled to do it this way.
PS I'm hoping that when I have a better king safety evaluation then I might break the 2000 ELO barrier. Other options I've thought about adding include null moves, fractional extensions, hash positions and lazy evaluations. Any idea which of these might give most bang for the buck (or most ELO for hours coding)?
If you don't have a transposition table yet, definitely get that one first! Null move is also easy to implement. Fractional extensions and lazy evaluation you can do without, at least initially (though fractional extensions are harder o implement afterwards; personally I found them to be useless after I'd done the work to implement them).
null moves and hash tables will give you the most strength increase for the least work. Make sure you store a best move in the hash table, and use that for move ordering. Depending on your search function arguments, null move searching can be added in maybe 5 lines of work, and could give you 100 elo or so boost, especially if you have no other selective search implemented. And hashing saves search and greatly improves move ordering, meaning you can search deeper in the same number of nodes.
check out chessprogramming.wikispaces.com if you have not already done so.
Evert: That link looks good - I'll have a think about that. I currently store how often a given square is attacked and how often it is defended but I don't store the piece values associated with this. With the king safety it appears vital to know whether a queen can attack a nearby square with impunity but finding out this info in the evaluation routine is quite expensive. Anyway I'll read up and report back.
I don't have transposition tables yet (actually they weren't even on my list). I'll look into these. Is there a list of possible features to add and percentage differences in playing strength produced? All I have at the moment is a small opening book, alpha beta, MVV/LVA, ID, stand pat, killer moves and quite a heavy evaluation routine.
mjlef wrote:null moves and hash tables will give you the most strength increase for the least work. Make sure you store a best move in the hash table, and use that for move ordering. Depending on your search function arguments, null move searching can be added in maybe 5 lines of work, and could give you 100 elo or so boost, especially if you have no other selective search implemented. And hashing saves search and greatly improves move ordering, meaning you can search deeper in the same number of nodes.
check out chessprogramming.wikispaces.com if you have not already done so.
5 lines = 100 elo => sounds exactly what I need It's nice to have some direction in how to approach all this. Currently I tend to try many random things to see if anything helps - I know I shouldn't but ... Eventually the program starts playing as if it's had a lobotomy. Then after desperate fixes and roll backs I end up just making the front end prettier - I actually find that bit quite relaxing.
mjlef wrote:null moves and hash tables will give you the most strength increase for the least work. Make sure you store a best move in the hash table, and use that for move ordering. Depending on your search function arguments, null move searching can be added in maybe 5 lines of work, and could give you 100 elo or so boost, especially if you have no other selective search implemented. And hashing saves search and greatly improves move ordering, meaning you can search deeper in the same number of nodes.
check out chessprogramming.wikispaces.com if you have not already done so.
5 lines = 100 elo => sounds exactly what I need It's nice to have some direction in how to approach all this. Currently I tend to try many random things to see if anything helps - I know I shouldn't but ... Eventually the program starts playing as if it's had a lobotomy. Then after desperate fixes and roll backs I end up just making the front end prettier - I actually find that bit quite relaxing.
I would advise to test every thing you make. Sometime something you touch and you think is good could be counterproductive, against your logic. Testing is not only very good in the long term, it is also a good habit, althought I know it could be quite desesperating at first because you dont get result as fast as you would like.
Kempelen wrote:I would advise to test every thing you make. Sometime something you touch and you think is good could be counterproductive, against your logic.
I tend to play the program in a set position to see whether my changes do what I'd hoped. I then get it to play itself for a number of games with the new code switched out for one side. Then I tend to play a whole game against it myself - this usually tells me nothing as it beats me quite easily these days. I then throw it out to the world and wait for feedback (it's a web based java applet).
The problem is that errors can be just a small fluctuation in how a given situation is scored. I recently had a situation where passed pawns were rewarded with the same score for both sides. This meant black tried hard to get protected passed pawns and white also tried hard to give black protected passed pawns. C'est la vie.
Kempelen wrote:I would advise to test every thing you make. Sometime something you touch and you think is good could be counterproductive, against your logic.
I tend to play the program in a set position to see whether my changes do what I'd hoped. I then get it to play itself for a number of games with the new code switched out for one side. Then I tend to play a whole game against it myself - this usually tells me nothing as it beats me quite easily these days. I then throw it out to the world and wait for feedback (it's a web based java applet).
The problem is that errors can be just a small fluctuation in how a given situation is scored. I recently had a situation where passed pawns were rewarded with the same score for both sides. This meant black tried hard to get protected passed pawns and white also tried hard to give black protected passed pawns. C'est la vie.
To avoid this kind of error try rotating the board and turn and compare scores. Should be the same. This simple trick catchs a lot of bugs.
mjlef wrote:null moves and hash tables will give you the most strength increase for the least work. Make sure you store a best move in the hash table, and use that for move ordering. Depending on your search function arguments, null move searching can be added in maybe 5 lines of work, and could give you 100 elo or so boost, especially if you have no other selective search implemented. And hashing saves search and greatly improves move ordering, meaning you can search deeper in the same number of nodes.
check out chessprogramming.wikispaces.com if you have not already done so.
5 lines = 100 elo => sounds exactly what I need It's nice to have some direction in how to approach all this. Currently I tend to try many random things to see if anything helps - I know I shouldn't but ... Eventually the program starts playing as if it's had a lobotomy. Then after desperate fixes and roll backs I end up just making the front end prettier - I actually find that bit quite relaxing.
We have all been there, and I am frankly still pretty close to there!
Kempelen wrote:I would advise to test every thing you make. Sometime something you touch and you think is good could be counterproductive, against your logic.
I tend to play the program in a set position to see whether my changes do what I'd hoped. I then get it to play itself for a number of games with the new code switched out for one side. Then I tend to play a whole game against it myself - this usually tells me nothing as it beats me quite easily these days. I then throw it out to the world and wait for feedback (it's a web based java applet).
The problem is that errors can be just a small fluctuation in how a given situation is scored. I recently had a situation where passed pawns were rewarded with the same score for both sides. This meant black tried hard to get protected passed pawns and white also tried hard to give black protected passed pawns. C'est la vie.
Look for a fast match playing program like cutechess-cli. It will let you play lots of games against known opponents. Using just fixed positions can mislead you a lot about strength since it is easy to optimize against a few positions, but harder in real games. If the opponents you use are a lot stronger, you can set different amounts of time for them (give them say 1/10th the search time, or lower search depth) to weaken it against your program. it is easier to see changes with closely matched opponents. Then as your program grows stronger, give the opponent(s) a little more time.
It's nice to have some direction in how to approach all this. Currently I tend to try many random things to see if anything helps - I know I shouldn't but ... Eventually the program starts playing as if it's had a lobotomy. Then after desperate fixes and roll backs I end up just making the front end prettier - I actually find that bit quite relaxing.