I'm new to chess engine. I want to ask what we should write in evaluation function. Besides basic chess knowlege, whether we should write some chess patterns in evaluation which one side can give a checkmate by a few moves, typically one move?
Actually, I'm writting a Chinese chess (XiangQi) engine. One major difference between XiangQi and chess is the king mobility. The King in XiangQi can only move in a 3*3 box, therefor we can make a checkmate more easily. For example, When one player has three or more major pieces in the same side of opponent, he may win very easily. But even to this simple example, there are many exceptions. If opponent's pieces in the right positions, it maybe wastes one's energy to put three pieces in the same side. Should I analyse every condition in details in evaluation function or just give some bonus when there are three or more major pieces in the same side?
question on good evaluation
Moderator: Ras
-
hgm
- Posts: 28391
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: question on good evaluation
Some general bonus will probably work better than looking for specific mate-in-N positons. Modern search trees are constructed such that they tend to search deeper when they get into a region where the evaluation i good, so you would discover the mate automatically, if there is one.
A bonus that is non-linear in the number of attacking pieces should work well; the problem you sketch can be solved by using the (properly weighted) difference between the number of attackers and defenders, before applying the non-linearity. E.g. two Horses already give a bonus when the opponent has no Advisors or Elephants at all, but when he has two defenders you need three attackers, and when he has all four defenders three attackers is not enough yet. The weight of each attacker and defeder can be made position-dependent through special piece-square tables for King Safety. (e.g. valueing an Elephant at e2 as a better defender than one at a2, and requiring a Pawn to be closer by before it is valued as an attacker than a Horse.)
When properly tuned this can also suppress the stupid behavior you see in engines with a linear evaluation, such as XQWLight: When they have to play, say, a single Horse against two 2H+2E+2A, their single Horse is drawn to the opponent Palace as a moth to a flame. While such an attack against a fully-defended Palace is totally futile, and the Horse was badly needed in defense. This way it bungles what could have been an easy draw. If keeping the Horse in proximity to its own Palace would have taken away a hefty attack bonus of the opponent (for two Horses against nothing), it would not show this behavior.
In my engine HaQiKi D, I use 32-bit integers in the Piece Square tables: the upper-most 16 bits are the normal, linear piece-suare tables, while the low order two bytes are the "attack-points" PST on the two Palaces. This way I can update the attack score for both sides without exta effort. The 8-bit attack values are then used to index a table for the attack bonus in the evaluation function. I never got to tuning this system, actually; in the Computer Olympiad this year I had put the bonus table to all zeros.
A bonus that is non-linear in the number of attacking pieces should work well; the problem you sketch can be solved by using the (properly weighted) difference between the number of attackers and defenders, before applying the non-linearity. E.g. two Horses already give a bonus when the opponent has no Advisors or Elephants at all, but when he has two defenders you need three attackers, and when he has all four defenders three attackers is not enough yet. The weight of each attacker and defeder can be made position-dependent through special piece-square tables for King Safety. (e.g. valueing an Elephant at e2 as a better defender than one at a2, and requiring a Pawn to be closer by before it is valued as an attacker than a Horse.)
When properly tuned this can also suppress the stupid behavior you see in engines with a linear evaluation, such as XQWLight: When they have to play, say, a single Horse against two 2H+2E+2A, their single Horse is drawn to the opponent Palace as a moth to a flame. While such an attack against a fully-defended Palace is totally futile, and the Horse was badly needed in defense. This way it bungles what could have been an easy draw. If keeping the Horse in proximity to its own Palace would have taken away a hefty attack bonus of the opponent (for two Horses against nothing), it would not show this behavior.
In my engine HaQiKi D, I use 32-bit integers in the Piece Square tables: the upper-most 16 bits are the normal, linear piece-suare tables, while the low order two bytes are the "attack-points" PST on the two Palaces. This way I can update the attack score for both sides without exta effort. The 8-bit attack values are then used to index a table for the attack bonus in the evaluation function. I never got to tuning this system, actually; in the Computer Olympiad this year I had put the bonus table to all zeros.