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.
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").
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:
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:
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.
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.
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).
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.
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.
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.
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.
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.
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....
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.
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.
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.)
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.
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.
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.
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).
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.
|
Manus Hand (manus@manushand.com) |
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.