[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [computer-go] Wishlist for playing programs on KGS
After thinking it over, I have decided that maybe the best solution is
one that would give the most flexibility to the engine authors, at the
expense of some complexity to them. This solution I'm about to propose
is something that has been requested before for other reasons, and it
may be useful in general.
1. Whenever a user talks to the engine at all, forward the text as
a KGS-specific command. Something like "kgs-chat <username>
2. If the response to this command to the engine is a success and
includes text after the "=", then the text of the response will
be sent back to the user who sent the chat.
3. When a game ends, the engine will get a clear board request.
Since clear boards never appear in-game (as long as you support
the undo command that is!), an engine can treat this command as
a "the game is over" signal. When the engine exits, kgsGtp logs
out, so if an engine decides though chat or any other mechanism
that it should log out when the game ends, it can simply exit
when it gets the next clear board request (or exit right now if
the last request that it received was a clear board).
4. This does have the drawback that, like all GTP commands, it will
be serialized, so if you send a message to the engine while it
is thinking, you will not get a response until the reponse move
Obviously in addition to using this mechanism to shut the engine down at
the end of the game, it can be used as a general query of engine state
if the engine programmer wishes. kgsGtp will simply pass through all
chats from all users, the engine author can do as much or as little as
they wish with these.
My feelings on the other proposals:
* Rereading the configuration added a lot of complexity and
confusing issues. Some things couldn't be changed after login
(e.g., user name of the engine), others could, and dividing the
properties up into these groups is difficult. There is also the
race condition, what if the file is read while it is being
written, and I get a partial file? Could lead to weird bugs.
Overall seems very "hack-like".
* Having magic messages that the GTP client itself understands,
without forwarding to the engine, simplifies things but removes
a lot of flexibility.
* Adding an extra GTP command to query the engine "should we do
another game?" also lacks flexibility, and doesn't seem to
simplify engine programming any over the chatting proposal.
Really instead of this, the engine could simply exit when it
gets a request to clear the board, that would do about the same
Comments are welcome. If the consensus is that this will be useful, then
I'll add it to my to-do list.
computer-go mailing list