Comments/Ratings for a Single Item

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.

Consider these two formats (XGF and SGF):
http://www.red-bean.com/sgf/xml/
XGF is an XML format for storing turn-based games.

And apparently Go uses SGF (Smart Game Format):
http://senseis.xmp.net/?SGF
Smart Game Format, commonly abbreviated as SGF, has become a common
file format for storing game records of board games for two players.