Clericus 1.03 / Hopeless 0.5 evaluation
Home
Download
FAQ
Evaluation
History
Links

KING SAFETY
 

At the initialization of TEval class, a table of "neighbouring squares" is created.  These are squares near to the king, used for attack calculation. Please note that not only neighbouring squares in the strict sense of the word are treated as such - program looks also at the three more distant squares in front of the King (by "front" I mean the direction towards enemy position).

For each sliding piece, a boolean function "IsAttacker" is fired. It checks if a piece attacks a square neighbouring enemy king, as defined above. This is done in the usual manner of sliding along the ray, as in move generation routine. The only exception is that the process is continued even after a ray is blocked - in that case a local variable called "masks" is increased by one. It denotes number of pieces standing on the attacker's path - and the attack counts as such if at most one such piece exists.

Boolean result of the function indicates that we have found an attacker, which in turn increases a counter declared in TEval class. The strength of attack (basically a number of important squares under attack multiplied by a factor depending on the attacking piece) is added to the value of TEval.WPressure/BPressure variable.

Similar function "IsKnightAttacker" counts attack value for the knights as well as their mobility (please forgive faulty design). Attack algorithm is similar to the one described above, except that there is no question of interfering pieces.

Number of attackers Multiplier Once each piece is evaluated in this way, we are left with two parameters for each side: the attack value and the number of attackers. The latter is used for scaling purposes instead of the material count. Since Clericus was meant to be an attacking program, scaling is rather sharp, as we can see on the right.

The result is that once program starts attacking, it tends to concentrate on this activity at the expense of almost everything else (see the philosophy section for explanation why I consider it a desirable behaviour) - until it delivers a checkmate, converts into another kind of advantage or fails miserably. In any case, there is no backing off!
1 0
2 1
3 2
4 4
5 or more 8

The stuff described above is the core of Clericus' king safety.  However, a couple of additional factors are also taken into account. The most important of them is the pawn shield.

For example, the rooks on open or half-open files are more valuable if the files are in the vicinity of the enemy king, the queen is awarded a slight bonus for approaching the enemy king and a slight penalty for going away from it. Also the fianchetto evaluation proved itself very helpful  in a couple of games.

BASIC PAWN STRUCTURE TERMS

Material value

Don't sneer: Clericus thinks that purely material value of a pawn depends on its placement on the board. Central pawn are considered more valuable, whereas rook pawns, which can capture only in one direction, are considered slightly weaker due to their poorer mobility.

Weak pawns

Weak pawns are defined as either isolated or backward. Hanging pawns currently do not fall into this cathegory, as they would need more elaborate evaluation. All weak pawns receive a penalty from the piece/square table, and further penalty of -5, if they stand on the open file. The table is constructed in such a way that the penalty increases towards the center. This decision is based on the following assumption: a weak pawn in the center can be attacked from more directions, therefore it constitutes far more serious problem. The maximum penalty is -16, the minimum -10.

Doubled pawns

Doubled pawns receive a penalty of -20. Tripled pawns, which are much worse, get -60.

Passed pawns

This is the part that definately needs correction. Passed pawns receive a bonus from a piece/square table, which is multiplied by 1.2 if the passer is defended by another pawn or if it has a neighbour on the same rank. At this moment program knows nothing about piece placement affecting the value of a passed pawn.

Pawn shield

My pawn shield evaluation routine may seem too simplistic, but it's good enough for this program. If a pawn is near enough to the own king, we assign a bonus (PROT_PAWN); A pawn which is too advanced gets no bonus, and with no pawns on a file near the king we impose a penalty (NO_PROT_PAWN).

Pawn center

Program gives bonuses for certain constellations of the pawns in the center. A long time ago, when my program played without the opening book, I decided that the notion of pawn center is asummetric: most of the time the pawn center is built by the means of supporting the "d" pawn - be it by defending it or by giving it a neighbour on c4 or on e4. Thus playing c2-c3 is vieved as more valuable than f2-f3. It is caused mostly by the factors not known to the evaluation function of Clericus: c2-c3 increases queen mobility (which isn't counted) and the square f3 is much more necessary for the knight than the square c3 (which might have to do with the distance to the enemy king).

ADVANCED PAWN STRUCTURE TERMS

Class TEval contains functions "WPRelations" and "BPRelations", which evaluate factors depending on the pawn structure. At present they include the following:

  • severe penalty for a blockage of a d/e pawn on its initial square

  • minor penalty for a blockage of a C2/C7 pawn in closed positions

  • a Slav / Stonewall / Colle exception code, discouraging c4-c5 (borrowed from Phalanx)

  • a hefty evaluation of fianchetto (more below)

  • code concerning certain pawn structures in the center, in which it is vital to preserve a good bishop

Fianchetto and long term plans associated with it are extremely difficult to evaluate for a computer. This part of the code had changed several times before reaching the current state.

  • fianchetto weakens the A3/H3/A6/H6 square; while program gets this information in a roundabout way (an unmoved rook pawn is considered weak after a fianchetto), it still doesn't know what to do about it. From a human point of viev the answer is simple: the weakened square should be covered by a bishop. To force this behaviour a pawn on, say, G3 gets a further penalty if the Bg2 is missing.

  • fianchetto on the kingside usually is a defensive formation protecting the king. While the above heuristic helps the program to understand that exchanging a fianchettoed bishop is good for attack, there is a greater danger of a color weakness - a situation when defender's bishop is missing and the opponent still has its counterpart. This situation can be lethal and in some positions it is worth at least an exchange.

  • the color weakness heuristic still applies when the king has not castled (I got tired of seeing Clericus doing silly things once out of book)

MOBILITY

Mobility evaluation in Clericus/Hopeless Chess can be described by a set of five rules:

  • One more move = bonus of one more centipawn.

  • For rooks and bishops all the available squares are counted.

  • Knight mobility is restricted to squares not attacked by enemy pawns. The reason for that is best explained by Ed Shroder on his excellent page on Rebel evaluation function. Since Knight can move to at most 8 squares, it is much more sensitive to the enemy control of this squares

  • Queen mobility is not counted at all, as it could easily become the dominant factor - distance to the enemy king is measured instead.

  • If a piece can make less than 3 moves, it gets a penalty to ensure that this situation will not persist. Size of this penalty may be determined in the .ini file - relevant parameters are MOB_ZERO, MOB_ONE and MOB_TWO.

Mobility calculation involves scanning the board for a possible piece moves. Therefore it constitutes a sound framework for checking attacks on stronger enemy pieces, rook connection and so on. For details, please refer to the source code.

There are solutions which would enhance the mobility calculation even further. For example, many programs read the bonus from the tables depending on a piece type and a number of available squares; it can make sense to allow a rook "see through" another one in the forward direction etc. However, these changes are low on my priority list,  since they would be very cost-effective in terms of testing time and especially in relation to the possible Elo gain. Therefore it may pay off to postpone them until my program reaches at least 2300 Elo level.

PATTERNS

By the means of defining several attack patterns, program knows about a couple of typical sacrifices, like Bxh7 or the "trojan horse" sacrifice on g5. This is achieved by describing the positions after such tactical shots and awarding them substantial bonuses. I don't think that this solution increases the playing strength by a significant amount, but I really enjoyed coding those exceptional situation and seing the engine solve them accurately.

PIECE EVALUATION

Knights, Bishops and Rooks are awarded mobility bonuses or penalties, as described above. Rooks and Knights may get outpost bonuses, if this option is set in the .ini file. All pieces except of the king contrubute to the king safety value.

1. Knight

  • material and piece/square value

  • mobility and king attack values (calculated by the same function, called IsKnightAttacker).

  • outpost bonus

  • penalty for a knight being trapped on the rim in the midst of the enemy camp.

  • a small penalty if opponent can move a pawn to threaten the knight

2. Bishop

  • material value and a piece/square bonus, rewarding centralization.

  • change of mobility value

  • change of king safety value

  • trapped bishop penalty ( A2/H2/A7/H7 = -150 and A3/H3/A6/H6 = -50 )

  • detection of knights pinned to K/Q/R

  • detection of bishop returning to their home squares after castling (see minor tweaks).

  • a small penalty if opponent can move a pawn to threaten the bishop

Please note that fianchetto is evaluated as a part of advanced pawn structure terms in WPRelations or BPRelations, and a bishop pair is dealt with as a correction of material value.

3. Rook

  • material value and piece/square table

  • change of mobility value

  • change of king safety value

  • a piece/square table bonus for rook connection

  • bonus for a position on half open or open file, greater if a file is directed towards enemy king

  • bonus for an outpost on an open file

  • penalty for a blockage by an uncastled King

4. Queen

  • material value and piece/square table

  • distance to the enemy king, used instead of mobility evaluation

  • centralization bonus, inversely proportional to the number of opponent's minor pieces

  • change of king safety value

5. King

  • In the middlegame, a king in the center is penalized if it has lost castling rights.

  • In the endgame, a centralization bonus is added.

  • In the endgame with all pawns on one wing, a king is penalized for wandering on the other wing.

  • Basic mating phase evaluation: the king of the weaker side gets huge centralization bonus, but the stronger side gets a bonus for small distance between the kings

MINOR TWEAKS

This part of evaluation function description is concerned with all sorts of not very significant details, which nevertheless contribute to more natural "feel" of Clericus' games.

  • Bishop on F1 is not penalized if the king is on G1. This is supposed to help in the openings like 1.e4 c5 2.Nf3 Nc6 3.Bb5 d6 4.0-0 Nf6 5.Re1 a6 6. Bf1, where it would be ill-advised to move Bf1 once more, since there are more important things to do.

ENDGAME KNOWLEDGE

  • detecting unstoppable passers in the pawn endings

  • ability to recognize drawn positions in KpK

  • endgames with bishops of opposite color are considered harder to win (score halved)

Draw rules:

  • a single minor cannot win

  • two knights cannot win against a single minor

  • rook pawn(s) do not win if opponent controls promotion square

  • KBP(p) vs K (rook pawn(s) and bad bishop ) draws if the weaker side controls promotion square

  • there is a rare draw with rook pawn(s) and theoretically good bishop against a king and a pawn, provided that a pawn of the weaker side is blocked by opponent's pawn on its initial square.

  • the same rule holds true if the position is moved one file towards the center

The last two points may sound quite complicated, so I will take a liberty to supply a drawing: