I also have spent a GREAT DEAL of time thinking about all of these issues.
My main goal was to build something that would benefit the whole computer Go community, a really usable Go interface that would work with ANY go engine.
I still want to do this, but I feel like I'm asking for something this group is not willing support. It's not my intention to force this on anyone, I just wanted to do something I thought was really cool and would benefit all of us.
Here is what I have decided to do. I will write a set of various tools including a user interface that I will contribute. All of these tools will use GTP extensions that I have defined. In order to make sure there are at least a few go engine choices, I will also provide "shell wrappers" for any text based go engine I have access to which will make them act as if they have implemented my protocol. Think of the go engines as devices and my wrappers as device drivers to get the general idea. I'll stay as close as possible to whatever minimal protocol we come up with as a group.
If a GTP standard ever gets defined and the protocol is complete enough to support those basic features end users want, I'll conform by making my tools use this protocol. I will also provide documentation on my extensions so that others can benefit if they choose.
Whether these tools are popular or not, I think the effort will benefit everyone. Maybe this will spur someone else on to do something better, and I am interested in seeing how the issues of inconsistent interfaces is dealt with by others.
Can anyone help me compile a list of freely available TEXT based go programs?
Don
From: William Harold Newman william.newman@airmail.net
On Wed, Aug 15, 2001 at 10:21:14PM -0400, Don Dailey wrote:
From: William Harold Newman william.newman@airmail.net References: 20010815145635.A5952@rootless 200108152144.RAA04457@silk.supertech
On Wed, Aug 15, 2001 at 05:44:17PM -0400, Don Dailey wrote:
Both GMP and IGS protocol support undo. How many programs actually use it?
What user interface is complete without undo?
Which is more important, to standardize a protocol which implements a complete user interface, or to standardize a protocol which does a good job on the features that programs actually use when interfacing to other programs (including servers and multitool-things like cgoban)?
The answer? BOTH! I say this out of my own needs. I want to build a really cool interface that everyone can use. Can't do it with GMP.
Last night as I was driving to the Dallas Go Club, I got to wondering..
Why do you want a go-playing engine to use text commands to interface to your really cool interface? Isn't it more normal, and convenient, for a user interface to talk to a program through a set of functions callable from C or Java or whatever?
The answer is that I don't want to write this interface just for myself, I want to contribute it to the whole computer go community. It seems too much to ask everyone to rewrite their code and link in my libraries just to be able to use my interface. What if 3 other people did the same thing? Then we have 3 sets of libraries floating around and lots of tools that won't work unless you picked the right one.
Now GTP could end up being a standard everyone uses. If so, then we would instantly have a pool of go engines that would "just work" without asking any questions. Additionally, we could write all kinds of tools that also will work with ANY Go engine. Of course these won't work either if we partition the GTP standard into many groups.
It is my feeling that we have lacked imagination here. Having the ability to communicate directly with ANY engine makes software possible that apparently no one has even thought about. The only thing I keep hearing over and over is "why do I need 'setup' to just play a match with another engine", as if that is the only possible use.
The library idea is good too, but it is essentially a different thing with a different goal. Since I would build GTP support into any engine I design, I would probably either build GTP into the library or make the
The idea of writing a library is of course a more specific answer, and less likely to get used by the whole how I would do it if all I wanted was to interface to
I have come to the conclusion that I just have to focus on these issues on my own, define my own protocol and write the software that no one is interested in for myself as a first pass. When someone I have discovered that peoples imagination is often stimulated when they actually see something work
If you want a protocol that lets lots of different combinations of computers play Go against each other, then TCP looks natural, and then text commands make sense.
If you want an engine to be able to present a GUI, why mess with TCP?
Are you thinking of an interface to an IGS-style server, as opposed to an interface to a Go-playing engine?
-- William Harold Newman william.newman@airmail.net "Three hours a day will produce as much as a man ought to write." -- Anthony Trollope PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp