Run on the KGS server's SQL game database:People actually play 8x8 ? I'll give NNGS a peek.
mysql> select from_unixtime(date_stamp/1000),black,white from games where board_size = 8 and owner is null;So people do play 8x8, just not very much (117 games out of about 400,000 in the 2+1/2 years that KGS has been around).
+--------------------------------+------------+-----------+
| from_unixtime(date_stamp/1000) | black | white |
+--------------------------------+------------+-----------+
| 2001-02-01 05:43:23 | faz | Sean2win |
| 2001-02-07 13:45:41 | Lantu | sencha |
| 2001-04-25 12:38:04 | jefounet | atadano |
| 2001-05-30 05:23:07 | JJ | kaz |
| 2001-06-21 15:37:25 | nickwild | dezomb |
...
| 2002-07-10 13:05:28 | bgoodwin | pinhead |
| 2002-07-10 13:23:49 | bgoodwin | touyo |
+--------------------------------+------------+-----------+
117 rows in set (3.35 sec)
KGS sends all coordinates as two bytes, "\0\0" beang the lower left, "\22\22" (two 18's) being the upper right and "\377\377" being a pass. But overall, I think this is all pretty unimportant - GTP should be implemented in whatever way makes sense for GTP, not in whatever way matches some server protocol. After all, if you are connecting GTP to a server, converting the vertex format will not be any difficulty.I think, communicating a vertex in %c%u format is pretty standard. Just stay with the hurd... paperware,IGS,NNGS: %c%u GMP: %u SGF: %c%c Kiseido: Propriety ?
KGS does indeed implement free handicaps for Chinese and New Zealand rule sets and players are using it. It seems to me that the GTP handicap system is both complex and restrictive. Why not just have a "handicap <n>" command, which specifies the handicap; then for fixed handicap, follow that with a series of "play b <location>" commands; for free handicap, follow the "handicap" command with a series of "genmove b" commands? That seems simpler to implement and more flexible, because now the arbiter in a game can do the handicap any way it seems right, the protocol no longer forces a particular handicap placement system. The only real need of the "handicap <n>" command at all is so that programs can (if they choose) move differently for the 1st handicap stone of 5 vs. the 1st move of a non-handicap game.I am not aware of any free-handicap implementation. Just passing will do for most cases. But, the real reason for wanting it in the protocol, is cause of the HA[] in the game record, I guess. For the rest, the position can just be set up (by AB[],AW[], play) , and komi set seperately.