Tamerlane Chess

[hgm]

This discussion started as PM, but it is perhaps better to make it public.

The issue is how XBoard can be used / must be enhanced to use it for playing Tamerlane Chess. The latter has some unique features:

* All Pawns promote differently, and are thus basically different piece types, although they move the same.
* One of the Pawns promotes to another Pawn
* Some Pawns promote to King
* As a result you can have up to 3 Kings, and only lose when you have none
* Not all Kings are completely equivalent; one of them can move to a special square where the others cannot go

The basic design choice is this: should it be visible how the Pawns promote, or which King is which? I.e., should all the Pawns be visually distinct? It is not unprecedented that parts of the game state are not visible, and players have to remember them. In orthodox Chess these are castling and e.p. rights, 50-move counter and game history (for rep draws). Players are supposed to remember whether they can still castle or not. When I played over-the-board bughouse, we did not actually change pieces when promoting Pawns. We just called out what piece they became, and players would just have to remember that this Pawn moved as a Queen (or Knight) until it was captured. Most bughouse interfaces do the opposite: they display the promoted Pawn as Queen or Knight indistinguishable from the real thing, and the players just have to remember that they only get a Pawn in hand when it is captured.

I am not sure whether it is known if the pieces people used to play Tamerlane Chess had distinguishable Pawns or not. If they had not, there certainly would be no reason to make them distinguishable in XBoard display.

So it seems acceptable to have XBoard use the same, undifferentiated Pawn for all Tamerlane Pawns. When a Pawn reaches last rank, XBoard invokes the promotion procedure, to allow the user to choose a piece. Here he can chose from all pieces participating in the variant, except Pawn or King. If the variant has restrictions that XBoard is not aware of, the engine can simply refuse the move (with an 'Illegal move' message) if the user makes an invalid choice; the engine will of course have to know which Pawn is which, and how it may promote.

Now it is of course silly to offer a choice when there really is none, but that is only a cosmetic drawback of using a general interface. Worse is that the default choice does not include Pawn or King. Now the Pawn you can promote to in Tamerlane is kind of a special Pawn, as it must stand immovable and invulnerable on the last rank until it can make a fork anywhere on the board, in which case it teleports there, to become a normal Pawn again (i.e. can only move as one). It might not be crazy to represent it as another piece (a 'Super-Pawn'?) while it can do that, meaning it does not really promote to Pawn, and the Super-Pawn would just be a different piece that does happen to be not present initially, but which would be offered as a choice.

When the Super-Pawn reaches last rank in Tamerlane, it instantly teleports to the starting square of the King Pawn, and becomes a 'Pawn of Kings', meaning it would now promote to King when it reaches last rank for the 3rd time. Although the jump back to the initial King-Pawn square is implied by the promotion move, an interface not knowing the rules would need the user or engine to specify the piece goes there. It also has to specify the promotion square, as conceivably something could be captured there. So this would be a 2-leg move. But XBoard does support such moves, with the aid of the highlight command, by marking the promotion square in cyan to indicate it isn't the final leg yet. When XBoard at all times makes the square marking in the engine's highlight command for indicating valid move targets prevail over its own idea how the pieces move (I am not sure that is the case now, btw), this would work without problems. The Tamerlane engine can just emit a highlight command for the second leg of the move to show where the Pawn must be put. And it can also do that when the Super-Pawn is waiting on the back rank for a forking opportunity, and one occurs.

Things could be smoothened by devising a mechanism to make the GUI aware of the promotion choice. The most flexible seems to do this on a 'per case' basis, as the choice could depend on where the piece promotes, and it would be quite complex to specify that in advance. Plus that it would require the piece types to be different if it depended on which Pawn it was, rather than the location. So it could be an extension of the 'highlight' idea: when the engine receives the 'put' command for the promotion square it could reply with

choice RB

to indicate that only B or R have to be presented to the user, starting with R (in case of 'sweep promotion'; when promotion popups are enabled it could pop down the default menu, which is tailored to orthodox Chess and would likely not contain the required choices anyway, and pop up a dialog with R amd B buttons). In cases where it is clear in advance that the piece must promote (which is typically the case for Pawns on the fore-last rank, which XBoard would then also know) the engine could even send the 'choice' command in response to the 'lift' command; this would enable XBoard to use the 'detour underpromotion': the Pawn morphs into the default choice as soon as you pick it up, and then cycle through the possibilities as long as you pull it backwards. If XBoard's idea of the default choice is wrong, the Pawn would initially morph into XBoard's choice, but as soon as the 'choice' command arrives it would correct that to what that command specifies as primary choice. This might flash the wrong choice for a short time; OTOH the morphing only takes place on a mouse move event, while the lift command is already sent on the button press. So there is a good chance that the 'choice' reply has already arrived at the point of first morphing.

Of course when the 'choice' command specifies a single piece, XBoard can do the promotion instantly.

[Evert]

This discussion started as PM, but it is perhaps better to make it public.

The issue is how XBoard can be used / must be enhanced to use it for playing Tamerlane Chess. The latter has some unique features:

* All Pawns promote differently, and are thus basically different piece types, although they move the same.
* One of the Pawns promotes to another Pawn
* Some Pawns promote to King
* As a result you can have up to 3 Kings, and only lose when you have none
* Not all Kings are completely equivalent; one of them can move to a special square where the others cannot go

It's actually slightly worse than that, they're all different:
1. The King is allowed to enter the enemy citadel, which ends the game immediately with a draw. It is also allowed to trade places with a friendly piece as a check (or mate) evasion once per game.
2. The Adventitious King (double-promoted Pawn of Pawns) is allowed to enter your own citadel, to keep out the enemy king (and since no other piece can enter the citadel, you could park it there and be safe until you run out of pieces).
3. The Prince isn't allowed to do either of these things.

The basic design choice is this: should it be visible how the Pawns promote, or which King is which? I.e., should all the Pawns be visually distinct? It is not unprecedented that parts of the game state are not visible, and players have to remember them. In orthodox Chess these are castling and e.p. rights, 50-move counter and game history (for rep draws). Players are supposed to remember whether they can still castle or not. When I played over-the-board bughouse, we did not actually change pieces when promoting Pawns. We just called out what piece they became, and players would just have to remember that this Pawn moved as a Queen (or Knight) until it was captured. Most bughouse interfaces do the opposite: they display the promoted Pawn as Queen or Knight indistinguishable from the real thing, and the players just have to remember that they only get a Pawn in hand when it is captured.

While this is true (and a board where all the pawns look different is just too messy, they should all look like pawns with at most a subtle mark to identify them), there is one other concern: the ability to pass relevant information in a FEN string. Of course that also doesn't tell you about 3-fold repetitions, but it should at least be clear to the interface what each Pawn is and what the different Kings are. At that point it becomes a question of whether you should display that information to the user, or if you should take explicit steps to hide it.

I am not sure whether it is known if the pieces people used to play Tamerlane Chess had distinguishable Pawns or not. If they had not, there certainly would be no reason to make them distinguishable in XBoard display.

Agreed. To my knowledge though, we have no idea. For all we know, people used engraved disks rather than figurines to tell them what piece was what (although that seems unlikely, since most forms of chess apart from Shogi and XiangQi are played with figurines).
In fact, it's not entirely clear to me how much we actually know about this game; the number of modern descriptions seems to out-weight the number of historic ones considerably. I'm mostly going with the history.chess.fr description, which seems fairly reliable and documented.

There appear to be sources that have boards with an even number of ranks, or without citadels (the latter of which simplifies things enormously). I had a sneak-peek at some of the Zillions implementations for the game, and they also simplify things: Pawn of Kings and Pawn of Pawns both immediately promote to non-royal King.

So it seems acceptable to have XBoard use the same, undifferentiated Pawn for all Tamerlane Pawns. When a Pawn reaches last rank, XBoard invokes the promotion procedure, to allow the user to choose a piece. Here he can chose from all pieces participating in the variant, except Pawn or King. If the variant has restrictions that XBoard is not aware of, the engine can simply refuse the move (with an 'Illegal move' message) if the user makes an invalid choice; the engine will of course have to know which Pawn is which, and how it may promote.

Now it is of course silly to offer a choice when there really is none, but that is only a cosmetic drawback of using a general interface. Worse is that the default choice does not include Pawn or King. Now the Pawn you can promote to in Tamerlane is kind of a special Pawn, as it must stand immovable and invulnerable on the last rank until it can make a fork anywhere on the board, in which case it teleports there, to become a normal Pawn again (i.e. can only move as one). It might not be crazy to represent it as another piece (a 'Super-Pawn'?) while it can do that, meaning it does not really promote to Pawn, and the Super-Pawn would just be a different piece that does happen to be not present initially, but which would be offered as a choice.

When the Super-Pawn reaches last rank in Tamerlane, it instantly teleports to the starting square of the King Pawn, and becomes a 'Pawn of Kings', meaning it would now promote to King when it reaches last rank for the 3rd time. Although the jump back to the initial King-Pawn square is implied by the promotion move, an interface not knowing the rules would need the user or engine to specify the piece goes there. It also has to specify the promotion square, as conceivably something could be captured there. So this would be a 2-leg move. But XBoard does support such moves, with the aid of the highlight command, by marking the promotion square in cyan to indicate it isn't the final leg yet. When XBoard at all times makes the square marking in the engine's highlight command for indicating valid move targets prevail over its own idea how the pieces move (I am not sure that is the case now, btw), this would work without problems. The Tamerlane engine can just emit a highlight command for the second leg of the move to show where the Pawn must be put. And it can also do that when the Super-Pawn is waiting on the back rank for a forking opportunity, and one occurs.

Things could be smoothened by devising a mechanism to make the GUI aware of the promotion choice. The most flexible seems to do this on a 'per case' basis, as the choice could depend on where the piece promotes, and it would be quite complex to specify that in advance. Plus that it would require the piece types to be different if it depended on which Pawn it was, rather than the location. So it could be an extension of the 'highlight' idea: when the engine receives the 'put' command for the promotion square it could reply with

choice RB

to indicate that only B or R have to be presented to the user, starting with R (in case of 'sweep promotion'; when promotion popups are enabled it could pop down the default menu, which is tailored to orthodox Chess and would likely not contain the required choices anyway, and pop up a dialog with R amd B buttons). In cases where it is clear in advance that the piece must promote (which is typically the case for Pawns on the fore-last rank, which XBoard would then also know) the engine could even send the 'choice' command in response to the 'lift' command; this would enable XBoard to use the 'detour underpromotion': the Pawn morphs into the default choice as soon as you pick it up, and then cycle through the possibilities as long as you pull it backwards. If XBoard's idea of the default choice is wrong, the Pawn would initially morph into XBoard's choice, but as soon as the 'choice' command arrives it would correct that to what that command specifies as primary choice. This might flash the wrong choice for a short time; OTOH the morphing only takes place on a mouse move event, while the lift command is already sent on the button press. So there is a good chance that the 'choice' reply has already arrived at the point of first morphing.

Of course when the 'choice' command specifies a single piece, XBoard can do the promotion instantly.

I actually really like this suggestion. It solves a gap in the information that can be passed from the engine to XBoard about rules of the game, at no cost to backward compatibility (old versions of XBoard just ignore the command).
Of course it does mean that I need to equip Postduif with the highlight command...

[hgm]

.. (and since no other piece can enter the citadel, you could park it there and be safe until you run out of pieces).

That was my first thought to, and it seemed strange to be able to draw so easily. (But of course you first have to promote twice, and then get there alive...) But then I realized thre is an other way: since the opponent King can enter the Citadel, he could capture your adventitious King there! If he has a second royal, he can thus use his King to checkmate your adventitious King in the Citadel.

I can live with the design where the GUI uses 3 identical Kings, and the engine decides which King can go where. (And the player just has to remember which is which, if he manages to get two in the first place, which doesn't seem so easy.)

I'm mostly going with the history.chess.fr description, which seems fairly reliable and documented.

Indeed, that guy is very good.

Of course it does mean that I need to equip Postduif with the highlight command...

Note that when you send feature highlight=1 there is no obligation to send highlight commands. When you have sent 'piece' commands XBoard would always highlight according to its own idea or the Betza string that overrules it, even with legality testing off, simultaneous with sending the 'lift' command. Only when you think it is important to inform the user in advance that this time things work differently you can send a highlight command to overwrite that. And this is only important if that highlight command would have extra or diffently colored highlights, because moves to unjustly highlighted squares (e.g. a forbidden repetition) you can always reject. So it is only when moves are possible that would not be included in the Betza description, or when you want to indicate unexpected promotions (outside the zone or of non-Pawns) or two-leg moves that you need to send a highlight.

As far as I can see in Tamerlane this would only be on the second promotion of the Pawn of Kings to make it a two-leg move (highlighting the promotion squares cyan in the first leg, and the final destination in the second), and to get it off the promotion square after the first promotion. For the second case, I guess you could also promote it to a 'wild-card piece' (native moves of Cobra and Falcon), where XBoard would allow any move that does not capture the King. The Lance used to be a wild-card piece too, before I requisitioned it as a Pawn type. There would be nothing against using it both as a Pawn type and a wild-card piece when on last rank, as Pawns would not normally get there! I could let the wild-card test pre-empt the Betza move generation, so that after making its wild-card move it could be defined to move as a normal Pawn, and XBoard would automatically promote it when it reaches last rank.

Swapping pieces poses a problem I had not realized yet: how to distinguish it from Fischer castling. I could make the default action for capturing your own piece in XBoard's ApplyMove routine a swap, rather than a capture. And only interpret it as a castling in variants that have castling rights.

[Evert]

.. (and since no other piece can enter the citadel, you could park it there and be safe until you run out of pieces).

That was my first thought to, and it seemed strange to be able to draw so easily. (But of course you first have to promote twice, and then get there alive...) But then I realized thre is an other way: since the opponent King can enter the Citadel, he could capture your adventitious King there! If he has a second royal, he can thus use his King to checkmate your adventitious King in the Citadel.

Note that parking the Adventitious King in your citadel doesn't guarantee you a draw anyway: if you run out of pieces, you will have to move it out. But good catch on being able to walk your (actual) King over to checkmate the Adventitious King in its own citadel!
I haven't seen much promotion action so far (with botched promotions forced to Ferz and no citadels) and I can't really imagine you'd ever get the chance to promote the Pawn of Pawns the full three times (it's three right? Or two? Damn, it's complicated).

I can live with the design where the GUI uses 3 identical Kings, and the engine decides which King can go where. (And the player just has to remember which is which, if he manages to get two in the first place, which doesn't seem so easy.)

Fine with me. It just occurred to me that I can give them all the same piece type, and just tell them apart by their index in the piece list. Same for the pawns.

Of course it does mean that I need to equip Postduif with the highlight command...

Note that when you send feature highlight=1 there is no obligation to send highlight commands. When you have sent 'piece' commands XBoard would always highlight according to its own idea or the Betza string that overrules it, even with legality testing off, simultaneous with sending the 'lift' command. Only when you think it is important to inform the user in advance that this time things work differently you can send a highlight command to overwrite that. And this is only important if that highlight command would have extra or diffently colored highlights, because moves to unjustly highlighted squares (e.g. a forbidden repetition) you can always reject. So it is only when moves are possible that would not be included in the Betza description, or when you want to indicate unexpected promotions (outside the zone or of non-Pawns) or two-leg moves that you need to send a highlight.

As far as I can see in Tamerlane this would only be on the second promotion of the Pawn of Kings to make it a two-leg move (highlighting the promotion squares cyan in the first leg, and the final destination in the second), and to get it off the promotion square after the first promotion. For the second case, I guess you could also promote it to a 'wild-card piece' (native moves of Cobra and Falcon), where XBoard would allow any move that does not capture the King. The Lance used to be a wild-card piece too, before I requisitioned it as a Pawn type. There would be nothing against using it both as a Pawn type and a wild-card piece when on last rank, as Pawns would not normally get there! I could let the wild-card test pre-empt the Betza move generation, so that after making its wild-card move it could be defined to move as a normal Pawn, and XBoard would automatically promote it when it reaches last rank.

It turned out that it was fairly easy to port over the implementation in SjaakII. That just scans the movelist and sends everything relevant in there. I guess there's no harm in that?

Swapping pieces poses a problem I had not realized yet: how to distinguish it from Fischer castling. I could make the default action for capturing your own piece in XBoard's ApplyMove routine a swap, rather than a capture. And only interpret it as a castling in variants that have castling rights.

This reminds me of another funny thing I ran into the other day. I added a cute variant called "Diana Chess" (late 19th century, targeted at draughts players and women); it's basically Los Alamos Chess, except bishops are included and the Queen is replaced by a Knight. However, it also has a type of castling where you exchange places with the rook.
So my first implementation was just KxR. That didn't work so well. For one thing, SjaakII assumes that the rook ends up next to the king after castling (an assumption that is hard-coded and can't be overwritten at the moment). So it would interpret "d1f1" as "King moves to f1, Rook moves to e1". XBoard on the other hand interpreted it as "King moves to e1, Rook moves to d1". Hilarity ensued.
My second implementation was "normal" castling: king moves to e1, rook moves to d1. So, what's "d1e1" then? Neither SjaakII nor XBoard thought it should be castling. It ends up putting the funny "O1" in the piece description.
So in the end I disabled castling altogether because I couldn't get SjaakII and XBoard to agree on how it should be done, and it didn't follow the written rules anyway.

[hgm]

Note that parking the Adventitious King in your citadel doesn't guarantee you a draw anyway: if you run out of pieces, you will have to move it out.

I figured you could always move it back in, and would be stalemated if you could not move out safely. But perhaps stalemate is a win in Tamerlane. The Citadel is a lot like defending KBPK.

Fine with me. It just occurred to me that I can give them all the same piece type, and just tell them apart by their index in the piece list. Same for the pawns.

Indeed, to an engine with piece list basically all pieces are different. The FEN is a problem, however. But the price of making that work is high. Feeding engines with FENs is a crummy way to set up positions anyway: you have no game history. Basically FENs are only useful for the opening position. Just loading an opening line is much better, and would work even in Tamerlane.

Perhaps it is best to simply accept that setting up positions must be done through feeding the engine moves rather than FENs, in some variants. When it gets a FEN the engine could assume Pawns are still in their original file.

It turned out that it was fairly easy to port over the implementation in SjaakII. That just scans the movelist and sends everything relevant in there. I guess there's no harm in that?

That seems the way it is intended to work. The tricky thing is what happens if XBoard reads a move in text form that is at odds with the Betza definition. I guess it should never refuse a move from an engine that is allowed to redefine pieces. But I suppose Tamerlane must be played with legality-testing off anyway.

I pushed XBoard commits now that implement the 'choice' command (first piece mentioned will be the default choice, all pieces must be in capitals) and swapping (in castlingless variants). For Pawns it is enough to emit the 'choice' command in response to 'lift', although for a click-click move I now let it emit an extra 'put' command before the selection of the promotion piece on the to-square starts, in addition to the one emitted after the move completes. So that in cases where promotion is not implied by the from-square choice, you can still send the 'choice' command in response to 'put'. I expect it to be sufficient for Tamerlane, but let me know if there are problems, as I could not really test it.

[Greg Strong]

For what it's worth, I think there value in being able to represent all positions with FENs and having a unique notation for all types of pieces. Of course, for games with lots of piece types it can be difficult or impossible with only single-letter notations. So, in ChessV I allowed two-letter notations. If the first letter of a two-letter notation conflicts with a one-letter notation, you prefix it with an underscore to disambiguate. (The underscore is always removed before any display to the user.) Even for games with less than 26 piece types, I didn't want to have to use random letters, and for example, in Chess with Different Armies, I wanted a unique notation across all armies.

P.S. Good to be back. Glad to see you're both still hard at work creating greater support for chess variants while I've been slacking I plan to be around for a while now that my kids have reached a more manageable age, and hopefully release the completely rewritten ChessV sometime soon.

Cheers,
Greg

[hgm]

Hi Gregory! Great to see you back!

Internally in my engine HaChu, which was designed for doing the large Shogi variants, so that it was sure beforehand that the alphabet would not suffice, I used a position-notation system somewhat similar to what you propose. Except that I disambiguated by pre-fixing all two-letter IDs with a colon. (Even in the case where the first letter might not occur as single-letter ID, because it would require too much thinking to make that distinction, and would make it variant-dependent. And I figured that any single letter would be in use anyway, sooner or later.)

The problem is that I experienced the resulting notations as utterly unreadable, while the whole idea of FEN was that it should be easy to read for humans. So I have been looking for various alternatives. Of course the Shogi habit to write all promoted pieces as the unpromoted form with a + prefix already doubles the alphabet in one swoop, but for everything beyond Chu Shogi that still isn't enough.

One candidate notation was DEMN ("Dailey-Edwards-Muller notation"), which would drop the capital/lower-case distinction between white and black pieces, so that it could be used to disambiguate piece-name boundaries: all piece names would start with a capital, and could be followed by arbitrarily many lower-case letters. The white/black distinction would be made by having two board fields, one for the white and one for the black pieces. Because in most crowded positions pieces are well separated this hardly drove up the size compared to FEN (and sparse positions have short FENs anyway because adjacent empty squares are collapsed to a single digit). And it has the advantage that it can be generalized to multi-player games. This format proved reasonably well readable.

In the latest WinBoard I have settled for another system, though, which is using "dressed letters" as ID in an otherwise normal FEN. The upper/lower-case encoding continues to distinguish sides (WinBoard is a strictly two-player interface), and the piece-boundaries are implied by that only the first character of the ID can be a letter. The following characters ('suffixes') are punctuation characters. By choosing characters with narrow glyphs for this, such as ' and !, the string parses very naturally to the human eye, which tends to group these symbols with the preceding letter. (This was one of the problems with the ':' as prefix.) So in WinBoard 4.9 piece IDs can be L, L' or L!, and could possibly be extended in future versions to also allow L" and L`. With just L' and L! the number of available choices is already increased to 78. This allows you to choose much more reasonable IDs in games with about 20 piece types, and you could even give some intuitive meaning to the suffixes, such as preferably using ! on very strong pieces. E.g. L for Lance, L' for Leopard and L! for Lion.

The Tamerlane Pawn problem seems to require a different approach, though. Although you could of course just use 11 different piece types as Pawns (WinBoard now supports 54 piece types, so no shortage there), and define IDs like R' for Pawn of Rooks, K' for Pawn of Kings, etc. These would then also be used in SAN, like K'e4 instead of the more natural e4, which still seems bearable. You would have to supply external images for the pieces, though, to make them all look Pawn like. Of course you could just clone the regular Pawn image for that, making them undistinguishable in display, or put subtle markings on them (somewhat like I did in the Gold General images for Shogi). You would run into all kind of other hurdles too, though. Like that WinBoard would not naturally assume these piece types would promote when they reach the last rank. But the engine could provide that information through the 'highlight' protocol. So it can be done.

XBoard 4.9 has a fall-back mechanism where every piece for which no external image is defined tries to use the image called 'Tile' (before falling back on a default image). And you could make that a copy of the Pawn image. But it also allows you two write a different UTF8 character on each piece type (intended for on-the-fly generation of images for Shogi kanji pieces). This could conceivably be used to write markings on the Pawns to distinguish them, writing a space on the other pieces. Problem is that the glyph size is probably much too large, so I would have to make the font size used for this user-configurable. (Perhaps I already did that, I would have to check.) No such thing in WinBoard yet, though.

Specifically for the case of Tamerlane it would be nice to use the counter-part of the Shogi +L notation: in stead of L/+L for a promoted/unpromoted pair you could use -L/L. You could adopt the convention that -L is always omitted in SAN moves, because it is a Pawn type. So it would appear only in FEN.

One problem is that WinBoard currently has a rigid way of pairing piece types as promoted-unpromoted partners: it assumes the second 11 pieces are the promoted partners of the first 11 pieces, stemming from the time there were only 22 piece types. And I am not even sure that it woud thing type #35 is the promoted partner of #24, or that it would refuse promotion of it because 24>11, and thus considered already promoted. The code is sprinkled with tests like that, and I am afraid in many places it would use the test type >= 11 where in view of the current situation it should have used type >= NRTYPES - 11, but which was the same when NRTYPES was still 22... In fact I want to abandon that pairing system entirely, as it is a constant source of problems (as not all pieces promote the same in the various Shogi variants). Rather than defining pieces as + or -, and having it implied by a fixed rule what they are the + or - of, it could be explicitly written what they are the + or - of in the pieceToCharTable string that defines that, allowing two-character combinations like -R and +P there. WinBoard could then build a partner[type] table from that, which for backward-compatibility would be initialized as type +/- 11. This requires pretty elaborate code changes, though.

[Evert]

Fine with me. It just occurred to me that I can give them all the same piece type, and just tell them apart by their index in the piece list. Same for the pawns.

Indeed, to an engine with piece list basically all pieces are different. The FEN is a problem, however. But the price of making that work is high. Feeding engines with FENs is a crummy way to set up positions anyway: you have no game history. Basically FENs are only useful for the opening position. Just loading an opening line is much better, and would work even in Tamerlane.

A closer reading of http://history.chess.free.fr/tamerlane.htm revealed the line "Pawns are all different: they were miniature reproduction of one given major piece", which suggests that yes, they were distinguishable.

I ran into an interesting problem last night: I had a Tamerlane Postduif-Postduif match where finally one engine managed to promote a pawn, but they couldn't agree on what it should promote to: one engine wanted it to become a Rook, the other insisted it could only be an Elephant. So I copied the current position, closed down XBoard, fired up the engine in the console to inspect what was up with the position in question - and promptly banged my head on the keyboard because the copied position doesn't have enough information and I should have copied the game instead.

I pushed XBoard commits now that implement the 'choice' command (first piece mentioned will be the default choice, all pieces must be in capitals) and swapping (in castlingless variants). For Pawns it is enough to emit the 'choice' command in response to 'lift', although for a click-click move I now let it emit an extra 'put' command before the selection of the promotion piece on the to-square starts, in addition to the one emitted after the move completes. So that in cases where promotion is not implied by the from-square choice, you can still send the 'choice' command in response to 'put'. I expect it to be sufficient for Tamerlane, but let me know if there are problems, as I could not really test it.

I haven't really been able to test it that far either yet, but I'll let you know!

[Evert]

For what it's worth, I think there value in being able to represent all positions with FENs and having a unique notation for all types of pieces. Of course, for games with lots of piece types it can be difficult or impossible with only single-letter notations. So, in ChessV I allowed two-letter notations. If the first letter of a two-letter notation conflicts with a one-letter notation, you prefix it with an underscore to disambiguate. (The underscore is always removed before any display to the user.) Even for games with less than 26 piece types, I didn't want to have to use random letters, and for example, in Chess with Different Armies, I wanted a unique notation across all armies.

In SjaakII I allow double-character encodings, but the second character has to be a punctuation mark. Beyond that it's arbitrary.
Not particularly pretty, but it works well for communicating with XBoard.

P.S. Good to be back. Glad to see you're both still hard at work creating greater support for chess variants while I've been slacking I plan to be around for a while now that my kids have reached a more manageable age, and hopefully release the completely rewritten ChessV sometime soon.

That would be awesome.
I opened up the ChessV source the other day (with HGM's changes to make it work through XBoard), with the idea to see how hard it would be to make it compile on Linux/OS X. Pretty hard was the answer, so I decided to do something else instead.

It would be really good to have another "current" multi-variant engine (in particular if it's configurable, hint-hint).

[Evert]

XBoard 4.9 has a fall-back mechanism where every piece for which no external image is defined tries to use the image called 'Tile' (before falling back on a default image). And you could make that a copy of the Pawn image. But it also allows you two write a different UTF8 character on each piece type (intended for on-the-fly generation of images for Shogi kanji pieces). This could conceivably be used to write markings on the Pawns to distinguish them, writing a space on the other pieces. Problem is that the glyph size is probably much too large, so I would have to make the font size used for this user-configurable. (Perhaps I already did that, I would have to check.) No such thing in WinBoard yet, though.

Can you specify what font it should use for that? The Quivira font defines a lot of chess-variant picto-graphs in its private use area; I'm not a big fan of the overall style and the fact that they're basically just outlines detracts from their appeal, but they could still be highly useful for this.

By the way - I never realised that there is such a difference between XBoard and WinBoard in this respect, I thought they were pretty much the same these days. Why is there this difference?

Specifically for the case of Tamerlane it would be nice to use the counter-part of the Shogi +L notation: in stead of L/+L for a promoted/unpromoted pair you could use -L/L. You could adopt the convention that -L is always omitted in SAN moves, because it is a Pawn type. So it would appear only in FEN.

One problem is that WinBoard currently has a rigid way of pairing piece types as promoted-unpromoted partners: it assumes the second 11 pieces are the promoted partners of the first 11 pieces, stemming from the time there were only 22 piece types. And I am not even sure that it woud thing type #35 is the promoted partner of #24, or that it would refuse promotion of it because 24>11, and thus considered already promoted. The code is sprinkled with tests like that, and I am afraid in many places it would use the test type >= 11 where in view of the current situation it should have used type >= NRTYPES - 11, but which was the same when NRTYPES was still 22... In fact I want to abandon that pairing system entirely, as it is a constant source of problems (as not all pieces promote the same in the various Shogi variants). Rather than defining pieces as + or -, and having it implied by a fixed rule what they are the + or - of, it could be explicitly written what they are the + or - of in the pieceToCharTable string that defines that, allowing two-character combinations like -R and +P there. WinBoard could then build a partner[type] table from that, which for backward-compatibility would be initialized as type +/- 11. This requires pretty elaborate code changes, though.

This is a bit similar to what SjaakII does: for each piece-type it has a bitmask of what piece types it can promote to, and another to indicate what it demotes to (which it only does when a piece is captured, I think). It would be great to have similar freedom in XBoard, but I can imagine that overhauling the code is a lot of tedious work that requires a lot of tedious testing.

I know it's the sort of internal detail thing that engines shouldn't be exposed to, but it would be really useful if there were some way to check what can and cannot be done through the piece-to-char table. In Postduif I have a setting that changes the piece-to-char that is sent to XBoard, so that it can still work on XBoard 4.8 (replacing the Zebra with a Nightrider and the Lion with a ... Cobra, I think). The user needs to activate that by hand though, which isn't ideal. If there is a new/better way to indicate promotion/demotion options, it would be useful if the engine could know about this so that it can use it, or fall back on the old method if needed/possible (just generate an error and tell people to upgrade if it isn't).
That's a whole different can of worms though...