The problem is not how to represent the hand pieces, but how to make the AI able to handle the drop moves without almost grinding to a halt. Variants with drops (or Universal Leapers, for that matter) get an excessively high branching factor. Furthermore, to judge the benefit of a drop, you need search depth. Because drops never capture something, and whether it made sense or was a pointless reduction of the piece its possible moves usally becomes clear only two ply later. The combination of high branching factor and large required depth is not a happy one.
Putting hand pieces in an extra board area, from where they move as mU, is likely to make things worse: if you have two identical pieces in hand, and they stand on different squares in the 'hand area', dropping one or the other would be considered different moves, doubling the already large number of potential drops. The holdings consist of counters, and when one generates drops for any counter that is non-zero it does not matter how many of a piece type you have in hand.
In my engines that can handle games with drops (CrazyWa and Shokidoki) I use reverse move generation in he last ply for selectively generating drops that can capture the King, because other drops would always look bad. But in case of a check the search will always be extended one ply for the evasion, which means the dropped piece will still get a chance to do something in the Quiescence search that follows. For earlier plies drop moves are typically searched 2 ply less deep than other moves, when this would leave a depth of at least 2 ply, and only be re-searched at full depth when they have proved they can recoup the initial score loss that dropping causes.
One problem in the I.D. is that there is no general way to do reverse move generation (finding possible origins for a given destination) for a given XBetza description. And that it also doesn't have a quick way to determine it is in check; it has to generate all opponent moves for that, to see if there is one amongst those that hits the King. So it does not award an extension for check evasions. At the depth the I.D. typically plays it would never make any drops, and just collect pieces in the hand (where they should be considered more valuable). Unless you force it to drop by making pieces in hand worth less, or putting a penalty on having too many of those. But then it would basically drop those in random safe locations.
The problem is not how to represent the hand pieces, but how to make the AI able to handle the drop moves without almost grinding to a halt. Variants with drops (or Universal Leapers, for that matter) get an excessively high branching factor. Furthermore, to judge the benefit of a drop, you need search depth. Because drops never capture something, and whether it made sense or was a pointless reduction of the piece its possible moves usally becomes clear only two ply later. The combination of high branching factor and large required depth is not a happy one.
Putting hand pieces in an extra board area, from where they move as mU, is likely to make things worse: if you have two identical pieces in hand, and they stand on different squares in the 'hand area', dropping one or the other would be considered different moves, doubling the already large number of potential drops. The holdings consist of counters, and when one generates drops for any counter that is non-zero it does not matter how many of a piece type you have in hand.
In my engines that can handle games with drops (CrazyWa and Shokidoki) I use reverse move generation in he last ply for selectively generating drops that can capture the King, because other drops would always look bad. But in case of a check the search will always be extended one ply for the evasion, which means the dropped piece will still get a chance to do something in the Quiescence search that follows. For earlier plies drop moves are typically searched 2 ply less deep than other moves, when this would leave a depth of at least 2 ply, and only be re-searched at full depth when they have proved they can recoup the initial score loss that dropping causes.
One problem in the I.D. is that there is no general way to do reverse move generation (finding possible origins for a given destination) for a given XBetza description. And that it also doesn't have a quick way to determine it is in check; it has to generate all opponent moves for that, to see if there is one amongst those that hits the King. So it does not award an extension for check evasions. At the depth the I.D. typically plays it would never make any drops, and just collect pieces in the hand (where they should be considered more valuable). Unless you force it to drop by making pieces in hand worth less, or putting a penalty on having too many of those. But then it would basically drop those in random safe locations.