Version 5.0 alpha. This rule set is still in development.
Welcome to Star Empires. In this game each player controls a collection of worlds and ships spread across the galaxy -- a star empire. These worlds produce resource units, or RUs, which are spent on building and repairing starships, which in turn are used to blow the snot out of other players' starships in the course of taking over more worlds. The object of the game is to take over at least half the RU production in the galaxy. The only problem is that all the other empires out there want the same thing as you.
Star Empires is played in a series of turns. At the start of each turn, your game map will show the current state of the galaxy. You have until the next turn's deadline to negotiate and scheme with other empires and issue a set of orders for your ships and worlds. When the turn deadline arrives, all empires' orders are processed in a series of phases and updates are made to all empires' maps accordingly. Turns continue until one empire (or allied empires) meet specific victory conditions and the game master (GM) declares a winner.
Your empire lives in a roughly circular galaxy, which is organized as a set of hexagonal sectors. At the start of the first turn your game map shows your starting sector and the few nearby sectors that you can scan. Your telescopes alone can not tell you what wealth lies in unknown space, so in order to expand your empire and increase your income, you must send your ships forth and explore the galaxy. As you travel through the galaxy, you'll encounter a variety of objects:
Worlds are the source of wealth throughout the galaxy. Owned worlds generate Resource Units (RUs), which you'll use to design, build, and repair your fleet of starships. At the start of the game you control only one world, known as your homeworld. As you explore the galaxy your empire will discover and conquer other worlds.
Ships are the vessels that each empire builds as it explores the galaxy and expands its empire. Ships come in a variety of configurations, but serve two main purposes;
See the section on Ships for more details about them.
Scattered throughout the galaxy are a series of space-time anomalies called wormnets. A wormnet is a set of two or more interconnected portals through which your ships can travel to distant portions of the galaxy in a single turn. Travel through a portal is possible through the use of a wormnet drive installed on every spacecraft. If a ship enters a sector containing a portal it can activate its wormnet drive and traverse the portal to one of its possible exits.
Until one of your ships travels through a particular portal, your empire knows nothing about its behavior, and your exit from the portal will be determined randomly. Once your ship has traveled through the portal your empire will acquire the navigation data for that portal, which gives you detailed information that allows non-random travel thereafter. Navigation data may be shared between empires. The prudent wormnet traveler should be aware of some interesting portal characteristics:
Only through diligent exploration and sharing of information will you learn the details of the galaxy's wormnets.
Nebulae are great clouds of interstellar dust that interfere with ship scanners. Ships cannot gather LRS data for items within a nearby nebula scanner, although the nebulae themselves do show up on LRS; only by entering the nebula sector will its contents be revealed on SRS. Nebulae thus make an effective place to hide from enemies. A ship occupying a nebula sector has an effective LRS radius of zero, regardless of that ship's actual scan rating, so the nebula confers some degree of blindness along with the cover it provides. Note that nebulae do not block your long-range scanners' ability to see sectors beyond them; they obscure only the nebulae sectors themselves. That is, a nebula one sector away from your ship will not prevent it from scanning a regular sector on the other side of the nebula (i.e., two sectors away from the ship).
It is entirely possible that nebulae can hide worlds and wormnet portals. Once a nebula sector has been explored, any worlds or portals discovered therein will be known to you, but since there is no way to scan into nebulae sectors from afar, your scan data of those worlds or portals will immediately become obsolete as soon as your ships leave the nebula sector.
Like wormnet portals, nebulae can drift from sector to sector, either randomly or according to a pattern. Two nebulae may drift into the same sector for a turn and then part ways the following turn; no additional effect occurs when two nebulae overlap in such a manner.
Ion storms wreak havoc on all ship systems, causing damage to ships just as if they had been hit by enemy fire. The stronger the storm, the more damage a ship will suffer while it remains within that sector. Each ion storm is rated with a number that indicates the amount of damage per turn that all ships in that sector will suffer. Note that there is no upper limit on this rating, and even the heartiest ship may find itself amid a storm that can destroy it in one turn. In addition to inflicting damage ion storms act as nebulae for purposes of interfering with ship scanners.
Like nebulae and wormnet portals, ion storms drift throughout the galaxy, either at random or according to deterministic patterns. Two storms that drift into the same sector add their storm ratings together for purposes of applying damage to ships within the overlapping storms.
Finally, ion storms can fluctuate in strength from turn to turn, yielding a corresponding change in the amount of damage they inflict. Like drift patterns, storms fluctuate either either randomly or according to a set pattern. Thus what may look like a small storm from afar can grow into an inferno by the time your ship arrives.
Your empire's map is a representation of the galactic sectors that your empire can currently or has ever scanned. All explored sectors are included in your map, whether they are visible (currently occupied by one of your ships or worlds), scanned (within scan range of, but not visible to, any of your ships), or stale (once scanned or visible, but not currently so). A sector for which you have no information other than its coordinates has unknown status.
The sectors on your map are labels using the oblique coordinate system, wherein each ector is identified by a pair of numbers written as (oblique, y). The oblique coordinate identifies a sector's position diagonally "northwest" or "southeast" of the origin, while a sector's y coordinate identifies its position "north" or "south" of the origin. In a typical Star Empires session your empire's homeworld is at the center of your map, sector (0,0). It's up to you to figure out where your empire is relative to the others. Each galactic empire defines its own coordinate system, so "north" to your empire, may be "southwest" to another.
Your empire's map contains a variety of information about your empire:
Your empire must design and build star ships to move around the galaxy and conquer worlds. Most ships are conquering ships, meaning that they are able to maintain possession of an unowned world. Other ships (such as missiles) are not conquering ships and can only be used in tandem with conquering ships.
All ships have a rating for each of five components:
These five components taken together define a ship class. For example, you might design a "frigate" class that has 20 guns, 15 DP, 4 engines, 1 scan, and 0 racks. The following additional ship stats are computed automatically for each ship based on its components:
As a ship incurs damage, its guns, engines, and scan ratings are multiplied by its OR and rounded to the nearest integer (possibly zero). Until a ship is repaired, it operates at this reduced efficiency.
Every ship is constructed from one of a set of basic hull types. A hull type represents a broad classification of ships that perform similar functions, for example, scouts or transports. Each basic hull type determines both the initial rating of each ship component and how expensive it is to customize a ship with additional components. In general, you can add as many components to a basic hull type as you can afford, although some hull types limit the number of certain components.
Capital ships are large ships with heavy firepower and defenses. They can carry an impressive number of guns and DP, but it is relatively expensive to add engines, scanners, and racks to a capital ship.
Basic configuration:
Additional component cost:
Additional component tonnage:
Gunships are the smaller complement to capital ships. They carry a large number of guns, but trade defenses for engines in order to be first on the scene. They have relatively few scanners or racks.
Basic configuration:
Additional component cost:
Additional component tonnage:
A missile is a special type of one-shot ship that is loaded onto a carrier's rack and then fired at a target. Missiles are destroyed when they are fired in this manner. Missiles have no engines, scan, or racks ratings, and all missiles have one DP. Only the guns component is configurable. Unlike other hull types, a missile's tonnage is a configurable parameter, which allows you to determine how big a missile class is (and therefore how many racks an instance of that missile class will require).
New missile classes are exempt from the one-time design fee.
Basic configuration:
Guns: 8
Tonnage: 1
Cost: 1
Additional component cost: exp(guns/(13 + (5 * tonnage)))
An orbital is a large, immobile ship, typically with heavy DP, a fair number of guns, scanners, or racks, and no engines at all. Orbitals are used for defending owned worlds and confer some special benefits to friendly ships at those worlds.
A starbase is a special type of orbital that each empire possesses at its homeworld at the start of the game. In addition to the standard orbital benefits, starbases provide these additional benefits:
Basic configuration:
Additional component cost:
Additional component tonnage:
A transport is used to carry several smaller ships. It has plenty of rack space and engines, a moderate number of DP, and relatively few guns or scanner. Note that the generic term carrier refers to any ship that contains cargo but a transport refers to a specific ship type.
Basic configuration:
Additional component cost:
Additional component tonnage:
Scouts are fast ships designed to collect a large amount of scan data. Its light structure limits the amount of components that can be added to it.
Basic configuration:
Additional component cost:
Additional component tonnage:
A wing is a cheap, immobile ship that must be transported to its destination. Attack wings favor more guns, while defensive wings favor more DP. Wings have no engines, scanners, or racks.
Wings (and only wings) can be used to form a defensive screen around larger ships.
Basic configuration:
Additional component cost:
Additional component tonnage:
You can customize each of the categories above (except devices) to create unique ship classes. Your empire's ship classes will not be known to other empires unless you give the design to them, or they salvage the design from one of your destroyed ships. When you first encounter a foreign ship of an unknown class, you will be able to tell only that ship's class name, tonnage, and operational rating. All other characteristics will remain to be discovered.
At the start of the game your empire knows the basic designs for each ship category, all devices, and the starbase class of orbitals:
| Name | Guns | DP | Engines | Scan | Racks | Tonnage | AR | Cost |
| starbase | 150 | 200 | 0 | 2 | 8 | 999 | 20 | n/a |
There are three ways that you can add new classes to your list of known ships:
ship of that class (rounded up). Missiles are exempt from this one-time design fee. See the Create New Ship Design phase.
You can build a ship on the same turn during which you research, salvage, or receive that ship's class design. New ships can only be constructed at worlds which you or your allies own, and the necessary RUs must be present on the worlds where you plan to build. One of the dangers of interstellar combat is that an enemy can take possession of your worlds that are slated to build new ships; in this case, the pending build orders become void.
Every ship has a unique serial number (SN), which is a case-sensitive seven-character identifier of the form XXabcde, where XX is a two-letter code uniquely identifying the owning empire, and abcde is a random and unique five-character string of hexadecimal digits. The game server will automatically determine your empire's two-letter code based on its name, ensuring that all empire codes in the same game are unique. For example, a ship owned by The_Culture might have the serial number TC5f09d.
For convenience you may give your ships unique names, and you may refer to any ship by its handle, i.e., either its SN or its name. Since two empires could have ships with the same name, referring to other empires' ships when submitting orders to the game server is a bit problematic. The server will try to accommodate, and if it does not detect any ambiguousness in ship names within a given sector, the enemy's own name for the ship can be used. Otherwise, the SN must be used to identify the ship you want to reference.
The transponder on each ship transmits its current location to the owning empire. These transponders can also be set to transmit ships' locations to other empires. Normally you can register a foreign ship on LRS only as unidentified tonnage. If the foreign ship's transponder is transmitting on your empire's frequency, you will be able to discern the ship's owner and class. If you have an official alliance with another empire, all of your ships' transponders will always identify themselves to your ally, and vice versa.
Devices are special ships that are deployed in a specific sector to produce a given effect. All empires start the game with the necessary technical details for constructing these devices, and are limited only by their cost. All devices have a one DP.
Some devices are single-use items, which produce their effect only for the turn on which they are deployed. Single-use devices are automatically destroyed when they are deployed. Other devices are persistent, and their effect is ongoing so long as the device is not destroyed. Persistent devices can be loaded (at which point they become inactive) and redeployed elsewhere.
The following devices are available to all empires:
A device deployed in the same sector as an operational starbase (friendly or otherwise) will not function. A persistent device deployed in the same sector as a starbase is simply unloaded and not deployed (and can be loaded and redeployed later). A one-shot device deployed in the same sector as a starbase is unloaded and destroyed without being activated.
Star Empires is, at its core, a game of interstellar diplomacy. At first you will be alone in space, but as you explore you soon will encounter your nearest neighbors and potential opponents. Whether you attack immediately or forge a strong alliance is, of course, your choice. A neighboring emperor with a vast armada of cruisers and destroyers is certainly cause for concern -- unless he thinks your armada is bigger than his, or -- even better -- if he's on your side. Deception, compromise, disinformation, intel sharing, backstabbing, and coordinated planning require constant communication with the other empires of the galaxy.
Make good use of your empire's lines of communication. Talk frequently with your allies lest they begin to mistrust you -- at least until you are ready to betray them. Talk also with your enemies, for you may learn useful information from them, or even settle your differences and become allies. Even an empire whose power is fading can be a thorn in the side of the dominant empire if you lend a helping hand, and several small empires acting in concert can swiftly dismantle a single larger opponent who suddenly finds himself fighting on several fronts at once. Remember also that you can send messages anonymously. A well-placed anonymous word can make all the difference when it comes to cementing your plans.
Making a deal with a friendly neighbor is useful, but there are greater benefits in forging a full alliance with another empire. You may declare an official alliance with at most two other empires. You may not ally with a third empire until you break one of your existing alliances. Alliances require a formal declaration of such from both parties, so if one empire fails to declare themselves allied, or if one empire unilaterally breaks an alliance, the other empire will be aware of the situation immediately.
Allied empires receive the following benefits:
Note that your allies have access to a great deal of information about your empire's map, ship, and scan data, so think twice about forging an alliance with an empire that you do not fully trust. Some game scenarios require an alliance as a victory condition.
The events of each game turn occur in a series of phases. You submit a complete set of your empire's orders for all phases of the turn. When the turn deadline arrives (or sooner if the GM has received orders from all empires) all orders for all empires are processed simultaneously, one phase at a time.
Updates are run at regular intervals with enough time in between to allow for negotiations, strategy, and submission of orders. Typically this is once per week.
The game server maintains a dedication rating (DR) for each player (not empire). Your DR increases by one if you have submitted your orders before the turn's deadline. If you miss a turn's deadline, you will lose three DR. This has no direct impact on the game, but every player's DR is maintained on the game server and can affect whether or not you are invited to join future games. If you think you're going to miss a deadline, please let your game master know, rather than let your DR slip. If a player missed a turn deadline without letting the GM know, the GM has the option to declare that player's empire abandoned. See the section about Abandoned Empires.
While the turn update is in progress, the game server will not accept any orders for or allowed communication among empires. Once the update is complete, players will be notified and may access their updated empire information.
During the Diplomacy phase alliances are officially established or broken.
During this phase you can formally break an established alliance. Either member can break an alliance unilaterally, but the other member is always notified at this point that the alliance has been broken.
During this phase alliances are officially established. In order to establish an alliance both empires must formally declare the other empire as an ally. If only one empire makes such a declaration without a corresponding declaration from the other empire, the alliance is not established. Alliances remain in places until one empire breaks the alliance or until one of the empires is officially eliminated.
You can maintain alliances with one or two other empires. In order to ally with a third empire, you must first break an existing alliance.
It is important to note that you can ally with two empires who are not allied with (and who may, in fact, hostile to) one another.
During the logistics phase, you can prepare your fleet for the coming turn's actions.
At this point you can unload any loaded ships from their carriers. An unloaded ship winds up in the same sector as its carrier. If the cargo and carrier ships belong to different empires, then either party may unilaterally unload the cargo.
If you have issued a fire order for a loaded missile or deploy order for a loaded device, it will automatically be unloaded during this phase in preparation for use.
Abandoned Empires: Any loaded conquering ships will be unloaded at friendly or allied worlds, or at worlds where they will be used in combat (see below). Loaded missiles will be unloaded if they are to be used in combat at foreign worlds; otherwise, they will remain loaded.
During this phase you can deploy any unloaded devices in the sectors that they occupy. When a device is deployed, it is considered to be activated even if its effect is not registered until a later phase, and any empire in the same sector will register that activation on short-range scanners. Empires in nearby sectors will not be able to see the device deployment directly, but they may be able to infer its use from its effects. One-shot devices are destroyed immediately when they are deployed. Persistent devices remain active until they are destroyed or loaded.
A device deployed in the same sector as an operational starbase (friendly or otherwise) will not function. A persistent device deployed in the same sector as a starbase is simply unloaded and not deployed (and can be loaded and redeployed later). A one-shot device deployed in the same sector as a starbase is unloaded and destroyed without being activated.
During this phase you can load your ships onto your carriers. The ships to be loaded must be in the same sector as the intended carrier, which must have sufficient free rack space to hold the cargo ships. Loaded ships cannot move under their own power, scan surrounding space, or attack other ships, with one exception: a missile can be fired only if it has been loaded onto a friendly carrier. (See the Fire Guns phase for details.)
You can never load your ships onto a foreign carrier unless it is owned by one of your formal allies. Both carrier and cargo empires must issue identical load orders; otherwise, the load action will fail. If multiple allied empires are attempting to load cargo onto the same carrier, the carrier owner decides the order in which rack space is allocated.
If a carrier ship is destroyed all cargo ships loaded onto that carrier are also destroyed, regardless of DP. If a loaded ship is self-destructed, it immediately destroys its carrier and any other cargo ships loaded onto that carrier.
Note that nested loads are prohibited, i.e., you cannot load cargo onto a carrier which is itself loaded onto a third ship.
Allies: Allied ships are the only foreign cargo that can be loaded.
Abandoned Empires: Abandoned missiles will be loaded onto any available friendly racks, starting with the missile having the most guns and the carrier having the most free racks, operational rating, and tonnage (sorted in that order). Abandoned empires never submit load orders for allied ships.
The Astronomics phase is the point where all map adjustments are applied. There are no empire orders to process here.
During this phase the GM can remove any map objects (worlds, portals, nebulae, storms, ships) as part of a particular game scenario.
During this phase the GM can move any map objects (worlds, portals, nebulae, storms, ships) as part of a particular game scenario.
During this phase the GM can add any map objects (worlds, portals, nebulae, storms, ships) as part of a particular game scenario. New ship classes can be added during this phase, as well.
During this phase the GM can make modifications to existing map objects (e.g., change world production values or ion storm ratings) as part of a particular game scenario.
At this point any drifting map objects (worlds, portals, nebulae, or ion storms) move to their next location. Drifting objects can move according to a fixed pattern that repeats once the object has reached the end of the pattern, or randomly into any adjacent sector.
Map objects continue to drift even if they are temporarily inactive (for example, due to the effects of a device).
During this phase the GM can remove knowledge of worlds, portals, ship classes, or foreign empires from any empire. The affected empire will no longer be able to establish lanes to the forgotten worlds, name the forgotten portals as wormnet exit points, build ships of forgotten ship classes, or send messages to forgotten foreign empires. Of course, the affected empire can regain the knowledge of any item through normal game play.
During this phase the GM can make map objects (portals or worlds), ship classes, or foreign empires known to any empire in the game. Map objects become known to an empire just as if the empire had scanned the object. Ship classes become known as if they were given to the recipient empire. Foreign empires become known as if the recipient empire were in message contact with them.
At this point any previously collapsed wormnet portals reform and function normally. Any warpdrone devices deployed on this turn will generate new portals during this phase. The new portal remains activate until the warpdrone is destroyed. Note that an operational starbase in the same sector as a deployed warpdrone device will prevent it from being activated.
At this point any collapsing wormnet portals are disabled, preventing travel through them. This includes any portals that are affected by portal hammers and any portals that drift into a sector occupied by a world or another portal. A portal can collapse even if it has just stabilized on the same turn. This can happen, for example, if a portal drifts out of a sector containing one world and into a sector containing a different world.
Portals associated with warpdrone devices can collapse (and later stabilize) according to the same rules that govern non-warpdrone portals, but note that such portals are immediately destroyed whenever the corresponding warpdrone device is destroyed.
During this phase any pocket nebulae whose corresponding devices have been destroyed are removed.
At this point any pocket nebula device that was deployed this turn generates a new nebula in its sector. The new nebula remains in place until the device is destroyed (or loaded). Note that an operational starbase in the same sector prevents activation of such devices.
During this phase any ion storms created by ion generator devices are removed if those devices are no longer operational.
At this point all ion storm ratings are updated based on the fluctuation pattern of each individual storm (if any). Storm ratings can fluctuate according to cyclic patterns, or randomly up to the initial rating of the storm. A storm that fluctuations to strength zero is not destroyed; it merely remains dormant until it later fluctuates above a zero rating.
Any ion generator devices deployed on this turn generate new ion storms at this point. A storm generated by an ion generator device has a rating of seven. The new storm remains in place until the ion generator device is destroyed (or loaded). Note that the presence of an operational starbase in the same sector will prevent activation of an ion generator device.
All ship-to-ship combat occurs simultaneously during this phase.
During this phase, you may destroy any of your own ships. A self-destructed ship is immediately destroyed, and cannot fire any guns that turn, although it can be the target of enemy fire (since all combat happens simultaneously). Any cargo ships loaded onto the destroyed ship are also destroyed; further, self-destructing a ship which is loaded or boarded onto a carrier ship causes that carrier (and any other cargo) to be destroyed, as well.
A ship which is self-destructed cannot be salvaged by other empires. Additionally, for every five tonnes (or fraction thereof) massed by the destroyed ships and cargo, every other unloaded ship in the same sector receives one DP of collateral damage (i.e., self-destruction of less than five tonnes worth of ships will cause one DP of collateral damage to other ships in the same sector, self-destructiong six to ten tonnes will cause two DP of collateral damage, and so on). All self-destructed tonnage in a sector is totaled together, regardless of owner, in order to compute the collateral damage to other ships in the sector. A loaded or boarded ship does not receive collateral damage, but it will be destroyed if its carrier is destroyed due to collateral damage.
Note that only ships that are explicitly self-destructed are exempt from salvage; any ship destroyed by collateral damage can be salvaged.
You cannot self-destruct your starbase, nor can your starbase be destroyed as the result of self-destructed cargo; however, a starbase will be damaged normally by collateral damage inflicted by other self-destructing ships.
Allies: You cannot destruct a ship if it is loaded onto an allied carrier, has loaded allied cargo, or shares a friendly carrier with allied cargo.
Abandoned Empires: Abandoned non-missiles will be self-destructed at foreign worlds if it appears that there are enough foreign guns present to destroy those ships, and if it appears that the abandoned ships will not also be able to destroy all of the foreign ships. If it appears that there are enough foreign guns present to destroy only some of the abandoned ships, then only those that would be destroyed by the foreign guns (ordering the abandoned ships by the criteria in the Fire Guns phase) will be self-destructed. The remainder will be moved out-sector.
At this point you can instruct your wings to form defensive screens around friendly larger ships in preparation for combat. Wings that make up defensive screens will automatically receive damage from any attacking guns aimed at the defended ships. If the defending wings are destroyed, any remaining attacking guns will strike their original targets as intended.
The defending wings will be activated to interpose themselves between attacker and target in the order that you specify. Note that only wings can form defensive screens, and they can screen only friendly capital ships, gunships, orbitals, and transports. Scouts, missiles, devices, other wings, and foreign ships cannot be so defended. A wing can be ordered to defend only a single target per turn.
As a convenience, if a loaded wing is ordered to defend a larger ship, it will automatically be unloaded.
Allies: Allied empires can form defensive screens to defend one another's capital ships.
During this phase any attacking ships will fire their guns and missiles at targets in the same sector. Each gun fired always hits its target and inflicts one DP of damage. A ship may fire any, all, or none of its guns in the same turn against one or more targets in the same sector, but a ship may not move and commit guns to an attack on the same turn.
Your battle computers provide you with two ways to target enemy ships: automatic and manual. Automatic targeting is most useful when you have sufficient firepower to destroy all enemy ships in a sector and do not want to be bothered with tactical combat details. Manual targeting is used when you wish to assign your attackers' guns and missiles to enemy ships in a specific manner. Each mechanism is described below.
Automatic Targeting
Most of the time automatic targeting will be sufficient to carry out your attack plans. You simply identify that attacking ships and the targeted empires. Your battle computers will automatically coordinate your attackers against all ships belonging to the targeted empire according to following criteria:
Attackers are activated in the following order:
You battle computers will use your attackers' guns and missiles in an efficient manner to destroy the targets. That is, missiles will be fired only as needed if your attackers do not possess sufficient guns to destroy all targets. If a target ship is of an unknown foreign design, your battle computers will not know how many guns are needed to destroy that ship before the battle commences, and you will not know until the battle is over if you committed (or even possessed) enough guns to destroy it.
Manual Targeting
In some cases it is desirable to override your battle computers and specify exactly how you would like combat to occur. Manual targeting allows you to do this, but requires more detailed planning on your part. In order to use manual targeting you must explicitly identify the order in which enemy ships are to be attacked and how many guns each attacker will bring to bear against those targets. This allows you to target enemies in any order that you like, but, unlike automatic targeting, your attackers will not use use their guns as a single efficient group. A poorly planned manual attack can waste guns on an enemy that is already targeted.
Attacking Defensive Screens
Any wings that have established defensive screens around larger ships will automatically absorb damage aimed at the screened ships. If the attacking ships possess sufficient guns to destroy the defending wings, then any excess guns will inflict damage on the original targets as intended. Since missiles impact only a single target, no excess damage carries over to a screened target if a missile destroys a defending wing.
Firing Missiles
When you fire a missile all of its guns are expended against a single target and the missile is destroyed. A missile must be unloaded from a carrier on the turn it is fired. You can explicitly unload a missile (during the Logistics phase) before you fire it, but if you fire a loaded missile the game server conveniently issues an automatic unload command for it during combat. If a missile is unloaded and not fired on that turn, it must be reloaded on a subsequent turn to be used (and it is also fair game for being attacked as unloaded cargo and for salvage purposes).
Note that firing a missile is not the same as firing its carrier's guns. That is, a loaded missile can be fired, leaving its carrier free to move to another sector in a "hit-and-run" attack. It is possible during the Logistics phase to unload one missile, load a second missile in the same rack space, and then fire both missiles during the Combat phase.
Allies: Allied empires may never fire guns or missiles at each other's ships. This includes wings forming a defensive screen, even if the screened target is not an allied ship. That is, if an ally is defending a non-allied target, no attacking guns will be fired.
Abandoned Empires: Abandoned ships will always fire at non-allied ships present at friendly or allied worlds, or at ships belonging to any empire which fired on the abandoned empire during the previous turn.
Abandoned ships present at foreign, non-allied worlds will fire guns if they expect to destroy all foreign ships present.
Abandoned ships between worlds will fire upon any empire targeted by either of the above two criteria.
If multiple empires are targeted in the same sector, the abandoned ships will first fire upon the empire having the fewest remaining DP (or tonnage if there's a tie).
All combat damage is applied simultaneously to all targeted ships at this point. A damaged ship has its operational rating reduced according to the damage it sustains. As a ship's OR decreases, that ship's guns, engines, and scan ratings all decrease accordingly, and the ship will be able to fire fewer guns, move fewer hexes, and scan fewer sectors until it is repaired. It is entirely possible for any or all of these ratings to be reduced to zero. A ship with a zero gun rating is no longer considered a conquering ship. A ship with a zero move rating is immobile. A ship with a zero scan rating has only SRS ability and cannot scan beyond the sector it occupies.
At this point any ship which has self-destructed or which has received damage equal to or greater than its remaining DP is now eliminated from its owner's fleet. Any ship loaded onto a destroyed ship is also destroyed (and may be fair game for salvage).
During this phase each damaged ship repairs some of its damage, increasing its DP by its auto-repair (AR) rating. These repairs happen automatically and cost no RU. A ship's operational rating (OR) is correspondingly increased by these auto-repairs. A ship can never be auto-repaired above its original DP value.
Note that auto-repairs are always visible to any empire which has an unloaded ship in the same sector.
At this point all conquering ships in any world's sector are used to determine that world's owner as follows:
Note that you must leave conquering ships in orbit around a world after you take control of it; otherwise, it becomes unowned. Any RUs stockpiled at an unowned world will remain at that world until a new owner takes possession of them, but production of new RUs never occurs on unowned worlds.
If the current owner loses ownership of a world, all existing shipping lanes to and from that world are cancelled immediately.
All ship movement, including travel through wormnet portals, occurs simultaneously during this phase.
During this phase you can share wormnet portal navigation data with other empires. You can give portal navigation data to any foreign empire with whom you are in message contact. The navigation data given is the same as that acquired by actually traversing the portal, i.e., it allows safe navigation through that wormnet to that portal.
When you receive nav data for a new portal you will automatically be able to tell if that portal is (or is not) connected to any other portals for which you have nav data. Receiving nav data does not reveal any portals in the same wormnet that are as-yet unknown to you.
You can give data only about portals which you have traversed or for which nav data has been given to you on previous turns, and the recipient can make use of the given portal nav data on the same turn it is received. The location of the given portal will appear on the recipient's map using their local coordinate system. It is not necessary for the recipient to have scanned that portal's sector, but the recipient will not know what else occupies that portal's sector until they scan it normally.
Allies: Allied empires always share all wormnet portal data with each other automatically.
During this phase any ships that you have instructed to move will jump to their destination sector if their operational rating permits such travel. A ship's engine rating determines the maximum number of sectors (hexes) that a ship can move in one turn. Ships jump straight to the destination sector without traversing the intervening sectors, so no scan information is generated for those intervening sectors. There is no stacking limit to sectors; any number of ships from any number of empires can occupy a given sector.
A ship damaged in combat may not have sufficient operational engines to move to the specified destination, in which case the damaged ship will not move at all, so be careful when planning movement for a ship under attack. A ship cannot move and fire in the same turn.
You can specify movement orders for individual ships or for groups of ships in the same sector. Individual movement orders are useful in a combat zone when you want to move each ship to a different destination. Group movement is useful when you want to move some group of the ships in the same sector to the same destination. If a ship is damaged before moving, it's possible that it will not possess enough operational engines to reach the designated group destination. In this case, the damaged ship will be dropped automatically from the group and will not move; the remainder of the group will move normally.
Abandoned Empires: Abandoned ships which are present at foreign worlds (and which are not ordered to self-destruct or fire) will move along the shortest routes (including wormnets) toward the nearest friendly or allied world (choosing the world with the highest friendly-DP-to-foreign-guns ratio in case of a tie). Abandoned ships between worlds will hold their positions for the first turn of abandonment, but will move on subsequent turns toward the nearest friendly world. An abandoned ship with a scan rating of three or more will be deemed a scout/scanner, and will always hold its position between worlds.
If a ship ends its move in a sector that contains a wormnet portal and has at least one operational engine, then it may traverse the portal as part of its movement. You may specify an exit portal, but unless you have acquired navigation data about both the entry and exit portals, your exit portal will be determined randomly. You can specify an exit portal for which you expect to receive navigation data from another empire on the same turn, but if the donor empire fails to provide you with this information, your exit portal will be selected randomly.
Once you have traversed a wormnet, you will receive navigation data for both the entry and exit portals of your journey. You may then navigate safely between those portals without error. You will not know if there are other portals connected to that same wormnet unless you continue to explore random exits, or until another empire gives you the navigation data for those other portals.
If a wormnet portal drifts to a different sector during the Astronomics phase any planned entry from its previous sector will fail, and any exits from that portal will end up in the new sector. If a wormnet portal collapses altogether, all movement into or out of it is cancelled.
Allies: A temporary portal created by a warpdrone device is normally accessible only by the empire that owns the warpdrone. Allied empires can traverse each other's warpdrone portals.
At this point your empire acquires updated nav data for any new wormnet portals traversed this turn.
Any ship that ends its movement in a sector containing an ion storm suffers damage equal to the storm's rating. This damage is equivalent to attack damage from enemy ships, and can reduces a ship's OR, prevents doubled auto-repair, or destroy it in the same fashion. If there are multiple ion storms present in the same sector, any ship in that sector suffers damage equal to the sum of all the storms' ratings.
Any deployed storm shield device will negate all ion storm damage to all friendly ships in that sector for one turn. Starbases confer the same protection from ion storms to friendly ships in the same sector in the same manner.
Allies: Any starbase or deployed storm shield automatically confers its ion storm protection to all allied ships in the same sector.
At this point any ship which has received damage from ion storms equal to or greater than its remaining DP is now eliminated from its owner's fleet. Any ship loaded onto a destroyed ship is also destroyed (and may be fair game for salvage).
At this point, world ownership is determined again, using the same procedure as described in the Determine Ownership I phase. The two separate ownership phases allow an attacker to take possession of a world after combat is resolved before the defender's reinforcements arrive during the Movement phase.
Every empire must maintain a single homeworld if it possesses any worlds at all. An empire's homeworld receives the following benefits:
If an empire's existing homeworld is conquered, its homeworld is automatically relocated at this point to the next safest world, as follows:
Homeworld relocation ignores blockade and interdiction rules. Additionally, the newly selected homeworld will have its production doubled for the current turn.
If the conquering guns present at any world are strictly more than three times the DP of the conquering ships belonging to the world's owner, then that world is said to be interdicted. No designs, builds, or repairs can take place at an interdicted world, nor can any RUs be shipped offworld (as per blockades). This interdiction remains in place from turn to turn until the above condition is no longer true.
Note that it is the total number of foreign guns, regardless of owner, which determines the interdiction; thus, it is possible for multiple empires to interdict a world (possibly by accident) that none of them could interdict alone. Missiles and devices are not included (by either side) for purposes of determining interdiction.
An empire's homeworld cannot be interdicted (although it can be blockaded).
Allies: Allied ships count as friendly DP, not as foreign guns, for purposes of establishing interdictions. Note that an interdiction affects all allied stockpiles on a world, as well as the owning empire's stockpile.
If the foreign conquering guns present at any world are strictly more than twice the DP of the conquering ships belonging to the world's owner, then that world is said to be blockaded. No RUs can be shipped offworld from any blockaded world; this restriction remains in place from turn to turn until the above condition is no longer true. A world that is interdicted is also blockaded, but the reverse is not necessarily true.
Note that it is the total number of foreign guns, regardless of owner, which determines the blockade; thus, it is possible for multiple empires to blockade a world (possibly by accident) that none of them could blockade alone. Missiles are not included (by either side) for purposes of determining blockades.
Allies: Allied ships count as friendly DP, not foreign guns, for purposes of determining blockades. Note that a blockade affects all allied stockpiles at a world, as well as the owning empire's stockpile.
During the Research phase, new ship classes can be salvaged and designed, and designs for ship classes can be given to other empires.
At this point you can attempt to salvage the design of any ship that has been destroyed on this turn in the same sector as one of your ships. You will salvage a destroyed ship's design automatically if all of the following conditions are true in the same sector:
Each destroyed ship is evaluated using these rules, and if they are all true, then the destroyed ship's design is added to the salvaging empire's list of known ship classes for their future use; otherwise no salvage can take place for that particular ship. Only one empire may be the salvaging empire in a given sector, although it need not be the empire that destroyed the salvaged ship; in the case of a tie, no salvage takes place in that sector. If the salvaging empire already owns the salvaged design, then no other empire receives that design on that salvage attempt. Note that any cargo loaded on a destroyed ship is also fair game for salvage (again, unless it was explicitly self-destructed).
Allies: Allies always cooperate in salvage operations. Allied empires combine their guns as a single friendly unit for purposes of determining salvage rights of foreign ships, and combine their remaining DP to prevent any foreign empire from salvaging an allied ship design. If a member of an alliance salvages a design, then all empires in the alliance automatically receive the design, even if they were not present in the salvaging sector.
During this phase you can create new ship designs. Designing new ships requires prototyping and testing by your empire, so the cost of the design is half the cost of the ship itself (rounded up). This is a one-time research fee that will be deducted from the RU stockpile at whichever world you specify. New missile designs do not require the one-time design fee. See the Ship Design page for more details.
Once you have paid the design fee, you can build new ships of that type starting on the same turn. The new ship design can also be given to another empire on the same turn that it is created. You cannot design a new ship class on a world during the same turn that you take control of it, nor can you design on a world that is interdicted.
During this phase you can share your known ship designs (either those you created or those salvaged from other ships) with any other empire with whom you are in message contact. The recipient(s) will receive the designs immediately and will be able to build ships of those classes on the same turn.
Allies: Alled empires always share any designs salvaged on this turn. New ship designs created by your empire are not shared with your allies automatically; you must share them explicitly.
During this phase you can establish shipping lanes in order to move resource units from one world to another.
During this phase each owned world's RU stockpile is increased by the production rating of that world. Production does not take place on unowned worlds. Interdictions and blockades do not affect production. There is no limit to the amount of RUs that can accumulate on an owned world.
If an empire has relocated its homeworld to a new location this turn, that world doubles its production for this turn.
At this point you can pool any or all of your stockpiled RUs to a world that you own. This is a convenient way to gather all of your RUs in one place and then disburse them as you see fit. RUs at blockaded worlds cannot be shipped off-world for pooling purposes, but RUs can be pooled to a blockaded world.
Allies: Allied empires can pool RUs to either other's worlds. If you pool your RUs to an ally's world, your RUs will be maintained as a separate stockpile at that world for as long as the alliance lasts. If the alliance is later broken, the world's owner immediately takes possession of any non-allied RUs stockpiled there. Similarly, if the owning empire loses control of that world, the new owner will take control of all separate stockpiles, unless the new owner is also an ally of the stockpile's owner
Abandoned Empires: Abandoned empires pool RUs at the owned world with the highest friendly-DP-to-foreign-gun ratio.
During this phase you can transfer RUs from your worlds' stockpiles to other worlds in the galaxy. RUs can be distributed from their origin point to one or many destination worlds. For example, if you own a world that has 12 RUs stockpiled, you can transfer six RUs to destination A, four RUs to destination B, and leave the remaining two RUs at the origin world. RUs can be transferred off-world during the same turn that you take possession of the world, so you can set up a tentative order to transfer RUs from a world that you plan to acquire in the coming turn.
If you are the owner of both the origin and destination worlds involved in the shipment you need only specify the number of RUs you wish to transfer. If you wish to send RUs to a foreign empire, you must also indicate the intended recipient empire, as well as the destination world, since that empire might not own the world at the time the shipment occurs. If the intended recipient does not own the destination world, the transfer order will be cancelled. You must be in message contact with the recipient empire at the time your transfer order is submitted and the destination world must be known to you (though not necessarily current scanned). The recipient will know that your RUs have been delivered, but will not know which of your worlds supplied the RUs.
RU transfers are executed in the order that you define them. If a world's stockpile does not have sufficient RUs remaining to match a given transfer order, the remaining RUs in the stockpile will be sent for that order, and all subsequent transfer orders for that stockpile will be cancelled.
If a world is blockaded, no RUs can be transferred off-world from it, but note that a blockaded world can still receive RUs transferred to it. Any unsent RUs remain stockpiled, without spoilage, and carry over to the next turn.
Allies: Allied empires can transfer RUs to each other's worlds, can maintain these RUs as separate stockpiles owned by each ally, and can transfer RUs from those allied stockpiles as if they were at friendly worlds. If you transfer RUs to an ally's world, they will automatically be stored in your separate stockpile unless you explicitly identify the allied empire as the recipient (in which case they will be added to the ally's stockpile just like a regular transfer to a foreign empire). If your ally does not own the destination world during this phase, the transfer will be cancelled altogether.
Note that if an alliance is ever broken, the world's owner will take possession of any non-allied RUs stockpiled there. Similarly, if the allied empire loses control of that world, the new owner will take control of all separate stockpiles, unless the new owner is also an ally of the stockpile's owner
Individual ships are maintained during this phase. New ships can be built and existing ships can be repaired or renamed. Transponder settings are also established during this phase.
During this phase you can build new ships for your fleet. You can build ships only in sectors containing a world owned by you (or one of your allies), and the requisite number of RU must be present at that world. If you (or your ally) lose ownership of a world before this phase, or if you fail to stockpile the necessary RUs, the build instruction will be cancelled. You cannot build ships on a world during the same turn that you take control of it, nor can you build on a world that is interdicted.
Unique serial numbers are assigned automatically to each ship built. You may give a name to each ship you build, although those names must be unique for each ship in your empire. Ship names can be any combination of alphanumeric characters, but they must contain at least one non-numeric character.
Allies: Allied empires may build new ships at worlds owned by their allies, assuming they have created a sufficient RU stockpile of their own at the foreign world. See the Transfer Resource Units phase. If you build a ship on an allied world, that ally automatically acquires that ship's design (i.e., it's impossible to hide the details of a ship's construction at a world owned by someone else).
Abandoned Empires: Abandoned empires always build on any world where there are stockpiled RUs. New ships to be built will alternate between the class which has the most DP that can be afforded and the most guns that can be afforded (choosing the cheapest design in the case of ties), until no RUs are left with which to build.
You can use the this phase to repair a damaged ship beyond what it can auto-repair on its own. You can repair two DP for each RU spent, but you can never repair a ship beyond its original DP rating. A repaired ship's operational rating is correspondingly increased by these repairs. You cannot repair ships that belong to another empire unless you are formally allied with that empire.
Damaged ships can be repaired in any sector, but you must specify which world will supply the RU for the repairs. You may schedule contingency repair orders for ships which you expect will be damaged during the upcoming turn, but if that ship is not damaged (or if it is destroyed) then no repairs will be performed, and the RU earmarked for those repairs will sit idle. A world cannot fund a repair operation on the same turn that you take possession of it. Note that repairs are always visible to any empire which has an unloaded ship in the same sector.
If a world is blockaded (but not interdicted), then ships belonging to that world's owner can still be repaired in that world's sector, but the RU on that world can be used to fund repairs only on that world. That is, since the blockade prevents RU from being shipped off-world, they cannot be used to fund repairs elsewhere; however, the lack of interdiction does not prohibit repairs at that world itself.
If a world is interdicted (and therefore also blockaded), then no ship belonging to that world's owner (or an ally) can be repaired in that world's sector (regardless of where the RU funds come from), and RU at that world cannot be used to fund repairs anywhere at all. That is, the interdiction prohibits that world's owner from conducting repairs at that world, and the implied blockade prohibits that world's RU from being shipped off-world for repairs.
You can repair a friendly or allied orbital at a ratio of three DP (instead of the normal two) for each RU spent. In additional orbitals automatically repair fully any friendly or allied ship loaded within it (regardless of any interdiction present in the same sector).
Note that the empires enforcing a blockade or interdiction can repair their ships at the site of the blockade or interdiction so long as the requisite RU are available from some other (unblockaded) world. Repairs can always be performed in empty space sectors that do not contain worlds, regardless of the empires present.
Allies: Allied empires can repair each other's ships for normal RU cost.
Abandoned Empire: Any RUs which cannot be spent on building new ships will be used to repair damaged ships, starting with the ship that has the smallest operational rating (or fewest remaining DP if there's a tie).
During this phase, you can rename any of your ships as you wish, so long as the new names follow the rules for naming ships when they are built.
During this phase you can toggle ship transponders from private mode to public mode, or vice versa. A ship with a private transponder is visible on LRS only to the empires that you choose. (See the Identify Ships phase.) A ship with a public transponder is always visible on LRS to all other empires, known or not. By default all ship transponders are set to private mode.
Allies: Allied empires always identify their ships to one another, regardless of their ships' transponder modes.
Abandoned Empires: Abandoned ships will always enable private transponder mode.
During this phase you can reset the private transponders for your ships so that they conceal themselves from any empires you choose. If you conceal a ship from an empire, that empire will see that ship on LRS only as unidentified tonnage (and will only be able to see its owner and class if it on SRS). A ship with a public transponder cannot be concealed from any other empire; you must first toggle that ship's transponder to private mode.
Allies: Allied empires can never conceal ships from one another.
Abandoned Empires: Abandoned ships will always be concealed from non-allied empires.
During this phase you can set the private transponders of your ships to identify themselves on LRS to any empires you choose. The selected empires will be able to see those ships' classes and your identity as their owner on their LRS. All other empires will see your ships only as unidentified tonnage on their LRS. Note that you cannot identify ships to individual empires if those ships transponders are in public mode; you must first switch their transponders to private mode.
A ship's transponder settings remain in effect until you alter those settings, either subsequent identifications or by concealing those ships from other empires. Note that loaded ships are never visible to foreign empires, regardless of their transponder settings.
Allies: Allied empires always identify all of their ships to one another.
During this phase all ships gather scan data for surrounding hexes, and this data can be shared with other empires.
At this point, you can instruct your ships to withhold any scan data they may have been sharing with other empires. The recipient empire(s) will no longer receive scan data from you from turn to turn.
Allies: allied empires never withhold scan data from one another.
Abandoned Empires: abandoned empires will withhold scan data from all non-allied empires.
During this phase you authorize other empires to access scan data that you collect later in the turn. This data access remains in place until you deny that same access in a future turn.
You can authorize a foreign empire to access your scan data at any of these levels:
Allies: Allied empires always authorize full access to all of each other's scan data.
At this point each ship collects short-range scan (SRS) data for the sector it occupies. Long-range scan (LRS) data is gathered by all ships for all sectors within range of their scan rating, as allowed by the the presence of any nearby nebulae and ion storms.
Destroyed ships (including missiles) generate only SRS info for the sector in which they were destroyed, and only through the Remove Destroyed Ships sub-phase of the Combat phase of the turn (i.e., a destroyed ship cannot scan ships which were moved into or built/repaired within the destroyed ship's sector since those actions occur after combat occurs). No LRS data is ever available from a destroyed ship, and, similarly, destroyed ships never appear on LRS for other ships. All destroyed ships in a sector, including cargo, will appear on the SRS of any empire that has a ship in that sector.
Loaded ships report neither SRS nor LRS information, nor do they appear on LRS. They appear on SRS only for the empires that control the cargo or carrier ships.
At this point any scan data that you have collected this turn is shared with any empires that have access to your empire's scan data. Shared data is merged with the recipient's map using the "most visible" status of each shared sector. For example, if a sector is visible to you, but has only scanned status on the recipient's map, then it will appear as visible to them; however, if the shared sector is stale on your map, it will still appear as scanned on the same recipient's map.
Only scan data that your ships collect directly will be shared with the authorized recipients, i.e., any data given to you by empire A will not be given to empire B.
Sharing scan data does not share ship designs, portal navigation data, or message contacts.
At this point any new map objects (worlds, portals, nebulae, or ion storms) that have been discovered by your empire are added to your map. Any known map objects whose sectors have become stale on your map are not forgotten, but you will not receive any current information for these objects.
An empire is considered homeless if it no longer has a homeworld. A homeless empire is automatically removed from any existing alliances. A homeless empire probably will have little direct effect on the game as it continues, but can still play a minor role, since homeless empires can share portal navigation data and ship designs as per usual. Homeless empires can continue to send messages to other empires with whom they were in message contact.
The GM need not wait on orders from an homeless empire in order to processes a turn's order if that turn's deadline has arrived.
Note that an homeless empire can still have conquering ships and could possibly retake control of a world. In this case, the empire would no longer be considered homeless.
If a player does not submit orders before the deadline, the GM may consider that empire abandoned and implement a set of default orders so that the game may proceed without the missing player (who will continue to lose dedication rating points until they return or a replacement is found). Default orders will be generated using the abandoned rules section under each phase, which assume a defensive posture in the hope that some player will assume control of the abandoned empire in the near future.
Star Empires was designed and coded by John Miller, but it owes a lot to several people.
The original game (SE 1) was crafted by Roger Lincoln, and first implemented among the folks at this site by Damian Hammontree (SE 2). Earl May was the mastermind behind SE 3-D (with help from John Miller, Bob Johnson, and Pete Meyers). John Miller wrote the SE 4 implementation, which ran for several years before the server folded. This version is SE 5.
The following folks helped design and playtest Star Empires over the years, and otherwise contributed good ideas, web assistance, moral support, and fun times:
Erich Cranor
Casey Dement
Dominic Esposito
Damian Hammontree
Bob Johnson
Greg Knussmann
Daniel Lesley
Earl May
Pete Meyers
Chris Patti
Chris Stanifer
Dan Sonnemann
Perry Wagle
Thanks, everyone!
It's been pointed out that Star Empires bears a striking similarity to a game called Galactic Conquest written by Adam L. Gruen in the late 1970s. Roger Lincoln claims that Adam's game was called actually Star Empires way back when and says, "Please give all due credit to Adam." Done!