XBoard and chess variants

[Evert]

What I had in mind for the move matching is to make a weighted count of atoms they have in common, (where R and B would be considered atoms), with a discount for missing directions. (I imagine that the pool of pieces kept by the GUI would almost all be completely symmetrical pieces.) The rarer atoms (in the pool as a whole) would get higher weights. So when there are only few pieces in the pool that have a Camel move, it would get a high priority to match a piece that does have the Camel moves with one of the Camel-like images.

Moves occurring on one and not on the other would also cause a penalty. This also should be proportional to the weights.

So some kind of weighted least-squared fit? That certainly seems like the best way to go about it. I just wonder about the best way to pick the weights.

My "Sjaak to Betza" translator conceptually writes out the move options in terms of base vectors by finding the "best match" that doesn't add spurious moves (the fundamental leapers themselves are of course orthogonal vectors in this sense, but once you add things like fF and sW to the list this is of course no longer true). The difference of course is that for the images, it's ok if a piece is "a bit like a Ferz, except it also has this other property". When describing the exact way it moves you can't be that lax...

[Evert]

Now this has been improved by at least ignoring pieces not present in the pieceToChar. But it still means I need an unnaturally large holdings size in Seirawan, because it also needs space for PNBRQ, while it only wants to store H and E.

Perhaps the 'piece' commands can be used to improve the matter. They can indicate which pieces can be dropped, and for pieces that cannot be dropped no place needs to be reserved in the holdings.

That, or just send another "pieceToHoldings" string (if we're keeping to the same spirit as the existing design) which would default to pieceToChar, but could be used to eliminate unwanted pieces.

… in fact, that doesn't sound like such a terrible idea. Might even be feasible.

Actually, it can be a bit easier than that from the engine side.

I suppose (not having checked the code) that in order to make something like that work in XBoard, the way to go would be to duplicate the pieceToChar table (into pieceToHoldings) and simply refer to this string when dealing with the holdings (the code should be functionally the same up to this point). Then pieceToHoldings could be modified, without touching pieceToChar.

This simplifies things from the engine setup in that if we''ve specified the pieceToChar, all we need to do is specify what holding slots should be copied over from it. All the other ones could be set to 0. Say for Seirawan the engine could send:

(PNBRQ..HEKpnbrq..hek) HEhe

(Well, you wouldn't for Seirawan, since it's a know variant, but you get the idea).

[hgm]

Well, I have done some thinking on this. From a game-state POV there really isn't any difference between holdings that swaps color and those that don't: you just record what is captured. The color-change thing is more a convenience for how to present this info to the user (i.e. a GUI thing). The color change can be imagined to occur on a drop, while no color change would occur on using a holdings piece as promotion choice. In OTB play you would grab the needed promotion piece from across the board, where your opponent collects the pieces he captured.

So the accounting of captured pieces can be implicit. The GUI would have to know how pieces demote on capture, however. For Shogi promotions this is already obvious from the pieceToCharTable. And in Bughouse promotions too, as the pieces that demote to Pawn would be marked as ~ in the pieceToCharTable. So there isn't any real need for the rule that what doesn't fit in the holdings should be demoted to Pawn.

All the GUI should have to know is which captured pieces should be presented to the user, and for which purpose. (Promotion choice or Drop/Gate.) Betza notation already provides a mechanism to encode whether a (captured) piece can be dropped. So the piece commands could convey this information, and with the convention that all XBoard's native pieces are droppable in variants with non-zero holdings, it would be hardly a burdon to require sending a piece command for the occasional exception (which could then be scratched from the holdings).

Thinking along those lines, the piece commands could also be made to encode how Pawns can promote. The fact that they currently cannot should be seen as a defect anyway. There are two ways for doing this: the Pawn definition could contain a list of pieces it can promote to, or the piece definitions could contain a marker to indicate they are possible promotion choices. By adding this info behind the Betza move notation, it can be done in a backward-compatible way. I guess the list method is better, as it allows presence of multiple promoting pieces that have different promotion choices.

E.g an element {NBRQ} could be added to the Pawn to indicate FIDE promotions, while [NBRQ] could mean you can only make these choices when previously captured. Default would be (for pieces that indicate promotability + zone depth by having an =N in their Betza string) unconditional to all non-Royal, non-Pawn pieces in the pieceToChar. The convention could be added that optional promotion would be indicated by listing the piece itself, so {PNBRQAC} in Grand Chess; this would not overrule the convention that promotion is compulsary for pieces that otherwise would get into a situation where they could never have any moves.

Cases not covered would be the Chu Shogi Lance, which apparenly turns into dead wood on playing it to the last rank without promoting it. (But there never can be any reason not to promote it, so it might as well be considered a piece that can never defer.) And promotion on capture, as some of the large Shogi variants have. This is basically a degenerate version of the case where promotions are possible only on entering the zone, or on captures (as Chu Shogi has), but where the promotion zone is the entire board. So it would be important to make a distinction in the zone specification between entry-only promotions (as in Chu) and in-out promotions (as in regular Shogi). Perhaps =N vs #N.

The =N zone flavor could imply promotion on capture for moves inside or leaving the zone. (There is a trade-off between flexibility and limitation of the symbol set here. I guess that considering '=' and '#' Betza atoms would make the notation m=4c#4 an accurate description of the Chu case: non-captures promote only on entry, captures (can) promote whenever they touch the zone. So there isn't really any need to introduce separate symbols for entry-only or entry-or-capture; Betza notation already provides the tools to make that distinction. The Dai-Dai case would be c#17.)

Anyway, I am digressing. When the GUI detects any [...] on the piece definitions it knows it will have to reserve space for the mentioned pieces in the holdings. It can combine those with pieces present in the holdings of the initial setup.

[Evert]

How bad of an idea is it to use bughouse as a parent variant for a game with drops?

It has the advantage (over crazyhouse) that you don'tt get captured pieces dumped in holdings when they shouldn't be, and just specifying that some pieces start out in-hand works fine (as long as the holdingsize is large enough). Just wondering if there's any catch to watch out for?

Slightly different question: does the lift/hover mechanic allow you to highlight valid drop squares?

[hgm]

I don't know much about XBoard's bughouse implementation. It was intended for ICS play only. Best is to just try it.

I must admit I have also no idea what the lift command would do in a game with holdings. My guess is that it would print square numbers in 'lift' like the holdings is the j-file in Crazyhouse. If you are playing black, however...

Of course the engine can highlight what it wants. Not sure it needs to highlight anything to make drops valid, though. It seems the pseudo-legality testing for drops even works when legality testing is off. (Which probably should be considered a bug.)

[Evert]

I don't know much about XBoard's bughouse implementation. It was intended for ICS play only. Best is to just try it.

As far as I can tell it "just works" because I never get anything placed in holdings (because the pieces go to my non-existent partner), which is exactly what I wanted… but I wasn't so sure what it implies for how reliable this is if I don't play over ICS.

I must admit I have also no idea what the lift command would do in a game with holdings. My guess is that it would print square numbers in 'lift' like the holdings is the j-file in Crazyhouse. If you are playing black, however…

Indeed, I just tried it and the logfile prints "j2" and "_7" for white, respectively black (the holding piece is a knight). This doesn't match any square that Sjaak knows about, so it goes unanswered.

Of course the engine can highlight what it wants. Not sure it needs to highlight anything to make drops valid, though. It seems the pseudo-legality testing for drops even works when legality testing is off. (Which probably should be considered a bug.)

Well, it could be useful, if the engine wants to pass along limitations on where a piece can be dropped (such as no pawn on a file that already has one in Shogi). However, we'd probably need a better way than an off-board square to tell the engine that the user wants to drop a piece from holdings. Perhaps "lift P", with "P" the piece symbol (capital letter) would work. There should be no room for confusing it with a square (which are lower-case and letter-number).

[hgm]

As far as I can tell it "just works" because I never get anything placed in holdings (because the pieces go to my non-existent partner), which is exactly what I wanted… but I wasn't so sure what it implies for how reliable this is if I don't play over ICS.

Well, I implemented the holdings. Otherwise the ICS code pretty much is completely separate from the code for local play; XBoard just acts as a display program for the text boards the ICS sends it. But I guess when you enter the move XBoard first updates the board locally, before it gets overruled by the ICS reply, and that it was annoying to see a piece put there automatically (when you captured) and then disappearing on a slow ICS update. So I probably added a statement to suppress addition af captured pieces to the holdings in VariantBughouse. And that would be all that is needed.

I think Seirawan would also allow drops from the holdings, btw. (But it might not allow to drop you just anywhere.)

Indeed, I just tried it and the logfile prints "j2" and "_7" for white, respectively black (the holding piece is a knight). This doesn't match any square that Sjaak knows about, so it goes unanswered.

I did not really give this any thought at all. The proper thing to do would of course be test whether the square is in the holdings, and print something special in that case. But j2 and _7 seem as good as anything else. OTOH, it might be more future-proof if it would relay piece name rather than position in the holdings. So how about "@P" when you lift a Pawn, etc.?

Well, it could be useful, if the engine wants to pass along limitations on where a piece can be dropped (such as no pawn on a file that already has one in Shogi).

Note that I already did address that particular problem in XBetza notation. You would just have to add f@8 to the Pawn move definition to describe Shogi drops. But it is true that there can always be drop rules so complex that XBetza cannot handle it, and that in this case the highlight command is the only remaining option. If you want to indicate drops. I never thought about this, because I also don't highlight drop squares with legality testing on. I decided it was more distracting than helpful. But Shogi Pawn drops could indeed be an exception to this.

However, we'd probably need a better way than an off-board square to tell the engine that the user wants to drop a piece from holdings. Perhaps "lift P", with "P" the piece symbol (capital letter) would work. There should be no room for confusing it with a square (which are lower-case and letter-number).

Ah yes, I already arrived at a similar conclusion above. I guess I would prefer the @P over just P.

[Evert]

I think Seirawan would also allow drops from the holdings, btw. (But it might not allow to drop you just anywhere.)

I think that was indeed the issue with selecting Seirawan as a parent variant.
But this works fairly well:

• For a variant where captured pieces go into holdings, to be dropped later at will, use "crazyhouse"
• For a variant where you can start with pieces in holdings to be dropped at will, but where captured pieces are just gone, use "bughouse"
• For a variant where pieces can be gated from the holdings, use "seirawan"

Of course, having legality testing off would also solve most problems, but it's nice if it can stay on.

OTOH, it might be more future-proof if it would relay piece name rather than position in the holdings. So how about "@P" when you lift a Pawn, etc.?

Sounds good!

Ah yes, I already arrived at a similar conclusion above. I guess I would prefer the @P over just P.

Either works for me. Using just P is the first thing that occurred to me, but having the first character as @ makes it a little bit easier to detect.