Frequently Asked Questions

Frequently Asked Questions

  1. What are the goals for the project?
  2. Why do you think that this project will succeed when all others have failed to produce a Dan level player?
  3. What is the state of the software?
  4. Why does the program play so poorly?
  5. How can I contribute to Moyoman?
  6. Who is in charge of this project?
  7. How do you use the SourceForge tools?
  8. What are the weaknesses of this design?
  9. Why do some module names start with Simple, and others end in Impl?
  10. Why did you write your own client, instead of supporting GMP or GTP?
  11. Don't you guys believe in testing?
  12. What are some of the more humorous bugs?

What are the goals for the project?

The long term goal is to have a program that can either compete with the top professional players, or else to determine the limitations of this approach, and to have a better understanding of how to design the next generation Go program. Certainly, it is expected that with enough contributors, the program should be able to reach the low amateur dan level. An optimistic estimate of this is June 2014, and that assumes the contributions of dozens if not hundreds of developers.

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.

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.

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.

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:
  1. Read the documentation!
  2. Decide what you want to do.
  3. Email me to discuss your plan.
  4. Do it.
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.

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.

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.

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.

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 has most of the information that you need.

To do a read-only checkout of the source tree, enter: cvs co moyoman

Alternatively, you can download the latest source or executable jar file from the summary page.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.