Can I set a bookmark (fans of Bill Gates: a "favorite") that will get me straight to my game?

Yes. Paste the following lines together into a single line, with no included whitespace, and there you have it:
    http://ukdp.diplomatic-pouch.com?
    game=gameName&
    power=powerName&
    password=yourPassword

Note that if your powerName contains a number-sign (#, as in POWER#2, which is what you might be before a game begins), or, similarly, if your password contains that character, the rules of the Internet require that you change the # character to %23 and if you don't, the URL won't work at all.

Where can I get a PostScript viewer so that I can see the PostScript "Season By Season" Maps?

At the Ghostscript, Ghostview, and GSview site. You need ghostscript (which is called gs if you need it for a Personal Computer) and ghostview (gsview32 for the PC). Downloading and installing ghostview (gsview32) should drag ghostscript along with it and set you all up. It should even tell your Web browser to use gsview to view PostScript files (if it doesn't, you can teach your Web browser to do so yourself). Note that you will want to set the "Orientation" in ghostview to "Auto."

Since the DPjudge supports a number of Diplomacy variants, and since orders in some of these variants (Payola Diplomacy, for example) can look a little different from those of a standard ("plain vanilla") Diplomacy game, I'm afraid there is no single answer for this question.

But if I answer the question strictly in regards to standard Diplomacy, then really, if you already know how to write a Diplomacy order that would be understood at a table-top game, you cannot go too far wrong. Just enter the order the way you know how. I know that's scary for someone completely new to the DPjudge, but what's even more reassuring is the fact that if you do enter an order the DPjudge does not understand, it will let you know about it and you will be able (and obliged!) to correct your error.

The only thing that might throw you (as a table-top player new to the world of electronic Diplomacy play) is the way in which a convoying army's order is written: it must contain, in order, each and every one of the bodies of water through which the army will travel. You can see some examples and read more about this.

In case you are still concerned, though, that you will not format your orders correctly when you enter them, and you want to make sure to get them right the first time, you can read the hard-and-fast rules for order formatting. As you'll see, they're not really all that hard or fast.

I can probably figure out how to interface with the DPjudge over the Web. But will I need (or want) to use the DPjudge's e-mail interface as well? And if so, how do I do so?

You definitely do need to send e-mail to the DPjudge at least once, since the e-mail interface provides the only way a person can actually join a game. After that, there are reasons when you may need or want to use the e-mail interface instead of the Web. The most common of these reasons is to send press. While press can indeed be composed and sent from the Web interface, it is often more convenient to write messages using your own favorite e-mail application. This gives you the ability to include the text of any message to which you are replying, etc. So the answer to your first question is that yes, you will probably want to become familiar with the e-mail interface. The answer to your second question is that everything you need to know about how to do so is in the E-Mail Interface Question and Answer List.

The abbreviations NMR and NVR are standard lingo in the Diplomacy hobby. They stand for "No Move Received" and "No Vote Received." Here at the DPjudge, though, you can always read them as "No Move Received Yet" and "No Vote Received Yet." In other words, the abbreviations are used by the DPjudge to indicate that you have not yet provided a retreat or adjustment phase order (for example) or a vote on a draw or concession proposal. Only if the game is set up to cause powers to be put into civil disorder (CD) will it proceed without any moves that are marked (NMR).

How about DIAS? What does that stand for?

DIAS is another standard Diplomacy hobby term. It stands for a Draw Including All Survivors. By default, all games run by the DPjudge adhere to the rule limiting the ways in which a game can end to:

1. a solo victory by (or concession to) a single player or
2. a draw agreed to and shared by all players who own supply centers (a so-called "DIAS").

If a particular RULE is used, games may also be run as "No DIAS," meaning that draws can be declared among a subset of the uneliminated powers (if all survivors agree). The implementation of "No DIAS" here at the DPjudge cleverly (if I do say so myself) avoids many of the negatives of the "No DIAS" implementation on the Ken Lowe judge. However, as a purist, I personally still frown on the "No DIAS" setting.

Every player who has orders due on the current turn may direct that the turn not be processed until the deadline has been reached (perhaps to ensure ample negotiation time despite orders having been entered). A player may change this setting at any time, and (unless a specific optional RULE is used) the setting of each player is never announced to any other player. This "wait flag" factors only into the examination that is described in answer to the next question.

So apparently the DPjudge does not process a move only when the game's deadline has been reached. So when exactly will a game's moves be processed? How does the DPjudge handle players who have not entered their orders by the time the deadline occurs?

What happens is this:

• Every active game is checked for readiness every twenty minutes. A game is ready if:
  1. All "active" players (see below) have issued orders and
  2. Either the deadline is past or no player has set his "wait" flag and
  3. The game's DELAY number is zero. (The two ways in which a game's DELAY number becomes non-zero are described later in this answer and in the answer to the next question.)
• If the game is ready, it is "locked" so that no one can change anything, and it is then processed. Processing at the DPjudge takes only a few seconds, so it is likely that you may never even encounter a "The game is waiting for processing of..." message on the Web screen (you'd have to catch it right in the middle of its work).
• If the game is not ready, then:
  • If the game's DELAY number is non-zero, it is decreased by one, and no further action is taken.
  • Otherwise (if the DELAY number is zero), then
    1. If the deadline has passed, the DPjudge sends out a "late notice" to all players, and sets the game's DELAY value to 24 (meaning, don't yell about late players until another eight hours have passed).
    2. Otherwise, if the deadline has not passed, it does nothing at all.

I think I understand. As long as no one has asked for the game to wait for the deadline, the game will process early if it orders have been submitted by all of its "active" players. But what exactly constitutes an "active" player?

There are three answers here:

• In a movement phase, a player is considered to be active only if the player owns at least one supply center. This means that the game will not wait for orders from players who own one or more units, but who do not not own any supply centers (as a result of the action of the GARRISON rule, for example).
• In an adjustment phase, an active player is one who is eligible to build, or who is required to remove at least one but not all of that player's units.
• And finally, the most complicated case of all. In a retreat phase, a player is active if the player has at least one unit in retreat, and if the player will not be eliminated regardless of every possible retreat, and if every possible retreat cannot possibly bounce against a unit being retreated by a player who will not be eliminated if the potentially bouncing unit is disbanded.

If I am the last player to put in my orders for the current turn, do I have an opportunity to change them before the turn processes?

Yes, you do. As you read above, the DPjudge processes games only at specific times (every twenty minutes). Therefore, there is at least some delay after having entered orders. To ensure that there is adequate delay, when the very last player to put in orders does so, the game's DELAY count is set to 1. (Unless the deadline has already passed, in which case it is set to 0, as discussed below.)

Setting the DELAY count to 1 has the effect that the game will not be processed on the very next scheduled check. This means that when the last player puts his offers in, he has somewhere between twenty and forty minutes to panic and change them (and, by changing them, obtain another 20 to 40 minutes, assuming the deadline has not arrived) before the game will be processed.

What, if anything, changes when a deadline is reached?

A few things.

First, if the last player to submit orders does so after the deadline (that is, while late), the DELAY count (described above) is not set to 1 but is instead set to 0. This means that this player has only twenty minutes or less before the phase will be processed.

Second, it is impossible to submit an empty list of orders after a deadline (doing so would have the effect of making or leaving a power late).

Third, unless a specific RULE is in use, it is impossible for a late power to send press (other than broadcast messages and messages sent only to the Master). Additionally, if a (different) specific RULE is in use, it is impossible for any player to send press to a player who is late.

A would-be GameMaster can create a new game through either the DPjudge's e-mail interface or the web interface. Details on the CREATE command that would be e-mailed can be found in the e-mail interface questions and answers list. To start a game using the web interface, you must be registered with the DPPD. Then, when you log in, you can create a game by using the left side of the screen. Simply enter the game name and the password. If you would like to use the PAYOLA or XTALBALL variants, choose those from the Variant selection box. Click Start New Game to create the game in the USDP.

How does a GameMaster configure a game to use certain variants?

The Master for a game has access to the "status" file for the game, and can update it at any time according to the required status file syntax. In this way, the Master can add or remove RULE commands at will, consulting the complete list of supported rules.

What Diplomacy variants are supported by the DPjudge?

The complete list of supported variants can be found at the main page for the DPjudge.

Can I teach the DPjudge a new map variant?

Yes. To completely support a map variant, two files are needed. The first is the necessary dpmap PostScript file with a .ps extensions (dpmap is the mapit-based PostScript map generation program used by the DPjudge -- you can create mapit maps using David Norman's MapMaker program). The preferred (required) maps are those that have been given the "Manusization" treatment to allow for colored supply centers. More information can be found at the Manusized Mapit Webpage. The second file should have a .map extension and is the DPjudge map description file. This file is written using DPjudge map file syntax. When you have both of these files, simply e-mail them to the DPjudge keeper and he can install them. Your map variant will then be supported. The hardest part is creating a decent-looking .ps file. Manus's advice is to find someone who's done it before and convince them to make your .ps file, or else serve an apprenticeship under them first, because Manus is notorious for saying, "nope, sorry; that map doesn't look good enough." They need to be beautiful to make the cut.

I'm happy you asked, because frankly, I'm rather proud of it. I began from a skeleton of the method given in the Diplomacy Players Technical Guide (on which I collaborated), but soon took an independent path. If you're interested in reading it, the complete adjudication algorithm is available.

I don't want to read the whole algorithm, so can you just tell me how the DPjudge handles Pandin's Paradox and the other convoying paradoxes?

The problem of convoyed attacks cutting supports has caused a lot of people a lot of head-scratching over the years. The 1976 rule, quoted below, is simple. A convoyed army cannot protect the fleets that convoy it.

If a convoyed army attacks a fleet which is supporting a fleet which is attacking one of the convoy fleets, that support is not cut.

This just always seemed logical to me. A convoying army "comes from" its original location and also "from" each fleet location along the way, so it seemed natural that the army should not be able to cut support directed against any of those spots.

However, paradoxes arise from this simple rule, and to remedy them, the 1982 rules added more fleet supports to the set of those that a convoyed army cannot cut. Specifically, a convoyed army cannot cut a support for any action in or into a space containing any convoying fleet.

Although the 1982 rule introduces new problems -- the results that are yielded in one particular rare situation may be said to run counter to common-sense -- this rule does seem to be the best choice to resolve all cases.

The problem with the 1976 rule lay in the exception that is made in the rules to actually allow the convoying fleet to cut the support despite the rule (quoted above) that says it cannot. This exception, of course, is that the support will be cut if the attack dislodges the fleet.

As it turns out, to ensure sensible results, all I had to do to the rule was amend it as follows:

If a convoyed army attacks a fleet that is supporting any action in or into a location containing any convoying fleet, that support is not cut by the convoyed army under any circumstance.

In other words:

even if a fleet is dislodged by a convoyed attack, if the fleet is supporting a convoying fleet or an attack against a convoying fleet, the convoying army does not cut the fleet's support

This reduces the number of possible inconsistencies in the results to a single case, which is that a fleet can be dislodged (by a convoying army) while delivering a valid, uncut support (for an attack on or defense of a convoying fleet). Despite being dislodged, it can deliver a valid support.

By leaving that support valid throughout adjudication -- never ever cutting it -- what this does is ensure that the convoying fleets truly do withstand all attempted assaults while delivering the army to its destination.

I don't find it too difficult to come up with a real-world justification for this amendment. A successful beach landing will only come at the cost of some ships being battered more than they would be in an open-sea battle. Even if the fleet guarding the beach against the invasion is forced into retreat, it has probably greatly aided any naval support it had, doing a lot of damage to the hulking, slow-moving ships that had to approach land so closely. In effect, such a supporting fleet makes the task of establishing a beach-head tougher.

The DPjudge also offers another adjudication option (a game parameter that the game's Master can set), which is simply that a fleet that is a beleaguered garrison may not convoy.