poirier@dg-rtp.dg.com (Charles Poirier) (05/04/90)
In article <4120@infmx.UUCP> giao@infmx.UUCP (Giao Tien Vu) writes: >The GNU Go version that I worked on a while ago was abandoned due to: > > a) poor computer player (as a beginner, I only lost one game during > playtesting). The computer made a lot of bad moves. I've beta tested a Gnu Go Amiga port lately, and took a peek at the source code, and the above is an understatement. A lot of those "bad moves" are, in fact, *random* moves. It's gen_move algorithm is basically 1) Can it capture immediately or threaten capture, 2) Can it avoid immediate capture, 3) Is there a stone pattern (out of about 20 canned patterns plus their rotations and reflections) for which it has a canned next move, 4) Pick someplace at random having at least two liberties and not too close to an edge, 5) If after 400 attempted picks it can't find a qualifying random move, pass. Needless to say, the last two rules make playing the endgame to conclusion really infuriating, at 40 to 75 seconds per move. I had to subdivide my entire vast territory into two-point cells to get Gnu Go to finally give up the ghost. Rule 3 is an interesting idea, but, I think, of inadequate power or generality to play good Go, regardless of pattern tuning. I believe it is doomed to run afoul of a common trap of rule-based design, by which it is easy enough to wire in a few sound features but terribly difficult to cover all bases. There is no provision for proscriptive patterns, saying "Don't play here!" Gnu Go's patterns have no global sense; it was rather eager to play move after move making redundant eyes inside its own territory. The rules have no sense of what makes for a live group, nor of how much area is needed to make a live group. They have no concept of influence. There are other problems. I'm sorry to say it, but I think Gnu Go deserves to be abandoned. Cheers, Charles Poirier poirier@dg-rtp.dg.com