FEN for multiplayer variants

[leanchess]

I recently started dabbling with fairy chess, and couldn't find any solid FEN extension/replacement for multiplayer variants.

Is anyone aware of a good one?

Regardless, I came up with an idea of a nice multiplayer (and, in fact, multidimensional) FEN replacement.

For example, this is the startpos for quatrochess (if I read the diagram correctly):

Code: Select all

/rKFCRH4bHRQWK/rWGLNH4bHNLGF/rQLGAH4bHBGLC/rRNBBH4bHBANR/rPPPPM4MPPPPP/14/6**6/6**6/14/wPPPPM4gMPPPP/wRNABH4gHBBNR/wCLGBH4gHAGLQ/wFGLNH4gHNLGW/wKWQRH4gHRCFK wrbg - -

Note the leading / that tells the processor to treat it as MFEN (tentative name). This is my idea of backwards compatibility with FEN

I used G for Giraffe, H for Horizontal Pawn and L for Camel. What do you guys think?

[leanchess]

(if I read the diagram correctly)

Of course I didn't. I just read the caption, and it turns out the inverted knight is the giraffe.

Just pretend that G means camel and L means giraffe.

[leanchess]

Here's something a little more interesting:

Code: Select all

/gL(WT)(RR)W(DM)(MR)(LO)(BC)(HR)(FR)(ED)(WO)(FT)Q(RS)(RG)G(CP)KG(LG)(RS)Q(FT)(CD)(ED)(FR)(HR)(BC)(LO)(ML)(DM)W(RR)(TS)L/g(RV)(FG)(TD)(FS)(CO)(RA)(FO)(MS)(RP)(RU)(SS)(GR)(RT)(BA)(YA)(GU)S(DE)(NK)S(WR)(BD)(BA)(RT)(GR)(SS)(RU)(RP)(MS)(FO)(RA)(CO)(FS)(TD)(WE)(RV)/g(GC)(SI)(RN)(RW)(BG)(RO)(TT)(RI)(BO)(WD)(FP)(RB)(OK)(PC)(WA)(FI)C(PM)(KM)C(FI)(WA)(PC)(OK)(RB)(FP)(WD)(BO)(LE)(LT)(RO)(BG)(RW)(RN)(SI)(GC)/g(SV)(VE)N(PI)(CG)(PG)HO(CN)(SA)(SR)(GL)(LN)(CT)(GS)(VD)(WL)(VG)(GG)(WL)(VD)(GS)(CT)(LN)(GL)(SR)(SA)(CN)OH(PG)(CG)(PI)N(VE)(SV)/g(CI)(CE)BR(WF)(FC)(MF)(VT)(SO)(LS)(CL)(CR)(RH)(HE)(VO)(GD)(GO)(DS)(DV)(GO)(GD)(VO)(HE)(RH)(CR)(CL)(LS)(SO)(VT)(MF)(FC)(WF)RB(CE)(CI)/g(WC)(WH)(HD)(SM)(PR)(WB)(FL)(EG)(FD)(PS)(FY)(ST)(BI)(WG)F(PH)(HM)(LL)(GT)(CA)(KR)F(WG)(BI)(ST)(FY)(PS)(FD)(EG)(FL)(WB)(PR)(SM)(HD)(WH)(WC)/g(TC)(VW)(SX)(DO)(FH)(VB)(AB)(EW)(LH)(CK)(OM)(CC)(NB)(SU)(VS)(NT)(TF)(MT)(RM)(TF)(NT)(VS)(ES)(WS)(CC)(OM)(CK)(LH)(EW)(AB)(VB)(FH)(DO)(SX)(VW)(TC)/g(EC)(VI)(EB)(HO)(OW)(CM)(CS)(SW)(BM)(BT)(OC)(SF)(BB)(OR)(SQ)(SN)(RD)(FE)(LI)(RD)(SN)(SQ)(OR)(BB)(SF)(OC)(BT)(BM)(SW)(CS)(CM)(OW)(HO)(EB)(BL)(EC)/g(CH)(SL)(VR)(WN)(RE)M(SD)(HS)(GN)(OS)(EA)(BS)(SG)(LP)T(BE)I(GE)(GM)I(BE)T(LP)(SG)(BS)(EA)(OS)(GN)(HS)(SD)M(RE)(WN)(VR)(SL)(CH)/g(RC)(MK)(VM)(OX)(LB)(VP)(VH)(BN)(DH)(DK)(SE)(HF)(EL)(SP)(VL)(TG)(SC)(DG)(LD)(SC)(TG)(VL)(SP)(EL)(HF)(SE)(DK)(DH)(BN)(VH)(VP)(LB)(OX)(VM)(MK)(LC)/gPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP/5gD4(GB)3D6D3(GB)4D5/36/36/36/36/36/36/36/36/36/36/36/36/5sD4(GB)3D6D3(GB)4D5/sPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP/s(LC)(MK)(VM)(OX)(LB)(VP)(VH)(BN)(DH)(DK)(SE)(HF)(EL)(SP)(VL)(TG)(SC)(LD)(DG)(SC)(TG)(VL)(SP)(EL)(HF)(SE)(DK)(DH)(BN)(VH)(VP)(LB)(OX)(VM)(MK)(RC)/s(CH)(SL)(VR)(WN)(RE)M(SD)(HS)(GN)(OS)(EA)(BS)(SG)(LP)T(BE)I(GM)(GE)I(BE)T(LP)(SG)(BS)(EA)(OS)(GN)(HS)(SD)M(RE)(WN)(VR)(SL)(CH)/s(EC)(BL)(EB)(HO)(OW)(CM)(CS)(SW)(BM)(BT)(OC)(SF)(BB)(OR)(SQ)(SN)(RD)(LI)(FE)(RD)(SN)(SQ)(OR)(BB)(SF)(OC)(BT)(BM)(SW)(CS)(CM)(OW)(HO)(EB)(VI)(EC)/s(TC)(VW)(SX)(DO)(FH)(VB)(AB)(EW)(LH)(CK)(OM)(CC)(WS)(ES)(VS)(NT)(TF)(RM)(MT)(TF)(NT)(VS)(SU)(NB)(CC)(OM)(CK)(LH)(EW)(AB)(VB)(FH)(DO)(SX)(VW)(TC)/s(WC)(WH)(HD)(SM)(PR)(WB)(FL)(EG)(FD)(PS)(FY)(ST)(BI)(WG)F(KR)(CA)(GT)(LL)(HM)(PH)F(WG)(BI)(ST)(FY)(PS)(FD)(EG)(FL)(WB)(PR)(SM)(HD)(WH)(WC)/s(CI)(CE)BR(WF)(FC)(MF)(VT)(SO)(LS)(CL)(CR)(RH)(HE)(VO)(GD)(GO)(DV)(DS)(GO)(GD)(VO)(HE)(RH)(CR)(CL)(LS)(SO)(VT)(MF)(FC)(WF)RB(CE)(CI)/s(SV)(VE)N(PI)(CG)(PG)HO(CN)(SA)(SR)(GL)(LN)(CT)(GS)(VD)(WL)(GG)(VG)(WL)(VD)(GS)(CT)(LN)(GL)(SR)(SA)(CN)OH(PG)(CG)(PI)N(VE)(SV)/s(GC)(SI)(RN)(RW)(BG)(RO)(LT)(LE)(BO)(WD)(FP)(RB)(OK)(PC)(WA)(FI)C(KM)(PM)C(FI)(WA)(PC)(OK)(RB)(FP)(WD)(BO)(RI)(TT)(RO)(BG)(RW)(RN)(SI)(GC)/s(RV)(WE)(TD)(FS)(CO)(RA)(FO)(MS)(RP)(RU)(SS)(GR)(RT)(BA)(BD)(WR)S(NK)(DE)S(GU)(YA)(BA)(RT)(GR)(SS)(RU)(RP)(MS)(FO)(RA)(CO)(FS)(TD)(FG)(RV)/sL(TS)(RR)W(DM)(ML)(LO)(BC)(HR)(FR)(ED)(CD)(FT)Q(RS)(LG)GK(CP)G(RG)(RS)Q(FT)(WO)(ED)(FR)(HR)(BC)(LO)(MR)(DM)W(RR)(WT)L sg

[hgm]

You could look for 'DEMN' (Dailey-Edwards-Muller Notation) in this forum, e.g. viewtopic.php?p=532810 .

Basically the idea is to have separate FENs for each player (so that there is no need to distinguish the players through upper/lower case, and even multi-character piece IDs could be used provided that you capitalize only the first character). The various FENs are then concatenated with a '#' as a separator, in turn order. So for orthodox Chess white would come first, e.g.

8/8/8/8/8/8/PPPPPPPP/RNBQKBNR KQ#RNBQKBNR/PPPPPPPP KQ/8/8/8/8/8/8#w - 0 1

where the (player-specific) castling rights would go in the player parts, and other game state description at the end. Because armies tend to be well-separated during most of the game this is not very much longer than a normal FEN:

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w - 0 1 KQkq

Conventional method for allowing multi-character piece IDs in Forsyth notation is to separate the piece IDs by commas.

[leanchess]

You could look for 'DEMN' (Dailey-Edwards-Muller Notation) in this forum, e.g. viewtopic.php?p=532810 .

Thank you for your reply.

8/8/8/8/8/8/PPPPPPPP/RNBQKBNR KQ#RNBQKBNR/PPPPPPPP KQ/8/8/8/8/8/8#w - 0 1

That's why I explicitly asked for a good one.

I believe what I'm proposing is much more readable. Here's startpos in MFEN (still subject to change):

Code: Select all

/bRNBQKBNR/bPPPPPPPP/8/8/8/8/wPPPPPPPP/wRNBQKBNR wb wAHbAH - 0 1

Conventional method for allowing multi-character piece IDs in Forsyth notation is to separate the piece IDs by commas.

I believe the FFEN way is better (as exemplified in my previous post with takiyoku shogi).

Unless DEMN is already widely used, I think I'll keep working on my idea.

Speaking of which, as I was formalising it, I came up with the following recommendations for fairy piece encodings:

Code: Select all

| Character | Piece           | XBN
| --------- | --------------- | --
| `A`       | Archbishop      | BN
| `C`       | Chancellor      | RN
| `D`       | Dabbaba         | D
| `E`       | Alfil           | A
| `F`       | Ferz            | F
| `G`       | Giraffe         | (1,4)
| `H`       | Horizontal pawn | mfWcefFimfnD
| `I`       | Tripper         | G
| `J`       | Zebra           | Z
| `L`       | Camel           | C
| `M`       | Mann            | K
| `O`       | Immobile        | O
| `S`       | Grasshopper     | ?
| `T`       | Threeleaper     | H
| `U`       | Unicorn         | NN
| `V`       | Duck            | -
| `W`       | Wazir           | W
| `Y`       | Berolina pawn   | mfFcefWimfnA
| `Z`       | Amazon          | QN

I'd appreciate your (especial hgm's) feedback on this (Is there indeed no way to properly distinguish between the orhodox and the horizontally-moving pawn using XBetza?)

Thanks!

[hgm]

Having a fixed assignment of IDs for fairy pieces seems a hopeless endeavor. Even the most common ones do not have universibly accepted names, making it even worse. (E.g. in many variants the RN and BN compounds are called Marshall and Cardinal.) Initially I started with such a fixed assignment in WinBoard, but I quickly gave up on that, and made the IDs just a configurable parameter.

To support games with more than 26 pieces WinBoard allows some diacritical suffixes on a one-letter piece IDs, like L', L" of L!. This doesn't interfere much with readability.

Your idea of using a player-prefix is interesting. The readability might be a subjective thing; I don't see any significant difference in the DEMN or MFEN representation of the FIDE start position. (The DEMN notation could even be improved in this respect by adopting the convention that each army could be shown from the corresponding player's POV.) In the areas without enemy incursion the descriptions would be very much the same. (You could even adopt the convention in MFEN that the effect of a color-prefix even extends to subsequent aows.) A more discriminating example might be a middle-game position where the armies are thoroughly interpenetrating in the central area.

In, say, a 4-player game most of the pieces in the combat area would need a color-prefix, potentially doubling the length of the description. In the army representation of DEMN any enemy piece would show up as an empty square, potentially combining with other empty squares on the same rank into a longer stretch. Which might even reduce the length of the description if there are empty squares left and right. But of course you already started with a description that added the description of an empty area at the opponent camps 4 times. (This could be further ammeliorated by allowing rank-spanning stretches to be encoded by a single number, i.e. write 32 instead of 8/8/8/8 (or something like 4:8).

Personally I like comma separation better than parenthesizing, for readability. If all pieces have multi-letter IDs it requires fewer characters (readability isn't very good if the line doesn't fit on the display...), but if there is an exceptional two-letter ID amongst single-letter IDs only parenthesizing those would be more compact than having commas everywhere. Of course a standard could allow both methods, but that would cause non-uniqueness of the representation. In the Interactive Diagram I now allow optional comma separation in values of parameters that resepresent a set or matrix of piece IDs, where presence of a comma in the decription of a row implies all elements on the row are comma-separated, while otherwise each character of the row is an element on its own.

I have my doubts on the usefulness of FEN-like representation for large games anyway. WinBoard protocol supports an 'obsolete' method for setting up positions, which just sends a number of lines containing piece ID and square coordinates, (and a command to switch colors), and this has no problem accepting multi-letter piece IDs or more than 2 colors at all. FEN loses much of its appeal when they get so long that they no longer fit on a line.

I don't understand your question about the Horizontal Pawn. If the (XBetza) move is the same (as you show it here) then the piece is the same, so why is there any need to distinguish? What you call 'Horizontal Pawn' is just a normal FIDE Pawn, presumably for a player that plays in a direction that the player with the first move perceives as 'sideways'. We also don't 'properly distinguish' white and black Pawns. I consider it one of the strengths of XBetza notation that it describes the pieces from the owning player's POV, so that white and black pieces have the same move. Recently I even changed the Interacive Diagram's interpretation of l and r in XBetza for the black player in a Diagram where you specified mirror symmetry to preserve that property in the presence of pieces with left-right asymmetry.