H. G. Muller wrote on Mon, Jan 1, 2018 05:14 PM UTC:
Just like it isn't useful for Chess engines to keep track of the 50-move count, I suspect it isn't very useful for a Makruk engine to keep track of the count. Usually the draw point wil lie beyond the horizon at the point of conversion, and once it is committed to a certain end-game, it should simply try to win in as few moves as possible, like it always does.
The counting rule does thoroughly upset which end-games are won, however. So I guess it is mainly the drawishness detection that would have to be adapted. I don't know how much of that ChessV is doing. E.g. does it know that KNK is a draw? Or KNNK? In Makruk, the counting rules would probably make end-games KRPPK drawish. The simple solution would be to strongly discount the score in end-games with a bare King, so that the engine will simply refrain from capturing a losig opponent's last piece.
Of course a GUI would have to know the exact rules, to correctly declare game end.
Just like it isn't useful for Chess engines to keep track of the 50-move count, I suspect it isn't very useful for a Makruk engine to keep track of the count. Usually the draw point wil lie beyond the horizon at the point of conversion, and once it is committed to a certain end-game, it should simply try to win in as few moves as possible, like it always does.
The counting rule does thoroughly upset which end-games are won, however. So I guess it is mainly the drawishness detection that would have to be adapted. I don't know how much of that ChessV is doing. E.g. does it know that KNK is a draw? Or KNNK? In Makruk, the counting rules would probably make end-games KRPPK drawish. The simple solution would be to strongly discount the score in end-games with a bare King, so that the engine will simply refrain from capturing a losig opponent's last piece.
Of course a GUI would have to know the exact rules, to correctly declare game end.