Thursday, December 25, 2014

Revisiting king safety

In order to improve the evaluation function in my engine I decided to revisit my king safety evaluation.

King safety is an important concept as when the king is going to be mated the game is over. King safety takes care of good king locations, intact pawn shelters, number of attacker and defenders around the king, material mating potential etc. Overall this is a fairly complex sub evaluation and to have it fairly accurate is important for the playing strength. A decision whether an engine should sacrifice material in order to be able to launch a mating attack against the opponents king comes mainly from this concept. And a wrong decision is usually fatal.

To get a better understanding what terms are important I first ran some statistics. I analyzed a few million positions where the king safety term kicked in and recorder the location of the kings.

Mid game probability the king is on a given square (black side is mirrored)
In the huge majority of the cases the king resides on the target square after castling short. In some positions it has not yet castled and in even less positions it has castled long. So obviously king safety evaluation around a king on G1 is the most important.

In my evaluation I increase or decrease a counter for attacking or defending pieces. Each piece type is handled individually. A defending queen gets no bonus, a defending bishop does. The valid counter range after adding all attackers and subtracting the defenders is between 0 and 50. Now I wanted to know how this counter is distributed. I expected a uniform distribution, but it looked quiet differently.


Obviously there are some values much more likely than others. Probably because some attack / defend combinations are much more likely than others but overall the range between 10 and 30 is the most interesting one. I intend later to give tuned values higher focus if they relate to a counter value that occurs frequently.

Finally I tuned the king safety evaluation where I assigned each counter value an evaluation value. If plotted as a curve the evaluation values form a somewhat exponential function.

Evaluation per Counter
The tuning resulted not in a smooth curve. I really would have like that. I thought about modelling the curve with an exponential function minimizing the error in the important data points. But so far I did not do it. I just hard coded all 50 tuned values for now. For a serious attack (counter >= 40) the evaluation goes over the value for a rook. This might encourage some nice sacrifices, I hope.

The final regression test got me a somewhat nice improvement in strength over iCE 2. So at least it was worth it.