FEEN?

[Don]

Also, games with a dominant Asian tradition should be using Asian language glyphs. For many years the Sons of Asia have learned and used a non-native character set; shouldn't the Sons of Europe now act reciprocally?

Using kanji glyphs (encoded in UTF-8, say) for representing board positions of the large Shogi variants is in itself a good idea, which would immediately enjoy wide support from people currently playing these games. There is one real problem, though: unlike latin characters, kanji don't come in an upper-case and lower-case variety that could be used to distinguish the sides. A popular format for Shogi diagrams is simply bare kanji written in a table representing the board:



in this case the sides are distinguished by writing thekanji for one of the players upside down, which is a very natural representation for Shogi players, because in over-the-board play the orientation of the pieces similarly decides which side they are on. But unfortunately, there are no UTF-8 encodings for upside-down kanji...

Also, in games like Tai Shogi (25x25) it is not really possible to make unique single-kanji names for all the pieces with kanji that occur in their multi-kanji name. This because the same kanji occur in the names of many pieces. E.g. there are Gold, Silver, Copper, Left, Right and Great Generals, but also a Great, White and Drunk Elephant and a Great Dragon, a Flying Dragon and a Blue Dragon, a Dragon Horse and a Dragon King, a Honorable and a White Horse, a Left, Right and Flying Chariot, a Chariot Soldier, a Vertical and a Side Soldier, Vertical and Side Movers, etc., all with 2-kanji names. So although there are enough kanji in the Chinese/Japanese alphabet, there would not be an obvious mapping of single kanji to pieces.

Another problem is that even though such a representation would be applauded by (the quite small number of) existing players of these variants, it would be a great obstacle to a wider popularity.

In the absence of lowercase one could have 2 position fields - one for each side. It would make the fen string itself larger but presumably that is going to happen no matter what you do.

[Don]

How often is chess/shogi/xiangqi data originated by hand via a keyboard compared to being generated by an application? Ease of keyboard entry should be a minor consideration at best.

Trying to fit board data for tan shogi or taikyoku shogi or my GatChess (more on this later) on a single line of text is a hopeless task. Forcing the use of non-Asian glyphs for Asian games is chauvinistic to the point of cultural arrogance.

I wouldn't go that far - English has become a universal standard. Air traffic controllers for example must all know English and the entire world has been taught English as a second language. If you want good international communication it is necessary to have such a language and the entire world is accustomed to using English for this and especially in computing systems. All the mainstream programming language are based on English keywords. So this is not chauvinistic, it is just good sense. It's the only way to accommodate almost everyone without leaving entire groups of people out.

Having said that, UTF-8 characters are not a big deal and I don't see a problem with using them to describe the position. Also, I don't like it when they "americaninze" pieces for the GUI display, for example converting the classical Shogi pieces to a different form to make Western users happier. That would be like drawing Chinese characters on tokens to accommodate Chinese users for western chess - it would seem rather silly to us.

If we up to me we would all learn Esperanto as a second language and that would become the international standard. It's a very nice little language that can be quickly learned. But that would leave just about EVERYONE out in the dark!

Here's what I propose:

[Part 0]

For each kind of chess/shogi/xiangqi, produce a Well-Formed-Object specification for position state representation. Each WFO specification is a bijective map to a conceptual diagram. However, the actual colors, fonts, and display attributes used to present the diagram are under application control. Application examples: a chess program, a shogi GUI, or a xiangqi document editor. The actual binary data is realized as a stream of Unicode so that it be readable by developers.

[Part 1]

For purposes of cut+paste, each WFO instance as needed gets its own hyperlink. The link will usually, but not always, point to some locally stored data. To cut+paste the position state, just cut+paste the link.

Example:

Say that there is a TalkTaikyokuShogi.com discussion board hosted in Tokyo, and on my computer is my own taikyoku shogi program. To communicate a diagram, I first have my program produce a position state snapshot which is presented to me as a short URL to local data. I then use my mouse to select and copy the URL and then paste it into the text box browser page from the TalkTaikyokuShogi.com site. A little JavaScript eats the paste which copies the local snapshot data and sends it on its way to be reproduced on the site's host machine. For the reverse, the reverse. No muss, no fuss, and no errors. Everyone gets to use the diagram style of their choice.

[hgm]

In the absence of lowercase one could have 2 position fields - one for each side. It would make the fen string itself larger but presumably that is going to happen no matter what you do.

Interesting idea. As in practical middle-game positions the various sides would not penetrate much into each other's lines, so the opponent's camp in such a representation would pretty much show up as an empty board half. And FENs are quite efficient in encoding empty space. So the FEN would not grow that much longer. In the late end-game, when all pieces roam the board, there would not be many pieces anyway, and the FEN would be short.

Not having to worry about distinguishing sides could also be very beneficial for encoding in ASCII. It is not just that you could double the available IDs by using both upper and lower case for the same side, (which would still not be enough for some of the bigger variants), but you could use a compact encoding with two-letter IDs (or actually arbitrary length IDs) without separators, where the first letter would be a capital. For the Chu Shogi start position this would give

LFlCSGKDeGSCFlL/Rv1B1BtPhKyBt1B1Rv/SmVmRDhDkFkLnDkDhRVmSm/PPPPPPPPPPPP/3Gb4Gb3/12/12/12/12/12/12/12//12/12/12/12/12/12/12/3Gb4Gb3/PPPPPPPPPPPP/SmVmRDhDkLnFkDkDhRVmSm/Rv1B1BtKyPhBt1B1Rv/LFlCSGDeKGSCFlL w 0 1

which is sort of readable.

I was thinking myself about using two-character piece IDs where the second is a letter that would encode the side in the usual way, but the first one would be non-alphanumeric, so that it can easily be recognized as a prefix altering the meaning of the following letter. E.g. using . , : ; as prefixes you would already have 4 x 26 possible IDs. This is far less than the 26x26 that can be achieved with Don's proposal, but enough for anything but the very largest (some would say 'insane') variants. The prefixes would have little optical density, and naturally act as separators to enhance readability. The Chu Shogi start position in this notation could look like:

.l,l.c.s.g.k.e.g.s.c,l.l/,r1.b1.t,p:k.t1.b1,r/,s.v.r.h.d;f;l.d.h.r.v,s/.p.p.p.p.p.p.p.p.p.p.p.p/3,g4,g3/12/12/3,G4,G3/.P.P.P.P.P.P.P.P.P.P.P.P/,S.V.R.H.D;L;F.D.H.R.V,S/,R1.B1.T:K,P.T1.B1,R/.L,L.C.S.G.E.K.G.S.C,L.L w

where .L would mean Lance but ,L would mean Ferocious Leopard, etc. I guess it might be better to also allow pieces without prefix, and with a space prefix

l.lcsgkegsc.ll/.r1b1t.p:kt1b1.r/.svrhd;f;ldhrv.s/pppppppppppp/3.g4.g3/12/12/3.G4.G3/PPPPPPPPPPPP/.SVRHD;L;FDHRV.S/.R1B1T:K.PT1B1.R/L.LCSGEKGSC.LL w

I think Don's proposal is better. It is also easily extendible to games with more than two players. The downside is that there is no backward compatibility with the FEN standard for Chess.

[Don]

Interesting idea. As in practical middle-game positions the various sides woul not penetrate much into each other's lines, the oppoent half so the board in such a representation would pretty much show up as an empty board half. And FENs are extremely efficient in encoding empty space. So the FEN would not grow that much longer.

Not having to worry about distinguishing sides could also be very beneficial for encoding in ASCII. It is not just that you could double the available IDs by using both upper and lower case for the same side, (which would still not be enough for some of the bigger variants), but you could use a compact encoding with two-letter IDs (or actually arbitrary length IDs) without separators, where the first letter would be a capital. For the Chu Shogi start position this would give

LFlCSGKDeGSCFlL/Rv1B1BtPhKyBt1B1Rv/SmVmRDhDkFkLnDkDhRVmSm/PPPPPPPPPPPP/3Gb4Gb3/12/12/12/12/12/12/12//12/12/12/12/12/12/12/3Gb4Gb3/PPPPPPPPPPPP/SmVmRDhDkLnFkDkDhRVmSm/Rv1B1BtKyPhBt1B1Rv/LFlCSGDeKGSCFlL w 0 1

which is sort of readable.

I was thinking myself about using two-character piece IDs where the second is a letter that would encode the side in the usual way, but the first one would be non-alphanumeric, so that it can easily be recognized as a prefix altering the meaning of the following letter. E.g. using . , : ; as prefixes you would already have 4 x 26 possible IDs. This is far less than the 26x26 that can be achieved with Don's proposal, but enough for anything but the very largest (some would say 'insane') variants. The prefixes would have little optical density, and naturally act as separators to enhance readability. The Chu Shogi start position in this notation could look like:

.l,l.c.s.g.k.e.g.s.c,l.l/,r1.b1.t,p:k.t1.b1,r/,s.v.r.h.d;f;l.d.h.r.v,s/.p.p.p.p.p.p.p.p.p.p.p.p/3,g4,g3/12/12/3,G4,G3/.P.P.P.P.P.P.P.P.P.P.P.P/,S.V.R.H.D;L;F.D.H.R.V,S/,R1.B1.T:K,P.T1.B1,R/.L,L.C.S.G.E.K.G.S.C,L.L w

where .L would mean Lance but ,L would mean Ferocious Leopard, etc. I guess it might be better to also allow pieces without prefix, and with a space prefix

l.lcsgkegsc.ll/.r1b1t.p:kt1b1.r/.svrhd;f;ldhrv.s/pppppppppppp/3.g4.g3/12/12/3.G4.G3/PPPPPPPPPPPP/.SVRHD;L;FDHRV.S/.R1B1T:K.PT1B1.R/L.LCSGEKGSC.LL w

I think Don's proposal is better. It is also easily extendible to games with more than two players. The downside is that there is no backward compatibility with the FEN standard for Chess.

One has to also decide whether concise encoding is the primary goal or not. If fen is primarily for humans (which presumably forsyth notation was indeed) then consideration should be given for that, if it's for GUI's and computers it's a different consideration. Fen is not very natural for parsing by computer - it's not that difficult but it's tedious and illogical for computers. It's rare that a human hand enters fen notation but I have done so from time to time.

[hgm]

Well, WinBoard/XBoard does allow you to type a FEN in Edit Position mode, and doing so for a complex position can actually be very competitive to using the mouse and the piece menu. Certainly if the menu would become huge. Let's face it: there is no easy way to enter a dense position on a 25x25 board.

So I think I will go for the separated-sides notation in XBoard. Perhaps with some extra leading character to make it immediately obvious to the parser that this is not an ordinary FEN. We could call it Dailey-Edwards-Muller Notation (DEMN!)

[Don]

Well, WinBoard/XBoard does allow you to type a FEN in Edit Position mode, and doing so for a complex position can actually be very competitive to using the mouse and the piece menu. Certainly if the menu would become huge. Lets face it: there is no easy way to enter a dense position on a 25x25 board.

So I think I will go for the separated-sides notation in XBoard. Perhaps with some extra leading character to make it immediately obvious to the parser that this is not an ordinary FEN. We could call it Dailey-Edwards-Muller Notation (DEMN!)

It's a good thing Steven Edwards was not born Steven Ackerman!

I am a command line junkie myself, I LOVE the keyboard and despise working with the mouse. Although I use the Linux windows managers I am only a short step away from doing away with that and using only the console - but that is no longer practical since I get a lot of documentation on the web when doing software development.

The nice thing about Linux is that you have a number of virtual consoles and by using utlities such as "screen" you can get as many separate consoles as you would ever want.

[cyril]

Thank you all for your interest to the FEEN format! I'm glad I read opinions, even objections.

Cyril Wack has proposed the so called "Forsyth-Edwards Expanded Notation" for cross-board and cross-style computer chess applications, that is for Shogi, Western, Xiangqi and for more than two dimensions, e.g. 3D chess.

Yes, because it's cross-style, Shogi, Western, Xiangqi, and even more exotic chess games could be compatibles.
It's also cross-board so board can be n-dimensional (from 1 to ∞), whatever the size of each dimension.

[melajara]

For many years the Sons of Asia have learned and used a non-native character set; shouldn't the Sons of Europe now act reciprocally?

Are you seriously considering that trading 26 characters for up to 80'000 is a fair "reciprocal" exchange?

And I thought you were extolling the virtues of terse notations

[cyril]

I can confirm that I was not involved. After glancing to the proposal, my first impression is that it is rather absurd. I am not sure what problem the inventor is trying to solve with this.

The goal of this format is to describe a particular board position of a two-players cross-board and cross-style chess game.

Especially putting a 'style' prefix on every piece name seems a very counter-productive way of doing things.

As well as FEN use algebraic notation's piece naming, in FEEN, piece naming come from PCN. The reason is that, inside chess variants, there's a lot of different pieces which sometime have the same name and the same abbreviation. As we could imagine, without a style prefix, collisions may occur.
Sure, this extends the size of the piece name and, by extension, it also extends the size of FEEN strings. We could certainly find some other way to compress more. However, thus, parsing remains easy.

In a FEEN for Chess all pieces would need a w: or W: prefix to indicate the following piece ID refers to orthodox Chess ('western style'). As one almost never deals with games that mix pieces of different games (and if they do, usually have many original new piece types which would not exist in any style), this seems extremely wasteful.

Yes that's true, I agree with you. For instance, in a chess game with two Western players, the FEN standard should be used and I recommend it. Here, using a long FEEN string would be extremely wasteful. Even if its board fingerprint of 256-bits can always help to identify positions, especially in database.

If some clarification would be needed as to what the letters in a FEN-like notation mean, it would be much better to express that in a single prefix to the entire FEN, naming the variant. Like xiangqi: or xq:.

Yes, this would be great. By this way, the style name could be centralized, following "Don't Repeat Yourself" principe. In some cases however, collisions may occur, despite the use of uppercase and lowercase.
Let's consider for instance a game with a Western player against a Shogi player, where at the beginning there are Western pawns with "P" abbreviation and Shogi pawns with "p" abbreviation. Everything is fine. Until a "P" is captured.

[hgm]

For many years the Sons of Asia have learned and used a non-native character set; shouldn't the Sons of Europe now act reciprocally?

Are you seriously considering that trading 26 characters for up to 80'000 is a fair "reciprocal" exchange?

And I thought you were extolling the virtues of terse notations

Note that I did not write that. You are quoting Steven here.