Prompted by a few requests I had very recently with regards to the
computer-Go framework I once started, plus some free time between a
project I just finished and waiting for a visa to start my next, I
have started on a project probably best described by the title of
this message.
Whenever someone looked at my computer-Go framework they invariably
where overwhelmed by what was there and didn't know where to begin.
And I must say it probably hasn't helped that it's gotten rather
intertwined with some of my personal experiments. So it's probably
not surprising that it doesn't seem to have too many users.
So when Jim O'Flaherty approached me a few days ago about a framework
to get new Go programmers started, I decided it may be a nice idea to
do just that. A project that can be downloaded, and when instructions
are followed a newcomer, someone who hasn't ever programmed Go
before, can have a bot that plays random moves up and running in
about ten minutes. As Jim pointed out, this potentially not only
helps out beginners to get started, but may also provide an easy way
for tournament managers to get a bot up and running in a standardized
way without the developer needing to be present. (Well, as long as
the bot is in Java of course. But other languages may follow this
example.)
Maybe this is stretching things a bit and ten minutes isn't a whole
lot for embarking on what is still one of the most challenging
software engineering problems that exists. But I am someone who
thinks that barriers are to be broken down and it should be made as
easy as possible. I myself have little patience for open-source
projects where it takes hours to download, compile and configure a
project just to get started. More often than not I give up in
frustration. I'm a "self-extracting-archive-that-installs-everything"
type of guy. Otherwise I move on and look for something easier.
I think there are already two pieces of excellent software that help
the Go programmer today. One is GoGui, which takes a boat-load of
work on the front-end out of the hands of aspiring Go programmers.
The other is CGOS, which I think is arguably the best platform for
testing new ideas against real opponents.
But in between the two, connecting with your playing engine in an
easy way is still a missing piece, so hopefully this is something I
can fill in. There has been much discussion recently about Don's Java
reference bot. I think there already exist several of them. Peter
Drake has a solid reference implementation with Orego. My framework
has one. And there are probably more out there. The problem with all
of these is that they still don't really make it easy for someone to
start their own.
So the last few days I've been busy making a kind of plug-in
architecture. All you need to do is provide a JAR with a class that
implements an interface of a handful methods and you're ready to put
it on CGOS. Or you can use it in combination with GoGui, or twogtp.
There are still some loose ends to tidy up before I'll make this
public but it probably won't take long. You're still 100% free to
design the playing engine any which way you like, but all the
communication stuff will be completely take out of your hands.
Doing this I have had a few bumps in the road though. And no matter
how invaluable I think CGOS is, there are a few (I hope constructive)
criticism I'd like to make.
I have everything working nicely on my Mac OSX. But on Windows things
are problematic. The cgosGTP-win application doesn't work at all.
When going to a bit more trouble and tracking down the tclkitsh and
using that instead, I see some erratic behaviour. Often it stops
after putting out "Engine does not support time control commands".
Even when it gets past that, I invariably get a broken pipe message
as soon as a game starts. Although exactly the same application works
fine on a Mac, I'm very willing to believe the problem is on my side.
But the problem is I get no feed-back. Whatever error would be put
out by my application is not shown on the console. Nor is there any
other hint of what could be the matter, it just splurts out a whole
lot of junk from some script. I believe it would be a big help if
this was improved. Input by others who have experience with this on
Windows would be greatly appreciated.
Since it takes some time for a new round to start, debugging quickly
becomes a very time-consuming business. Before actually putting it
out on CGOS, I always do some test-runs with GoGui and the related
twogtp, but apparently this is no guarantee to success. So what I'd
like to see is a CGOS-mockup implementation. A program that puts a
bot through its paces to make sure it completely complies with CGOS
before actually going online.
I want to stress again, I don't just want to throw some random
criticism out there. I want to help improve things. So if I can help
with the issues I just described above I'm more than willing to help
work out a solution. And preferably I'd like to make sure that I'm
going to be the last one having to deal with these issues.
Mark
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
