Friday, April 10, 2009

Release of goia v2, progress of the players

I have finished moving goia to the gnugo engine. It is now working fine, and, although it is much slower than the old version, it seems to be also far more efficient : the bunch of players I evolved on my computer during the last week is already far better than the players that were evolved with the old version in the same period. The differenc lie in the way game is scored : GnuGo provides a far more reliable way to assess game situation, were OpenGo only counted stones and territory without trying to figure out living and dead stones (every stone being regarded as "living").

As an example, here is what happens when the last Goia-GnuGo (white) plays against the last Goia-OpenGo :


For what I could figure out seeing the two play against each other, it rather makes sense : Goia 1 as ended up trying mainly a simple strategy consisting in playing diagonals, which is the most efficient way to obtain territory easily. Now that big chunk of territory can be assigned to the players if they manage to get it (as it is the case in the game shown), Goia2 tries to do this also, mainly here by drawing a vertical line in the middle of the board to clain one half of the board.

This seems pretty encouraging to me, although of course there is much progress to be done. My first serious opponent I am using as a benchmark to test real go playing skills of my players is Joshua, my 5 years old son. He learned the rules of go 3 months ago, and doesn't play very often. No need to say he is objectively pretty bad at the game. Still, he beat Goia2 with ease (he was playing black here) : 



So, here is the new Goia v2 :

I will release very soon a slightly modified version that provides more relevant information in the console.

Also, I still have much difficulties to compile this for Linux, so I am begging for anyone who could use some time trying to help me figure out how I could achive this. I have submitted the whole source code here : http://code.google.com/p/goia/source/browse/#svn/trunk

3 comments:

  1. You shouldn't need a sophisticated programme like Gnugo to score the games at the end, as long as the networks play to the very end so that all stones left on the board can be considered alive. The eye-rule should avoid endless games. Using Gnugo will be relatively slow and also could result in duplicating some of Gnugo's weaknesses. Using the game with your son above as an example, white should have played in the lower left corner to kill the black stones.

    ReplyDelete
  2. Ok, thinking about it it could be only better indeed, forcing the players to learn simple thing (very end game) as well as the more complicated stuff.

    I have two questions though :
    - what is the eye rule you are citing preventing the game to go infinite ?
    - Do you know an existing scoring algorithm I could use when the game is finished indeed, I am kind of a lazy guy (beside, you know, the "real work" thing...).

    ReplyDelete
  3. The "eye rule" is: don't play somewhere if all 4 neighbors are same color AND there is no more than one diagonal enemy (if the point is in centre) or, if the point is on the edge or corner, there are no diagonal enemy stones. When there are no moves left, pass. This is how random playouts in MC engines seem to play.
    Then at the end of the game, they use "Tromp/Taylor" rules for scoring: "A player's score is the number of points of her color, plus the number of empty points that reach only her color."
    To speed things up further, you can use a "mercy rule" to end the game earlier if the score becomes very one-sided. This may not work if you want to extract more information than a simple win/lose.
    Simple monte-carlo "reference bots" that implement these rules (in C, Java etc...) are available online somewhere if that helps.

    ReplyDelete