[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: computer-go: gnugoclient 2.0
I've been wondering for a while : is it intended that
there be a distinction between commands "not_implemented"
and generic unknown commands ?
That was not my intent. As you say, you must return "not_implemented"
for any command not understood.
It is fair enough to reserve the syntax of 'undo',
so that anyone who does implement it agrees on the
parameters. But I'm not sure all engines should
recognise it just so they can report a different
message.
But perhaps I've misunderstood the intention
behind a "not_implemented" reply.
The truth of the matter is that if we define a minimal set, and a
program does not honor this, then all that happens is either that the
interface will break, or the interface will be written in a forgiving
style so as to simple report that the program doesn't support it.
I guess it has to do with how minimal you really want to get. I don't
believe we should define every bell and whistle, but I think we should
cover something this basic.
> I discussed how undo should be implemented in GNU Go's gtp
> with Gunnar today and he suggested a scheme that was simpler
> than the one I was thinking of. I think it should be easy
> to do. He wants to keep a stack of all moves that are
> played, just as I did. While I wanted to also keep track
> of captures, his idea was that if undo is called you just
> go back to the beginning of the stack and play each move.
> That should be fast enough.
And even if an engine doesn't keep track of the moves,
the driving program could use gtp commands to reset the
state and replay the moves..?
It's my opinion that this would be poor engineering, a bad way to
implement takeback. This absolutely requires something in the minimal
protocol a lot more complicated that "undo." I'm really against the
idea of requiring a GUI to perform this complicated operation in order
to trick a program into taking back a move.
Also, some programs will lose important state if the position is just
reset as if it's from a completely different game. Even though this
can be preserved by making the engine more complicated, it's a pretty
ugly hack and the goal is to simplify the engine, not complicate it.
And what if the engine is keeping a log of the game? Is it to view
this a brand new position?
I do, however, feel that we should have a setup feature documented,
even if not requiring it. Perhaps we should have an extended set and
a minimal set?
Don