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.
Then we are finished. The 4 commands are genmove_white, genmove_black, black and white. Everything else can be done by passing the proper commands line parameters to the program.
This means everything else is optional, the very thing you (and everyone else who responded) seemed to think was a bad idea.
If we don't start with something complete, I will end up making up my own private commands and no one else will be able to use my tools (and this will happen with everyone elses tools too.) Do you think this is really what our goal is?
If you are saying we do a complete optional set and just specify a subset as "the minimal set", then let's move on to defining the "real" set.
Don
From: "William M. Shubert" wms@igoweb.org
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@igoweb.org) mailto:wms@igoweb.org http://www.igoweb.org/~wms/ http://igoweb.org/%7Ewms/
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp