[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]
Comments/Ratings for a Single Item
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.
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.
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?
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.
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.
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.
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.
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'.
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
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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).
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.
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.
Solitaire mode doesn't give you a full sense of how it works with a human opponent.
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.
25 comments displayed
Permalink to the exact comments currently displayed.