A blog about learning go and learning computer go. A go beginner tries to improve his game and use their software engineering skills to build a computer go player. Entries about their go reading, computer go reading, go playing, go improvement, go concepts (seki, ko, miai, etc) and progress building the computer go player.

Saturday, June 25, 2005

Go Text Protocol

I've been reading the GTP (Go Text Protocol) spec (version 2, draft 1, July 2002). It's a tool that everyone seems to use to communicate with computer-go engines, whether it's GUIs communicating with engines, servers communicating with engines or scripts that play engines against each other (twogtp and friends).

I've been thinking about why it's done so well and is so widely implemented:

  1. It has a clear objective (communication between a master and a computer-go engine)
  2. It does what it needs and as little as possible else (unnecessary commands in the reference implementation as namespaced out)
  3. It is as simple as possible
  4. It leaves out the issue of haggling over rules (Chinese/Japanese/New Zealand/etc), komi and handicapping.
  5. It leaves out the issue of arranging who is to play
  6. There is a widely available, high quality reference implementation (GNU Go) which is useful in itself
  7. It is clearly better than the protocol it replaced (GMP)

These appear have completely outweighed the fact that the sections seven and nine of the spec are completely empty and the last six commands are completely undocumented. It also doesn't handle boards above 25x25, to be fair, few if any other programs do either, mainly because the standard notation breaks down when the letters A-H and J-Z are all taken (I is not used).

This got me to thinking whether it might not be possible to define a protocol that covered a broader range of problems.


godgeorge said...

go is good

酒店經紀威力 said...

Hello! My name is 酒店經紀 called, is very happy from Taiwan can see your article in here, and knows you