computers that I'm familiar with play on Internet servers in part to establish their ratings, and as far as I know no one has a good scheme for judiciously allowing undo without being taken advantage of by the usual emboldened-by-anonymity Internet twit.
Both GMP and IGS protocol support undo. How many programs actually use it?
-- William Harold Newman william.newman@airmail.net
My program Viking plays on NNGS and do not allow undo.
As a matter of fact my program are able to make "undo" easily sinc the abstract base class of my Go Engine defines TakeBack, I realized that if i did not implement that from the very beginning (that was a random player) I would regret it later.
So what is my point? I think undo in GTP for is a good thing. But a server that uses GTP should allow the user (the computer programs) to refuse undo. Most conveniently would be to have a flag for this in the server. That is: the programs should handle undo but the server would never allow the human player (the usual emboldened-by-anonymity Internet twit) to issue the command.
My implementation of Undo on NNGS is like this: if the opponent try an undo the program will hang and the user has to manually adjourn and then reload that painful position. The idea is that emotional distress will punish this undisired behaviour. ;-)
*About Position setup*
The protocol as far as I understand it (I have not gone into any details yet), make a difference between proposing a move and actually playing it in the game. This is good (my program works this way :-) ).
There is a catch though: if we want to load a position, (Such as "reload" on NNGS which has to be implemented, but is not fun at all because of the IGS-style protocol) there is a danger in using the usual game playing commands for this.
The reason is that playing a move in a game might induce a lot of overhead in a game playing program. My program makes a full rematch of all patterns on the board which is quite slow (up to one second). If an endgame position is loaded it could take minutes to do so. I once had a bug that caused exactly this problem for a while and I thought my program was too slow and that I had to abondon my approach of wait for 100 GHZ computers)
Thus I think setup has to be separated from ordinary playing commands. (If your program is fast there is no pain involved implementing this because you just use the same code for both playing and setup).
Conclusion: undo is good for all (programmers should adapt) and setup has to be separate (gtp cannot expect playing moves take no time) and the nice thing is that if you can implement fast setup undo follows conveniently. It is just a matter of good design. And the protocol should encourage that.
Best Wishes Magnus Persson -- Magnus Persson Department of psychology, Uppsala University Box 1225, SE-751 42, Sweden 018-471 2141 (work), 018-460264 (home) 070-2987879 (cellular) MAILTO: magnus.persson@psyk.uu.se URL: http://www.docs.uu.se/~magnuspe