If the line begins with SKIP, this indicates that no orders are to be solicited for the listed phase. This is rarely used, but one use for it is in Crystal Ball games that begin with an empty board -- this allows players to enter moves (during the previous, "SKIPped" movement phase) and then after locking those moves in, build their units in an adjustment phase.

If the first word is WAIT, this means that the game is waiting for the Master to process the turn. This can happen when the game phase is not recognized by the variant (e.g. an INCOME phase in a Standard game or a phase intentionally inserted into the map FLOW to give the Master the opportunity to implement a rule not supported by the DPjudge). Similar to the WAIT flag for players, the phase will eventually be advanced when the deadline passes if the Master omits to process it himself. Note that the normal way for a Master to prevent the turn from processing is to temporarily change the status from "active" to "waiting", in which case the deadline is simply ignored.

Important: The DPjudge will automatically change the PHASE from FORMING to (for example) SPRING 1901 MOVEMENT when the final needed player JOINs (unless the START_MASTER rule is in effect), and will also change the PHASE to COMPLETED when the game completes. In both these cases, the update to the PHASE line is not the only thing that must be done to change the game's status either to or from "active." Therefore, the PHASE should only be manually modified by the GameMaster when setting up a specific position in a game already in progress. In all other cases, allow the DPjudge to modify the PHASE automatically, or use the "Current Game State" pulldown on the Master's Web page.

The DPjudge will automatically set the initial deadline of the game when the game begins. The initial deadline will be twice as long as a normal deadline for its type of phase (see TIMING, below).

The DPjudge will never automatically set a deadline that is earlier than any current value of DEADLINE (though of course the GM may manually move the current deadline earlier).

Note that the deadline should be expressed in the game's local time ZONE (see below).

AT hh:mm[,hh:mm...]

Specifies the times-of-day at which all deadlines should occur. The hour is specified using a 24-hour clock, and based on the game's timezone. Deadlines need to respect the DPjudge turn processing schedule and thus can only occur at 0, 20 or 40 minutes past the hour, unless it's a REAL_TIME game or the delay (see NEXT) is less than 20 minutes. If you specify a time-of-day that falls in between, the deadline will be adjusted upwards to the next valid time slot. Note that when a deadline is to be set less than 12 hours in the future (or less than half the gap between the previous and next time-of-day if more than one gets specified), AT is ignored. Otherwise, all deadlines will fall at the next occuring specified time-of-day after or around (see FUDGE ) the requisite delay period has passed.

FUDGE delay

Specifies the amount of fudge time, pushing the deadline to an earlier time-of-day in case the previous deadline was only shortly exceeded. The delay must be some positive whole number followed by either M (for minutes), or H (for hours). The default is one third the gap between the previous and next time-of-day (given in the AT data of the TIMING), while the maximum is half that same gap (respectively, 8 and 12 hours in case only one time-of-day is specified). The minimum is 1 minute in REAL_TIME games and 20 minutes otherwise. This setting gets ignored if there's no AT timing parameter.

DAYS dayList

Specifies the days of the week on which the deadline could fall. The dayList must be seven characters in length, with the first character representing Sunday and each subsequent letter representing Monday, Tuesday, etc. The letter at each position must either be the first letter of the day name (that is, S for Sunday, etc.), which indicates that the deadline may fall on that day of the week, or a dash (-), which indicates that it may not. If not provided, the game will use -MTWTF- as its DAYS control. If the day-letter is in UPPER-CASE, this indicates that deadlines for any phase may be set on that day. If it is in lower-case, this indicates that movement phase deadlines may not be set on that day. (Therefore, at least one of the days must be specified in upper-case.)

START delay

Specifies an offset relative to 00:00, midnight to determine when skipped days start and end. The delay can be negative. E.g. if this parameter is set to 8H and DAYS is left as the default, no deadlines will be set between Saturday 08:00 and Monday 07:59. If it's -2H the blackout period is from Friday 22:00 to Sunday 21:59. Absences expressed in full days are affected in the same way.

NEXT delay

Specifies the default time period to be used to set the next deadline. The delay must be some positive whole number followed by either M (for minutes), H (for hours), D (for days), or W (for weeks). There's a catch though. In combination with the AT control, delays specified in days or weeks have an 8 hour fudge period. Late orders entered in this period will not cause the deadline to be pushed back for the full delay period and then some, but will be set to the AT time-of-day of the previous day as if the orders had been entered on time (or on the most recent AT time-of-day if the player is a couple of days late). This means that e.g. a 1D delay actually acts the same add a 16H delay. You must specify the delay in hours (or minutes) instead (e.g. 24H) if you want to guarantee at least a full day until the next deadline. See below for the default value if no NEXT control is given.

phaseType delay

Specifies a time period to be used (instead of the value from NEXT) for any phase whose final word begins with the letters making up phaseType. For example, to set a game to have one-day deadlines for all phases except movement phases, which should have three-day deadlines (note that these are the default settings for any game not given a NEXT or appropriate phaseType control), use:
         TIMING NEXT 1D MOVE 2D

WARN delay[,delay...]

Specifies a time span before the deadline at which time any players who have not yet submitted orders will be sent a "friendly reminder." If this option is not specified, warning is given four hours before the deadline. To prevent warnings from being given, specify a delay of 0 (or any value greater than the length of the deadline delay). Multiple warnings may be specified, by separating the time controls from each other using a comma with no whitespace. For example, to specify that warnings should be given to players without submitted orders one day before the deadline and then again at twelve hours and at six hours before the deadline, use:
         TIMING WARN 1D,12H,6H

GRACE delay

Specifies a time span after the deadline. Whenever that time span expires before the game-phase processes, any player who still has not submitted orders will either be automatically resigned or (in games using the CIVIL_DISORDER rule) declared to be in civil disorder. In games without a GRACE period set in the TIMING line:

• players are never automatically resigned (note that immediate resignation of late players when the deadline hits can be specified by setting the grace period to zero, such as GRACE 0H), and
• civil disorder processing (in games using the CIVIL_DISORDER rule) occurs at the deadline (no waiting).

NOT vacationInfo

Specifies one or more upcoming vacations, during which time no deadline should be set. The format of vacationInfo is the same as the format of the game's DEADLINE (that is, yyyymmddhhmm but can be shortened in length to omit days, hours, or minutes). A vacation spanning more than a single day can be specified by listing the first and last day of the suspension separated by a dash (-). The first day may be omitted, indicating a suspension from the current date. Multiple vacations can be listed by separating them from each other with a comma (and no whitespace). For example:
     TIMING NOT 20040831,20040920-20040927
specifies that no deadline should occur on 31 August 2004 or between 20 September and 27 September (inclusive) of 2004. Vacations are removed automatically whenever a deadline is set beyond the end of the vacation.
     TIMING NOT -20020812
specifies that the next deadline should not occur until on or after 12 August 2002.

Important: A Master should never manually add RESIGNED to any PLAYER line! The addition and removal of RESIGNED must always be left to the DPjudge to do when e-mailed RESIGN and TAKEOVER commands are received!

• DUMMY is used if the power will or may receive orders without a specific person playing the power (for example, the Master could enter orders for the power, or other players could be responsible for entering the orders, etc.), or no orders will be entered for it at all (civil disorder). A Master may create DUMMY powers before game-start (that is, by adding
  POWER POWER#1
  PLAYER DUMMY
  (etc., etc.) to the status file to cause a certain number of powers to be unassigned to human players. If the CD_DUMMIES rule is in effect, DUMMY powers without orders will be considered to be in civil disorder as soon as all other powers either have submitted orders (and not set their WAIT flag) or have been declared in civil disorder (by the operation of the CIVIL_DISORDER rule).

  RESIGNED is used when a position is in need of replacement, and a NEED line should appear in the status file describing the missing position. If the CIVIL_DISORDER rule is in effect, any power without submitted orders (including DUMMY powers, but not including those marked RESIGNED), will be considered to be in civil disorder when a deadline occurs, and the phase will process without orders from the power.

     POWER GERMANY
     CONTROL TURKEY AUSTRIA ENGLAND FRANCE RUSSIA
     END MORPH
You could also let a single player control the same power the whole game, thereby effectively allowing him to play two powers. If everyone is given a second power (on maps with an even number of powers), the game would only need half the normal number of players. In such a case it makes sense to add the TEAM_VICTORY rule, so that the combined SC total of the powers a player controls determines his victory score.