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.

What I am saying regarding to FEN and FEN's size is:
1. In comparison to using notation that would be used to communicate
moves, it will almost always be larger.
2. An extended version of FEN is going to be needed for all games.  I am
no denying its importance.  There is a question of whether or not, when
doing communication of changes in game states, when connecting to the
Courier system (or others) whether one only needs to pass a FEN to
accomplish what is needed.  Will EVER game on the planet not need to track
moves?  There PGN also for recording all moves.  Would having something
besides a FEN be helpful here or not?  If so, I am of the belief that what
is used to record moves is needed.  With this point, in a nutshell, is
there NEVER a need to simply pass a move onto a system to check whether or
not it is legal.  If you were to have a GUI interface with a server for
example, is the GUI every turn supposed to pass the FEN onto the server as
a way to communicate a move?
3. As I said before, we are going to need a more robust FEN for handling
all sorts of abstract strategy games.  The question is whether or not we
will also need a way to record moves. Do we need a way to store entire
games that were played or not?  Should we come up with a more robust and
universal version of the PGN format or not?  Are you advocating the
abolition of PGN and replacing it with a FEN solution?  Well, you still
track games, but a file with records of games, rather than be a list of
moves, contains every single board move in the game in a single file.

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.

On this note, I will agree with the this comment: That a FEN is a better
way to store a game state, but there is also a need to be able communicate
a game move or series of game moves.  If this is what I said, I would agree
to it, and believe that both need to be worked on.  I believe we need both
an extended FEN, and a reworking of PGN so that it is more universal.

If this is what is being said, I do believe we have common ground on here,
and we can proceed to work on these.  I am of the believe that the move
notation will likely come before the extended FEN.  The issue with the
extended FEN is that FEN relies on being able to record a set number of
piece types.  However, we have a potential for an infinite number of game
pieces, so his is an issue.  FEN, as of now, can't handle this.

A wiki page is added on the abstract strategy games for putting notation
there.  I would be interested in also getting FEN finalized. ^ was
replaced with +

http://abstractgamers.org/wiki/iago-notation

I don't quite understand the description of the system you give on the
IAGO site. It seems there is a typo in the captures description.

Could you give examples of how you would denote a Checkers capture, a Go
capture of a chain of 3 stones, and a reversi move that flipped 3 stones.
How would you denote a capture in the Checkers variant which stacks the
tompost chip of captured stacks under the stack that captures them? (e.g.
if I have a stack of 2 white chips on top of 3 black chips, and would jump
with this stack over a stack that had 1 black chip on top of a white chip,
taking away the black one, leaving behind the white one, landing on its
target square as a stack of 2 white chips on top of 4 back chips.)

Another point: To call this 'a FEN for movement' is truly ridiculous.
FEN means Forsyth-Edwards notation, and neither Forsyth nor Edwards have
anything to do with it. It is a bit like calling the wheels of your car
'Dollar bills for driving'.

Can I comment here by saying that what is on the AbstractGamers wiki page
is a first attempt at this?  It needs a bunch of work.  Some issues are
easy to deal with.  In the case of Othello, since conversion is mandatory,
all you need to do is record where the move took place.  Cases where
capture is mandatory, it isn't a problem.  The issue becomes when you do
an action, and it is not mandatory.  That is an issue that needs to be
resolved.  I am not sure what solution people use today in games where if
you do a capture vs a non-capture move.  Say, you have a case of checkers
where you can jump, but you may or may no decide to choose to take a
piece.

Anyhow, more work needs to be done here on this.  I would expect others to
come up with solutions.  The idea here is to have something that works.  We
will both need to have a FEN solution for storing position, and a common
standard for communicating moves.

In regards to a 'FEN for movement', FEN was used to describe a method
for recording game states.  The 'FEN for movement' comment, even if it
was a poor phrasing, was meant to state a format that would describe
moves, the way FEN is used to describe game states.

Yes, I understand what you meant by FEN for movement, but it sounds
rediculous. Especially since there are already plenty of standards for
move notation (with limited scope, e.g. Chess), that do have sensibla
names. Like SAN = Standard Algebraic Notation.

I understand that you don't mind that the mve notation would make use of
knowledge of the rules of the variant. This does imply that the same move
could have different notation in different variants (because in one
variant the move would need extra info to disambiguate it, while in others
it would not (e.g. promotion to Q in Shatranj, if Ferz is represented by Q,
would be implied, while in Chess there woud be a choice.)

I am not sure if you could call something a universal standard if it would
need knowledge of the rules of the variant to define the meaning. If it was
allowed to draw on the rules of the variant, such a system is likely to
degenerate to the union of the most-convenient notations for each variant.
In Chess an Alfil jumps without capturing the piece it jumps over, in
checkers a jump implies a capture. I guess the most important part of the
standard would not be how you can describe mutations to th board, but in
stead when you have to do it, and when you have to omit it. If you would
indicate a drop with '@', as in SAN (e.g. N@e4), in Go the fact the
piece type as well as the fact that it is a drop would be implied, and
there would no reason to include tem in the notation. So Go moves simply
become the indicator for the cell where you drop, everything else could be
implied.

If it is allowedto use knowledge about the game when interpreting the
moves, the need for many delimters disappears. Why separate the FromSquare
and ToSquare by a hyphen? You could simply concatenate the square
coordinates if it their syntax is known. a character behind that could
indicate the new state of the target cell, if different from the state of
the source cell 9as with promotions). Only non-implied side-effects would
hav to be described. e1g1 would still be a perfect notaton for castling,
as the Rook move is fully implied by it.

H. G. Muller raises an important point concerning the difficulty of having
universal move notation standards for all games. In different games, the
same notation can have different effects on the game. Compare 1. P e2-e4
in both Chess and Magnetic Chess, just to give one example. In order to
support just about any Chess variant, Game Courier supports the most basic
of move primitives. It lets you string together a series of move primitives
to handle any type of complex movement possible in a game. This is good
inasmuch as it makes Game Courier a universal Chess variant platform, but
it can get tiresome to play a game like Magnetic Chess this way.
Therefore, Game Courier also supports automation via its GAME Code
programming language. A game preset can be programmed to handle all the
stuff that is supposed to happen automatically when a piece is moved. If
we have a universal standard that works equally well for all abstract
games, especially if we are looking for one that will work with a dumb
game viewer, then we may have to settle for a standard full of move
primitives that describe complex moves in full detail. Yet that seems
undesirable. It would be best to record only the moves players make, then
rely on the rules of the game to imply the consequences of those moves,
such as whether other pieces get moved, captured, etc. Doing this much
seems fine to me. Where I would draw the line is at having a notation that
cannot be deciphered except by knowing the rules and the board position.
PGN uses notation of this sort. For example, Ne5 tells me that a Knight is
to move to e5, but it doesn't tell me where the Knight is coming from. So
here is what I would advocate in a movement notation standard: Let the
notation clearly describe the player's move without depending on any game
specific knowledge, but allow the use of game specific knowledge for
deducing any additional changes to the game state that are automatically
consequences of the move.

I want to address questions raised, and then go for what I would like to accomplish:
1. The reason for having and from notation: A7-B4 (or I gave A7:B4, because negatives are reserved for board notation) is several reasons: A.  I need to account for the difference between games where a piece does multiple moves, verses one where a game enables multiple pieces to move. B.  It is easier to read, and communicates better also to a computer what is going on.  Again, if you are thinking in terms of chess, you can drop the delimiter. C. In cases where pieces interacting with one another can have multiple possible outcomes (capture vs non-capture), you need to have some way to signify this. D. Need to be aware of the standard picked for handling multiple dimensions.  As it is now, it is letter, number, letter, number, etc... In case of where you would have a piece leaping from a 2D board to a 3D board, then you could have possible uneven dimensions between spaces.  The desire is to avoid possible conflicts.  If there isn't any, then it might be possible to do shortening even further.
2. I believe I do have a way to account for pieces being dropped on the board.  It is important to signify this.  I have been a bit shy about using @ though, out of concern what can be passed through a web browser as data.

My main interest now in regards to some universal notation is to have some
format for data, that enables sending of data from one system to another,
to insure that a move is properly executed by a computer, based on what
was sent.  This format should be universal in its format, and work with as
many abstract strategy games as possible, so that people running a site
like the Play.Chessvariants Courier system, SuperDuperGames, Richard's
PBEM Server, and others, only have to worry about getting a player's turn
properly transmitted.  Yes, knowledge of the game will be important, but
what matters is the formatting works.  It is one format for communication
that works.  

As for N-H7 to a possible move, is that such a notation ends up being
broken when you look at a near infinite number of pieces.  You also risk
running out of letters here.  If you go with algebraic notation for
spaces, such as F6-H7, then you can be able to facilitate every single
chess variant about, if only one piece is permitted per space at a time.

Again, what I want to attempt here with this format is for someone to be
able to create a GUI that can interact with the Chess Variant website's
courier program and the others.  I would like a format that would work to
enable the GUI to communicate with the server.  I would like the format to
remain consistent and robust enough, that one could add another game and
chess variant, and all you have to do is worry about maybe the name of the
pieces, and the game rules, and standards for board set up.  You don't
have to create some format to communicate moves for every game.  You have
the format done.

If people want to create some universal format that is easy for humans to
understand that communicate moves, please come up with it.  My interest
now, though, is enabling computers to be able talk to one another and
communicate moves.

Ok, let me sum up what I would like to accomplish with some standards at
this point:
1. How do we have it so a player could log an AI on the chessvariants (and
other sites), and be able to play against a human opponent?

2. How could someone with Winboard, Zillions, ChessV, etc... log onto
those sites and play games on them, using the GUI from the programs?

The main probem is not to devise a standard, but to get everyone to use it.
And in interfacing one medum with another, the problem of how to represent
the moves is a serious, but at the same time totally insignificant fraction
of the problem.

Take for example the Game-Courier server. Its main function is to allow
people to play games using a browser as client. Now we don't control what
browsers do, so the GC server has to adapt to the browser and send web
pages (i.e. html code). This html code does not only contain the current
move, but a graphical display of the board position (a FEN would certainy
not do), the game history, graphics to explain the pieces, text to explain
the rules, control elements to allow the user to step through the game
history, etc. To get an idea what the GC server sends FOR EVERY MOVE, click
'View -> Source' in the browser menu while ou are logged in to GC.

Now other game-play servers, even if they play through a browser like GC
(and not through a specially downloaded client, like Internet Chess
Servers, or through browser-loaded Java clients that use a dedicated TCP
channel, like the Unspeakble server), will use completely differently
formatted webpages, and might even use differently formatted webpages for
each game they provide. Having standardized moves somewhere on those pages
solves nothing. (Well, 0.1% of the problem, maybe.) The main problem is to
identify the current move on such a huge web-page of unspecfied layout.

To standardize the entire page would require most websites to give up the
looks that define their identity, and you can be sure they will never do
it. In addition, for merely exchanging the moves with an automated entity
(rather than a Human using a browser), the entire webpages that are used
now are extremely cumbersome, as 99% or more of what they contain is
redundant information. The logical solution would be that websites like the
GC server would provide, for each ongoing game, a separate access channel
designed for automated play.

Such an auxiliary 'web page' might contain nothing but the move. And it
does not even have to be in html format, as it is not intended for browser
viewing. It could even be a binary file, although I would not recommend
that. The most logical choice would be a text file, that would contain
nothing but the move, or (to allow viewers to come in during the game) the
list of all moves so far. In fact something very similar to the format I use in
the move.txt file that my Javascript viewer periodically downloads, when I
am broadcasting the comp-comp games going on in my PC. (See http://home.hccnet.nl/h.g.muller/goths.html )

Of course all the GUIs you would want to interface to would have to be
modified to become able to use this channel, and understand the format
that it uses. No GUI I know does load webpages over the internet. They all
open permanent TCP links to the server, as this offers two-way
communication, which is much more efficient. (You don't have to
incessantly poll the server to see if your opponent moved, but can wait
idly until the server sends you the move.)

Furthermore, note that Zillions of Games does not use a true GUI, as it is
not capable of handling automated play between two different engines. In
fact there is no way at all Zillions can communicate its moves to the
outside world, apart from the outside world staring to the computer
display and doing the image processing to interpret what it sees. ChessV
does not have any GUI-engine separation at all, it is an integrated
program, and not capable of playing games against entities that cannot
look to the display either. Gregory has told me that the next version of
ChessV will be a pure engine for running under WinBoard, though. As to
Zillions: there exists an adaptor to use the Zillions (semi-)GUI with a
WinBoard engine as AI, but not the inverse, which would allow you to use
the Zillions AI as a WinBoard engine. The makers of Zillions told me that
they are currently not contemplating of providing this capability, as they
ae not sure there is any demand for it. Of course the Zillions AI is quite
weak compared to dedicated engines, so setting it up for engine-engine
matches would likely only generate bad publicity for Zillions.

The only viable solution I see is that servers would provide an additional
channel geared for dedicated-client (GUI) based play, next to the
browser-based play they provide for Humans, and that a peudo-engine would
be developed that can run under a GUI as any other engine, but in stead of
thinking up moves, handle communication with the server. The logical choice
for communication between GUI and pseudo-engine would of course be WinBoard
protocol, as WinBoard is the only general purpose GUI that supports a wide
range of Chess variants. For communication with the servers, the whole
project would hinge on the willingness of game servers to provide the
auxilliary channel according to the adopted standard.

H.G, thanks for the message. 

I just had a few comments:
1. Why do we need to worry about having each website give up their look
and feel?  Why can't we have the back end be standardized?
2.  Pretty much, I would agree hat an 'additional channel' approach
would be wise to be created and added, and that is what I would like the
standards to help lead to, and help regulate how it works.  This channel
could be added to programs out there, such as WinBoard, or even the
program 'Cyberboard' which is used now for wargames.  The channel could
also be used to enable AIs to communicate with Websites, so people
specializing in AI can have their AI work with websites, and they no have
to worry about having to code GUIs and so on.

Of course all parties would need to agree to the format.  You get at least
some to agree, and it is shown to work.  From there, others end up using
it, and we now have something that works.  I do thank you for using the
word 'additional channel', as that is the best way to describe it.

By the way, please send me some email.  I would be interested in having
you input into a Yahoo forum set up now to discuss this.  I would like get
you the link.  Please email me at rich [at symbol] IAGOWorldTour.com or
richardhutnik [At symbol] optonline.net , so I can get you the URL link. 
I would post the URL link here, but I want to make it be a bit private.  

Also, anyone else please email me, so I can get you the link.