If you test the first version of Maverick (v 0.05) you’ll soon find out it cannot mate at fast time controls with rook and king vs. a lone king. Quite shocking! Despite gnawing its way through 9 million positions per second, the mate is too deep for an engine without hash tables. So it just pushes its king and rook around the board aimlessly. Obviously it needs help.
I could add a few “if-then” statements to handle these cases. This would work well if there are only a few standard endgame. But I’d like to create a scalable solution where I can add all sorts of knowledge. I posted a questions on the Computer Chess Club and Steven Edwards pointed me in the rights direction – material hash tables.
Material hash work like this. Each position has a material hash value which is calculated based on the number of each type of pieces on the board. So when a piece us added or taken away the material hash value is updated. Unlike a normal zobrist hash value the location of the piece is not relevant.
When the evaluation routine is called, one of the first tasks is to check to see if the material hash of the position matches the signature of a known endgame. If there is a match the endgame specific routine is used to evaluate the position. Here’s the code to evaluate white rook and king vs. long black king:
void known_endgame_RKvk(struct t_board *board, struct t_chess_eval *eval)
eval->static_score = lone_king[board->king_square[BLACK]] + 800 - 10 * square_distance(board->king_square[WHITE], board->king_square[BLACK]);
eval->static_score *= (1 - board->to_move * 2);
Adding knowledge is also really easy. Here’s the routine to add KBN vs. K:
//-- R + K vs. k
material[WHITEROOK] = 1;
key = get_material_hash(material);
index = key & material_hash_mask;
if (material_hash[index].key != 0)
material_hash[index].key = key;
material_hash[index].eval_endgame = &known_endgame_RKvk;