![]() StartingPoints Referenced by
|
The Code So Far - 2
I decide to write a simple move chooser. The initial algorithm is extremely naive: for each connected string of stones, assign an urgency based on the number of liberties that it has. For all empty spaces, add up the urgencies of all adjacent strings. Pick the space with the highest score. Note that it has no concept of kill versus save or even who the current player is. (defun urgency (liberties-length) (case liberties-length ((1) 50) ((2) 10) ((3) 3) (otherwise 1))) (defmethod get-candidate-moves-0 ((analyzer analyzer)) (let ((worm-info (worm-info (game analyzer))) (game-board (game-board (game analyzer)))) (let ((candidates (mapcan (lambda (worm) (let ((liberties (liberties worm game-board))) (mapcar (lambda (point) (cons point (urgency (length liberties)))) liberties))) (snakes worm-info)))) (collapse candidates #'+))))
The right hand side move a is good if white plays, unfortunately, the problem is for black to play and kill. Problem 1-23 is the first problem in the book for which the correct move is different depending on who is to play.
I add the victory condition code back in - the program now knows it has solved the first 14 problems, 15 is "to save" and it has no criterion by which to judge success. For now, I'll just add the "more than 3 liberties is safe" rule. Maybe I should implement a series of analyzers, varying from fast and simple to slow and careful? Unresolved boards could start with simple analyzers and retry with the more complex ones as game time permits? I've recently been working on an IGS client for Common Lisp, it's far enough along to play games, but lacks a front-end. It might make a good option for integration with some sort of AI. Currently it only plays mirror Go, since I spent all of 5 minutes on the AI :-). You should stop by #lisp on irc.openprojects.net, if you haven't already, there are several of us Go-inclined CL programmers. I'm 'emu'. I'll probably put it up on CLiki at one point or another, too. -- mrd? Gorobei: I will, as soon as I get around to setting up an IRC client on my Linux box :) Life and Death is proving to be really hard. While mulling over ideas, I write a little Bouzy 5-21 implementation: (Print-Bouzy-Map-For-SL +luckys-problem+ 5 21)
This is all very pretty, but reminds me a lot of image processing code: simple stuff looks good, but hard problems (e.g. finding camouflaged tanks) are beyond its scope. E.g. Bouzy's algorithm requires we remove all dead groups, but if we could do this, we probably won't need Bouzy's algorithm in our game code :)
Worse, the algorithm is basically untunable: you can change the dialation and erosion counts, add 'fake' stones, remove dead stones, etc, but at its core it is still a relatively inflexible function.
I rewrite a bunch of the code: symbols are very cool (e.g. having a class represent a Stone seemed a good idea, now I see a symbol is a much better fit.) Computer analysis of life and death has been an open problem for several decades. So it *should* be hard.:-) -- WilliamNewman This is a copy of the living page "The Code So Far - 2" at Sensei's Library. (C) the Authors, published under the OpenContent License V1.0. |