The first short term goal is to have the program complete a game in computer - computer mode at least at the level of a human novice. This means that the program plays legal moves, and then each side passes at the appropriate time. It does not imply that the program removes prisoners and computes the score. Even this requires a non-trivial amount of work, and the program is not yet at that point. This is estimated to be complete by June, 2005.
A slightly longer goal is to have the version 1.0 release. This is the first release that would actually be useful to a beginning player. An objective measure of this might be when Moyoman can beat the GNU Go program with a four stone handicap, where Moyoman takes black. Keep in mind that the algorithms used by GNU Go can be ported to Java and used in Moyoman. An optimistic estimate of this would be June, 2006.
Once the version 1.0 release occurs, there is then continuous development
until the limitations of the current design are discovered.
The design is not fixed, and will change as a result of comments and
suggestions from other developers. Until version 1.0 is released, anything
might change. Once that occurs, the core design should only change in ways
that are backwards compatible. The closer the release numbers are to 1.0,
the less frequent and smaller the changes should be.
The main features generally work, but there are lots of more complex boundary cases
that do not. For example, resume game may or may not work depending on
the point at which the program was interrupted. Issues like this will all
have to be addressed before the version 1.0 release.
There is a great deal of work to be done. It is important that the design
of the system is sound. Reviewing this and making suggestions for improvements
would be very useful. Another useful thing would be to implement a new module,
such as Shape or LifeAndDeath, or writing a better version of an existing module
such as Endgame or Fuseki. See the documentation for more information.
You may implement any module type that you like, whether or not one already
exists. In particular, any module type where there is only implementation,
and the name starts with Simple is a candidate for a more sophisticated
implementation to be written. If you coordinate with
me, then I can tell you
if anyone else is working on the same module type that you are interested in.
David Weiss conceived,
designed, coded, and documented the entire project except for the client for the
version 0.1 release on SourceForge, and is responsible for the project as
a whole.
To do a read-only checkout of the source tree, enter:
cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/moyoman co moyoman
Alternatively, you can download the latest source or executable jar file from the summary page.
A Ko module would want to use the results of the LifeAndDeath module in order
to generate ko threats, but the LifeAndDeath module will have to deal with
problems involving kos, and so might want to use the results of the Ko module.
Currently, if module A can use the results of module B, then module B cannot
use the results of module A. The current solution is to have a Ko and Ko2 module
type, where Ko is before LifeAndDeath, and Ko2 is after. This type of problem
will have to be carefully addressed.
The design of Moyoman assumes incremental processing, so the Shape module
determines good and bad shape, Tesuji finds sequences of good moves, etc.
Some modules, such as LifeAndDeath, might need to do extensive reading of
moves in order to do their work. The current design, where the module would
call getScheduler() and then clone the Scheduler object and call makeMove()
on it for each possible move, is not the most efficient way of allowing
for search in terms of number of positions evaluated per second. The developer
needs to understand up front that this is a potential problem of working
within the Moyoman framework. Signficant work will need to be done to make these
types of operations as efficient as possible.
Module names which end in Impl indicate a more sophisticated implementation
than the modules starting with Simple, usually taking one to four months to
develop. Or, as in the case with RandomImpl, they are so simple that no
other implementation is needed. Modules such as BoardImpl or GeometryImpl
can be replaced, or they can be modified over time as needed.
Hopefully at some time in the future, some of the Go clients will develop
a standardized means of communicating and displaying debugging information,
and Moyoman would add support for third party clients at that time.
Almost all of the testing will be integration testing, as it would be rather
difficult to do unit testing by using tools such as JUnit.
Developing an overall strategy for this, and coordinating the work of different
testers is obviously a very large problem, which could rival the scope of the
development effort. Ideally, there would be a separate group of developers who
would work solely on the testing code without writing any modules. Until
developers are found to lead this effort, testing will mostly be done manually.
Somewhat less humorously, the open and resume code needs to be more
sophisticated, so that the last move for which both sides were saved
is the one which is loaded.
Both the GeometryImpl and SimpleSafety modules often produce results
which are way off.
Over time, as new code is added and older code is refined, these types of issues
will go away and the overall quality of the project will rise. This is mostly
a matter of putting in adequate time and effort. It was considered important to
publicly release the project sooner rather than later, and to fix all of the
warts and blemishes over time.
Why do you think that this project will succeed when all others have failed to produce a Dan level player?
It is assumed here that one hundred person years of effort or one million executable lines
of code are required for a program to reach amateur 1 Dan in ability. Since no one
has yet developed a program of this magnitude, I would say that no attempts have been
made so far to write a Dan level program. I see this as being as much of a management problem as a
technical problem. If enough developers contribute their time to this project, then
it will succeed.
What is the state of the software?
All of the functionality kind of works. Basically, I released the software
as soon as I could without it being too embarrassing. Very little of the
code can be considered to be mature, except for the client which was written
by Jeff Thompson. It is only meant to be used by developers, as it is not
nearly strong enough for anyone to find it useful to play against. There is
way too much work for one or a small number of people to try to do this on their own.
Why does the program play so poorly?
Writing a Go program is very labor intensive. Unlike a Chess program,
the programmer is doing most of the work. About 2 person- years of work
have gone into Moyoman so far. Perhaps 8 months of that was work on
the strategy. The quality of play should increase rapidly as other
developers contribute modules.
How can I contribute to Moyoman?
Here are a series of steps that you should follow:
There is no point in working on a project if you don't agree with its design
philosophy, or you don't understand it. If you are considering putting in a
serious amount of time on this project, taking at least one day to study the documentation
and the javadoc seems prudent.
Who is in charge of this project?
It is intended that responsibility for the code be widely distributed.
Thus, if you implement a LifeAndDeath module, you are in charge of that
particular module. If three different people implement LifeAndDeath modules,
each is responsible for their own implementation. So there might be dozens,
or eventually even hundreds of people in charge of various parts of the code.
How do you use the SourceForge tools?
SourceForge has a good selection of tools, along with extensive documentation
and excellent technical support. Registering as a SourceForge user is free, and
you should do so if you want to be a contributor to this project. The page
http://sourceforge.net/projects/moyoman
has most of the information that you need.
What are the weaknesses of this system?
I have tried to make the assumptions on which Moyoman is based as explicit as possible. Two of the most problematic are the assumption of linear ordering of modules, and the
heavyweight nature of the framework.
Why do some module names start with Simple, and others end in Impl?
This is a naming convention which I have used as a hint to others. Module
names which start with Simple indicate that the algorithm used is very simple,
and that a more sophisticated implementation is needed. It also indicates
that this module is not intended to evolve into a more sophisticated form,
but that a new one should be written from scratch. For example, the SimpleFuseki
module was written in three days. It will take an empty corner if one is
available, next it will play on the third line under the side star point if
there is room for a two space extension in either direction, and finally it
will make a shimari if possible. The algorithm is very simple, but it is
good enough for now. Also, it can be used as an easy to understand example
of the minimum that a Fuseki module needs to do. It would be very
useful for other developers to write simple modules. Even though the code will
be replaced within a few months or years, it will allow the developer to learn
how to write a module for the system, and it will allow the program to quickly improve.
Why did you write your own client, instead of supporting GMP or GTP?
It is intended that Moyoman will support a GTP player so that the program
can play against other computer programs. This will be implemented at some
time in the future when necessary. The reason that a custom client was written
is to support the graphical debugging capabilities of the server. This is
considered the most important feature of the program other than actually
generating moves, and there is currently no third party client which supports this.
Don't you guys believe in testing?
Testing is going to be a large component of the Moyoman project. Testing will
not just be looking for bugs, but also evaluating modules. For examples, if
a strong player determines that for a given board position there are 23 moves that
would result in good shape and 15 moves that would result in bad shape, then
Shape modules would be tested and given a score based on how many of these
they get right. This would obviously not be a pass-fail test. For other modules,
such as the Board module detecting illegal moves, there would be pass-fail tests.
What are some of the more humorous bugs?
The program will sometimes pass around move 40. That is pretty funny.
There is lots of other humorous stuff scattered throughout the code.
Take a look at the org.moyoman.framework.ServerConfigTool class.