Comments/Ratings for a Single Item

That's really vague. I'm asking for specifics. Since I wrote Game
Courier, I would probably be the one to program this, and I know I won't
program it if I don't have a very clear, specific, and detailed idea of
what it is supposed to do.

What you need is the Courier program to receive a file with the move
someone that someone wants to make, and output the results of the move to
the file.  The format it is in would matter.  CVML or IML/IAGML would
define the format.  Do this right, and the likes of ChessV and others
could interact with the Courier program.

As for specifics (aka how to implement), we need to discuss this further, and agree that it would be a good idea.

One of the main problems with having Game Courier communicate with another
program is that Game Courier is mainly just a toolbox for creating
play-by-mail versions of Chess variants. Game Courier itself does not have
the rules for any game encoded into it. It is mainly an interpreted
programming language that interfaces with a visual board display.

Well, at this point, maybe rules reffing could be done via the GUI
interface that would log in.  However, even outside of that, there may not
be a need now for it, just a program that can act as an easier to use
interface, and allow entering of moves, without needing to type.

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.

Game Courier is a server-side PHP program. It communicates with the user by
means of webpages. It also sends out email. The email is just a reminder
that it is your turn in a game, showing you the latest move and giving you
a link back to Game Courier. It is not a true play-by-mail system in the
sense of playing games entirely through email. It is actually a
play-by-web system with email notifications, the email being entirely
inessential if you check the website regularly.

Ok, several questions and comments:
1. When using Winboard, how do you use it?  Do you use it to log into the
CV websites, or enter in the current move manually, enter in your own
move, have it spit it back and then type it in here?
2. If Winboard works as I am thinking with chess, anyone know if it could
be expanded to cover other games, like checkers or Go?
3. CVML is merely a data structure for formatting data files so different
systems can understand them.  The format also makes these files easy to
understand.  The format explains what data should be where in the file. 
They also use XML stuff (CVML would be derived from XML) to also handle
formatting of web pages.
4. In regards to FEN, CVML could be used as a way to extend FEN and handle
more than FEN does.

Anyhow, these are my latest thoughts on this.  Thanks for the comments. 
Is it time that we break off a separate topic to discuss CVML?

Anyone know anything about the Universal Chess Interface?
http://en.wikipedia.org/wiki/Universal_Chess_Interface

Or the Chess Engine Communication Protocol?
http://en.wikipedia.org/wiki/Chess_Engine_Communication_Protocol

I am curious if we can find answers here.  I am asking about this, because I saw it on Wikipedia when looking up Winboard.

Another perspective on this Standards discussion is the Rosetta Stone comes
to mind:
http://en.wikipedia.org/wiki/Rosetta_Stone

What is agreed to on regarding the FEN, data transfer protocols, and other
things can act like a Rosetta Stone allowing a diverse community to
communicate with one another.

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.)

Thanks for the info on Winboard.  I am wondering if it can be extended to
cover other games.  As of now, if you check the IAGO Clubhouse site out,
there are over 900 games available to play through the partners of the
website: http://www.IAGOClubhouse.com

Next up is to have a way for people to access the websites on there, and
play by means of a GUI.

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 games I am looking for now are abstract strategy games.  Not cards or
dominoes, but games with boards and pieces.  Like what you find on here,
SuperDuperGames, Little Golem, and Richard's PBEM server.  

The problem with a dedicated GUI is that every game of a different type is going to require its own GUI.  This would be like taking Zillions and breaking it up into a different program for each and every game you play.  The idea is to have a Zillions type program which would enable people to play one another over the Internet, or with AI plug-ins.  It would enable a program like Axiom, for example, to be able to have an interface to play it.

I will say that, while I am not looking at abstract strategy games now, I do believe if we can come up with a system for recording and transferring game state data between environments/programs that can be extended to include cards, dominoes, and anything else that is a tabletop game, we will have done the world a big favor.  Note, the standards don't need to be fully used by the CV community, but can be used by others.

H. G. Muller wrote:

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!)

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.

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.

But that, Harm, is just the way SMIRF works. It asks the engine for a list
of valid moves and from that filters only valid move inputs from the user.
And that has been the basic idea of the TMCI protocol. The intended utmost
goal was to have some engines playing and a certified referee engine
secure a correct play of a chosen variant. That would make a GUI able to
communicate a family of games even unknown to it without any need to be
changed or updated. Therefore the base of its communication: X-FEN has to
be maximally independent from any selectable variant. The subset of
variants it aimed to cover has been called: FullChess.

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...

Harm, FullChess games have moves defined by TWO seperatedly to be clicked
squares. Those fields are encoded within the algebraic move encoding sent
by the engine before. In doubt, e.g. at promotings, the GUI is prompting
possible moves to be selected by the user. After any move the engine is
sending the current X-FEN position to be interpreted and displayed by the
SMIRF GUI. The GUI is absolutely unable to generate any Chess move by
itself or to modify the board position by its own means.

Go is defining its moves by exactly ONE to be clicked square. Thus Go
belongs to a different family of board games, for which a similar approach
would be possible.

H. G. Muller wrote:

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?

The form remains the same, and the move syntax remains the same. Details are given in the Game Courier User's Guide. You learn the opponent's move by viewing the game when it is your turn. It will tell you what the last move was and display the current board position. You can also learn it from reading your email, but the email will not have any diagrams in it. All the moves in a game are stored in a log file kept on this website. I suggest you play a game with Game Courier to get a better sense of how it works.

I would like to comment regarding what is gained about having a common GUI
for multiple game types.  You can have one GUI that then could be used to
record keep and capture whatever games people play.

Secondarily, may I suggest that, if you come up with a common format for
data transfer, and recording moves and changes of game states, even if you
had different GUIs for each game, the server end would only have to worry
about one formatting of data to communicate between the GUI and the
server.  So, you come up with a data formatting and transfer format, and
leave it at that.  Eventually, even if there are different GUIs initially,
someone then can come up with a Zillions type GUI that could interface with
all environments.

I will be posting an initial attempt at some standard for this in a
separate message.  This standard would end up working with chess,
checkers, Go and anything else abstract strategy game.  It, of course,
would need work.  Besides this, I believe one could extend it to cover
cardgames and boardgames even.  Think of it as a FEN for changing game
states.

This is an initial attempt to come up with a standard for data transfer
between GUIs or AIs and a server.  Please comment, question and suggest
alternatives. Also point out any flaws with it.  I am of the belief we get
something like this working, we could then faciliate Winboard and other
programs from interacting with the Courier system on here.  I would like
to add that I believe all notation should be case insensitive.  A letter
dimension should be same uppercase or lower case for recording game
states.  The core if this approach is to say something from a space goes
to another space.  This approach doesn't care what is on a space.  You
look to what is on the space for whether a move is legal.


Notation for recording a space:
A1B2C3D4E5F6G7H8I9J10K11...AA27AB28AC29
Dimensions alternate letter (odd dimensions), and numbers (even
dimensions).  The ... is not part of notation, just used to reduce space. 
In the ... would be a bunch of other spaces.
- is used for negative spaces
. for decimal spots 
, for separator between decimal and zero letter and a number. Example:
A.23,27:
0 for letter represents transition between positive and negative. 0,0


Notation for recording movement:
: Piece moving from one space to another space. Example, A5:B6:D9.  Move
from A5 to B6 and then to B9.
& Another piece moves a series of spaces Example, A5:B6&J2:M7.  Piece from
A5 moves to B6, and another piece moves from J2 to M7.
/ End of player's turn.  Example: J2:E4/M7:J9.  One player moves a piece
from J2 to E4 and then the next player moves frm M7 to J9.

# All players turn is done for a round [set of turns]. Example:
A7:B6/J2:E4# .  A line break can also be used to indicate this.

() Indicates piece type to be placed on a space or result of move
[Example: A7:A8(Q) or J2(Q)].  In this piece from A7 to A8 becomes a Q,
and Q piece is put on J2 [example of promotion].  In this, if there is a
single space as part of a move (example: J2#) then it is assumed that each
player has only one type of piece.  If there is queing of pieces, then
order of notation represents first piece out of queue/piece on top of
stack).  In case of A7(RP):A8 as a move, it is assumed that R and P pieces
on A7 are moved to A8 together, and the will be there as RP. 

() by itself as a move, in such as ()# represents a player passing turn,
either voluntary or they have no legal moves.

' Message, indicating status of a move, typically illegal [Example:
(Q)J7'Illegal-Occupied]. ' ' is the preferred way to indicate a
message, indicating start and end of message, as in the case of
(Q)J7'Ilegal-Occupied' [J7 space is occupied, so move isn't legal, and
must be repeated].


This configuration is meant to be used as a FEN for movement.  The
notation is only for recording movement and changes in game states.  It
doesn't determine if move is legal or not.  The ' [for messaging is used
to pass a message between one application/environment and another].  This
notation trusts that somewhere in the environment is used to check for
legality of the moves.  Also, initial board set up (Normally done by FEN),
and rules governing pieces, and game rules, are handled differently.  There
should also be naming conventions for messages.

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).