Progress on Rustic

[hgm]

KingSlayer is a good example of what type of chess knowledge you would want in the evaluation beyond PST, in a serious (i.e. non-minimalistic) chess engine:

* Pawn structure (passers, doubled Pawns, isolanis, (half-)open files)
* King fortress (to prevent it from exposing its King; related to castling-rights value)
* Drawishness (recognizing material compositions that offer poor winning prospects)
* Mobility (to prevent it hiding its pieces on boxed-in squares)
* King seige (actual attacks on the King neighborhood, to defuse mate nets early, or spin its own)
* Recognizers (Some specific knowledge on end-games that are difficult to predict from material alone, such as KPK, KQKP)
* End-game King location (w.r.t. passers, opponent King)
* Patterns (to recognize some unsolvable problems early, such as a white B on h7 with a black Pawn on g6)

Typical implementation is through an incrementally updated material key and pawn key, which are used for hashing info on Pawn structure and drawishness which is expensive to calculate, and is necessary for calculating the actual terms. E.g. the Pawn hash could contain the location of the passers, so that the King location can easily determine if the King is positioned favorably to stop or advance them. And it could contain the quality of the Pawn shields in the Q-side and K-side loacations, so that the King-location evaluation can draw on those. Etc.

[mvanthoor]

All of that stuff will (hopefully) eventually get in there, but not in the very first version. That has more features than I intended already

The only thing I'm going to still fix/add is the capability to mate with KQ and KR against K, because that did cost the engine a few games in my initial testing.

[hgm]

Sure, all that is for later. The first version of KingSlayer also was PST-only.

If the King's end-game PST would penalize approaching the edge, and within the edge penalize approaching the corner, the only thing that should be needed for winning KQK and KRK is a term that penalizes a bare King for being close to the other King. The problem is that without that, a Queen can drive the bare King in a corner on her own. (Provided the penalty the Queen gets for moving out of the center is less than what the King gets.) So there would be no need to involve the King in that, and if the search depth is really low, the attacking King would happily stay in the center. (But of course with the search depth you already reach you would then have the mate within the horizon on 8x8.)

It is always good to make the King PST 'parabolic' rather than 'pyramidal': the difference for being one step closer to the edge should get larger as you approach the edge (or corner), so that it pays for the attacking King to step a bit out of the center to press the bare King against the edge.

[Joost Buijs]

Usually it's enough to drive the king thats got to be mated to the edge or corners of the board by means of an endgame PST. Then the engine will find the mate with a very shallow search.

Mating with bishop and knight is not so easy though, in this case you have to add some intelligence to get the job done.

[hgm]

Indeed, with Bishop and Knight you should know which corners are safe for the bare King, and award it for being there. In KingSlayer I have a recognizer for that, which abuses the ability of recognizers to indicate drawishness: near the wrong corners it reports the KBNK end-game as moderately drawish, meaning the score gets divided by 2. As the naive score is about +6.5, that gives quite an encouragement to prevent the bare King from fleeing into the safe corner.

In Makruk & Shatranj Fairy-Max had problems to force checkmate with 3 Ferzes, because the Ferzes want to centralize, and you really need the lot of them to drive the King into a corner. So I now multiply the PST of a bare King by a factor 5 or so, to make driving it into a corner by far the largest concern, no matter how many pieces have to leave the center to do it.

[mvanthoor]

Sure, all that is for later. The first version of KingSlayer also was PST-only.

If the King's end-game PST would penalize approaching the edge, and within the edge penalize approaching the corner, the only thing that should be needed for winning KQK and KRK is a term that penalizes a bare King for being close to the other King. The problem is that without that, a Queen can drive the bare King in a corner on her own. (Provided the penalty the Queen gets for moving out of the center is less than what the King gets.) So there would be no need to involve the King in that, and if the search depth is really low, the attacking King would happily stay in the center. (But of course with the search depth you already reach you would then have the mate within the horizon on 8x8.)

It is always good to make the King PST 'parabolic' rather than 'pyramidal': the difference for being one step closer to the edge should get larger as you approach the edge (or corner), so that it pays for the attacking King to step a bit out of the center to press the bare King against the edge.

That's almost exactly what I implemented; a set of bitboards that define how close the king is to the edge, and penalizing higher the closer the king gets to the edge. Its probably simpler to just create the extra endgame PST for the king... which was originally planned when adding the tapered evaluation.

Maybe this is how those engines that are 3000+ Elo at version 1.0 are born: "Just one more feature, and then I'll release it."

Before that, I got the engine to mate by just generating king moves, counting the legal moves, and using that as a bonus. Obviously that's really slow, so I took it out again.

With regard to search horizon: it's true the engine could find the mate on its own as it is now, if its within the horizon. The KQ-K mate can be found almost instantly, or not at all, depending on where the pieces are on the board (Obviously closer to the edge finds the mate faster.) Often only one or two moves in the right direction are all that is needed to find a mate in 9.

Because it doesn't have any search optimizations yet (except for mvv-lva) and no TT, the engine is capped at depth 11-12 in the best positions in the endgame. In the middle game it reaches depths of 6-8 depending on the board. That'll all get better in due time though.

I haven't considered KBN-K yet. I've not seen it happen in any of the +/- 250 test games Rustic has played. I'll implement it at some point.

PS: I can't actually mate with KBN against K myself, reliably. I also have never encountered the situation in an OTB game.

[hgm]

If you already have tapered evaluation, then it is indeed just a matter of using an end-game table for the King that centralizes, and an opening table that pushes it out of the center. (Perhaps by twice as much, so that the King gets neutral after 2/3 of the material has gone.)

You don't really have to give different PST value for g1 and h1; even when checkmating you have to allow the bare King to shuttle between those two until you can give the final blow. It just works as a distraction when the strong side wants to manoeuvre such that it gets the King exactly in the corner in the leaves.

[mvanthoor]

I don't have a tapered evaluation yet. In fact, I'm trying to get the engine to finish off games with trivial mates such as KQ-K and KR-K without adding too much stuff to the evaluation; i.e., keeping this from spinning out of control and postponing the release to add yet another feature. I think I'll be adding just a PST "KING_EDGE" to the set of PST's, and apply that when one of the sides has a bare king. First I thought to apply it if a side has less than 1000 material, but that would be wrong; the king would become paranoid* and stay in the center while the opponent threatens to promote a pawn.

*As this fix works, I should become less paranoid myself, and just implement a feature when it is needed. The above solution might not be the prettiest ever, but it works. The king has no material value in my engine, so if material == 0 for one side, the king is bare. Then the KING_EDGE table kicks in, and the engine swiftly mates KQ-K and KR-K. And it does it in the minimum number of moves too

As Joost and HGM stated above, this doesn't work for KBN-K, but for this version Alpha 1, it's good enough. At least it won't draw KQ-K and KR-K anymore, which will net it (or, more accurately, not lose it) some Elo in testing.

[hgm]

KBN-K virtually never occurs.

Just be careful with temporary solutions to weaknesses that would disappear automatically when your engine gets more advanced; they are often hard to part with.

[mvanthoor]

KBN-K virtually never occurs.

Just be careful with temporary solutions to weaknesses that would disappear automatically when your engine gets more advanced; they are often hard to part with.

Yes... one of my teachers in uni once said: "The temporary solutions are the ones that last the longest."

In this case however, KING_EDGE is basically what the king's endgame PSQT would be in a tapered evaluation. It is only applied in the endgame, where (in this case) the "endgame" only starts if one side has less than 1 pawn of material. It seems to work fine. Worst case, the engine will whittle an opponent down to a bare king before checkmating, but most of the time that doesn't happen.