Comments/Ratings for a Single Item

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

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.

Solitaire mode doesn't give you a full sense of how it works with a human
opponent.

Rich, what you're proposing as a standard is very different from how Game
Courier already operates. Game Courier's movement notation is programming
code with recognition of simple algebraic notation built into it. It is
designed as a series of sequential operations, so that it works with just
about any Chess variant. It would not work with the compact way you want
to express multiple operations. For movement, Game Courier uses -, not :.
This use is adopted from algebraic notation, though it extends the use of
- for capturing moves. For multiple operations in the same move, it uses
the ; operator, which is commonly used to end a line of code in many
programming languages, including GAME Code. I would not recommend the use
of & for anything you want to pass to a form through an URL, because HTML
uses the & to separate form variable assignments from one another.

I wanted to make several additional comments here:
1. FEN is fine if you are dealing with some sort of standard board layout
with squares.  But, what do you do when you go multiple dimensions, or
hexes or other board formats?
2. Also, how does FEN send changes in a game state such that you are able
to tell if a given move is legal or not in a given environment?  I am not
saying you won't need something like a FEN to store a game state, or an
initial start position.  BUT, when it comes to checking legal moves that
would be like the case of Chinese Checkers (say you do multiple jumps) or
Progressive Chess, where players make an increasing number of moves? 
Would you send multiple FENs for each and every move?
3. How does a FEN recording games with stacks or multiple pieces in it,
and how they change?
4. What I am looking at here is something that would not only handled
chess, but other abstract strategy games, like Checkers, Chinese Checkers,
Go, Mancala and Focus.  
5. The focus of this approach, which also joins FEN, as another format. 
If you manage to get this right, then you could have universal FEN which
records all types of setups, and the move format also attached, so there
is the ability to roll back to see what the prior position was.  This
would offer redundancy in this to make it work.
6. The format I am discussing here is meant mainly for computer programs
to talk to one another.  While it is possible for people to manually to
enter it, that isn't really meant for it.  It is cumbersome.  
7. The format is meant to capture the minimal in change, without tying up
too much bandwidth.  It is meant as a one size captures all.  You could
even happen to have a way to compress the format even further.
8. As for how it works being different than the Game Courier, is that my
hope is this approach can map to the way the Game Courier works, and you
provide it as a different format for data transfer that can be added to
the Game Courier system.  Yes, I know I propose using : instead of - to
indicate to and from.  I would go with -, but I am aware some games may
have a board space with negative spaces.  I know, for example, Beyond
Chess, when you move tiles, the board spaces tend to spread out and board
positions end up in negative spaces.  As for what I am proposing, I don't
care if the symbols get changed.  I care that they do work though, and are
robust enough.   Again, this is an initial attempt, open for people to
change if they like.  What is seen here need not be a replacement, but it
can act as a Rosetta Stone of a sort to allow intersystem communications.

By the way, I propose a double quote mark ''  '' for messages, rather
than a single ' (the symbol should be the one above the ' on the
keyboard).

In Game Courier, at least, the FEN code and the move notation are in
separate fields. So the use of - for moves does not affect the use of - to
represent spaces not on the board.

GAME Courier used to pass FEN code representing the current state of the
board with each move. This was before I implemented log files and the use
of GAME Code for enforcing rules. Now the only FEN code it uses is for the
opening position. Each time a player moves, it goes through all the moves
in the game, updating the board, which is held in an array, with each
move. If there is code for enforcing rules, it also checks the legality of
all previous moves. Finally, it gets to the last move, finishes updating
the board, and displays the current position to the player.

One reason I made this change is that it allows Game Courier to use
relevant information about past moves to tell whether subsequent moves are
legal. In Chess, this is important for castling and en passant. You can't
tell from FEN code alone whether a King can castle or a Pawn can perform
en passant. It might be possible to overload FEN with this kind of
information, but I didn't think it would translate well to games that
either didn't need it or had different rules concerning how past moves
affect the legality of present moves. Rather than trying to anticipate all
possibilities of this sort in an expanded FEN standard, I left it to GAME
Code to keep track of it by using flags or variables.

I happened to rework what is presented under movement a bit.  Please
comment.  I hope it is more URL friendly.  I am more interested in making
sure everything that needs to be covered gets covered as far as regulating
movement, rather than which symbols are used. Below is examples of what
could be.  Agreement would need to be for what WILL be.  Also, please view
this as an addition to FEN, rather than a replacement.

Anyhow, my latest attempt.  Please comment:
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 by all players).
Example-> A7:B6#J2:E4## .  A line break can also be used to indicate this,
instead of ##.

() Indicates piece type to be placed on a space, or result of move, or
even a special move type. 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.  

Another possible use for () is to indicate a special move type, such as
(O-O) and (O-O-O).  For example, a possible move could be: A5-A7(O-O). 

() 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 .  If the message ends in a line break, this is
acceptable.  
[ ] is the preferred way to indicate a message (however), 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 a new move must be selected.  Systems
would communicate to each other using comments between [ ].  Conventions
for what constitutes messages needs to be established.

{ } Comment.  Ignored by processing after data transfer.  [] is used for that.  Useful for people's comments, to explain context or anything else. This was taken from PGN.

Game Courier handles hexagonal boards by basing its coordinates on only two
of its three axes. Since the board is still two-dimensional, this works.
See my earlier comment with examples. Other 2D boards can be handled in a
similar manner.

Game Courier assumes a board is two-dimensional, representing all
positions in a two-dimensional array, but it could fake a 3D board. For
example, a developer could represent two of the boards dimensions as a
single dimension. Since Game Courier is not designed to draw 3D boards, a
3D game would have to use a custom board.

As for my proposed V-FEN standard, since / by itself cannot be used as a
shortcut for an empty rank, it could recognize //, i.e. a single /
following the / meaning end of rank, to indicate a drop in plane. The FEN
code would start on the top board and proceed to the bottom board.

I want to add another reason for NOT using a FEN approach to indicate
movement.  Besides making it difficult to check legality of a move, of the
play area is HUGE, then doing a FEN data transfer ends up wasting a lot of
bandwidth to transfer.  Big difference between C4FB:J15FB#M8CV:D120HL##
and do a board for a multi-dimensional space (like that entry indicated
two pieces moving in a 3 dimensional space).  If you were to do a FEN for
that, it would be FAR larger.  Only place where I can see a FEN approach
taking up less space is with a small board with a small number of pieces. 
I would say you use a FEN approach for sending a saved game state, and also
a case of a small board with only a few pieces on it.

By the way, in the tradition of what I see FEN does, you could have a V-FEN format, and then something like what I have discussed with moves, to be bundled together as a stream of data that could be sent from system to another.

I was also wondering how a FEN position would be able to be sent over a web browser, since a / is used to indicate a directory or a file in a directory.

What comes after the ? in an URL is not part of the address but part of the
form data. Sometimes the form data includes whole URLs. I think / is a safe
character, since it is already used in the address part of an URL. Special
characters used in form data can be encoded and decoded for safe
transmission through URLs. I have sometimes seen the / encoded.

Ok, thanks for the clarification here.

I do believe whatever we work on would end up being an extension of PGN:
http://en.wikipedia.org/wiki/Portable_Game_Notation

Some changes would likely need to take place in the format, and with the
moves, in order to account for a much larger range of games.

Like with PGN, we have essential data on top, a FEN, but also list the
moves.  Unlike normal PGN, we need to be able to handle more than 2
players playing, a wider arrange of boards and dimensions, and other
things like a wider range of move types.

Maybe we can call this V-PGN (Variant PGN) or even X-PGN or XPGN 
(Extendable PGN) or PGNX (Extended PGN).  It would handle all chess variants and all abstract strategy games.  It could also eventually be extended to other game genres also.

Rich: If you think FENs are too large, (which to me seems a gross
exaggeration at the current state of technology; note that FENs involve some inherent compression, as stretches of empty squares are indicated by a single number), an alternative would be to only transmit the difference between the previous game state.

Note that the FEN standard for normal Chess, unlike what Fergus wrote,
does contain a full description of e.p. and castling rights. The only thing that is missing is the possibility to recognize game-state repetitions in connection with 3-fold repetition draws. In Chess this does not affect legality of a move; in Xiangqi this might be different. But I think that is not really important for communicating moves between entities that play or display, as they can remember the game history. This is the issu if the protocol should be stateless, or not. UCI is an example of a stateless protocol (it sends the engine the entire game history plus opening position for every move the engine has to make), and I think in general this is a very bad idea. It just makes the protocol awkward and cumbersome. Fergus has good reason for wanting the Game Courier protocol to be stateless, though: you have to be able to resume a game halfway, with a freshly-started browser. ICS protocol is not stateless, but solves this problem through bidirectional communication: although the board position is transmitted with every move, the game history is only available on explicit request. So normally, you don't request it, but if you enter a game halfway (recognized by the fact that the move number of the first move you got sent was not 1), you have to make a one-time request for the game history.

As in most games only a small fraction of the cells change state, (this is even true in games like Reversi and Go), you could just send a list that names the altered cells and their new state. E.g. 'e2=0,e4=P;' for e2-e4, and 'e1=0,h1=0,f1=R,g1=K;' for O-O. This would work over an exremely wide range of games. As in many games moving a piece from one cell to another is the only thing that happens most of the time, it can be very useful to make 'x-y'; a short-hand notation for 'x=0,y=P;', when P was the old state of cell x.