The DPjudge

An Overview, a History, and a Status

by Manus Hand

Even before I published the first issue of The Pouch Zine -- fully five years ago now (wow!) -- I had a vision of a Web-based adjudicator. Now this vision is close enough to reality to write about. In this article, I plan not only to hit on some of the unique features of the DPjudge, but also reflect on the rather strange path that led to its realization.

I set out writing this article intending to keep it short. The plan was simply to list for you the features of the DPjudge. This is still done (at the bottom of the article) but my typing fingers took me on more of a trip down memory lane than I thought they would. So before we get started, I'd like to apologize beforehand to any of you who might not find the history of a software development project interesting reading. I've tried not to be too dry and boring, and, well, believe it or not, it's actually exciting reading for people like me, so give it a shot; it's not bad.

What is the DPjudge?

Before discussing how the DPjudge came to be, it might be nice to actually explain what the DPjudge is. Perhaps the best way to do this is simply to point you to the DPjudge itself and let it teach you.

The DPjudge can be found at:

What will you find when you get there? In brief, you will find a number of active and completed Diplomacy games (and perhaps a few that are forming -- waiting for players). Right there on the Web. A map is viewable for each game, and if you happen to be playing a power in any of the games, you may enter your password at the Website and be treated to a page all your own, where you can enter orders, compose press messages, and do all other things the leader of a major power should be able to do.

That's about all the explanation that I will give in this brief article. We'll be discussing, later in this article, some of the features of the DPjudge that make it unique, but for the complete story, head for the DPjudge itself, and explore its documentation pages (by clicking on "About the DPjudge" and "DPjudge Questions").

Origins of The Pouch

I named the DPjudge after The Diplomatic Pouch. This is because -- as you're about to find out -- the two Websites really grew out of each other.

In 1994 I had my first Diplomacy article published: an article laying out the rules for the "Crystal Ball Diplomacy" variant that I had created with John Woolley. This article appeared in the pages of Diplomacy World, and by then the bug had bitten me hard. I quickly submitted a second article, this one on the "Payola Diplomacy" variant.

At just this time, though, Diplomacy World seemingly ceased publication. As the scheduled publication date fell further and further in the past, I decided to take action on my own so that the hobby could read my all-important article (I've never been the most modest guy; maybe you've noticed). The result, of course, was The Diplomatic Pouch.

As I said in an interview in these pages a couple of years ago, the original intent was that The Diplomatic Pouch would be a print magazine, not a Webzine. (In 1994, there was no such thing as a Webzine.) A couple of things caused The Pouch to blaze its trail on the Web rather than into postal mailboxes:

  1. I dreaded maintaining a mailing list, printing reams of paper, licking envelopes, collecting subscription money. I had resigned myself to the necessity of all this, but I truly dreaded it. To be honest, I probably would have folded after about the first two issues if The Pouch had been a postal zine. Frankly, I don't know how the Postal 'zine publishers do it.
  2. I couldn't find a decent desktop publishing package (remember, this was 1994), or, if I did, I didn't want to pay for it. So I decided to compose The Pouch Zine using HTML and the Web. My intention, though, was to push "Print" on the formatted Web pages, and still go through the postal rigamarole.
Luckily, the light bulb went on during the editing of the first issue. I realized that all I needed to do was make the formatted Webpages publically accessible, et voila! No subscriber list, no printing and enveloping, and no real restriction on issue size. Good thing, too, because it turns out that the first issue of The Pouch (and those subsequent, of course) is something like 100 pages long. I could never have afforded to mail such a tome around.

Nice capsule history of the early Diplomatic Pouch, but I hear you asking "what does this have to do with the DPjudge?" Well, I'll tell you.

When that light bulb went on and I realized that I had birthed the concept of Diplomacy on the Web, my natural inclination was to plan to bring more than just article content there, but to host games, with maps and everything. Easier said than done, of course, especially when you're as busy as I have made myself with The Pouch and everything else. But the seed of the DPjudge had been planted in my mind coincident with the germination of The Pouch itself.

And remember, the whole raison d'etre for The Pouch was my impatience to announce my "Payola" variant after having foisted "Crystal Ball" on the unsuspecting hobby. These two variants were to continue to play a crucial role in driving the DPjudge to completion.

Before we actually get into that, you might be interested to know how The Pouch eventually fulfilled its original mission -- to publicize the "Payola" variant. If you look back in the pages of The Pouch, you will see that I didn't actually publish an article on Payola until the fifth issue of the Zine. There were a few reasons for this:

  1. Unlike my Crystal Ball article, I decided to actually have Payola playtested before publishing anything about it. (Yes, that's right, I believe Crystal Ball was completely untested when it was announced in Diplomacy World. Perhaps the first game was underway but not completed. Luckily, the Crystal Ball rules have remained virtually static since initial publication, though.) So I waited until a few Payola games were completed before publishing my article.
  2. The quality and size of the Pouch Zine issues were not being hurt by my holding the Payola article (this is a credit to all the contributors who answered my earliest calls for articles).
  3. I had time (and -- with the decision to publish via the Web -- the space) to revise and expand the article, and make it truly what I wanted it to be: a complete set of rules, fully annotated with design notes and anecdotes from play.

And so Payola was announced. And the base of Payola players started to grow. By contrast, the Crystal Ball variant, having had no exposure on the Internet, lived only in the back of my mind. Even the first-ever test game was quietly abandoned in mid-stream as I got too busy with editing The Pouch.

Origins of the DPjudge

Why did I find it necessary to abandon (as its Master) the first-ever Crystal Ball game? As I said, I got too busy with The Pouch to do the hand-adjudication that was necessary. Because, by its nature, Crystal Ball could not be run on a normal Ken Lowe Internet judge computer, I adjudicated all the turns myself, and out of stubbornness and an interest in reading all the press, I insisted that the players not know against whom they were playing, so I was also a human forwarding mechanism for all the player-to-player messages (again, remember this was 1995; yes, I know it could have been automated even then, but the fact is that I didn't go to the trouble).

The point is that Hand-adjudicating Crystal Ball Diplomacy was a pain. And the Payola variant suffered from the same problem. Both variants required either an attentive and active GameMaster, or some form of automatic pre-processing before moves could be resolved. Since no such automation existed, I was forced to be an attentive and active GameMaster. And given that I was already overactive here at The Pouch, the variants could have suffered.

One of them did. As I mentioned, Crystal Ball was basically forgotten. In fact, it wasn't until the most recent issue of The Pouch, when Joe Carl submitted an article on Crystal Ball that any space in the Zine was devoted to it. However, I did force myself to make time to start creating something to aid in the adjudication of Payola variant games. This started as a standalone program, completely unattached to anything (let alone to the World Wide Web) to which I, the GM, would feed each player's "bribes" and which would spit out to me the orders to be issued to each of the players' units.

Initial Interaction With The Ken Lowe Judge

The rest, as they say, is history. But since I'm writing the history of the DPjudge, I can't use that cop-out, so -- before you can get to all the cool stuff that makes the DPjudge unique -- you have to put up with me telling you about how the snowball grew as it rolled downhill.

The most important early development in the Payola bribe adjudicator was the ability to feed the output of this standalone program directly to a Ken Lowe judge. By allowing a Ken Lowe judge to do all the grunt work (actually deciding on bounces, dislodges, and -- most of all -- press forwarding and deadlines!), I was freed to concentrate on fine-tuning and expanding the bribe processing code.

In fact, the pre-existence of the Ken Lowe judge was by far the most important single factor in the eventual growth of the DPjudge. Were it not for being able to run games on a Ken Lowe judge, the player base would never have expanded for my variants, and they may have ended up on the heap. Also, the Ken Lowe judge provided a model for the eventual functionality (especially the e-mail input and output) of the DPjudge. As you'll read later on, the results and other e-mailed output of the DPjudge have been constructed to mimic the Ken Lowe judge in nearly every respect. This enables the DPjudge to take advantage of all the hobby projects that have grown up over the years which accept and expect Ken Lowe judge-formatted text as their input.

But I'm getting ahead of myself. At the point I went off on this tangent, remember that the DPjudge was still nothing but a standalone computer program that I, the GM, would execute whenever I had mail from a player. I would then manually forward the output to the Ken Lowe judge (which would either HOLD a player's units when his "bribe" offers were received, so as not to mark him late if another player didn't make the deadline, or actually issue the orders for adjudication if all of the players' "bribes" were submitted).

The Webification

Slowly, the outlines of today's DPjudge started to take shape. Players in the active Payola games were given a Webpage that interfaced to the standalone bribe processing program. It was a rough fit, but a fit nonetheless. The Website grew a Payola player ratings system, started affording the capability to study the completed games, and so on. The messages sent to the player by the bribe processor improved in content and appearance. At this point, I had a set of Web pages that accepted bribe offers, and which then used a completely separate program to validate the bribe offers and/or mail a Ken Lowe judge the appropriate output. Three truly separate pieces of software, passing information from the player to the first (the Web pages), then to the second (the bribe processor), then to the third (the Ken Lowe judge), and finally back to the player. Clunky, but it worked.

Years passed. Literally. The Website and the Payola bribe processor code both matured constantly (but separately), but the thought of integrating the latter into the former was too daunting to think about. Mostly because I was too busy.

Eventually, both the Payola Web pages and the Payola bribe processor grew very stable. So it seemed the perfect time to put all that success in danger.

And the way to do it was to resurrect Crystal Ball. I contacted the players of the long-abandoned first game of CBD, and invited them to finish it by submitting their orders on Webpages for automatic adjudication (so that no inconsiderate human GM could possibly abandon them again on some flimsy excuse). Having taken a copy of the Payola adjudicator and quickly converted it to an equally clunky Crystal Ball adjudicator, I was happy that the players (with some replacements) climbed back into the game. And I was even happier that they put up with the growing pains as Crystal Ball went to the Web.


Once Crystal Ball and Payola each had their own separate Websites, both up and running well, my work on the sites was limited to providing enhancements that were requested from the players. It was then that my attention turned to generalizing from the specific solutions for these two variants.

The first thing to be done was to pull the separate pre-processing programs into the Website code. Once that was done, the Website communicated directly with the "hosting" Ken Lowe judge for each game. I was able to finally throw away the code that started it all -- the standalone GM helper "bribe processor" program.

The next thing to do was to add retreat and adjustment phase support to the Webpages. Until this time, all retreats and adjustments needed to be sent directly by the player to the Ken Lowe judge. New pulldown menus were added to give players the option to have the Website forward the retreat and adjustment orders for them.

During this de-clunking effort, the Payola and Crystal Ball Websites started sharing code and it became possible for other variants to be implemented by similarly modifying the base code. The decision was made that the next such "variant" to be supported would be the non-variant. Standard Diplomacy.

Meet The Press

in the "DPjudge Questions" page at the Website. Oh, one more thing I should mention. The results will come to you the same way this message did -- under the subject "Diplomacy press (philby)". I could change it to set the subject to "Diplomacy results philby F1923B" but it's not worth my trouble to do so. Also, you should know that your account statements for any movement phase that is processed this way will NOT come to you via e-mail. You'll have to just head for the Website to see them. Anyway, there you have it. Complaints, criticisms, etc., are being entertained. But unless I hear a good reason not to continue, the game is about to go on. FROG (and sadly, any observers we had, whose e-mail addresses I had not recorded into the game data on my end) can catch up with us later. Manus --> The Website was still a front-end that relied on the Ken Lowe judge for a number of things. The easiest of these to add to the Website was the ability for players to compose and send press messages. The press messages that players could compose at the Website were still simply forwarded to the Ken Lowe judge, but events were soon to take a hand.

At this time, the Ken Lowe judge known as FROG went down. And it never came back. Since FROG had proven to be the most resilient judge in my experience, I had used it to host nearly every one of the games I ran. The fact was that virtually all of the Payola and Crystal Ball games came to a sudden stop when FROG went off-line.

So I quickly taught the Websites to forward press to actual player e-mail addresses, rather than to the judge, so that the players could continue communication. And I resigned myself to either manually adjudicating the results (by simply telling the Websites that I myself was its "Ken Lowe judge," and manually processing any e-mail it sent me), or moving the games to another judge.

The players appreciated the ability to use the Website to compose press, but the fact was that it was an imperfect solution. Players could not really respond to e-mail they received without cutting and pasting the received text into the Web page. A far cry from the convenience of just hitting "reply" in their favorite e-mail client.

Accordingly, I added an e-mail interface, so that players can send and receive messages via an e-mail address that is managed by the Website code. The Ken Lowe SIGNON, PRESS, and BROADCAST commands were suddenly understood in any e-mail sent to the DPjudge address. The die was now cast. This was when the Websites truly became the DPjudge.

The Big, Important (Scary) Stuff

Ever since I entered the online Diplomacy hobby (actually, since well before then), I had wanted to write a computerized move adjudicator such as the Ken Lowe judge. I can't tell you how many times I started and gave up, frustrated either by seemingly irresolvable problems or by the obscure nature of the Ken Lowe judge's code (when I decided to seek help with such a problem).

When FROG went down for the count and I was forced to face Hand-adjudication of all the games I was running, I finally bit the bullet hard enough to get through the operation.

The surprising thing to me was that I didn't really have to bite that hard. I wrote the move adjudication code in two evenings, and it performed nearly flawlessly in its first test. I honestly was flabbergasted. In the course of writing the move processor, I came up with a novel approach to resolving convoy paradoxes. Elsewhere in this issue of the Zine, Simon Szykman and I debate the merits of his own pet paradox-resolution rule and mine. Once a convoy paradox resolution rule was chosen, writing the adjudication code became a breeze. (Okay, that's not quite true, but anyway, it got done.)

As I say, this surprised me no end, because within a matter of two days, the Payola and Crystal Ball Websites went from being front-ends to the Ken Lowe judge to being part of a system that included a full-fledged integrated adjudicator. A system that no longer needed to host its games on a Ken Lowe judge at all. (I made sure, though, that the DPjudge still retains all its Ken Lowe judge integration capabilities, and it is available to provide a Web face for any game hosted by a Ken Lowe judge.)

The adjudication piece was in and active so quickly that I never even Hand-adjudicated a single turn! Necessity is the mother of invention.

Working to a Deadline

The only thing that was missing at this point was deadline setting and enforcement. Games run by the DPjudge ran for a month or so without deadlines, and players played by the honor system.

After all the little bugs in the adjudication code were worked out, though, I added deadlines to the DPjudge. This was actually a major effort, since the DPjudge code had to be prepared for asynchronous, scheduled execution to check and remind players about deadlines.

Additionally, something for which the players had been clamoring since the earliest days of the Website finally became possible: the final player to submit orders actually gained (as with the Ken Lowe judge) the ability to panic and change what he or she had submitted. Until deadline support was added, the final player to submit orders caused an immediate processing of the moves.

Supporting the Normal People Out There

Once deadline support was provided, the DPjudge was nearly ready for prime-time. But it still knew how to run only Payola and Crystal Ball Diplomacy games. Most players (sadly for them) don't (yet) play these variants on a regular basis. So a quick trip through the Crystal Ball code module resulted in a module that knew how to run the standard, non-variant game. Test games proved the new module, and standard Diplomacy came on-line. By now, nearly a whole handful of standard games have been run by the DPjudge.

Incorporating the Mapping

Since the first days of the Website, players had been treated to graphical game-maps made by the mapit program (which takes Ken Lowe judge output and creates a PostScript map), long a staple tool of the PBEM hobbyist.

The DPjudge's adjudication code was programmed to issue output in the Ken Lowe judge's format, so that mapit could continue (as a standalone, separate program) to fulfill all map creation needs even when the games were disconnected from the Lowe judge.

However, as more and more features kept being added to the DPjudge (see below), small divergences from the Ken Lowe output format were the outcome. Either a specialized version of mapit would have to be created, or a replacement for mapit would need to be written and incorporated into the DPjudge.

I chose the latter, and the result was dpmap, which is not only a standalone program (like mapit) but is also an integrated module, part and parcel of the DPjudge package. The DPjudge now relies on absolutely no external hobby tools, so I finally felt like the time had come to announce it. Here we are.

Well, there's a nutshell history (okay, it's a big nut) of the DPjudge. And with that, let's (finally) take a look at some of its new and different features -- what you can find at the DPjudge....

Ten Selected Features of the DPjudge

Bulletproof Order Validation
One thing that had bothered me about the Ken Lowe judges was that some impossible orders (such as convoying an army to Switzerland) are not considered erroneous, but others (such as supporting an army into a water space) are caught and forbidden. This inconsistency had as its result the growth of an arcane set of knowledge -- a "language" used by no-press game players to communicate future intentions and alliance requests through their moves. No-press players have taken what they can and cannot get past the Ken Lowe judge and made it into an interesting subculture, but the fact that the rules of communication they follow are based more on the accident of an incomplete implementation than on any intentional design has always bothered me. I had always dreamed of the "all or nothing" validation that the DPjudge now provides. Either an order is valid or it's not, and there is no inbetween. At the DPjudge, nothing falls through the cracks. Unless a specific "rule" is used on a per-game basis (see below), every order is guaranteed to be a valid order at the time it is submitted by a player.

True No-Press
Making the order validation bulletproof (such that no invalid orders are acceptable) was actually one of the first features of the original Payola bribe processor -- because complete bulletproofing is a necessary feature of the Payola variant. For the longest time, the "all or nothing" wish discussed above sat at half-finished (the "all" was done, but no work had been done on the "nothing"), with every order always being rigorously checked. With every invalid order always caught, this meant that no-press games became truly no-press. Players could no longer issue convoys to Switzerland to hint at their intentions to their allies and enemies. This is both a good and a bad thing. True, no communication, no-press is something that has not been available to the PBEM player, so it's good to be able to have it. The bad part is that no-press PBEM players have grown to expect to be able to use spurious orders to communicate, and with all orders strictly validated at entry-time, this was not possible. So...

Face-to-Face Order Writing
In addition to the inability to write off-kilter orders to signal intentions in a no-press game, the fact that all orders are completely validated also means that there was no possibility of human error in order entry (either accidental or otherwise). Every face-to-face player knows that human error (misordering a unit at a crucial moment, or forgetting to write down a vital order) is often a big part of the game. In fact, I have used the intentional misorder tactic myself at the 1998 World Championships. (Hi, Scott! Yes, I know, "Eastern Med to Smyrna, not to Constantinople!" Woops!) The play-by-email player has never had any such capability. Not until the DPjudge.

Prompted by the wish to follow the conventions of face-to-face play when running certain games for the 1999 E-Mail "Masters' Tournament," the DPjudge was taught the "nothing" half of the "all or nothing" edict. It is now possible for the DPjudge to run standard Diplomacy games that accept pure garbage orders (as long as they are sensible Diplomacy orders, syntactically), and report them as invalid only in the adjudicated results.

Not only does this allow for the dynamics of a face-to-face game, but no-press games can be run at the DPjudge using this rule. Instead of checking every order for validity when it is entered, no checking is done until adjudication time, and the result is that the play-by-email no-press player finally has the ability to use any invalid order (and any number of them) to signal his intentions.

The DPjudge retains (and probably always will retain) the mandate that players must list all fleets to be used in a convoy in the army's convoy order. This feature of the Ken Lowe judge just solves too many programmatic problems to be easily removed. Frankly, my opinion (as expressed elsewhere in this issue) is that convoy path specification is also the logically "proper" way to write an army's convoy order. It avoids the unwanted ("kidnap") convoy and all of the (to my mind) inconsistencies that arise from the possibility of an army being able to follow any one of many possible convoy routes.

Vacation Handling
Perhaps the biggest headache that Ken Lowe judge players face is accidental abandonment. A player who suffers a network outage or who forgets to request a deadline extension for an absence often finds himself declared abandoned. His position is taken over, and then he requests his spot back. My biggest shortcoming as a Ken Lowe judge GM, in fact, is forgetting to extend deadlines when requested. The result is that a player ends up abandoning, is replaced, and then returns from his absence to ask for his position back. All my fault, but caused by the Ken Lowe judge taking action to boot a player from the game after a period of inactivity. The DPjudge doesn't do that. The only way out of a game is to RESIGN or be RESIGNed by the GameMaster. Player abandonment is one place where, in my opinion, the human touch is indispensible.

Deadline management, as implemented by the DPjudge, is much easier, though, and as a GM at the DPjudge, I no longer miss deadline extension requests. This is because the DPjudge supports what could be called post-dated deadline extensions. The most common deadline extension request that a GameMaster receives is of the form, "I will be gone three weeks from now for a week and a half. Please don't let any deadlines fall on those days. Until then, though, I'm still here and playing; let's keep the deadlines moving as they are." Using the Ken Lowe judge, the GameMaster has to remember, three weeks from now, to enter an extension. As I recounted above, I often did not remember to do so. The DPjudge, on the other hand, has the ability to "remember" for me. The GM can tell the game at any time of any future planned absences, and it will be sure to set deadlines around them all.

Note: At some point after this article was published, the Ken Lowe judges started supporting the SET ABSENCE command, duplicating this DPjudge innovation.

All Games Anonymous
When I first entered the hobby, I felt sorry for anyone who played anonymously. What fun was that? Before too long, though, I was sold on the concept. In fact, I am now so sold on it that the DPjudge has been told never to reveal player identities during a game. There is no way to get it to do so. (Player identities are, of course, revealed after the completion of a game.)

I have had too many bad experiences with players deciding to either befriend or attack a power based on his or her record or reputation. Since my name is widely known in the hobby (that's about as humbly as I can put it -- who, me? humble?), I am perhaps more attuned to this than others might be, but the fact is that this point of view is not based only on my own experiences as a "marked man." In fact, the true motivation for this DPjudge philosophy came when I saw two players in one of the games I was running targeted immediately and not really given a chance to participate in the game, simply because they were good or well-known players.

(Non-anonymous games are obviously possible simply by announcing one's own identity, and this is usually acceptable in games for a select invited audience.)

New Draw Mechanisms
The DPjudge provides three different methods in which a game could be ended in a draw. By default, each player has a permanent silent "vote" on record, which he may set either to In this scheme, the game may either end in a solo victory, or by a concession to a single player (if all other players vote to concede and the victorious player votes otherwise) or in a draw that includes all survivors (DIAS).

The second possibility is if a game is set up to allow NoDIAS draws (draws that can be shared by a subset of the surviving powers). Personally, I'm not a fan of NoDIAS, but I bowed to the possibility that sometimes they are expedient. Certainly in face-to-face tournaments, they can save a lot of time if foregone conclusions can be acknowledged. As an aside, though, I argue that conclusions should never be considered foregone, and simply the fact that NoDIAS is a possible conclusion can actually affect the play of each player in a way detrimental to the game. Despite this personal philosophy, NoDIAS is supported at the DPjudge. It works just like the scheme described above except that instead of three voting choices ("a solo for me," "a DIAS draw," "a concession to someone else"), each player can also specify the maximum number of players he will accept (including himself) in any declared draw. If enough other players ever are found to be voting to concede to any other power or coalition, the draw will be declared.

In both these schemes, each player's "vote" is private and never revealed to the other players. The "vote" is perpetually "in effect" and can be changed at any time.

The third scheme of declaring draws is meant to mimic the face-to-face game. Under this scheme, a player actually publically proposes a draw or a concession, and the players secretly vote either "yes" or "no" on the proposal. As soon as the proposal is vetoed, it is taken off the table, but if all players agree to it, it passes and the game ends. Under this scheme, only DIAS draws and single-player concessions are supported. This method is intended to best implement the Calhamer rules on game termination.

Multiple Game Maps
The DPjudge supports a great many game maps, from the standard map (of course) to those for the Modern, Pure, Classical, Hundred, and Sail Ho! variants. Minor variants of the standard map, such as Crowded and Britain and 1898 are also supported, of course.

Adding support for any new map variant to the DPjudge is relatively simple once a graphic map that is attractive enough and that is in proper PostScript template form for display on the Web pages has been created.

Juho Snellman was the first to really answer my call to take the work I had done to prepare a few maps (standard, modern, etc.) for the DPjudge and do the same for others. His maps for Classical and Hundred and Pure and Sail Ho! are works of art, and at the time of this writing he is busy preparing more for the collection.

Easily Customizable for Addition of New Variants
Because of the way the DPjudge matured from a modular and object oriented design, and since it was actually built initially to provide support for a couple of very non-standard variants, the fact is that it is a fairly simple task to add support for other non-standard rule variants. I'm not just saying so myself. Juho Snellman (who I mentioned above) is working on adding support for the "It Came From Outer Space" variant. Here is what he had to say just a few hours after receiving the DPjudge code:
By the way, I really need to compliment you on the dpjudge design. I've already made a small toy-variant by modifying a copy of your standard variant code module and it was truly much easier and (especially) cleaner than I expected based on the adjudicators I've seen earlier.
Some concepts for non-standard play (such as having new and different phases -- in addition to movement, retreat, and adjustment -- and having any number of movement phases per game-year, etc.) are already supported in the base code.

Ken Lowe and Ken Lowe-esque E-Mail Commands
As was mentioned earlier, the DPjudge was modeled in many of its particulars after the Ken Lowe judge. Importantly, the format of the results mailings is in line with the Ken Lowe judge, so as to allow processing by the many hobby tools that have grown up over the years.

Equally important was the wish to make the format of the commands that players send to the DPjudge as consistent as possible with the commands that the players have grown accustomed to using. For this reason, the DPjudge player will find himself using a number of familiar commands, including PRESS, SIGNON and SIGNOFF, LIST, SET PASSWORD and SET ADDRESS.

A couple of the commands were changed, though. For example, the command JOIN (rather than SIGNON) is used to enter a forming game, and similarly TAKEOVER takes the place of Ken Lowe's SIGNON when it comes to replacing an abandoned player position.

There are also a couple of new commands, notably PREVIEW, which allows a Game's Master to "pre-process" a phase. This will send the Master (only) a sneak peek at the results of adjudicating the orders as currently entered, but will not actually advance the game to the next phase. This command was suggested by Dave Partridge, who has served as a very patient and helpful guinea pig through the testing of the face-to-face written order emulation support (that is, the "don't report erroneous orders until adjudication" feature).

Multiple Press and Rule Variants
The DPjudge supports, as options, a great many minor rule and press variants, including the following:

Taking It From Here

Well, I've spent a lot of your time telling you what the DPjudge has. Now it's time to tell you what it doesn't yet have. Here's just a few of the items on the laundry list:

In discussing the "feature creep" that has built the DPjudge, it seems that I have finally found a place to work in a very necessary and overdue nod to Bruce Duewer and to "Tarzan," the two most ardent suggesters of DPjudge enhancements. Both of these players come at the DPjudge as variant creators, and their wishes to have the DPjudge support their new variant concepts truly drive the evolution of the DPjudge. Answering their requests (or heeding their reminders about brilliant feature ideas of my own that I had bounced off them) also guarantees that my focus as the creator of the DPjudge is never far from the modular design that allows all these "weird bits" to fit in nicely and cleanly without introducing spaghetti. As a matter of fact, so much of the impetus for moving this project to its current state from just a standalone Payola bribe adjudicator and the separate Web pages that fed it belongs to Bruce (for pressing me to support his Exchange variant of Payola) and "Tarzan" (for spurring the first true move towards "judgehood" -- the addition of press to the DPjudge). To both Bruce and "Tarzan," thanks, and don't worry; the things you've asked for will get done.

And That, My Friends, Is The DPjudge

Thanks for taking the time to read about the DPjudge. I hope you weren't too bored. I'll end this article with an invitation and an appeal:

Manus Hand
([email protected])

If you wish to e-mail feedback on this article to the author, and clicking on the envelope above does not work for you, feel free to use the "Dear DP..." mail interface.