gtp

gtp@lists.lysator.liu.se

164 discussions

Undo on Servers
by Magnus Persson 16 Aug '01

16 Aug '01

> 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(a)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(a)psyk.uu.se URL: http://www.docs.uu.se/~magnuspe

2 1

Re: [gtp] GTP Goals, ver. 3
by Dave Denholm 15 Aug '01

15 Aug '01

Don Dailey <drd(a)supertech.lcs.mit.edu> writes: > Another footnote: > > I suggested at one time that we just do a complete (but small) set and > to let all commands be considered optional. This is pretty much the > same idea. There are only 4 commands that you cannot manage to play a > game with, genmove_white, gen_move_black, white and black. > > Some other stuff can be faked with great effort by the interface > builder, by carefully studying everything you can about each program > you are building an interface for. Assuming we have only the 4 > commands I mentioned, let's consider how we might do certain things: > > newgame - kill the engine and restart. > > takeback - kill the engine and feed back in all the game history. > > version - build a configuration file that contains the programs with > the version names. > > Level - Have a configuration that understands the apropriate > commands line arguments for setting various levels for > various programs. If level is set during a game, kill > the engine, reinvoke it with the correct command line > arguments, feed back in the move to catch up to current > position. > > Setup - I'm not sure how easy this is to fake. You can place stones on > the board to set up a position from a book or problem set, but > you cannot be too arbitrary about the order you put the stones > in, or you might accidently make an illegal move. You > would probably end up with a program that could set up most > positions, but people would notice that there were certain ones > that cause it to crash, hang or simply reject. > > > > Doesn't it seem silly that the interface builder should go through > such superhuman efforts to build an interface everyone can use? If a > new go engine comes along, the user must tediously create and careful > test a large set of configuration options that are specific to the > program being "interfaced." Yes, but a client-side library can do this stuff once, rather than requiring every interface builder to do it themselves. > > In fact, why bother with GTP to do this? If GTP itself can't handle > this why would I waste my time using GTP? > > I don't need GTP to learn how each program works, wrap it up in my own > shell and tediously configure a list of programs to work with it. GUI > oriented programs will be harder but even this is doable, I used to do > it with commercial chess programs so that I could autotest them > against each other unsupervised. In involves trapping mouse or > keyboard events, "reading" the screen in graphics mode etc. > > So GTP is either a communication protocol or it isn't, and if it can't > communicate then it's really a "could have been" thing, and people > will stick with GMP (why would they change?) Does gmp allow stones to be placed explicitly ? dd > > Don > > > > From: "Cabrera, Alan" <adc(a)multex.com> > > Couldn't there be a bare bones standard with a set of standardized > extensions? Each set of extensions could be standardized by this same group > that is working on GTP. During the initial protocol negotiation, the set of > extensions that each machine supports could be exchanged. Each machine > would gracefully degrade in features available to the user, depending on > what both machines were capable of. > > > Alan > > -----Original Message----- > From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] > Sent: Tuesday, August 14, 2001 5:02 PM > To: dave.denholm(a)insignia.com > Cc: gtp(a)lists.lysator.liu.se > Subject: Re: [gtp] GTP Goals, ver. 3 > > > > Hi Dave, > > Rather than making each user-interface add the composite commands, we > could provide a separate (free) client-side library which implements > high level commands out of the minimal commands provided by the > protocol. > > But this is not really possible unless GTP has enough primitives to > support it. If there is no "setup" command, as an example, how do you > set up a position? I absolutely agree with you however, we SHOULD > be able to do these things. > > You need a few basic primitives to do all the cool things. I am in > favor of making sure we get them in a standardized set. If we don't, > people (like me) will end up creating our own GTP extensions, and > whoever builds the most popular user interface (or library like you > are suggesting) will be the one actually defining the standard, in a > defacto manner. > > My user interface will actually have incredibly advanced features like > the ability to set up a position or "take back" a move!!! I know how > amazing that may seem to some, but I have this fear that I may have to > create a non-standard GTP command to do these simple things. Since I > will want other programmers to benefit from this, I'll have to > communicate my extensions to the world, and the GTP "standard" itself > will not really be treated as a standard or gain any respect. > > You will get conversations like this: > > Q "Hey, I want to implement the standard GTP protocol so I can use > this super cool user interface I found on the web with my own program." > > A "No, don't use the GTP standard, you can't really do anything very useful > > with it except push moves back and forth between 2 programs. The best > > set is the 'John Doe' set which most everyone else uses." > > Q "But I heard the Bill Johnson set is better?" > > A "Well, they are basically the same, but 'undo' is called 'takeback' > and the Johnson set doesn't let you set levels except by editing the > 'program invocation' box and adding the proper command line arugments." > > Q "I just tried the John Doe set like you suggested, but it does't work." > > A "Which user interface are you using?" > > Q "I'm using the 'SuperGo tools' gui package." > > A "Ok, that's a good one, but doesn't really work with the Doe set, I > guess you have to use the Johnson set. By the way, there is a > patch that let's you set levels by storing a library of different > program invocation strings in a buffer and pressing the F7 function > key to cycle through them." > > ... etc. > > > Don > > > > > > From: Dave Denholm <dave.denholm(a)insignia.com> > > Don Dailey <drd(a)supertech.lcs.mit.edu> writes: > > > I would like to also point out that we CAN have a very complete set > > without it being "big" and involved or difficult to implement. A set > > was already sketched out that is very small, but makes it possible to > > design a full featured user interface. > > > > By "full featured" I mean just all the basics, saving and loading > > games, positions, setting levels, taking back moves etc. Almost any > > highly advanced features can be composed by a user interface if we > > have the minimal support that I am asking for. Also, I don't want to > > be forced to add my own non-standard commands just to be able to do > > something really as basic and simple as taking back moves. How lame > > is that? > > > > > Haven't really been keeping up, but... > > Rather than making each user-interface add the composite commands, we > could provide a separate (free) client-side library which implements > high level commands out of the minimal commands provided by the > protocol. > > In fact, it could even do things like > > if ( gtp_do_this_thing() == NOT_IMPLEMENTED ) > { > gtp_do_that_first_simple_thing(); > gtp_do_that_second_simple_thing(); > ... > } > > > Eg if loading an sgf file is not implemented, the library can load > it and send down lots of addstone commands. > > > > (I'm not suggestinging this as part of a gtp interface library, but as > a value-added separate layer...) > > > dd > -- > dave.denholm(a)insignia.com http://www.insignia.com > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp > > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp > > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp -- dave.denholm(a)insignia.com http://www.insignia.com

4 4

Re: [gtp] New Command: command_list
by Dave Denholm 15 Aug '01

15 Aug '01

Don Dailey <drd(a)supertech.lcs.mit.edu> writes: > This would be a useful command but the idea is to have a single > standard (I think.) There is a lot of resistance to any kind of > convienence feature, so I doubt this will go over well, even though I > personally like it. It would be an easy way for a GTP based tool to > quickly find out if the client implemented the standard set or at > least enough for the tool to function. Well, there is the precedent that, even though protocols like smtp or nntp are intended for program<->program, they provide help : $ telnet localhost smtp Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. 220 honda.isltd.insignia.com ESMTP Sendmail 8.9.3/8.9.3; Wed, 15 Aug 2001 18:36:18 +0100 help 214-This is Sendmail version 8.9.3 214-Topics: 214- HELO EHLO MAIL RCPT DATA 214- RSET NOOP QUIT HELP VRFY 214- EXPN VERB ETRN DSN 214-For more info use "HELP <topic>". 214-To report bugs in the implementation send email to 214- sendmail-bugs(a)sendmail.org. 214-For local information send email to Postmaster at your site. 214 End of HELP info help mail 214-MAIL FROM: <sender> [ <parameters> ] 214- Specifies the sender. Parameters are ESMTP extensions. 214- See "HELP DSN" for details. 214 End of HELP info quit 221 honda.isltd.insignia.com closing connection Connection closed by foreign host. So given that gtp might be used interactively, list of commands could double up as help. Feels kind of wrong to standardise the format of the help output, though ! But would a gtp version number would be a better indicator of level of standard support ? Possibly worth tracking separately the comms protocol and the command set. > > Don > > > From: "Phil" <PhilippGarcia(a)home.com> > > I would like to propose a new GTP command: command_list. It that returns a > list of all implemented commands (space delimited). For example: > > < command_list > > boardsize name protocol_version version black white genmove_black > genmove_white undo > > This way the client can determine what GTP commands are available without > having to attempt them. > Maybe one per line rather than space-separated list ? (Is there a maximum line length defined by the lowlevel part of the protocol ?) dd -- dave.denholm(a)insignia.com http://www.insignia.com

1 0

Re: [gtp] GTP Goals, ver. 3
by Dave Denholm 14 Aug '01

14 Aug '01

Don Dailey <drd(a)supertech.lcs.mit.edu> writes: > I would like to also point out that we CAN have a very complete set > without it being "big" and involved or difficult to implement. A set > was already sketched out that is very small, but makes it possible to > design a full featured user interface. > > By "full featured" I mean just all the basics, saving and loading > games, positions, setting levels, taking back moves etc. Almost any > highly advanced features can be composed by a user interface if we > have the minimal support that I am asking for. Also, I don't want to > be forced to add my own non-standard commands just to be able to do > something really as basic and simple as taking back moves. How lame > is that? > Haven't really been keeping up, but... Rather than making each user-interface add the composite commands, we could provide a separate (free) client-side library which implements high level commands out of the minimal commands provided by the protocol. In fact, it could even do things like if ( gtp_do_this_thing() == NOT_IMPLEMENTED ) { gtp_do_that_first_simple_thing(); gtp_do_that_second_simple_thing(); ... } Eg if loading an sgf file is not implemented, the library can load it and send down lots of addstone commands. (I'm not suggestinging this as part of a gtp interface library, but as a value-added separate layer...) dd -- dave.denholm(a)insignia.com http://www.insignia.com

2 1

RE: [gtp] GTP Goals, ver. 2
by Cabrera, Alan 13 Aug '01

13 Aug '01

Two good points. Thanks for the quick response. My response would be that for every platform, there usually is an XML/SAX/DOM library so, lexing, parsing, character encoding, would automatically be taken care of. These libraries are quite easy to use; have you ever tried to read someone else's lexer/parser, much less debug it? Using XML would encourage implementations across the many OS/language platforms while also supporting internationalization. Extensions could be handled with namespaces. You don't have to worry about issues such as newlines/CR. I think that many implementation issues would be solved using XML. Regards, Alan -----Original Message----- From: William M. Shubert [mailto:wms@igoweb.org] Sent: Sunday, August 12, 2001 12:02 PM To: Cabrera, Alan; GTP Mailing List Subject: Re: [gtp] GTP Goals, ver. 2 For UTF-8 vs. ascii, the beauty of it is that ASCII is a subset of UTF-8 and all non-ascii characters show up as strings of bytes >127 in UTF-8. That means that having the base command set in ASCII but comments in UTF-8 lets people write 100% ASCII lexers if they want, and they only need to worry about UTF-8 if they have non-ascii comments coming in. If they don't care about non-ascii comments looking garbled, then they can write a purely ascii parser and everything works fine. For XML, my question to you is: how would XML be better than what people are talking about now? XML has a few definite drawbacks (XML is much more complex than what has been discussed here so far, so you would need to use an XML library to parse GTP, and integrating another library into your program always requires more time and work). Usually XML's benefit is that you can deduce the structure of your communication without knowing anything about the content, but in the case of GTP, how would that make our lives any easier? Cabrera, Alan wrote: >What was wrong with my idea of using UTF-8 instead of ASCII? Also, what >about XML? Do you have any thoughts on this or am I way out in left field? > > >Regards, >Alan > >-----Original Message----- >From: William M. Shubert [mailto:wms@igoweb.org] >Sent: Sunday, August 12, 2001 2:15 AM >To: GTP Mailing List >Subject: [gtp] GTP Goals, ver. 2 > > >OK, there were some good suggestions, here's take 2 on the GTP goals. My >thoughts... > > * I think a minimal command set is absolutely necessary, but I > clarified the bullet for what most people seem to think is the > need: tournaments. If we leave all things optional, I can see one > programmer saying "Hmm, I don't ever do undos, I can leave that > command out", then if in a tournament an undo is needed (due to > operator error entering a move or some such), one of the programs > is totally screwed. We 100% need to say "you MUST implement these > commands to play in GTP tournaments." > * I clarified many of the points to say more precisely what they mean. > * I added "additional programs that would be nice but aren't > necessary for GTP to be usable" because lots of people were > suggesting programs they wanted to see written. > * I left in the requirement for GMP vs. GTP tournaments. I also see > this as necessary, because we don't want to force all old programs > to get GTP front ends, and we want to let GMP and GTP programs > participate in tournaments together. > * A few items added that people recommended, such as have GMP be > able to do general interfaces. (Seems like a really good idea, > that way one front end can be used by several programs, letting > programmers spend more time on their algorithm and less on front > end programming.) > * Some people were bringing up commands that they wanted, I left all > them out of this document. That belongs in the spec, not in the > goals document...I want the goals to be just what we want to do > with GTP and what we need to do to be successful, not include info > on how GTP will work. > >Well that's enough babbling. Here's the next version of the goals >document. Again, all comments are welcome! >************************ >GTP Goals version 2 > >Part I - Functional Requirements. These are the actions that our command >list must allow go programs to perform. > > 1. Usable to play games vs. other programs head to head. If the protocol > requires some kind of arbiter, that's OK, but see III.1. > 2. Usable for regression tests on programs. > 3. Usable for playing go on a server. > 4. Usable to write full featured interfaces. > >Part II - Implementation Goals. Constraints that we must follow when >designing the exact command list. > > 1. Simple to implement, debug and understand; all commands are ASCII, > all human text (comments etc.) is UTF-8, exactly one line per > command, each command gets an exactly one line response. > 2. Possible to create bridges that let GMP programs play head to head > vs. GTP programs in tournaments. Note that GTP and GMP will not > necessarily have the same feature set - just the possibility of > playing against each other is necessary. > 3. There must be a minimal command set that is exactly enough > commands to play head to head tournament games, no more no less! > All commands required for regression tests or server play should > be optional extensions that programmers need not implement. > 4. It should be possible to design software that gracefully deals > with unimplemented GTP commands/features. > >Part III - Necessary Auxiliary Programs. These are programs that we (the >GTP designers) must write for GTP to be successful. All must be open source. > > 1. An example program that implements the minimal GTP command set > properly and can play a legal game (similar to the goDummy program > for GMP). > 2. An arbiter to be used in head-to-head games, communicating to both > programs, judging legal/illegal rules, etc. Should the arbiter > know how to score a game? > 3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play > against each other. > >Part IV - Additional Programs. These are programs that are not necessary >for us to call GTP "done" but would be useful to have publicly available. > > 1. A sample GTP program that understands all of the commands. > 2. GTP bridges for various servers. > 3. GUIs and other human-usable front ends so that programmers who > write GTP programs can automatically play against their programs, > query their programs as to evaluations, etc. > 4. A GTP test system/test library to determine whether or not a > program is emitting legal GTP. > >************************ > -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

3 2

GTP Goals, ver. 2
by William M. Shubert 13 Aug '01

13 Aug '01

OK, there were some good suggestions, here's take 2 on the GTP goals. My thoughts... * I think a minimal command set is absolutely necessary, but I clarified the bullet for what most people seem to think is the need: tournaments. If we leave all things optional, I can see one programmer saying "Hmm, I don't ever do undos, I can leave that command out", then if in a tournament an undo is needed (due to operator error entering a move or some such), one of the programs is totally screwed. We 100% need to say "you MUST implement these commands to play in GTP tournaments." * I clarified many of the points to say more precisely what they mean. * I added "additional programs that would be nice but aren't necessary for GTP to be usable" because lots of people were suggesting programs they wanted to see written. * I left in the requirement for GMP vs. GTP tournaments. I also see this as necessary, because we don't want to force all old programs to get GTP front ends, and we want to let GMP and GTP programs participate in tournaments together. * A few items added that people recommended, such as have GMP be able to do general interfaces. (Seems like a really good idea, that way one front end can be used by several programs, letting programmers spend more time on their algorithm and less on front end programming.) * Some people were bringing up commands that they wanted, I left all them out of this document. That belongs in the spec, not in the goals document...I want the goals to be just what we want to do with GTP and what we need to do to be successful, not include info on how GTP will work. Well that's enough babbling. Here's the next version of the goals document. Again, all comments are welcome! ************************ GTP Goals version 2 Part I - Functional Requirements. These are the actions that our command list must allow go programs to perform. 1. Usable to play games vs. other programs head to head. If the protocol requires some kind of arbiter, that's OK, but see III.1. 2. Usable for regression tests on programs. 3. Usable for playing go on a server. 4. Usable to write full featured interfaces. Part II - Implementation Goals. Constraints that we must follow when designing the exact command list. 1. Simple to implement, debug and understand; all commands are ASCII, all human text (comments etc.) is UTF-8, exactly one line per command, each command gets an exactly one line response. 2. Possible to create bridges that let GMP programs play head to head vs. GTP programs in tournaments. Note that GTP and GMP will not necessarily have the same feature set - just the possibility of playing against each other is necessary. 3. There must be a minimal command set that is exactly enough commands to play head to head tournament games, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement. 4. It should be possible to design software that gracefully deals with unimplemented GTP commands/features. Part III - Necessary Auxiliary Programs. These are programs that we (the GTP designers) must write for GTP to be successful. All must be open source. 1. An example program that implements the minimal GTP command set properly and can play a legal game (similar to the goDummy program for GMP). 2. An arbiter to be used in head-to-head games, communicating to both programs, judging legal/illegal rules, etc. Should the arbiter know how to score a game? 3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other. Part IV - Additional Programs. These are programs that are not necessary for us to call GTP "done" but would be useful to have publicly available. 1. A sample GTP program that understands all of the commands. 2. GTP bridges for various servers. 3. GUIs and other human-usable front ends so that programmers who write GTP programs can automatically play against their programs, query their programs as to evaluations, etc. 4. A GTP test system/test library to determine whether or not a program is emitting legal GTP. ************************ -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

3 4

RE: [gtp] GTP Goals, ver. 2
by Cabrera, Alan 12 Aug '01

12 Aug '01

Good point. I'll return to my lurking status. Regards, Alan -----Original Message----- From: Daniel Bump [mailto:bump@match.Stanford.EDU] Sent: Sunday, August 12, 2001 5:15 PM To: gtp(a)lists.lysator.liu.se Subject: Re: [gtp] GTP Goals, ver. 2 Alan Cabrera wrote: > Why not use XML as a basis for GTP? It could handle: > > 1) Private extensions by using namespaces > 2) Newline conventions would be no longer an issue GTP is not XML. If you want to develop an XML based protocol please don't call it GTP. We would object if the name GTP is applied to something too different from what is already implemented and in use. The purpose of this list is to standardize the GTP, not to dream up something different. Daniel Bump _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp

1 0

Re: [gtp] GTP Goals, ver. 2
by William M. Shubert 12 Aug '01

12 Aug '01

For UTF-8 vs. ascii, the beauty of it is that ASCII is a subset of UTF-8 and all non-ascii characters show up as strings of bytes >127 in UTF-8. That means that having the base command set in ASCII but comments in UTF-8 lets people write 100% ASCII lexers if they want, and they only need to worry about UTF-8 if they have non-ascii comments coming in. If they don't care about non-ascii comments looking garbled, then they can write a purely ascii parser and everything works fine. For XML, my question to you is: how would XML be better than what people are talking about now? XML has a few definite drawbacks (XML is much more complex than what has been discussed here so far, so you would need to use an XML library to parse GTP, and integrating another library into your program always requires more time and work). Usually XML's benefit is that you can deduce the structure of your communication without knowing anything about the content, but in the case of GTP, how would that make our lives any easier? Cabrera, Alan wrote: >What was wrong with my idea of using UTF-8 instead of ASCII? Also, what >about XML? Do you have any thoughts on this or am I way out in left field? > > >Regards, >Alan > >-----Original Message----- >From: William M. Shubert [mailto:wms@igoweb.org] >Sent: Sunday, August 12, 2001 2:15 AM >To: GTP Mailing List >Subject: [gtp] GTP Goals, ver. 2 > > >OK, there were some good suggestions, here's take 2 on the GTP goals. My >thoughts... > > * I think a minimal command set is absolutely necessary, but I > clarified the bullet for what most people seem to think is the > need: tournaments. If we leave all things optional, I can see one > programmer saying "Hmm, I don't ever do undos, I can leave that > command out", then if in a tournament an undo is needed (due to > operator error entering a move or some such), one of the programs > is totally screwed. We 100% need to say "you MUST implement these > commands to play in GTP tournaments." > * I clarified many of the points to say more precisely what they mean. > * I added "additional programs that would be nice but aren't > necessary for GTP to be usable" because lots of people were > suggesting programs they wanted to see written. > * I left in the requirement for GMP vs. GTP tournaments. I also see > this as necessary, because we don't want to force all old programs > to get GTP front ends, and we want to let GMP and GTP programs > participate in tournaments together. > * A few items added that people recommended, such as have GMP be > able to do general interfaces. (Seems like a really good idea, > that way one front end can be used by several programs, letting > programmers spend more time on their algorithm and less on front > end programming.) > * Some people were bringing up commands that they wanted, I left all > them out of this document. That belongs in the spec, not in the > goals document...I want the goals to be just what we want to do > with GTP and what we need to do to be successful, not include info > on how GTP will work. > >Well that's enough babbling. Here's the next version of the goals >document. Again, all comments are welcome! >************************ >GTP Goals version 2 > >Part I - Functional Requirements. These are the actions that our command >list must allow go programs to perform. > > 1. Usable to play games vs. other programs head to head. If the protocol > requires some kind of arbiter, that's OK, but see III.1. > 2. Usable for regression tests on programs. > 3. Usable for playing go on a server. > 4. Usable to write full featured interfaces. > >Part II - Implementation Goals. Constraints that we must follow when >designing the exact command list. > > 1. Simple to implement, debug and understand; all commands are ASCII, > all human text (comments etc.) is UTF-8, exactly one line per > command, each command gets an exactly one line response. > 2. Possible to create bridges that let GMP programs play head to head > vs. GTP programs in tournaments. Note that GTP and GMP will not > necessarily have the same feature set - just the possibility of > playing against each other is necessary. > 3. There must be a minimal command set that is exactly enough > commands to play head to head tournament games, no more no less! > All commands required for regression tests or server play should > be optional extensions that programmers need not implement. > 4. It should be possible to design software that gracefully deals > with unimplemented GTP commands/features. > >Part III - Necessary Auxiliary Programs. These are programs that we (the >GTP designers) must write for GTP to be successful. All must be open source. > > 1. An example program that implements the minimal GTP command set > properly and can play a legal game (similar to the goDummy program > for GMP). > 2. An arbiter to be used in head-to-head games, communicating to both > programs, judging legal/illegal rules, etc. Should the arbiter > know how to score a game? > 3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play > against each other. > >Part IV - Additional Programs. These are programs that are not necessary >for us to call GTP "done" but would be useful to have publicly available. > > 1. A sample GTP program that understands all of the commands. > 2. GTP bridges for various servers. > 3. GUIs and other human-usable front ends so that programmers who > write GTP programs can automatically play against their programs, > query their programs as to evaluations, etc. > 4. A GTP test system/test library to determine whether or not a > program is emitting legal GTP. > >************************ > -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

1 0

GTP Implementation
by Phil 12 Aug '01

12 Aug '01

I'm making my Go Text Protocol (GTP) over TCP/IP implementation available to those who are interested. You may download it from: http://www.tgiphil.com/ComputerGo/GTPImplementation.htm

1 0

Why not XML?
by Cabrera, Alan 11 Aug '01

11 Aug '01

Why not use XML as a basis for GTP? It could handle: 1) Private extensions by using namespaces 2) Newline conventions would be no longer an issue Alan > Alan Cabrera > Multex.com, Inc. > 100 William Street, 6th Floor > New York, NY 10038 > mailto:adc@multex.com > http://www.multex.com > Tel: 212-607-2422 > Fax: 212-607-2410 > > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. Any unauthorized > review, use, disclosure or distribution is prohibited. If you are not the > intended recipient, please contact the sender by reply email and destroy > all copies of the original message. > > Any views expressed in the email message are those of the individual > sender except where the sender specifically states them to be the views of > Multex.com, Inc. >

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

gtp