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
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:
submit a move/command to a game processing server
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
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!
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.
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.
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.
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?
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.
I posted my comments to the Yahoo group.