## Part 2: A detailed description

### Evaluation

Material

First NagaSkaki evaluates the material score, which is as follows:
Pawn = 100
Knight = 310
Bishop = 320
Rook = 500
Queen = 1000

The reason a pawn is valued at 100 and not 1, is to give you enough resolution to use integers which is faster than floating point operations.

Positional

Next NagaSkaki will punish things like a king trapping a rook at a1/h1, and a bishop trapped at a7/h7 (computers easily fall into this trap when they notice a pawn can be captured at a7/h7, but can’t see far enough ahead to notice the bishop will be trapped when the opponent moves his pawn to b6/g6. The opponent can then take his time and move his king to the trapped bishop and capture it.)

NagaSkaki will also give a bonus for a rook on the seventh rank and a big bonus for two rooks on the seventh rank.

Mobility

NagaSkaki’s mobility score is based on the amount of moves available. Unfortunately this is very expensive to calculate, thus NagaSkaki makes a compromise and use the amount of moves available on the previous ply. The (probably faulty) assumption is that the move count won’t change that much in one ply.

King evaluation

Give a bonus if we’ve castled / can castle.
This one can be a bit tricky. For the first versions of NagaSkaki I gave a bonus if he still has the right to castle (which sounds like a good plan), but what happened is that NagaSkaki would never castle, because then it lost the bonus of being able to castle.You might think the obvious thing to remedy the situation is to add a bigger bonus if we’ve already castled. But this can lead to an unbalanced score if both sides’ kings are safe, but one has castled to reach the situation and the other one not, thus the side that castled has a better score although things are even. Another problem I saw is that you have to give such a big score for having castled that it just seemed a bit ridiculous.
The current version overcome the above problems by only giving a bonus to castling if we haven’t castled at the root ply, but castled somewhere in the search. Thus I don’t explicitly give a bonus if NagaSkaki still has the right to castle. This isn’t perfect, but much better than the previous algorithm.

Give a penalty if:
There is an open file in front/close to the king (files with no pawns on it)
There is less than 3 pawns in front of the king
There is no knight close to the king
The opponent has a knight close to the king
The opponent has a rook on the same file as the king
The opponent has a bishop attacking the kingInstead of giving a fixed penalty value to everything, I use an exponential lookup table (I got the idea from Rebel – http://members.home.nl/matador/chess840.htm) which gives only a small penalty if one or two of the above is present, but a huge penalty if a lot of them are present.

Pawn evaluation

Add a bonus for passed pawns (the bonus gets bigger as the amount of pieces gets less)
Add a penalty for backward pawns
Add a penalty for isolated pawns (extra penalty if they are on an open file, smaller penalty if opponent has no pieces)
Add a penalty for doubled pawns
Give a small bonus for a pawn protecting another pawn and for two pawns next to each other
If kings have castled on different sides, give a bonus for advancing pawns to opponents’ king
Give a bonus/penalty based on pawn’s position on the board

Knight evaluation

Give a small bonus for a pawn protecting a knight
Give a bonus for a knight on an outpost (a knight on one of the four centre squares with no enemy pawns that can chase it away)
Give a bonus if knight attacks weak pawns
Give a bonus/penalty based on knight’s position on the board

Bishop evaluation

Give a small bonus for a pawn protecting a bishop
Give a bonus for two bishops
Add a penalty if bishop blocks own pawns on d2 and e2
Give a bonus if bishop blocks enemy pawns on d7 and e7
Add a penalty for bishop on first rank behind pawns
Give a bonus/penalty based on bishop’s position on the board

Rook evaluation

Give a small bonus for a pawn protecting a rook
Give a bonus for a rook on a half open file (no friendly pawns in front of it)
Give a bonus for a rook on open file (no pawns in front of it)

In the endgame:
Give a bonus for a rook behind passed pawns
Give a bonus for a rook behind enemy passed pawn
Give a bonus/penalty based on rook’s position on the board

Queen evaluation

Give a small bonus for a pawn protecting the queen
Punish the queen if she moves before we’ve castled
Give a bonus/penalty based on queens’s position on the board

Special cases

If a side is behind by two or more pawns, the following apply:
Give a bonus for every pawn removed on the board (pawns can become queens and then we’re really screwed!)
Give a bonus for two rooks (two rooks can be drawish)
Give a bonus for keeping the queen (the queen tend to make things more difficult for the opponent)
Give a bonus for bishops of opposite colours (in an endgame with only pawns and bishops of opposite colours, the losing side can put his pawns where the opponent can’t reach them easily and the opponent must protect his pawns with his king if he wants to advance them)

NagaSkaki knows that certain endings are very difficult to win and if behind will try to force them:
King and two minors (bishop and knight) against king
King, queen and bishop/knight against king and queen
King and rook against king and knight/bishop

For an endgame with only kings and pawns NagaSkaki uses the following algorithm:
Give a bonus if own king is close to enemy king
Give a bonus if enemy king is on the side of the board

NagaSkaki also has an algorithm to calculate if a passed pawn can be caught by the opponent’s king.