Re: [gnugo-devel] Webinterface to gnugo

[Gunnar Farnebäck]

Arvid wrote:
> I guess my main-problem is how I can make gnugo remember a state? I
> may be wrong, but wouldn't the "best" (read "easy") way to solve this
> problem just be to feed gnugo a state -> record the move -> terminate
> gnugo -> give gnugos move to the user -> let the users make a move ->
> feed the new state to gungo. This does however require a lot of new
> processes, which indeed takes time, but to me it looks like a lot
> cleaner solution that holding gnugo alive - or what do you think?
> 
> Second - is there a good way to feed gnugo a state? Again - the easy
> solution would be if you could just feed the current state of the
> board as an argument to gnugo, but as far as I can se that isn't
> possible. Second - does gungo have some kind of save/load
> functionality which could be used to save/load a game? ..or would I
> have to write my own top-level interface using the gnugo API to do
> something like this?

You can feed a board state to GNU Go by multiple means, including:
* Load an sgf file at startup with the -l option.
* Load an sgf file from within the ascii mode. (Not recommended.)
* Enter a sequence of moves in the ascii mode. (Not recommended.)
* Enter a sequence of moves in the gmp mode. (Not recommended.)
* Load an sgf file in gtp mode with the loadsgf command.
* Enter a sequence of moves in gtp mode with the play command.

For sgf output there is the -o option and to a limited extent the gtp
printsgf command. Just the move itself can be obtained in any mode.

The main drawback of not keeping the GNU Go process going between moves
is that you lose the internal persistent cache which speeds up move
generation significantly. There is currently no support implemented for
dumping and restoring this cache.

/Gunnar