Many people have used the Ken Lowe Play by Email Diplomacy judge, often simply referred to as the 'Judge', but perhaps it is not clear exactly what this is or how it was developed. Well, in this article, I will try to make it clear. The HistoryIn 1987, a person called Ken Lowe started working on a program to automatically adjudicate PBEM Diplomacy games. He wrote it in 'C' and designed it to run on a University of Washington system. It was given the name Judge, and quickly gained a large usage. When Ken Lowe decided to retire from the hobby and close the judge, he passed over its handling to David Kovar. Around 1992, David started up USEF to replace the Judge. During the next few years, a number of other judges started, including USWI, USCA, ZADU. Initially, all the code maintenance was done by David himself, and as other judges started up, the other JKs, and then other members of the hobby, started to join in. However, for a long time, David kept the master copy of the code, and all changes made were sent to him for integrating back into the main source. When David was no longer able to host USEF at his work, he took an old Sun machine from his collection, and donated it to the hobby. This is currently hosting www.diplom.org. With a machine now available and dedicated to the judge development, things moved on. The source code was made accessible to several people, and later put into RCS. Other services to the hobby were also put onto this machine, including at one time, five judges simultaneously running on diplom.org. One of the problems with the source code was that it had been written by Ken Lowe as a project to learn C, and had then been maintained by many different people. As such, it was not in the best of states. So Nathan Wagner (then JK of USWI) decided he was going to take his own version of the code, put the entire code through a code layout program, fix all the warnings which were being generated during compile time, get it as close to ANSI C as possible, improve the implementation of some parts of the code etc. Thus was created Nathan's judge, or njudge. As time passed, the development stopped: David Norman maintained his judge for testing new variants, but new features weren't being added. In 1998, David and Manus Hand started work on USWJ, a judge that used the Ken Lowe source code, but had its input and much of its output through a web front end rather than e-mail. This got to the stage of having a game played on it, but was never set up for full operation, such as producing maps. However, this, together with the web interface Manus had put together to run Payola games, prompted Manus to write a new web-based judge from scratch, the DPjudge. At the end of 1999, I started work on the software and made many changes to it, both new features and some bug fixes. In 2000, Tim Miller and later Greg Greenman, joined the group of developers. Since then, several new judges have been established with new releases of njudge running on them. How it worksNjudge is a set of programs that is (fairly) easily installable and runs on a Unix or Linux machine. It is written in 'C', and is reasonably platform independent. It consists of a message processor, that reads incoming email and then decodes them to work out the commands, as well as a move processor, to perform the movements and other housekeeping tasks (late notifications, dedication adjustments etc.). It uses no special tools or databases, working with a set of files only, and typically occupies between 10Mb to over 100Mb (depending on number of games and activity). It can run on machines from an Intel '386 (or equivalent) upwards. It requires little special skills for the JudgeKeeper (JK) to maintain it, aside from simple system administration. What has been changedSince work started in 1999, a whole host of things have been changed. Some of the most important can be summarised as:
How it is maintainedA long-existing mailing list is used to notify and discuss found problems or possible enhancements. It is then up to the maintainers to decide what will be done and by whom to fix it. Every so often, when the amount of changes made seems significant, a new release is made and those judge-keepers that want can upgrade their judges. Currently, the three active maintainers all run judges and these are usually kept up to date (DEDO, USTX and NZMB) with other judges changing less often. David Kovar maintains the repository of the judge software and the hardware it is stored on. What remains to be doneThere are many changes that could be done, but lack of time as well as minority interest tends to keep the list down. In general, things get done if there is someone who wants them done, and is prepared to put in the time to code it. Current items that are being worked on for future releases include:
How to participateNew developers are always welcome to look at the code and provide their input. The main entry point for the project is www.njudge.org, where all the software can been seen (either as stored archives, or directly from the CVS version tree). Also, the maintenance list can be joined, its archives consulted, a list of judge codes assigned and the code version those active are running. The project currently has three active developers (myself, Tim Miller and Greg Greenman) and one documentator (Christophe Courtois), with a host of people actively participating in the maintenance list, such as Alain T�sio, Philippe Lalande and Kevin Roust, to name a few. If you want to participate, to provide suggestions, make enhancements or whatever, please join in!
If you wish to e-mail feedback on this article to the author, and clicking
on the mail address above |