SFB PBEM Rules
   SFB Rules Errata
   Comm Rules
   Rules To Use
   PBEM Rules FAQ
   FC PBEM Rules
   FC Rules Errata


The person who checks, compiles, collates, and posts the data associated with a Federation Commander PBEM game is known as the moderator. Moderators are simply players who volunteer to run the game for fellow players.

It helps for the prospective moderator to have Federation Commander PBEM experience, though it is not generally necessary. As long as the players know about the lack of experience, and accept the moderator, that is all that is required.

(9FC1) PREREQUISITES: Agreeing to moderate a Federation Commander PBEM game is a commitment to the players of that game to process their turns correctly, in a timely manner, and to remain unbiased toward any of the players.

Generally, you should only agree to moderate a Federation Commander PBEM game if you will have the time to do it right. Helping out your fellow players by volunteering to moderate is a noble endeavor. BUT, if you donít have the time, you will likely cause more harm than good. You are the one who will keep the game running, and check the players documentation for mistakes.

Now, everybodyís human... or... at least fallible beings, so mistakes will be made, but effort should be made to check Energy Allocations and SOPs for errors prior to running the turn. Some will inevitably slip by, but the moderator should try to minimize these, where possible. It should be noted, however, that it is the PLAYERSí responsibility if they make an error and the moderator doesnít catch it in time.

(9FC1a) EXPERIENCE: At the present time, these Federation Commander PBEM rules have no exact qualifications for a moderator. A simple rule of thumb would be that if youíre comfortable with playing Federation Commander PBEM, then you should have no trouble running a game.

It is possible to moderate a game without having played it, but this is not advised. If the moderator has to "learn" the game while moderating, there will be no one to catch their mistakes, which could cause some serious problems during game play. If all else fails, and a moderator with experience cannot be found, then the inexperienced volunteer may be able moderate the game, as long as everyone realizes that this is their first time. (Players should take extra care when submitting Energy Allocations and SOPs in this event.)

(9FC1b) COMMITMENT: When you sign on to moderate a Federation Commander PBEM game, you are telling the players that you will take the time and put forth the effort to moderate their game to the best of your abilities. If you cannot commit to regularly logging on and processing turns, then you should not volunteer to moderate a game.

This is not meant to sound draconian. It is simply a courtesy to the players that you, as a moderator, donít waste their time by delaying the game unnecessarily, causing them to log on time and again in a futile attempt to retrieve their Sitreps. If you can only log on once a week, then make sure that the players knows this, and ASK them if this is acceptable.

You are responsible for the game flow, so you must be willing to spend the necessary time to ensure that the game flows smoothly.

(9FC2) DUTIES / RESPONSIBILITIES: The moderators duties are outlined below. Please take the time to read them thoroughly before volunteering to moderate any Federation Commander PBEM games.
(9FC2a) GAME FLOW: The moderator is responsible for maintaining the "flow" of the game. This not only means processing the turns in a timely manner, but also means that (s)he must occasionally "prod" delinquent players, and (if necessary) assign penalties for tardiness.

Now, no one says you must "rule with an iron hand", but being fair to the players includes the player who gets their turn in on time.

(9FC2a1) DEADLINES: The Time Limits shown in (9FC2b) are the standard limits. They may be altered prior to or during the game, but only with the approval of all players.

It is your duty as the moderator to see that these limits are held to as often as possible. If for some reason they cannot be adhered to, you must let all the players know about the delay, and when they should expect to be able to download the next Sitrep.

It is expected that should the players require extra time, or an extension, they will inform you of this fact in advance. If they fail to inform you of a foreseeable delay, then they will be considered delinquent.

By "foreseeable delay", we mean vacations, upcoming heavy work loads, moving, etc. A computer crash would be a valid excuse for not informing the moderator of a delay, as the player has no available means of doing so.

(9FC2a2) DELINQUENCY: This will most likely be the most uncomfortable aspect of moderating a game. When players are delinquent, it is your responsibility to give them a warning, and (if there is no response) to assess a penalty against the late player. [See (9FC2b1).]

This may not be fun, but most players understand the need, and will accept the penalty without comment.

Once a penalty has been assessed, it should not be revoked lightly. A playerís excuse "after the fact" may sound reasonable, but if it is apparent that the player just "forgot", rather than something unexpected happening, then the penalty should stand.

However, it is up to YOU, the moderator, to decide the issue. You are allowed to revoke your own penalties if the playerís excuse is valid, but you are not required to do so. Should a player complain about your decision, try to work it out with them. If that fails, then direct them to contact the PBEM Coordinator for further resolution.

(9FC2b) TIME LIMITS: In order to make the game fun and enjoyable for all players, certain time limits are imposed. The time limits listed here are suggested time limits. Games can move slower if it is known by all participants that there will be a time delay. Time limits are imposed on both players and the moderator. The suggested time limits are:
  • Energy Allocation: 3 days
  • Initial SOP: 3 days
  • Normal SOPs: 2 days
  • SITREPs: 2 days

This means that, from the time you are informed that such information is due, you have the stated amount of time to send your reply to the moderator. For moderators, there is a two-day delay for getting out a new SOP once you have all the information from all players.

Note that any players that cannot access the Internet (or their E-Mail) MUST inform the moderator of such limitations. If you access your E-Mail from work, and donít log on during weekends, then this information must be shared with your moderator, so that your time limits can be extended if they fall on a weekend.

(9FC2b1) LATE PENALTIES: If a player is late with a post (either Energy Allocation or SOP), the moderator should issue a warning to that player, reminding them of the passed deadline, and requesting a reply within 24 hours. If, after 24 hours have passed, the player still has not posted their form, the moderator must asses a penalty of one hull or cargo box damage (F-Hull, R-Hull, C-Hull or Cargo, whichever the ship has the most of). If there are no Hull or Cargo boxes left, then the moderator should assign a random hit using the Damage Allocation Charts. They must also send a message to the player noting the penalty and requesting a reply within 24 hours.

When assigning the random Damage Allocation Chart hit, treat all late penalties assigned in a row as ONE VOLLEY. If the Player submits SOP's, and is then assessed late penalties in the future for a different occurrence, then that would be a new volley.

This cycle continues until the player responds, or it becomes apparent that the player will not respond.

There may be, unfortunately, people who will try to abuse the system. If a player is consistently late, the moderator may (at his discretion) assign late points without give the 24 hour warning. This should only be done in extreme cases [i.e., the player is late every time (s)he is required to send in something because (s)he is using the 24 hour warning as an extra day].

(9FC2b2) EXTENSIONS: We realize that Federation Commander is (probably) not the most important thing in your life. From time to time, you will need a few days, or even weeks, off. Since a game can last several months in real time, it is not always possible to foresee when you will need an extension. However, extensions for good reason are always granted. Simply ask your moderator for an extension. If it is reasonable, it will be granted. If it is for an extended period of time (several months) the Moderator may decide to end the game at its current point.
(9FC2b3) MODERATOR DELAYS: While it is not common, it does occasionally occur that the moderator is the person who is being delinquent in their posts. If this is the case, the players should first prod their moderator with an E-mail. If you do not get a response from your moderator in 48 hours, send E-mail to the PBEM Coordinator. (S)he will check into the situation and determine what needs to be done. Possible solutions are to call the game or to assign a new moderator to finish the game. (This is one reason that good record-keeping by the players AND the moderator is so important.)

(9FC3) RUNNING THE GAME: The following guidelines are provided for moderators running games.
(9FC3a) SITREPS: The main difference between a Sitrep and an SOP is the nature of the information. In an SOP, the player tells you EVERYTHING they want to do. When you convert this information over to a Sitrep, you must be sure to exclude (or alter) the information to which the other Player would not normally have access.

Prior to putting the Sitrep together, check over the SOPs and Energy Allocations to make sure that a player didnít inadvertently make a mistake. Errors caught after the fact are MUCH more difficult to deal with.

Once the Sitrep is put together, check it over one more time to make sure the YOU didnít make any mistakes.

If the Sitrep gets run, and a mistake is discovered later, it is difficult to simply "back up" the game to where the mistake was made, as vital information has already been given to the opponent about what a playerís intended actions will be.

Note, however, that if a player makes an error on their SOP or Energy Allocation that the moderator doesnít catch, then it is the PLAYERíS responsibility for that error, and that player must live with any consequences. (Just as if they had made the mistake while playing face-to-face, without the benefit of a moderator.) Still, the moderator should take care to provide as much error checking as possible.

As to the format of a Sitrep, see (7FC).

(9FC3b) PLAYER ERRORS: As a moderator, it is your job to see that as few mistakes as possible make it through you and into the Sitrep. HOWEVER, you are NOT supposed to point out errors to the players until those errors actually occur in the Sitrep. You are not to point out that something that someone wants to do a few impulses from now is not legal until that activity is actually supposed to occur.

For example; Player A submits an SOP that says (s)he wants to fire a phaser at a drone on Impulse #1 and that same SOP has that phaser used for defensive fire on Impulse #4. As an impartial Moderator, you ARE NOT to point out to that player that (s)he needs to fire a different phaser during defensive fire and let them resubmit a new SOP launching the fighter earlier.

You would fire the phaser on Impulse #1, just as (s)he requested, but when Impulse #4 rolled around, you would notify them (privately) that the phaser didnít fire because it had already fired that turn.

At that point, you have corrected the mistake in the SOP (by NOT firing the phaser when it was not eligible), but you have not assisted them by pointing out the misinterpretation of the rules until (s)he would normally have found it out (by the opponent yelling; "HEY! YOU CAN'T DO THAT!").

Obviously, Energy Allocation is a different matter, and Federation Commander PBEM players have the advantage of a Moderator to inform them of incorrect Energy Allocation. While Energy Allocation in Face-to-Face games would only be checked after the game was over, the moderator cannot allow an improper Energy Allocation to be accepted at all, because if (s)he did, the game would be pointless. (The moderator would know who won because one of the players had an illegal Energy Allocation on Turn #1.) If you have ANY questions about this aspect of moderating, contact the PBEM Coordinator.

Also, remember that player errors are the PLAYER'S responsibility. Do everything you can to catch them and prevent them. But if any slip by, it is the PLAYER who made the error, and who must accept the responsibility for it, NOT the moderator who missed the error. (Now MODERATOR errors are another matter.)

(9FC3c) DISCHARGED WEAPON STATUS: When a ship discharges weapons (whether aiming them at someone or not), the load status of that weapon MUST be announced. If a weapon missed it's target, or was discharged into space, the opponent must still be informed as to whether the weapon was standard or overloaded (and the level of overloading, where applicable.)
(9FC3d) SEEKING WEAPON MOVEMENT: Seeking Weapon Default Movement: If a player does not specify a movement plot (either specific, or general), then the moderator should move the Seeking Weapon using a leading plot. Turns or sideslips are entirely at the discretion of the moderator in this case. A leading plot is suggested, (though not mandatory), so the moderator has no dilemmas about moving seeking weapons with the foreknowledge of the opponent's movement plans.

Note that these are GUIDELINES ONLY. If a player does not specify any SW movement orders, and the moderator does not move the SW according to these voluntary guidelines, then the player has NO recourse. (Players should specify SW movement if they wish to control their own SW's.)

(9FC4) SMALL UNIT DESIGNATIONS (SUDS): Small Unit Designations is the term used for any seeking weapon or shuttle actually on the board. The moderator will assign a SUD to a seeking weapon or shuttle upon launch, using the guidelines below. (Note that all stationary objects are excluded from this rule, as they do not move, and can be referenced by their locations.)

SUDs will be assigned using the following format:

RACE TYPE / ID: Each component will use one letter/number, with no spaces between, and a slash just before the ID.
  • RACE: A one letter race designator will be used to minimize clutter on the Sitrep. Simply use the first letter of that raceís name. (For Kzintis, use the letter Z) In the case of the same race battling each other, use a RACE letter/number designator. i.e., R1 would be Romulan ship 1. (Note that the Race designator can be omitted for those battles in which only one side could possibly have that type of unit.)
  • TYPE: A one letter type designator should go here. Once again, use the first letter of the object for a type designation (i.e., S=Shuttle, D=Drone). Weapons not listed here that require different letters will simply use a suitable designating letter.
  • ID: An ID number (for Drones and Shuttles) will be the last part of the SUD.

For Drones and Shuttles, simply use sequential numbers to ID them. (i.e., the 1st launched would be #1, the 2nd; #2, etc.)

Here are some examples:

  • 1st 4 Kzinti Drones: ZD/1-4
  • 5th Klingon Drone: KD/5
  • 3rd Federation Shuttle: FS/3
  • 2nd Federation Shuttle from 2nd Federation ship: F2S/2

(9FC5) RECORD KEEPING: You must keep a copy of the Energy Allocations of all players for the entire game. This is so that any questions that arise, either during or after the game, can be referenced with the Energy Allocations.

You must also keep a copy of your Sitreps the entire game, for the same reason that youíre keeping Energy Allocations.

The playersí SOPs should be kept until they are resolved. Being "resolved" means that the period covered by the SOPs has been run and posted, and the players have submitted new SOPs, without any complaints about the interpretations of their old SOPs. Of course, you could keep them longer, if you wished, but it is not required.

(9FC6) REPORTING: Upon game completion, results of games must be reported to the PBEM Coordinator (or designee). It should include at least a final Sitrep and an analysis of the Level of Victory scored by each player.

Previous (8FC) Index Next (10FC)

Copyright © 2006 Amarillo Design Bureau, All Rights Reserved Updated 15 November 2006