FEDERATION COMMANDER PLAY-BY-EMAIL RULES (1FC) INTRODUCTION This document contains rules for playing Federation Commander via E-Mail. These are the official rules used by the Federation Commander Play-by-E-Mail (FCPBEM) System. Playing Federation Commander by E-mail is in many ways very different from a face-to-face game, though the Federation Commander rulebook is followed in almost every case. The FCPBEM rules attempt, as much as possible, to allow players to maintain direct control of their ships. However, it is not an exact duplicate of a face-to-face game. The basic gist of the Federation Commander PBEM system is that you and your opponent submit your orders for the turn to a moderator via E-Mail. The moderator then processes them, and sends a "Sitrep" (Situation Report) to the players via E-Mail. You receive the results, write up your next set of orders, and then submit your orders once again. The process is repeated until the game is completed. Sounds simple? That's because it IS! It'll take a little getting used to (after all, what doesn't?), but once you’ve got the hang of it, you'll be lobbing photon torpedoes (or whatever your weapon of choice is) at opponents from all over the world. Every Federation Commander PBEM game has at least three participants: two or more players and one moderator. The moderator’s purpose is to accept orders from the players and carry them out, reporting the results of those orders to all players. While (s)he is not a player, the moderator fulfills a very important role in the game. Good moderators and good players make for a good, enjoyable game of Federation Commander. Moderating a Federation Commander PBEM game is also an excellent way to learn more about the Federation Commander rules. NOTE: You will not be able to play Federation Commander PBEM unless you actually own the Federation Commander rules. If you do not have the rules for Federation Commander, you will need to purchase the rules from your local hobby or gaming store, or from ADB, Inc. (1FC1) TERMS: Below is a list of terms used in these Federation Commander PBEM rules, along with their definitions: * PBEM (Play-by-E-Mail): The term for using E-Mail (or other electronic means) to send orders and turn results back and forth. * MODERATOR: The person who "runs" the Federation Commander PBEM game for the players. * SOP (Standard Operating Procedure): The written orders that a player submits to the moderator via E-Mail. * SITREP (Situation Report): The written results of each turn that the moderator sends to the players, showing what happened during that period of play. (2FC) PBEM STANDARD RULES This is a listing of the different rules which are normally used (or not used) when playing Federation Commander PBEM. These are not all-inclusive, as you and your opponent can decide to use more (or less) of the rules than those listed here. These rules are simply the standard ones used if no others are specified. (2FC1) STANDARD (NON-TOURNAMENT) GAMES: Unless agreed upon prior to game start, the following rules will be used. These are considered "PBEM STANDARD" and will be the assumed rules during the game. * ALL rules from the Federation Commander rulebook. o EXCEPTION: (1E4) Simultaneous Decision Rule. Considering the time required to send messages back and forth this rule will not be used. Players will indicate what actions they are intending to take on their SOPs. While conditional orders can (and should) be used to simulate this rule, the rule itself will not be in use. Note that these are the standard rules, and are intended to help speed game setup and play. Other rules can be used with the mutual agreement of both players and the moderator, and there is no penalty for doing so. (2FC2) TOURNAMENT GAMES: At this time, there is not a tournament setting. This rule is reserved for future use when (and if) a tournament system is put in place. (2FC3) PLAYTEST GAMES: Playtest games use the Standard Rules, as modified by specifications in the playtest scenario. (3FC) SETTING UP A GAME There are a few things you need to do before requesting a Federation Commander PBEM game: * Read and understand THESE rules. If there’s something unclear, then please feel free to E-mail the PBEM Staff with your questions. You can also post any questions on ADB’s Discussion Board (in the Federation Commander Play by Email topic. * Decide what type of game you want to play. (i.e., Standard Duel, Scenario #, etc.) * Decide what rules you want to use. If you’re using PBEM Standard then you’re done with this step. Otherwise, make a listing of all the optional rules you want to include (or standard rules you want to exclude). * If you’re new to Federation Commander itself, then you’ll need to make sure this fact is known before you call for a game. (3FC1) FINDING AN OPPONENT: Once you’re ready to go, you’ll need an opponent. The easiest way to do this will be to post a message to that effect on the Discussion Board. (3FC2) MODERATORS: Every game must have a moderator, which makes moderators a very important commodity in the Federation Commander PBEM universe. Generally, it is requested that every player, after playing a couple of games, make themselves available to moderate games. Demand for moderators can be quite high, and volunteering to help out will help to keep new game starts from being delayed. While players with some Federation Commander PBEM experience are preferred as moderators, it is not absolutely required. Moderating a can be a very rewarding experience. (You get to see all the nasty tricks that two other players can pull on one another. Then you can use them yourself!) So give it a try. (4FC) GAME PROCEDURE The exact game procedure may vary slightly from one game to the next (mostly dependent on the moderator), but will follow the sequence shown below at all times, unless specifically spelled out prior to game start. (4FC1) GAME SETUP: The first turn of a game will differ from subsequent turns only in the initial "setup" phase. This is where you let the moderator know of any special circumstances that are required to be laid out prior to game start. This information is usually included in (or sent at the same time as) the initial turn’s Energy Allocation. Some of the items that need to be specified include (but are not necessarily limited to): * Option Mounts: If your ship has Optional Weapons Mounts, you need to specify these for the moderator. * Prior Loading Energy: Any weapons that have energy in them (i.e., Pre-Loaded photon torpedoes) will need to be identified. * Any other pre-start info that may be required by the scenario. (4FC2) TURN SEQUENCE: The Turn Sequence will vary from one moment to the next, as break conditions, conditional orders, and other unforeseeable events occur. What follows here is a basic example of how a turn will proceed. Explanations of the forms and how they work are described in later sections. (4FC2a) SEQUENCE OF PLAY: 1. All players send their Energy Allocation to the Moderator. (This will include startup info on Turn #1.) 2. Moderator informs all players of each unit’s baseline speed. 3. All players send their initial SOPs to the moderator. 4. Moderator processes all orders on the SOPs. When a break condition occurs, (s)he will post a Situation Report to all players, requesting an updated SOP for the player(s) who had the break. The Sitrep is also sent to the webmaster of that game (if applicable). The end of the SOP period is always a break condition. 5. Player(s) send revised SOP(s) to moderator. 6. Moderator processes the revised SOP(s) and posts another SITREP. 7. [** Steps 5 & 6 are repeated until the end of the turn.] 8. End of turn procedures are carried out. 9. An end-of-turn SITREP is mailed to the players. Then it all starts over at step 1. (5FC) ENERGY ALLOCATION An Energy Allocation “form” will be required for each ship. This form will list the unit’s baseline speed for the current turn, and any energy expenditures that need to be made during the Energy Allocation (pre-loading/loading photon torpedoes, shield regeneration, tractor beams carried over into the new turn, etc.). Also, an effort should be made by each player to double check their Energy Allocation (and SOPs) for errors. Some will probably slip by, but these will be minimized by careful attention on the players’ parts. This is to minimize the number of times the moderator has to stop the game in order to get a clarification of some illegal action taken by a player. (5FC1) ENERGY ALLOCATION REQUIREMENTS: Each player is required to keep track of their own Energy Allocation. This is true for all the forms used in Federation Commander PBEM. The moderator will also keep records in case something happens to your files, but you must still keep copies for yourself. This is to avoid repeated requests for copies of your last Energy Allocation, which would be an unnecessary hassle for the moderator. (5FC2) FORMAT: While there is no “official” form for Energy Allocation, there are a couple things that can be done to make the moderator’s job a bit easier. (5FC2a) SUBJECT LINE: The Subject Line is the "Title" of the message. This is what is visible when you look at the list of messages, and is also what you can key on when "searching" for a specific type of message. As such, it’s important that you include certain information here so that your moderator can find your Energy Allocation and SOPs without any trouble. The format of the Subject Line is as follows: Gxx T.im RAC TYP Where: Gxx = Game Number (i.e., FC0001 - You will be given this by the Games Director.) T.im = Turn & Impulse. (i.e., Turn 3, Impulse 6 = 3.6) RAC = Race designation. This can be spelled out or abbreviated (i.e., FED, Klingon, Kzin, etc.). TYP = Form Type. (i.e., SOP, Energy Allocation, SITREP) For example: FC0001 2.0 Orion Energy Allocation (5FC2b) HEADING: The Heading is the section at the top of the form and is used by the moderator to quickly identify certain game information. The format of the Heading is as follows: Gxx T.im RAC TYP (see above) YOUR NAME & ADDRESS (i.e., Christopher Pike / cpike@somewhere.new) SHIP: BASELINE SPEED While some of this info is also available in the subject line (up at the top of the message), it makes it easier for the Moderator to keep track of everything if the heading contains all of the above info. This way, if the Moderator "cuts & pastes" the info into a word processor, the necessary info will go right along with it. Energy Allocation Heading Example: FC0001 3.0 Klingon Energy Allocation Ardak Kumerian / kumerian_ardak@redfleet.deepspaceforces.kl C7: Baseline Speed 24 (5FC3) ENERGY USED: The rest of the form shows energy available at the start of the turn, items that have energy applied at the beginning of the turn, and energy remaining for use during the rest of the turn. For example (Squadron Scale Federation CA): Total Energy Tokens: 40 (4 batteries) Baseline Speed 16: 16 tokens Load Photon (A): 2 tokens Load Photon (B): 2 tokens Tractor Beam: 1 token Remaining Energy Tokens: 19 tokens (5FC4) EXAMPLE: Below is an example of a completed Energy Allocation (in Squadron Scale): FC0001 2.0 FED Energy Allocation Phillip Kosnet / pkosnet@starfleetnavy.ufp.mil CA: Baseline Speed 16 Total Energy Tokens: 40 (4 batteries) Baseline Speed 16: 16 tokens Load Photon (A): 2 tokens Load Photon (B): 2 tokens Tractor Beam: 1 token Remaining Energy Tokens: 19 tokens (5FC5) MULTIPLE SHIPS: If a player is controlling multiple ships, they can be combined on the same Energy Allocation. For example (in Squadron Scale): FC0001 2.0 FED Energy Allocation Phillip Kosnet / pkosnet@starfleetnavy.ufp.mil DNG: Baseline Speed 16 CA: Baseline Speed 16 DNG: Total Energy Tokens: 65 (6 batteries) Baseline Speed 16: 24 tokens Load Photon (A): 2 tokens Overload Photon (A): 4 tokens (+8) Load Photon (B): 2 tokens Overload Photon (B): 4 tokens (+8) Hold Photon (C): 1 token Hold Photon (D): 1 token Hold Photon (E): 1 token Hold Photon (F): 1 token Regeneration Shield #2: 6 tokens (regenerate 3 boxes) Remaining Energy Tokens: 19 tokens CA: Total Energy Tokens: 40 (4 batteries) Baseline Speed 16: 16 tokens Load Photon (A): 2 tokens Load Photon (B): 2 tokens Tractor Beam: 1 token Remaining Energy Tokens: 19 tokens (6FC) STANDARD OPERATING PROCEDURE (SOP) SOPs are your way of telling the moderator what you want your ship(s) to do for the turn. This will include everything; from where you want them to move, to when you want to fire your weapons, and which weapons to fire. EVERYTHING that is done during the turn goes into the SOP. Note that if you are controlling multiple ships, you should combine them all onto a single SOP. (6FC1) LENGTH: The turn will normally be broken up into two "halves" of 4 impulses each. Each halve will have it’s own separate "initial" SOP. This is known as the SOP Period. Breaks which occur during the half-turn will not "reset" the period. In other words, the first SOP Period of the turn would be for Impulses 1-4. If it is Impulse 2, and a break occurs, the rebid would be for Impulses 2-4. (The rebid starts on Impulse 2 because the break will have occurred on a specific action, and other actions could be taken to respond to that break condition later in the Impulse Activity Segment of that impulse.) Note that each and every rebid MUST include a FULL SOP for the impulses it covers. A "FULL" SOP is considered to be ALL movement, impulse activities, and any other instructions, just like the original. The Player is not allowed to submit alterations or "amendments" to their previous SOPs. So, in the above example, a rebid for impulses 2-4 would consist of a COMPLETE SOP for impulses 2-4. This means rebids consisting of statements like; "Use my old SOP, except change my break conditions to..." would NOT be allowed. (This is done to make the Moderators' jobs a little easier, and reduce the likelihood of Moderator errors.) Note that a rebid of “Please continue with my previous SOP.” is allowed (as long as there are no changed included). A Moderator receiving a partial SOP, alteration request, or amendment request should immediately notify the player that a FULL SOP for the impulses covered must be submitted before the orders can be processed. Once impulses 1-4 were complete, the moderator would ask for new SOPs (from all players) for impulses 5-8 (the second SOP Period). The length of the SOP Period is assumed to be 4 impulses, unless all players agree to use a different number of impulses. (6FC2) RECORD KEEPING: SOPs only need to be kept until they are resolved. Being "resolved" means that a Sitrep covering the impulses relevant in the SOP has been posted by the moderator, and all players agree with the results. There is not necessarily a formal agreement by the players. As long as they accept the Sitrep, and repost new SOPs, agreement can be implied. This way, if there are discrepancies (no one is perfect... even moderators!) they can be discussed while you still have a copy of your latest SOP. Basically, once you’re satisfied that the portion of the turn which applies has been run according to your SOP, you can dispose of it. Obviously, you are not required to dispose of it. Feel free to keep it as long as you like. NOTE: If any discrepancies are noted AFTER the players have accepted the Sitrep and submitted new SOPs, then those discrepancies may or may not be corrected at a later time, based upon the situation and at the discretion of the moderator. Note any discrepancies to your moderator IMMEDIATELY. (6FC3) FORMAT: The format of the SOP is laid out to make viewing and processing it easier for everyone concerned. If a "standard" format is used, then new players (and new moderators) won’t be surprised by an unknown format. Another benefit of a standard SOP is that the required information will be less likely to be accidentally left out. (6FC3a) SUBJECT LINE: The Subject Line format is identical to an Energy Allocation subject line, (5FC2a), with the exception that you put "SOP" in the TYP slot, rather than "Energy Allocation". (6FC3b) HEADING: The SOP’s heading is similar to an Energy Allocation’s heading, (5FC2b), minus the Baseline Speed. (You must still include the ship in a multi-ship force.) The format is as follows: Gxx T.im RAC TYP YOUR NAME & ADDRESS SHIP (If there is more than one ship of your race.) IMPULSES COVERED The SHIP is included to differentiate between two ships of the same race. This would also apply if there were two players on one side (i.e., a 3+ player game). SOP Heading Example: FC0001 2.5 FED SOP Phillip Kosnet / pkosnet@starfleetnavy.ufp.mil IMP 5-8 (6FC3c) CURRENT POSITIONS: The Current Position shows each of YOUR unit’s starting locations. (Beginning with the first impulse of THAT SOP.) For instance; For SOP 2.05, the starting situation would reflect the ship’s starting location on Impulse #5 of Turn #2. You should include Ships, Shuttles, etc. (but not seeking weapons) here. An example follows: SHIP HEX ========== DNG 0607D CA 0707D Note that the HEX location of a unit is shown as it’s actual hex number, with it’s facing immediately after. (i.e., A ship in hex 0607 facing direction D is said to be in hex 0607D.) (6FC3d) MOVEMENT: The Movement Section contains the locations of all ships during the course of the SOP, on an Sub-Pulse by Sub-Pulse basis. For each Sub-Pulse that one of your ships is to move, simply put the new hex location (including heading) under the appropriate ship. If you want to take other actions during that impulse, that will be listed in the Impulse Activities Section. (i.e., If performing a High Energy Turn, just list the new hex location in the Movement Section, while listing the High Energy Turn action itself in the Impulse Activity Section.) Movement Section Example (for Impulse #4 only): SUB- PULSE DNG CA ================== 4.1 ----- ----- 4.2 0608D 0807C 4.3 ----- ----- 4.4 0709D 0908C Notice that during Sub-Pulse #4, the DNG sideslipped. This information does not need to be spelled out, as the plotting of movement will make it apparent. Also notice that the CA turned during Sub-Pulse #2. This is also apparent, and does not need to be specifically noted. The movement plot itself is sufficient. (6FC4) IMPULSE ACTIVITIES: This is where all other actions are spelled out. Weapons fire, shuttle launches, Seeking Weapon launches, Tractor use, Transporter use, etc... ANYTHING you want to do during the turn (except normal movement) is done in this section. Note, special movement functions (high energy turn, acceleration, etc.) will be listed in this section as well. The format of this section is simply; Impulse #: Activity. That’s it. List each impulse separately, and each activity separately. It makes it easier to sort the actions out when the Moderator processes the turn. If movement activities are to be performed, the Sub-Pulse the activity will take place on will also be listed. Impulse Activity Example: IMP 2: DNG Launches 1x drone (drone rack W) at D7. IMP 3: CA Uses 1x Energy Token to accelerate to speed 16+1 IMP 4: DNG Uses 1x Energy Token to decelerate on Sub-Pulse #2 DNG Uses 1x Energy Token to tractor CA Note that when listing weapons fire / launching, MAKE SURE you include which weapon (A,B,C,D,1,2,3,4) is being fired / launched. It may be obvious in most cases, but sometimes it isn’t. It’s better to get in the habit. Otherwise the moderator has to delay the game to request the information, or pick one out at random. (6FC5) BREAK CONDITIONS: Break Conditions are your requests to interrupt the game under certain conditions so that you may reassess the situation and "rebid." (Rebidding is simply the act of submitting a new SOP.) Once a break occurs, your old SOP is considered "dead" at that point, which means that you can change any of the orders you had originally put down (from that point forward). Break Conditions are listed after the Impulse Activity Section. You may include a set of "Break Conditions" in your SOP so that, if your opponent takes certain actions, or if events develop a certain way, you will have the opportunity to rebid your SOP. They are here so that your initial SOP doesn’t have to be 12 pages long to cover every response to every event which may possibly take place. They are also here to give you a chance to react to actions or events that would make you want to change your ship’s orders (either movement or impulse activities.) For example; Let’s say that you are approaching an enemy ship with your drones "leading" you. Rather than list all the possible responses to all their possible actions, you could put in a request to break if (s)he sideslips away, or tractors some drones. You could then look to see what (s)he actually did, and respond to it. Also, when a break condition occurs, it is that specific event which triggers the break. This means that you may still take any actions which occur later during the Impulse Procedure of the SAME IMPULSE as the event which caused the break. For example; Let’s say that you originally had an SOP that had you not launching any drones. Your opponent fires all of his phasers on Impulse #4, which triggers an Auto-Break (6FC6). This means that you now have the opportunity to launch your drone(s), because the Launch Phase comes AFTER the Offensive Fire Phase in the Sequence of Play. (6FC5a) BREAK CONDITIONS FORMAT: The format of Break Conditions is basically a description of what would make you want to reassess the situation. Try to make it brief and to the point, so the moderator doesn’t have to wade through it to get to the point. For example: BREAK CONDITIONS: CA Drops a shield CA Uses a transporter CA Tractors a drone There are two major dangers with Break Conditions; not enough, and too many. First is the danger that you’ll overlook a possible action, and miss an opportunity (or worse, fall into catastrophe). It’s a very real concern, and one which you have to keep in mind. Second is the problem of loading up with every conceivable break condition, and bogging the game down to unacceptably slow speeds by having every other impulse trigger a break, and an SOP rebid. The trick is to balance these two situations out. The easiest way to do that is to update your break conditions with EVERY SINGLE SOP! By updating, we mean add those breaks which are now applicable, and DELETE THOSE WHICH ARE NO LONGER APPLICABLE. The situation is changing all the time, and there are very few break conditions that are applicable throughout the game. While some inapplicable ones may actually trigger a break, there are a few instances where a break was triggered, and the player rebid with "Just go ahead and use my old SOP." This is usually an indication of an unnecessary break. There are times when a break is valid, but when (upon consideration) you decide that your original course of action is the correct one. Far more often, however, it turns out to be just a "I wanna look around and see what’s up" or a "I forgot to update my Break Conditions Section" situation. Remember, there are (at least) two other people involved in the game, too. It’s not fair to them to have the game drag out just so someone won’t miss any conceivable event. That’s part of the "skill" of playing Federation Commander PBEM. Having a streamlined SOP that will break the action when it counts, but not when it doesn’t. (6FC5b) AUTOMATIC BREAKS: Automatic Breaks are breaks which will occur without any request from the players. Auto Breaks are for those events which most players would request a break for anyway. The number of "Auto-Breaks" is purposely kept to a minimum, so that they don’t unnecessarily bog the game down with unneeded delays. It does include some of the most common and continually asked for breaks, however. Auto-Breaks will be assumed to be in effect unless it is agreed upon by all players (and the moderator) PRIOR to game start. There are two basic classes of Auto-Breaks. First, is the "Universal" break. This is a break which allows all players to rebid. An example of these types would be along the lines of internal damage, so that the both players could see what was damaged, and then decide what action to take based upon which systems were destroyed. In other words, the events which trigger a Universal Auto-Break are ones that all players (even the one who initiated the action) would normally want to see the results of before proceeding. The second type is the "Singular" break. This kind of break would only allow the player(s) who DID NOT cause the event to rebid. For example; Drone Launch: The player who launched the drones already knows about them, so there’s no reason for that player to need a rebid. The other player(s), however, would like to take action in response to the drone launch (namely... KILLING THEM!). For either type of Auto-Break, the player(s) can state in their SOP that the Moderator can skip any upcoming Auto Breaks that won’t affect them. For instance; You and your opponent have played many times before, and you KNOW that once (s)he unloads their photons, turning will follow. If you see them unload, you can let the moderator know that you don’t need the "Course Change" Auto-Break, and plan for them turning. (Of course, you would then put in a Break Condition so that the action would break if (s)he DIDN’T turn after a specified period of time.) This would also apply near the end of that SOP Period, when certain actions won’t change your plot anyway. Below is a list of all the Auto-Breaks. If you don’t see it here, then you’ll need to specify it in your SOP. If you DO see it here, then you don’t need to clutter your SOP with an identical break. (6FC5c) "UNIVERSAL" AUTOMATIC BREAKS: These events will trigger an Auto-Break. Each player must submit a new SOP in response to these breaks, or inform the moderator to continue on with their most recent SOP. * SHIELD DAMAGE on any ship which leaves 5 or less shield boxes (on damaged shield) intact. * INTERNALS scored on any ship. * Any shuttle becomes crippled or destroyed. * Any UNIT FIRES Heavy Weapons. * Any ship shows DOWN SHIELD to any enemy unit in range & capable of firing. * TRACTOR initiation that targets a unit able to resist via Tractor Auction. (6FC5d) "SINGULAR" AUTOMATIC BREAKS: These events will trigger an Auto-Break. Only the player(s) NOT responsible for the below actions is allowed to rebid. If the players do not desire a rebid, they must let the moderator know that. * COURSE CHANGE by enemy ship (excluding shuttles). This includes High Energy Turns, Tactical Maneuvers, or any other situation that results in a course change. * SPEED CHANGE announcement by enemy ship. This includes Acceleration, Deceleration, Emergency Deceleration, or any other situation that results in a speed change. * Starting or stopping erratic maneuvers. * NEW COUNTER on board. This includes Shuttle launch, Seeking Weapon launch, reinforcements, etc. * Marine Raid conducted against any friendly ship. (6FC6) CONDITIONAL ORDERS: Conditional Orders are orders you put down to react to the developing situation without using a Break Condition. In other words, they are "IF X THEN Y" Impulse Activities. Conditional orders can be used to do the following, based upon certain conditions you specify: * Change Impulse Activities * Change your Movement Plot * Change / Cancel Break Conditions * Cancel Automatic Breaks A Conditional Order allows the game to proceed (without a break), under certain conditions which you anticipate. They are normally used to eliminate a Break, and keep the game moving. For example: If the FED CA turns to direction C, then the D7 will turn to follow. If the D7 attempts to tractor, use up to 3 energy Tokens to fight the attempt. Conditional Orders also take precedence over, and CANCEL, Auto-Breaks. For example; In the above examples, the first Conditional Order would also cancel the COURSE CHANGE Auto-Break, (for a direction C turn only), while the second example would cancel the TRACTOR Auto-Break and instead conduct the tractor auction. (6FC6a) FORMAT: The format for Conditional Orders is similar to Impulse Activities. It can be a simple IF / THEN statement, or it can be a paragraph on what your intent is. Just keep in mind that the more specific you are, the more likely it is that it will happen the way you want. If you give the moderator a lot of leeway, (s)he may not do exactly what you wanted. Here’s some examples: If the D7 moves to 1220D, launch a suicide shuttle targeted on the D7. [This is pretty specific and clear cut.] If the CA sideslips or changes course, then keep it lined up along my forward centerline, using sideslips (if possible) or turns, it that’s the only way. [This is relatively specific.] I want to keep away from the Fed’s centerline. Move me so I don’t line up on it. [This leaves a LOT to the moderator…actually, too much. According to the letter of this Conditional Order, the moderator could theoretically move you anywhere (s)he wants…EXCEPT lining you up with the Fed’s centerline, and you would have no recourse if you considered it a “stupid” move.] The more specific approach is usually best, but you can "talk" your way through what you want to do... just be careful. (6FC6b) LIMITATIONS: The biggest limitation of Conditional Orders is that it can be difficult to anticipate much of what’s going to happen in the next few impulses. Conditional Orders are not meant to replace Break Conditions. They are simply meant to enhance them. It’s just another tool for you to use when constructing your SOP. As such, if you load your SOP up with a LOT of Conditional Orders, you may be able to catch enough of the upcoming events to avoid a break altogether. However, the poor moderator is going to have to wade through your 34 Conditional Orders to make sure (s)he didn’t miss anything, which will take some time to do. On the other hand, there are enough times when the courses of action your opponent can take are limited to two options. In these cases, try to use Conditional Orders instead of Break Conditions. Your game will speed up considerably. Another limitation of Conditional Orders is that they can get very complex. If you try to do too many things in a Conditional Order, the moderator has the option of requesting clarification, or just triggering a break, and letting you rebid from there. Keep in mind that Conditional Orders are NOT mandatory. Everyone involved will benefit from their proper use, but if you feel too uncomfortable, then just use Break Conditions. Of course, you can ask your moderator for advice, too. They can help you turn your Break Conditions into effective Conditional Orders. (6FC7) REINFORCEMENT/DAMAGE ORDER: This section will list orders for shield reinforcement and damage order overrides. These instructions should be listed on EVERY SOP. If there are no orders listed here, the moderator will assume that no reinforcement is to be used and the default damage allocation procedure is to be used. (6FC7a) RESERVE POWER SHIELD REINFORCEMENT (RSPR): RPSR orders follow the same format as other conditional orders. It specifies under what conditions you want to use reinforcement, and how much to use. Some examples of RPSR orders: Use RPSR as necessary to protect the last shield box of any shield about to be dropped by damage. DO NOT use RPSR if the last shield box cannot be saved. If the shield cannot be saved, then use RPSR points to stop ANY AND ALL INTERNALS. Do not use RPSR unless the shield is dropped. In that case, use all available RPSR to prevent internals. (6FC7b) DEFAULT DAMAGE ALLOCATION PROCEDURE (DDAP) OVERRIDES: This section should list any changes to the DDAP (8FC) that the player may wish to make. This includes, but is not limited to, changing the order of weapons hits, taking frame damage in place of the last box of a given system, etc. These overrides can be used for specific cases or can be general in nature. For example: Do not destroy the phaser-3 #4 unless it is the only one left. If the enemy has any drone racks remaining, destroy my drone racks before hiting the ADD racks. Otherwise, take the ADD first. Take frame damage instead of the last tractor box. Frame damage will be take instead of skipping any damage points. (6FC8) ENERGY ALLOCATION: Your energy allocation information should be included on each sop. The information will be the same as in the Energy Allocation section above (5FC), except that it should be modified to include any energy expenditures that have been made so far in the turn. (6FC9) SOP EXAMPLE FC0001 2.5 FED SOP Phillip Kosnet / pkosnet@starfleetnavy.ufp.mil IMP: 5-8 START: ======================= SHIP HEX ---------- DNG 0404D CA 0504D MOVEMENT: SUB- PULSE  DNG    CA ----------------- 5.1  ----- ----- 5.2  0405D 0505D 5.3  ----- ----- 5.4 0406D 0506D 6.1 ----- ----- 6.2  0407D 0507D 6.3  ----- ----- 6.4  0408D 0508D 7.1  ----- ----- 7.2  0409D 0509D 7.3 0410D ----- 7.4 0411D 0510D 8.1 ----- ----- 8.2 0412D ----- 8.3  ----- ----- 8.4 0413D 0511D IMPULSE ACTIVITY: IMP 7: DNG Uses 1.5 Energy Tokens to acceleration to speed 16+1 IMP 8: CA Uses 1 Energy Token to deceleration on Sub-Pulse #2. IMP 8: DNG Fires 6x Photons at C7. IMP 8: CA Fires 4x Photons at C7. Also uses 4 Energy Tokens to fire 4 Ph-1 (1-4) at C7. CONDITIONAL ORDERS: If the C7 reaches range 3 of the CA, the CA will launch a suicide shuttle at the C7. IMP 8: If C7 is within overload range of the CA, the CA will use 8 Energy Tokens to overload each photon to the +4 overload level before firing. Do not use any shield reinforcement. DNG Energy Allocation: Total Energy Tokens: 65 (6 batteries) Baseline Speed 16: 24 tokens Load Photon (A): 2 tokens Overload Photon (A): 4 tokens (+8) Load Photon (B): 2 tokens Overload Photon (B): 4 tokens (+8) Hold Photon (C): 1 token Hold Photon (D): 1 token Hold Photon (E): 1 token Hold Photon (F): 1 token Regeneration Shield #2: 6 tokens (regenerate 3 boxes) Acceleration Imp 7: 1.5 tokens Remaining Energy Tokens: 17.5 tokens CA Energy Allocation: Total Energy Tokens: 40 (4 batteries) Baseline Speed 16: 16 tokens Load Photon (A): 2 tokens Load Photon (B): 2 tokens Tractor Beam: 1 token Deceleration Imp 7.2: 1 token Phasers: 4 tokens Remaining Energy Tokens: 14 tokens (6FC10) BLANK SOP FORM: Below is a standard version of a Blank SOP form: Gxx T.im RACE SOP Name / Address IMPULSES COVERED START: ======================= SHIP HEX ---------- MOVEMENT: SUB- PULSE SHIP (SHIP) --------------- 1.1  ----- ----- 1.2  ----- ----- 1.3  ----- ----- 1.4 ----- ----- 2.1  ----- ----- 2.2  ----- ----- 2.3  ----- ----- 2.4 ----- ----- 3.1  ----- ----- 3.2  ----- ----- 3.3  ----- ----- 3.4 ----- ----- 4.1  ----- ----- 4.2  ----- ----- 4.3  ----- ----- 4.4 ----- ----- IMPULSE ACTIVITY: CONDITIONAL ORDERS: ENERGY ALLOCATION: (7FC) SITUATION REPORTS (SITREPS) Sitreps are the moderator’s tool for informing players what happened that turn. A Sitrep (as the name implies) is a report from the moderator on actions taken by both players (including movement) and the results of those actions. It will look similar to your SOP, but it will blend the info from your opponent(s) in. When the Sitrep is posted by the moderator, it will be sent by email to all players involved in that game and the webmaster if (s)he is not one of those people. This way everyone involved gets all the information they need and all the spectators can follow the action on the web pages. End of Game Sitreps are also normally sent to the PBEM Coordinator, so that they can keep The Games Pages up to date. (7FC1) SUBJECT LINE: The subject line is formatted similarly to the subject lines for Energy Allocation and SOPs, with the obvious difference that it is for all players. This allows you to "search" for the subject line content to find the Sitrep you’re interested in. The format is as follows: Gxx T.im SITREP For example: FC0001 3.2 SITREP (7FC2) CURRENT POSITIONS: The Current Positions section will be identical to the Current Positions section on the SOPs, (5FC6) except that it will include the locations and speeds for all units (of ALL sides) as of THAT Sitrep. (i.e., If the Sitrep is for impulses 5-7, then the Current Positions section would show the locations on IMPULSE #7.) For example: SHIP      HEX  ============== FED DNG  1708C FED CA   2010D KLIN C7  1318F KLIN D7 1215E KS/1 1215E Note that KS/1 is the designation for the 1st Klingon Shuttle launched. See (9FC4) (Small Unit Designations) for further explanation. (7FC3) BODY: The body will show everything that has happened (so far) that turn. (7FC3a) MOVEMENT PLOT: The Movement Plot will look exactly like an SOP’s movement plot (6FC3d), except that it will contain the movement information for all units (on both sides), INCLUDING Seeking Weapons. Also, the Movement Plot will be listed for the entire turn, even though the Sitrep is only for a few impulses. This makes it easier for the players (AND the moderator) to keep track of what’s going on, since it’s all on one form. For example: MOVEMENT: SUB- PULSE CA D7 KD/1 KD/2 ============================ 3.1 3.2 1811C 2923F 3.3 3.4 1912C 2822F 2822F 2822F 4.1 4.2 2012C 2821F 2722F 2722F 4.3 2721A 2721A 4.4 2113C 2721F 2720A 2720A Note that KD/1 (and KD/2) is a designation for a drone. See (9FC4) (Small Unit Designations) for further explanation. (7FC3b) IMPULSE ACTIVITIES: The Impulse Activities section will list actions and events that occurred that turn. The difference between this and the SOP Impulse Activities section is that this one will list only those actions which have actually come to pass. The format is: IMP xx: Event. (i.e., IMP 17: D7 Launches 1x drone at CA) Each action will be listed separately, and each impulse will be listed separately. If two actions are being done on the same impulse, they will be listed on separate lines. For example: IMP 7: CA Accelerates to speed 16+1 D7 Launches 2x drones, facing A, target CA (KD/1-2) (7FC3c) DAMAGE RESOLUTION: When damage is scored due to a "dice roll", then a Damage Section is included to explain the results, including the dice rolls obtained. For example: DAMAGE: Weapon     Roll Damage ------------------------ Disruptor A  2    3 Disruptor B  6    0 Disruptor C  2    3 Disruptor D  3    3 ------------------------ sub-total        9 Reinforcement     1 Shield damage     4 TOTAL INTERNALS   4 INTERNALS: CA Damage Allocation Chart Roll = 2 Phaser (#9) R Hull Reactor Lab (Repeat as needed for additional Damage Allocation Charts.) A more simplified version of this information could be used, if the moderator desires. For example: IMP 5: D7 Fires 4x Disruptors at CA (range 7) Rolls=2,6,2,3 for 9 damage on #2 shield 1 reinforcement, 4 point shield – 4 internals Damage Allocation Chart Roll=2 Internals=Ph-3 (9), R Hull, Reactor, Lab (Repeat previous two lines as needed for additional Damage Allocation Charts.) CA shields now 30/24/24/24/00/24 Note that when a shield is damaged, the total damage scored on the shield is reported, as well as the amount of damage the shield actually took. For example, a ship with a 20 point shield took 22 damage, but it had one point of reinforcement on it, plus a conditional shield reinforcement order to use batteries to save the last shield box. This would be reported as 22 damage, 3 reinforcement, 19 hits to the shield. (7FC4) REMAINING POWER: This section will list the remaining power for each ship in the battle. Each ship will have it’s own line. This will not be a complete Energy Allocation list, just the number of remaining tokens the ship has. POWER REMAINING: Federation CA: 7 power Klingon D7: 14 power (7FC5) NEXT SOP INFO: This is where the moderator will tell the players the Sequence of Play step the break condition occurred in, who must submit an SOP to continue the game, and when that SOP is due. If the break occurred during movement, the movement sub-pulse will also be listed. For example: BREAK CONDITION MET (1E2b #3) - FED NEW FED SOP DUE 6-20 (7FC6) EXAMPLE: Below is an example of a complete SITREP for a complete turn. (This is for example purposes, so please excuse any “bad” tactics.) FC0001 2.8 SITREP SITUATION: SHIP      HEX  ============== FED CA   2520C KLIN C7  2123F MOVEMENT: SUB- PULSE CA D7 KD/1 KD/2 =========================== 1.1 1.2 1409C 3225F 1.3 1.4 1410C 3125F 2.1 2.2 1610C 3024F 2.3 2.4 1711C 2924F 3.1 3.2 1811C 2923F 3.3 3.4 1912C 2822F 2822F 2822F 4.1 4.2 2012C 2821F 2722F 2722F 4.3 2721A 2721A 4.4 2113C 2721F 2720A 2720A 5.1 5.2 2213C 2620F 2619F 2619F 5.3 2618A 2618A 5.4 2314C 2520F 2617A 2617A 6.1 6.2 2315D 2420E 2517F 2517F 6.3 2316D 2416F 2416F 6.4 2317D 2421E 2317E 2317E 7.1 7.2 2318D 2322E 2318E 7.3 2319D 2319E 7.4 2320D 2323E 2320E 8.1 8.2 2420C 2223E 8.3 8.4 2520C 2123F IMPULSE ACTIVITIES: ==================================================== IMP 0: CA Announces baseline speed 16 D7 Announces baseline speed 16 CA Holds 4x +8 overload photon torpedoes IMP 3: D7 Launches 2 drones, facing F, target CA (KD/1-2) IMP 5: D7 Fires 4x Disr (A-D) at CA (range 7) Rolls=2,6,2,3 for 9 damage on #2 shield No reinforcement – shield reduced to 15 CA shields now 30/24/24/24/15/24 IMP 6: CA Accelerates to speed 16+1 KD/1 Impacts CA #5 shield KD/2 Impacts CA #5 shield CA Attempts defensive fire against KD/1 CA Fires 1x Anti-drone from Drone rack #1 at KD/1 Roll=6 – anti-drone missed CA Fires 1x Ph-3 (9) at KD/1 Roll=3 for 4 damage – KD/1 destroyed CA Attempts defensive fire against KD/2 CA Fires 1x Ph-3 (10) at KD/2 Roll=6 for 3 damage – KD/2 not destroyed CA Uses 1x Energy Token to tractor KD/2 IMP 7: CA Accelerates to speed 16+1 CA Attempts defensive fire against KD/2 CA Fires 1x Ph-1 (7) as ph-3 at KD/2 – autokill* CA Fires 4x Photons at D7 (range 3) Rolls=5,2,6,5 for 8 damage on #3 shield No reinforcement – shield reduced to 14 D7 shields now 30/22/14/22/22/22 POWER REMAINING: KLINGON D7: 18 POWER FEDERATION CA: 11.5 POWER END OF TURN ENERGY ALLOCATION FROM BOTH PLAYERS DUE 2-7-06 * An autokill is when the minimum damage from a weapon (or weapons) is more than enough to destroy the target, a die roll is not needed. The weapon is fired (energy is expended and the Weapons Fired track is marked) and the target is destroyed, but no die is rolled. In the above example, the drone only had 1 damage point remaining. Since the minimum damage of a phaser-3 at range 1 is 3, this was an autokill. (7FC7) BLANK FORM: Below is an EXAMPLE of a blank Sitrep form. You can use this, or make one of your own. As long as it covers at least what is presented under Sitrep Format. Gxx T.im SITREP SITUATION SHIP   HEX  =========== MOVEMENT: SUB- PULSE SHIP A  SHIP B =================== 1.1 -----   ----- 1.2 -----   ----- 1.3 -----   ----- 1.4 -----   ----- 2.1 -----   ----- 2.2 -----   ----- 2.3 -----   ----- 2.4 -----   ----- 3.1 -----   ----- 3.2 -----   ----- 3.3 -----   ----- 3.4 -----   ----- 4.1 -----   ----- 4.2 -----   ----- 4.3 -----   ----- 4.4 -----   ----- IMPULSE ACTIVITIES: REMAINING POWER: NEXT SOP INFO DUE (8FC) DEFAULT DAMAGE ALLOCATION PROCEDURE (DDAP) The Default Damage Allocation Procedure outlines how damage is applied when internals are scored if no damage preference is given by the player prior to the internals being rolled. (8FC1) PURPOSE: The purpose of the DDAP is to speed the game by having a standard order of damage so that the moderator does not have to break the action in order to find out where the player wishes the damage to be applied. As such, the DDAP will be used unless otherwise specified, and the moderator will not stop damage allocation to request specific damage instructions. The Damage Allocation Charts are still used. This procedure is only used to determine which box is damaged when there is more than one choice, and that choice can affect the battle. For example: The Damage Allocation Charts call for Phaser Damage. Rather than stop and ask the player which phaser to damage, the moderator will simply follow the Order of Precedence (below) to determine which phaser gets the hit. (8FC2) FRAME DAMAGE: Frame damage will only be scored (by this procedure) as the alternate to the last damage point on a given Damage Allocation Chart. It will not be used in place of the last box of a given system (i.e., the last lab will be hit instead of frame damage), and if both the primary and alternate systems are destroyed/unavailable, the damage point will be skipped instead of scoring frame damage. Note that the player can use (8FC3) to override this rule and take frame damage in place of the last box of certain systems (which would need to be listed) or instead of skipping a damage point. (8FC3) EXCEPTIONS: The players have the option, at any time PRIOR to the actual damage being scored, to override the DDAP. The exceptions that the player wants to make must be spelled out clearly to the moderator in the most recent SOP. These overrides must follow all other normal rules of damage allocation. For example, if you’re expecting damage, and want to save your 360º Ph-3 (phaser #5) more than your FA arc Ph-1s (due to an incoming drone from the rear), you can let the moderator know that you want the 360º Ph-3 (#5) to be the LAST phaser damaged. You would give the moderator this information in your SOP. The info would have to be in each and every SOP that you want it to apply, otherwise the DDAP will be used. Remember to delete it from your SOP if/when you want the exception to no longer apply. Note that this procedure can be used for Frame Damage as well. For example, a player may with to take frame damage instead of the last shuttle box. (8FC4) DAMAGE ORDER OF PRECEDENCE: Below is the Default Order of Precedence for damage applied from the Damage Allocation Charts. This is listed from first weapon hit to last. * PHASERS: Fired Ph-3, unfired Ph-3, Fired Ph-2, unfired Ph-2, Fired Ph-G, unfired Ph-G, Fired Ph-1, unfired Ph-1, Fired Ph-4, unfired Ph-4. * HEAVY WEAPONS: Smallest Fired, smallest charging, smallest unfired. In the case of multiple types of weapons on one ship, the owner will need to specify which will be hit first. * DRONE RACKS: Hit ones that have Fired/Launched on the current turn prior to ones that have not, and within each category, the one with the least spaces of available drones. * SHUTTLE BAYS: Unoccupied, occupied with admin shuttle, occupied with suicide shuttle. * TRACTOR BEAMS: Used and dropped this turn, unused, in use holding object. * OTHER SYSTEMS: Used this turn, not used this turn. * UNDETERMINABLE: In cases where the default or modified order of damage results in two or more weapons falling into the same category, hit the one with the most restricted arc first. If both arcs are equal, determine randomly. The moderator’s interpretation of what the players DDAP override orders mean is final. If an order is vague or illegal, the moderator will fall back upon the default order of damage without contacting the player prior to internals being scored, so make sure you're specific. (9FC) MODERATING 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. (10FC) PROBLEM RESOLUTION Occasionally, you are going to run into a problem. Simple rules problems are easy, as the answer is either right there in the book, or you can ask ADB, Inc. The problems that this section addresses are problems with the running of a game. This may involve a moderator, or one (or more) of the players. Should it be a player problem, the moderator is primarily responsible for resolving it. Tardiness is covered in (9FC2a2), but other problems may arise, and it is the moderator who must attempt to work them out. For moderators who cannot (for whatever reason) resolve a player conflict (besides the one where they’re trying to drill holes in each other’s ships), the PBEM Coordinator should be contacted for further direction on how to proceed. (10FC1) MODERATOR PROBLEMS: If you find that the moderator of your game has gone absent, or you feel that (s)he is not running the game correctly or fairly, the first thing that you should do is to bring it to their attention. A lot of the time, the problem can be resolved by communicating it directly with the person involved, and has probably been caused by a lack of communication. However, if that does not bring a resolution, it may be necessary to "go over their head". In this case, bring your problem up with the PBEM Coordinator. The PBEM Coordinator will try to work your problem out from both ends, and will hopefully be able to come up with a solution. (11FC) SQUADRON RULES These rules are designed to handle large scenarios. A large scenario is one in which 5 or more players are involved. These games present specific problems for a moderator and players, particularly of time. While the standard PBEM rules are designed to simulate a face-to-face game as much as electronically possible, these rules sacrifice some flexibility on order to gain greater playability. With many people involved in a scenario, the game tends to drag due to turn-around time, a lot of things happening on the board, and lots of breaks. These rules provide a faster game by modifying the rules for breaks and enhancing the rules for standard and conditional orders. These rules can also be used in games that have large fleets controlled by just a few players (i.e., 5+ ships per side in a two player game). NOTE: The Squadron Rules defined here have no correlation to the Squadron Scale Ship Diagrams in Federation Commander. The word “squadron” used here refers to the grouping of the ships being used, not the Scale of the Ship Diagrams. These rules can be used for either Squadron Scale or Fleet Scale. (11FC1) WHEN TO USE THESE RULES: The Squadron Rules are not required for any game. It is up to the moderator to decide if these rules will be in force in his game. (11FC2) DESCRIPTION: The Squadron Rules differ slightly from normal Federation Commander PBEM rules in that each turn will be run in 1-Impulse increments. Every impulse, the action will break, and there will be NO other break conditions. The particulars are spelled out below. (11FC3) SOPs: SOPs in Squadron Rules fall into two categories; INITIAL SOPs (those submitted at the start of EACH turn), and 1-IMPULSE SOPs (those submitted every impulse). (11FC3a) INITIAL SOPs: All beginning of turn SOPs must be submitted for the FULL 8 Impulses. This SOP will be referred to should you miss a deadline. (There are NO warnings and NO waiting in Squadron Rules.) You will still get to submit 1-Impulse SOPs throughout the turn. [This section modifies (6FC1) SOP LENGTH.] (11FC3b) 1-IMPULSE SOPs: You will submit all subsequent SOPs for the turn in 1 Impulse periods. There will be no reason to submit beyond that, as the game will break every impulse, no matter what you want. (11FC4) SOP DEADLINES AND GAMEPLAY: When the Moderator posts a Sitrep, he should put a deadline for new SOPs on the post. All players should get their new SOP to the moderator by the deadline. Unlike the regular PBEM rules, there is no grace period and no warning period in Squadron Rules. In order to keep the game moving, the moderator will process SOPs on a strict schedule. This will eliminate the situation of nine players waiting for a tenth player to submit a new SOP. If a new SOP is not received prior to the deadline, the moderator should continue the game using the player's current SOP and Standing Orders. He should NOT extend a grace period or deal out hull box penalties. Extensions will not be granted in Squadron Rules. If you are going to be out for an extended period of time, have someone else on your side handle your ship until you return. If in a free-for-all, take what precautions you can, and hope you're still there when you return. If a player had not responded by end of turn, the moderator should make other arrangements for that player's ship. (Hand it off to another player on the same side, or perhaps have it self-destruct.) If a player returns after two weeks and discovers that in the interim his ship has been destroyed, he has no recourse. Because the game is large and players are forced to plan ahead carefully, we suggest that moderators run no more than 2 posts per week, and to be sensitive to the fact that many Federation Commander players do so via work E-mail addresses and may not be able to get SOPs done on weekends. (11FC5) BREAK CONDITIONS: In Squadron Rules games, players do not specify break conditions at all. Instead, an automatic break occurs after every impulse. At each break, all players have the opportunity to modify and resubmit their SOPs. The 1-impulse breaks are the only breaks in the game. There are no player-defined breaks, and no automatic breaks of any kind. [This section modifies (6FC5) BREAK CONDITIONS.] (11FC6) CONDITIONAL ORDERS: Because there are no breaks other than the 1-impulse breaks, the ability to define and carry out Conditional Orders (6FC6) is of paramount importance in Squadron Rules games. However, because a break occurs every impulse, you need only worry about those events which you suspect may occur within that limited time span. (Note: The Squadron Rules do specify that the initial SOP should cover through the end of the current turn. This is so that the turn can be completed in the event a player drops out or disappears mid-turn, or does not get a new SOP to the moderator within a given time limit.) In most cases, the number of significant events that can happen in such a short period is limited, reducing the need for all-encompassing conditional orders. (11FC7) STANDING ORDERS: Standing Orders are a special class of Conditional Orders. The are submitted once at the beginning of the game. These orders are designed to cover many common situations that occur in the game. They define actions that will be taken in response to a situation, regardless of whether a conditional order has been issued. Conditional Orders (and the SOP) can override Standing Orders by player request. The following Standing Orders form will help new players define standing orders for their ships. Gxx T.im RAC Standing Orders NAME / E-MAIL SHIP Use of Reserve Power for Shield Reinforcement: ___ Never ___ If doing so will preserve a shield box ___ If I take over ____ internals ___ Any time I take damage If I am tractored, I will use up to ___ points of reserve power to fight it. I will use ___ energy to defend against enemy tractor attempts. If drones/suicide shuttles will Hit Me Next Impulse: ___ Slip away if at range 2. ___ Tractor ___ drones. ___ If a drone takes ___ hits to kill, fire ___ phaser-___s at it. ___ Launch drones at them. ___ Launch SS Shuttles at them (if possible by movement) If drones/suicide shuttles will hit me this impulse: ___ Use ADDs as available ___ Fire up to ___ phaser-___s at it. <== repeat as necessary ___ Use up to ___ tractors to stop the seeking weapons If plasma will hit me next impulse, I will: ___ Fire phasers at it if it is more than ___ points. ___ Slip to take it on my #___ shield ___ Slip to take it on my strongest shield, including reinforcement. If opponent has fired and knocked down a shield, I will: ___ Turn to take the shield away, if possible. ___ High Energy Turn to take the shield away, if possible. ___ Use Phaser-1/2s as phaser-3s in order to fulfill any of these orders. As you can see, the Standing Orders cover a lot of the events that can occur and run their course  within an impulse. This sheet is designed as a guideline. You are encouraged to add your own Standing Orders for situations specific to your game. (11FC8) DAMAGE ALLOCATION: Damage allocation will be handled using the PBEM Default Damage Allocation system (8FC) unless otherwise specified in Conditional or Standing orders. (12FC) FINAL WORD We all enjoy a good Federation Commander game, (or you wouldn’t have read this far!) But, finding an opponent is probably the most difficult maneuver of all. The Federation Commander PBEM Rules were developed to enable Federation Commander players around the world to play their favorite game by E-Mail. There are bound to be situations that are not covered in the present PBEM rules. When those situations arise, the PBEM Coordinator can give you immediate resolution. Clarifications can be discussed and put into the next Federation Commander PBEM rules revision so that the questionable situation won’t come up again in another game. We hope you get many enjoyable hours from them. If you have any questions, comments, or suggestions, direct them to PBEM Coordinator. After all, these rules are here for YOU. (ZFC) REVISIONS Below is the list of Revisions that the Federation Commander PBEM Rules have undergone. * Initial Writing, 11/15/2006 by Frank Brooks (PBEM Coordinator)