I found the following search scheme to work quite well in games with drops: you distingush check-drops from other drops, and make a special move generator to selectively generate those (by generating retro moves for all piece types, starting from the King). At d=1 the only drops searched are the check drops; at d>=2 LMR reduces non-captures by 1 ply, and (non-check) drops by 2 ply.
Well, that sounds pretty easy. What about QSearch? I assume it just doesn't consider drops at all?
In CrazyWa I used a King Safety evaluation that seemed to work quite well generically across many drop variants. It was kind of unusual by being asymmetric. It awardeds a bonus to the side to move which is the product of the hand value and the number of squares attacked next to the enemy King (the possible drop locations). The latter could be cheaply calculated as side effect of the move generation, while the hand value can be kept track of incrementally. The idea was that in games with drops 'initiative' is all important, and the side that has the initiative typically checks the opponent all the time (mostly through drops, and captures with the slider it just dropped when evasion was an interposition). The side that is in check will never evaluate, but extend for the evasion even at d=0. So the leaves typically have the side on move that has the initiative, and this player usually doesn't have to worry much about his own King Safety.
This also makes sense. I'll make a note of this.
Xiangqi chasing rules indeed are very annoying; especially the fact that they are based on legal attacks and protects means that you have to search 3 ply ahead to judge them: one to play the attacks that are chase candidates as a capture, then the possible pseudo-legal recaptures, and finally the potential King captures resulting from these. And you have to do that for every position in the repeat loop. Always for both sides, because they could be mutually chasing, and then it is a draw again.
That is really painful. I wonder if it is possible to collect this information incrementally during the search rather than searching deeper to determine?
Well, that sounds pretty easy. What about QSearch? I assume it just doesn't consider drops at all?
This also makes sense. I'll make a note of this.
That is really painful. I wonder if it is possible to collect this information incrementally during the search rather than searching deeper to determine?