Comments by HGMuller

Fergus Duniho:
| Very Good. Zillions of Games and Game Courier both provide software 
| support for numerous variants. ChessV supports several games. Shogi, 
| Chinese Chess, and selected other variants have dedicated programs to 
| play them.

You forget to mention WinBoard and Fairy-Max!

About FEN standardization:

I agree with most of what Fergus says. The purpose of a FEN is to express
the game state, not describe the game.

I would not be against having the FEN unambiguously desrcibe the board,
though. So I would like to outlaw 'sloppy' FENs, which do not fill out
the ranks completely, and use the rank-separator '/' to imply the rest
of the rank is empty. This would only invite undetectable errors.
Preferably a FEN reader should be able, once it knows the variant, to
detect omissions or spurious characters in the FEN.

I would also like to fix the use of various types of parentheses: The
brackets [] should preferably be reserved for delimiting an optional
holdings field in the FEN, for games with piece drops like Crazyhouse and
Shogi. For delimiting multi-character piece names, we coud use braces {}
to delimit arbitrary names referring to the legend, like {griffon} or
{Griffon}. The first letter decides if the piece is white or black,
through being upper or lower case, respectively. Upper and lower case in
the rest of the name are at the disposal the creator of the legend to
enhance readaility, e.g. {MurrayLion}, {highPriestess}. Normal parentheses
() I would like to reserve for delimiting fully descriptive piece
indications, like (BN), according to some nearly universal
(variant-independent) notation similar to Betza notation.

The Cannon indeed seems to have the strongest claim on the letter C
(altough most people call it Pao...). But we should not be blind to
reality. Any 'standard' that will not allow Chancellor to be indicated
by C in Capablanca-type variants is still-born. Too many people and too
much software World wide is already using the FENs with the C in it. So a
standard that outlaws this might as well be referred to the garbage bin
immediately. The most reasonable compromise that makes the standard viable
seems to be the use of board-width dependent defaults, and predefine A=(BN)
and C=(RN) on a 10-wide board. This hurts no one: variants that name these
pieces differently can simply use (BN) and (RN), and are off no worse than
they would have been when A and C were not predefined.

Actually we might even go a step further, and allow the variant-specific
legend to define any one-letter code as it pleases, just as it can define
multi-letter piece names. I am not even sure if there would be any reason
to protect the letters for the orthodox Chess pieces from redefinition.
The FEN reader could always look in the legend first to see what a letter
means. If the letter is not listed, the defaut meaning (if any) would
apply. If there is also no default in force, we have a FEN syntax error.

The CVML discussion is hard to follow for me, as I don't know Game
Courier. When I play Chess Variants, I use the WinBoard GUI. WinBoard
supports local play against a computer opponent (if you have an AI
available that can play the variant), play on an Internet Chess Server
against any other entity that is logged in on that server, play of an AI
against the ICS, local play between two AIs, or can be used as a game
viewer/editor.

Now ICS (like FICS and ICC) only support a very limited number of
variants, and the protocol with which they operate is not suitable for
variants in general. There is a server where you can play the unspeakable
10x8 variant, but it uses and entirely different protocol. I have written
a back-end to WinBoard to communicate in this protocol, so WinBoard can be
used as a GUI to play or have computer AIs play on that server. In cases
like these, the communication channel is a TCP link to a dedicated port of
the server.

What is the underlying medium that Game Courier uses to connect players
with each other? Is there a specialized server somewhere, or can any POP
server act as such (and would a dedicated account be needed on the POP
server, in that case)? What communication channel is used, and what is the
protocol on this channel? If I new that, it might be possible to directly
connect WinBoard to the system, so that people can play through a regular
GUI.

To Rich:

WinBoard is an application that runs locally on your PC, and displays a
Chess board there. You can enter moves by typing them, but the more common
way is to just drag the displayed pieces with the mouse to the square where
you want to move. You can put WinBoard in a mode where it accepts every
move (of the side that is to move) or where it checks if the move is
allowed. The latter of course only works for variants WinBoard knows the
rules of.

WinBoard is limited to rectangular boards, knows 22 piece type, can handle
variants with piece drops. Amongst the fully supported variants are Chess,
Shatranj, Xiangqi and Shogi.

WinBoard merely is a GUI, i.e. an I/O device for Chess moves, and it
takes care of such tasks as saving the game on a file in standard
(Human-readable) format, loading saved games for viewing, copying and
pasting games and positions to and from the clipboard. It communicates the
moves to entities that play the game. Locally this might be other processes
that think up the moves, with which it communicates in a text-based
standard language known as 'WinBoard protocol'. (The 'Chess-Engine 
communication protocol you found the link for) This protocol is the
current 'market leader', and there are litterally hundreds of engines
that understand it. The 'Universal Chess Interface' is a recent
competitor of WB protocol. Adapters between UCI and WB protocol exist in
both directions.

UCI is rather limited in its support for variants: It does go as far as
Chess960, but I believe Crazyhouse is already 'a bridge too far'.

WinBoard can also act as a 'client' to communicate with a Chess Server
over the internet (e.g. FICS, ICC). For this it uses a different protocol
(ICS protocol), which does supports 'variants' like losers and atomic,
and even Shatranj. But nothing beyond 8x8 boards.

Currently WB cannot be used to login on the CV pages. But if I knew the
protocol needed to play on the CV pages, I could make WinBoard support
that too. I have done the same thing for the Unspeakable-Variant server.
What I understand from Fergus, playing on the CV pages involves polling
html pages until you see a change, and then uploading your own move over a
TCP link. (Correct me if I am wrong, Fergus!)

Well, as they say, one program paints a thousand words, so if you really
want to get an idea what WinBoard is, you can try it out by downloading
from http://home.hccnet.nl/h.g.muller/WinBoard_F.zip , and clicking the
'Fairy-Max' icon in the downloaded folder. You can then immediately
start playing the Mad-Queen game, or select one of the variants in the
menu that the Fairy-Max engine (included in the download) plays, like
Knightmate, Capablanca, Shatranj, Falcon, Superchess, Courier. (Note it
does not nearly play all variants supported by WinBoard. If you want to
play Xiangqi, Shogi, Crazyhouse or Losers you would have to download other
engines for this.)

What other games do you have in mind? Checkers and Go? Bridge and Poker? Of
course any program can be changed to do anything else, but the question is
if this is useful. The current WinBoard is designed for Chess-like games,
and rests on the assumptions that there are only two players, which
alternate turn, in which they move only a single piece to a square that is
empty or occupied by an opponent. 

Normally there are no side effects to a move. The protocol does not
provide a mechanism to specify side effects, it just specifies a From and
a To square. The rare side effects that occur in Chess (castling and e.p.)
are implied. Only for promotions the promotion piece is specified.

For games like Checkers and Go you basically would have to teach WinBoard
what the side effects of the moves are (capture of opponent pieces on
jumping or surrounding), and this would be easier if you were using a
dedicated GUI for Checkers or Go. For games with hexagonal or triangular
boards the required graphics would be so different, that it also makes no
sense to integrate it in the same GUI.

The problem is that if two games are too different, there is really nothing
gained by having them handled by the same GUI. You would basically get two
completely independent programs, that are both put in the same executable,
one of them serving no other purpose than occupying space while the other
is running. Tht becomes progressively worse if you want to handle more
unrelated games. They will each need their own code for game notation, for
parsing games, for describing moves, for performing moves on the screen.

For Chess variants it is very useful that they are all handed by WinBoard.
Most of the time the fact that you play a variant merely means the
parameters for the board format have to be adapted, and a few pieces are
replaced by a few others. With a limited set of unorthodox pieces a far
greater number of variants is automatically supported.

Of course you could make a client that is completely dumb, and does
nothing more than record mouse clicks and send tose to the server, and
display the board as a table of bitmap pictures, where it gets sent a
completely new boarad position (adapting the contents of every cell of the
table) when anything changes. And when the user asks to save the game,
relay the request and have the server send a text string that represents
the game, and save that. But I would not consider such a simple thing a
GUI.

Fergus:
| That is wrong. A player views a board in his web browser, enters a move
| in a form, then submits the form. Game Courier then displays the move 
| or tells the player that the move is illegal. If the move is not found 
| illegal (either because it is not or because the preset doesn't enforce
| rules), the player then clicks a form button to verify that this was 
| his intended move. The player can find out when it is his move again in
| one of three ways: (1) Get an email, (2) check the logs page, or (3) 
| let the Game Courier page reload at intervals (by means of Javascript) 
| until it is his move again.

Well, it is not that wrong: the latter is what I mean by polling, you
either have to poll your POP server to see if you have mail, or keep
requesting the page over the http port. The latter you could do by hand,
by clicking the browser refresh button, or have the browser programmed to
do it by JavaScript. Or have an independent program that you wrote
yourself (not a browser) do it.

This is different from the way the normal ICS protocol works, where the
TCP link to the server is two-way, and the server actively sends a signal
to the client when the opponent moved. Especially in bullet games you
would have to poll so frequently to get decent response times that it
would likely overload the server.

As to submitting a form: doesn't the browser simply open a TCP link to
port 80 of the server for that, and send it an http packet with arguments
appended to a file name (after a question mark, or something like that),
which the PHP server can interpret?

If I would know what text messages are interchanged over the various TCP
links that the browser opens to the server (and which ports it uses to
establish these links), it is easy enough to write a backend for WinBoard
that generates and interprets these messages. 

If I would know how to use Game Courier, I would simply use a packet
sniffer like WireShark to record what went over the line when I was doing
it; this is how I did it for the Unspeakable-variant server. But there I
knew how to operate the client to play on the server (which in that case
was a Java program, that was downloaded by the browser). But I had the
disadvantage that I was not able to pump the programmer for information.
;-)

Is the form that you send to enter the move variant dependent, or always
the same? I suppose the move syntax itself could be variant dependent. Or
is it simply long algebraic notation? How do you learn what the
opponent's move is. Do you get sent a new board position, and do you have
to decode the move from that by differencing it against the previous
position? Or is the move itself somewhere on the page, and if so, in which
format?

Reinhard: 'But that, Harm, is just the way SMIRF works'

But I suppose the Smirf GUI does no somethings about (Full)Chess, to help
it understand the moves. Or do you really have to send, say, a castling as
a pait of moves (e1g1,h1f1)? If you would use the Smirf GUI for 8x8 Go,
could you make the Go engine send a list of moves that makes it clear to
the GUI which stones have to disappear from the board. Could the engine
even tell the GUI to properly perform its own move, if that inolved
capture of a number of stones, without knowing that it is playing Go?

It would highly surprise me if the way you encode moves would be general
enough to handle that...

Rich, why not simply send the FEN of the position you want to move to, in
stead of sending a move? This completely eiminates the problem of encoding
moves (which for different gaes might need a very different amount of info
to be trasmitted), and reduces the problem to encoding game states (which
you need to have a solution for anyway).

Fergus, I have gone to the GC preset for normal Chess, played a few moves
in solitaire mode, and then asked for the source code of the page.

I suppose the move you referred to is the one in the form that is
displayed below the board, in the SELECT NAME='movenum' field (which
triggers the message 'use this menu to select a move to view'). So what
the GUI backend would have to do is scan the downloaded html code for this
SELECT tag, and then look for a following OPTION tag before the
corresponding /SELECT tag, which end in SELECTED DISABLED. After this tag
if finds the most recent move, preceeded by a number, and possibly some
periods (if it is a black move).

The back-end should keep trying this (every second, or every 10 seconds)
until it sees an opponent move there, extract the coordinates of From and
To square from the move, and send those to WinBoard.

When WinBoard sends a move to the back-end, the latter must translate the
WinBoard move into GC syntax by adding the hyphen, and then mimic the
submission of the form containing it. To see how the browser submits the
form, I will have to use the packet sniffer. I will try this tomorrow.

So it seems the basics are quite simple to achieve. The more tricky part
would be to set up the game: if the uer starts up WinBoard, with the GC
adapter back-end as pseudo-engine, the selection of a new variant from the
WinBoard menu, and requesting a new game in it, should somehow lead to the
creaton of a web page on the GC server for this new game. As I have only
tried solitaire mode, I have no idea how this works yet. I guess at some
point it would be needed to transmit the name of your intended opponent to
the server. I could have the pseudo-engine ask for a name through WinBoard
(WinBoard can pop up an input dialog box on request of the engine), and
then have the pseudo-engine transmit that name to the GC server in a
context that would initiate a game against that opponent.

So the whole process would become as follows:
1) Start up WinBoard in the mode with computer opponent, but in stead of
entering the name of a true engine, request to play against the GC
pseudo-engin.
2) The pseudo-engine on startup (or in fact on the starting of any new
game) downloads a few pages from the GC server, to find out which
opponents are available for the currently selected variant.
3) It presents the list of available opponents in a popup dialog box, and
the user could type the number of the opponent he wants to play, or a zero
if he wants to be added to the list himself.
4) WinBoard would relay the typed number to the pseudo-engine, which would
perform the required communication with the GC server to initiate the game
5) After that, it would be a simple exchange of moves, as discussed
above.

This sounds quite feasible.

Main disadvantage would be the huge waste of bandwith: while the
pseudo-engine was polling for a new move, it would receive this enormous
html page with the board display and rules of the game each time it polls,
while it needs only 4 characters of it.

I think we should clearly separate communication needs from storage needs.
PGN as it exists is a great standard for Chess variants for storing games.
And indeed it is what WinBoad uses. But the current standard heavily leans
on Standard Algebraic Notation (SAN) for the moves. And SAN is designed to
be convenient in games with many different pieces, so that the combination
(Piece, ToSquare) hardly ever needs disambiguation. SAN has the
disadvantage that it is non-trivial to parse, and the semantics can only
be extracted in the context of the current position. This forces all
entities converting SAN to an explicit move to keep track of game state.

All this is a consequence of SAN being designed for use by Humans. For
communication between computers, Chess moves are much more efficiently
encoded as (FromSquare, ToSquare), and indeed this is what WinBoard
protocol does. For games like Checkers, where all pieces are identical,
this is more convenient than SAN anyway. Side efects in Chess are rare,
(limited to castling and e.p. capture), and fortunately the moves with
side effects can be recognized from the base move of Pawn or King. In
Chess960 castling this is not always true, and castlings need a
conventional, rather than descriptive, notation. Next to the O-O and
O-O-O, the King-captures-own-Rook convenstion can be used for this. But
all these trcks critically depends on the communicating entities having
knowledge about the variant, so that when they encounter a Pawn capture to
an empty square, or a double sideway King step, or a King that captures its
own Rook, they do not take the move at face value, but know what is meant
by it. Furthermore, for Humans, (FromSquare,ToSquare) is more difficult to
read than SAN.

If you want to have a system of describing moves that would work for any
variant, you cannot rely on the communicating entities to recognize moves
that imply side effects. There is no limit to the number of cells that
change state, there is no conservation law on the number of pieces on the
board. You ould have to spell out everything. e.g. in Go you would have to
tell which stones have to be removed, although this is fully implied by the
drop coordinates. But there might be Go varints where not all these stones
re removed, and where the mover has to chose a subset of those. So the
move format will have to be able to specify this. This makes the format
too cumbersome to use for Humans, who prefer compactness rather than
explicit mentioning of side-effects that were already fully implied.

In my Live Chess-Game Viewer (see
http://home.hccnet.nl/h.g.muller/goths.html for a short demo) I opted for
a completely dumb system. The JavaScript code that manages the page nows
nothing about chess, and interprets the moves it fetches from the server
as simple cut/paste instructions which copy the contents of one square to
another and then make the source square empty. Which is quite efficient,
because it is exactly what the archetypal Chess move does. The viewer does
not even care who's turn it is. But to make sure that castlings, e.p.
captures and promotions can be viewed, the entity sending the moves must
slip in extra moves for the side effects. So an e.p. capture is
transmitted as two steps, e.g. e4-f4 and f4-f5, while for castling the
Rook move has to be explicitly added. To define the promotion piece,
another move format is added.