IAGO Notation Introduction

This document is cover different types of notation needed to handle games for IAGO.

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.


The contents in this document represent a work in progress, and represent more an example of the finish product. At this time, there is discussion and debate going on regarding this, in a separate forum. If you would like to input, please check comments section for more information.

Notation for game positions


Dimensions alternate letter (odd dimensions), and numbers (even dimensions). The … is not part of notation, just used to reduce space. In the … would normally consists of a bunch of letters and numbers.

Symbol Description
- used for negative spaces
. used for decimal positions
, for separator between decimal and zero letter and a number. Example: A.23,27:
(0A) for letter represents transition between positive and negative. For numbers between -A and (0A) and A→ -A to (-0A.000…1) to (-0A.999…9) to (0A) to (0A.000…1) to (0A.99…9) to A.

Notation for recording pieces on positions

This section handles pieces on a given position. The format is a letter or letters; a number and letter(s); or a number, letter(s) and a number). This is used to record cases of multiple pieces of same or different types in a space. Below is a table that explains this in greater detail.

Symbol Description
No symbol Position has a single piece on it belonging to one player.
Letter or letters A space has multiple pieces on it of different types, each belonging to a the same player. This denotes which piece it is (see letter). Example → B
(1-n)Letter or (1-n)Letters A space has multiple pieces on it of different types, each belonging to different players. This denotes which players piece, A specific player's piece is on a given position. n represents number of players in game. Example → 2K (Player 2's K piece is on position)
(1-n)Letter(1-n), or (1-n)Letters(1-n), A space has multiple groups of pieces of the same type belonging to different players. This denotes a group of those pieces. A comma is used as a separator between two groups of pieces. n represents number of players in game. Example → 3J5, (Player 3 has 5 J piece is on position).

Notation for movement

For what it's worth, here are some sample scores with no weighting:

Symbol Description
: Piece moving from one space to another space, performs capturing or non-capturing move. Example→ A5:B6:D9. Move from A5 to B6 and then to B9.
* Piece performs capturing move. Example→ A5*B6. Piece on A5 captures on A6. Notation is also used to indicate what pieces would be removed from a board in a stack, when multiple pieces interact. Example→ A7*B4(WBW*B). B piece that was on the position and was then moved off the board. This symbol is used to signify a capture happened, where (a piece moving off board)
+ 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 ##. It could also be placed at the start of a serialized list of moves, in an extended version of PGN file, to indicate that section of moves is about to start.
( ) 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.
[ ] 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.
< > Customizable command, usable for expansion, and game specific. If a new condition not accounted for arises, this will be used. An example would be the placing of a Prong into a piece in Octi, or rotation in Ploy. Commands such as: B4<Prong-NE># or C6:C7<Rotate-CC># could be used. There is a case for standardization in this also. <> (empty and no spaces between) could also be used for pass. Another possible use for <> would be castling in Chess, such as <O-O> and <O-O-O>. For example, a possible move could be→ A5-A7<O-O>. This can also be used for games with established notation, to be able to transmit their current moves, using their current notation, such as→ <move: A5-B5>##<move: A7-B4> .
{ } 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. Comment can also be used as part of series of moves to indicate turns. Example→ {1.}b1:c3#b8:c6## {2.}g1:f3#g8:f6## {3.}d2:d4#d7:d5##

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.

+ was used because ^ is reserved as wiki notation. Another option instead of + could be &, if it is permitted as a way to pass data via a web browser.


RSH: 10/11/08 Discussions regarding this thread has moved to the private Yahoo forum. If you would like to be part of this forum to discuss this issue, and part of the IAGO Standards Committee that is handling this, please either send email to: rich [at symbol:@] IAGOWorldTour.com or a private message to richardhutnik on the abstractgamers forum.

A few comments:

  • Forget all questions of legal or illegal moves. This would have to be for data transfer only.
  • We seem to be conflating data transfer with game state representation. These are 2 completely different things and should be discussed separately. (Personally, I'm not convinced there is a way to express game states for all games in a compact, homogeneous, standardized way without some information being assumed by the GUI/AI.)
  • I see no reason to start using different symbols than commonly used in most games; that is, 'x' for capture, '-' for movement, ',' for separating a list of moves.
  • Is there a reason XML is not being considered? It is more verbose but is completely standardized, commonly supported, and more human readable.

Basically you want GUIs/AIs to be able to:

  1. submit a move/command to a game processing server
  2. receive and understand messages from the server

This is trivially handled using standard web architecture. You establish a RESTful interface that allows GUI/AIs to post a move in plain text to the server and it responds using normal HTTP response procedures. XML could trivially be used to allow more complex commands and messages (without resorting to the way-too-dense SOAP structures). GUI/AIs can also query the server to obtain specific game states.

Standardizing the notation for making moves is to me unnecessary. The game server will by definition completely understand the rules of the game in question, and those rules will determine what notation is most appropriate. All IAGO should do is insure that supported games are as homogeneous as possible in the notation they choose. Games with internationally-recognized formats should be immutable and others should simply attempt to conform to the standard very clearly, and usefully, set by Chess; namely, 'x' for capture, '-' for movement, ',' for separating lists of moves, etc… I believe such an approach has worked very well on SDG.

As for representing game states, I fear this will be a much more difficult issue. I agree that it would be ideal to have an unequivocal notation that allows 3rd-party GUIs to be completely 'dumb,' but I don't think it is possible. I am pretty sure that for a large portion of games the GUI will have to understand something about the game to correctly render a given state. If you accept that postulate, then you can take more liberties with the representation for all games. I have been contending with this issue in my system rewrite at SDG, attempting to represent all the games in a flexible XML format. Issues include:

  • games which have a finite stock of pieces for each player
  • games with “hands” and/or “decks”
  • any games with hidden information as it must then be determined by the server what information to provide when queried for game state
  • games with dynamic (or no) boards (Eg. Homeworlds has a playing field that is always changing, some games have areas that can be rotated, etc…)

I have decided to accept the postulate that an unequivocal notation is impossible and I now express states in terms appropriate for a given game. There is still a certain high-level structure in the XML file (<board>, <player>, <clock>, etc…), and some parts can certainly be completely standardized (player and clock elements for example), but beyond that the GUI/AI is going to have to have some understanding of the game rules to correctly render a given state.

There's my $0.02 =) Aaron (SDG) Dalton

RSH 10/10/08

Thank you for the reply Aaron here. We do have a lot of work here. I just wanted to address your comments above:

1. Messaging notation will enable a system to communicate that a move was illegal to a GUI. That is the purpose of the message command.

2. The problem with using x and - is due to how positions are noted. Because you are looking at negative position spaces, it takes the -. And, because a board position can go out beyond 25 spaces, X is used to indicate row/column named X, so it can lead to confusion there. I was also looking at possibly having upper case letters represent positive board positions, while lower case indicate negative board positions.

3. As I think on this, XML could be used the way PGN is currently. The series of moves do need their own notation before XML is considered for that. An idea would be to figure out what the least amount of space needed is. There is overkill on bloat if every single to and from has its own thing in an XML doc. I am proposing for PGN that something called ASML (Abstract strategy Markup Language) as an extension off XML. The best use is probably as a replacement for PGN.

4. One does want to attempt to have the entire data format leave as small of a footprint as one can.

5. We can think in terms of cards, but can avoid that for now. However, by using board positions, we could indicate hand space.

6. We need to get a lot more people involved in this, so that whatever is arrived at is used.

7. The reason for standardization are needed here is to be able to have some system by which to store and record all abstract strategy games. Standardizing this enables things to work faster, and makes it easier to add things. You want to accelerate the adding of new games into a system. The system needs to be robust enough to handle stacks and so on. Even things such as what piece is on a space needs to be noted. Also, learning one way to handle all types of games, prevents the need for a new game type to come up with its notation, and then trying to get everyone to adopt that notation for the new game. There will need to be standards set for each game, when it comes to where board positions are and what symbol is used for what piece, but these are parts of the standards process. If you work out a standard way of handling these things, like the first position on a board is always A1, then we accelerate development. Standardization also reduces the amount of rules you need to store and people memorize.

8. Reason for the use of negatives and decimals for positions, is that it would allow for games like Homeworld and Icehouse (boardless) to be able to have their positions record.

9. In order to transfer the data for game positions, there is a need to agree what exactly is where. What is transferred is changes in game states, and that needs to be figured out.

In a nutshell, the idea is to come up with a universal abstract strategy games notation system that would work a bit as a “Rosetta Stone” between different games.

1) There is no need for such a notation. HTTP already provides all the necessary mechanisms for returning both a general error code and specific message to querying clients.

2) Again we are conflating game state representation and command submission. When the client submits the move, it does not pass any game state. It only sends the command and the server replies. There is no collision here.

5) I'm afraid I am not understanding what you're saying here.

6) I agree. Forums and mailing lists are best for this sort of discussion. It gets cumbersome with a wiki.

7) Again, I am not convinced that there is an all-encompassing, general way to represent all possible abstract-strategy board games. We are not the first people to try this. Zillions is very successful but also limited. Universities have been examining similar issues as well (University of Alberta GAMES Group). I personally feel that it is a waste of time and resources to attempt this. It is much more logical to me to accept the limitations and work with them. I think we are making this more complicated than it needs to be.

8) Sorry, but I don't know what this means.

9) “What is transferred is changes in game states…” With this I must disagree. Perhaps you don't actually mean to say that. The client should not have to understand the game rules (although it would be helpful if it did). All it should have to know is enough to correctly render a given game state to the user. The GUI issues a command (make a move, send a chat, whatever) to the server which in turn returns the updated game state or some sort of error. The client should not have to calculate a thing (again, though it would be helpful to the user if it could). It should most certainly not pass information about what it thinks the board should look like or anything like that. The point of a client/server architecture is that the server is authoritative. Clients can submit whatever move they want, but the server decides if it's legal or not.

The most difficult part will be agreeing on a way of representing games assuming the postulate that a universal representation does not exist. I certainly have my own ideas (some of which have been previously stated) but I would be most interested in continuing the discussion. The trick is to Keep It Simple!

Fun! =)


Greg Schmidt 10/10/08

Rather than dive into the specifics of a particular notation, I think it's best to start by agreeing on a set of requirements. Ideally, this set would be “minimal” in the sense that a specific notation satisfying these requirements would apply to a wide range of games. I am assuming a generic client which presents moves to a server containing full knowledge of the game mechanics and game state.


1) The notation shall allow specifying a position by name.

2) The notation shall allow specifying a piece type by name.

3) The notation shall allow specifying a player by name.

4) The notation shall allow assigning a player as the owner of a piece type.

5) The notation shall allow creation of a new piece on an empty position.

6) The notation shall allow changing the piece type of an existing piece.

7) The notation shall support piece movement.

8) The notation shall support the ability to capture a piece.

9) The notation shall support the ability to indicate that a move is incomplete (e.g. the first jump of an n jump sequence)

10) The notation shall allow for a “pass” move.

11) It shall be possible to annotate a move with an arbitary user supplied comment.

Note: The Zillions saved game format, which works for a wide variety of games, is a specific notation that satisfies the above requirements with the exception of #11.

I have not mentioned consideration of games where multiple pieces can exist on a single position such as stacking games or card games. As long as more than one piece can be moved or created on a single position, I think that is sufficient. An order could be presumed and managed by the client such that the first piece placed would be considered “bottommost” and the last piece placed would be “topmost” (i.e. a “stack”). If a piece is moved from a position containing a stack, the client would be able to determine whether or not the piece was topmost, interior or bottommost (if that were to be important for the game) simply by matching the piece name against all pieces in the stack. As an additional consideration, movement to a position which already contains a piece would not automatically presume a capture, it would simply add the piece to the position “stack”. If capture is intended, then it would be explicitly specified.

Additionally, I think it would be nice, but not absolutely necessary to support some “discovery” capabilities existing on the server side for the benefit of the game client.

A) It shall be possible to request a list of all legal position names.

B) It shall be possible to request a list of all legal piece types.

C) It shall be possible to request a list of all legal player names.

D) It shall be possible to request the player name whose current turn it is.

These could be optionally used by the client to provide some nominal checking (e.g. was a legal position specified) and information such as the current player name. The server need not implement them as long as the client would have some way of determining the degree of support (such as by returning an empty list in that case or through a standard way to query the server for feature support).

Finally, I agree wholeheartedly with Aaron's comment that the notation itself should be based on standard (algebraic notation), e.g. ”-” for movement, “x” for capture, etc.

– Greg

If there is indeed a committee that is to discuss this, may I suggest we start a new Yahoo group or something? That or create a forum place. I don't care which, but we need something more than the wiki.

I think we need to take one step back. What is the problem we are trying to solve? Does IAGO intend to run actual game servers like Gamerz and SDG? I think that would be a duplication of effort. I'm not sure why IAGO should be concerned about how such sites configure their APIs. My understanding in the beginning was that IAGO would like to serve as a repository for game records and rankings. If this is the case, then the approach is slightly different. Now the discussion becomes do you attempt to completely describe all elements of each game state? Or do you simply record a list of moves with some tags, like a PGN report? As I said before I don't think it is worth our time to try to develop some universal game notation that will describe all games. I don't think it exists. I think it is more logical (not to mention feasible) to define parameters and a review process for PGN-esque game report formats. The individual game designers need to have some liberties in defining a notation that is appropriate for their games, but standards can be in place to enforce as much homogeneity as possible. This also will require other guidelines as well such as authentication, review of game records, who's allowed to post them, what applies to IAGO ratings, etc…

There's lots to discuss so again I would request a mailing list or forum. Cheers! Aaron

RSH 10/11/08:

We could start a discussion category on here also, but this does sound like it is better suited for Standards Committee discussion. We could use a Wiki entry to store the findings. As for what IAGO is trying to accomplish, is to have standards so someone can develop a Winboard type GUI that could communicate with servers that have games, store data, and manage IAGO membership. It would then work to get people to be part of IAGO, and get the sites hosting games, revenues to keep their sites up. IAGO would track stats, records and so on, and facilitate the development and maintaining of standards that should work in open-source manner. They would be such that say Chessmaster folk wanted to get into chess variants, and the standards here would enable their program to log onto game sites and enable people to play games on the site, with their program. Do this right, and people could also create stand-alone AI programs that could log onto sites to serve as opponents. You look to decouple everything, allow specialization to take place, and the standards enable everything to work together. You save sites like SDG from having to develop a GUI for move entry on them. Someone else can do that that is much better suited. The interest I have in there being standards is so all the pieces people create can work together. From an IAGO perspective, this enables it to go out in the world and find players who may want to play these games and get them places to play.

I will say there is less of a challenge coming up with some solution, than getting all stateholders agreeing to what the standards are (and using them) and the standards not blowing up later. In regards to people trying this in the past, it does appear that there is a need for it. Please consider what I wrote a starting point on this discussion.

RSH 10/11/08:

Ok, to sum up here. Shorthand way to describe what I was looking get is answers to: 1. How do we have it so a player could log an AI on the chessvariants or SDG site, 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?

GS 10/11/08:

No doubt it makes sense to first agree on the problem that we're intending to solve here. The notation should support human vs human and human vs machine (machine vs machine also?) play. I believe the requirements I proposed are consistent with what Rich has written above (I originally based my post on a telephone conversation with Rich). Anything less, would constitute a subset of what I have proposed above.

ACD 2008-10-11:

I posted my comments to the Yahoo group.

/home/html/iago/HTML/wiki/data/pages/iago-notation.txt · Last modified: 2009/12/11 13:34 (external edit)
Except where otherwise noted, content on this wiki is licensed under the following license:CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki