0.4 Design Pad edit

From FreeOrionWiki

This page is a notepad/preliminary design document for the designers to prepare for 0.4, which deals primarily with space combat and ship design.

Contents 1 General Bullet Points 2 Weapon Types 3 Weapon Ranges 3.1 Reasons and Consequences 4 Ship Designs 4.1 Hulls 4.1.1 Size 4.2 Parts 4.3 Slots 4.4 Justification 5 Stealth and Detection 5.1 Basics 5.1.1 Within Battles 5.1.2 On the Galaxy map 5.2 General Principles 5.3 Mechanics 6 Planets in Combat 6.1 Orbitals 6.2 Shields 7 Consumables 7.1 Fleet Supply System 7.1.1 Mechanics 7.2 Fuel 7.2.1 Mechanics 7.3 Ammo 7.3.1 Mechanics 8 Building Ships 9 Shipyards 10 Ship Upgrades / Part Refinement 11 Ship Roles 12 Battle Balance Tactical Goals 13 Battle Map Layout 14 Pre-Battle Deployment 15 Exiting Battle 16 Combat Objectives 17 Battle Pace, Timing and Orders 18 Battle Math 18.1 Meters and Damage 18.2 Ship Design and Meters 18.3 Repair 18.4 Weapons 18.4.1 Damage and Launch Rate 18.4.2 Range and Targetting 19 Battle User Interface 20 Planet Resource Distribution 21 Health, Food Distribution and Population Growth 22 Planet Focus

General Bullet Points

• Combat will be rendered in 3D. Ships will be represented with 3D models. This does not imply movement in 3D space; it only refers to representation on screen.
• Combat occurs only inside star systems, and is a system-wide affair; all combat assets in a system will be present on the tactical map.
• FO is a turn-based 4X strategy game (primarily) with a RTS-TBS hybrid battle system (secondarily). The pseudo-real-time battles should complement the TBS strategy, and strategically interrelate with it as much as possible. Combat should be important, but other paths to victory should be just as viable. Other strategies than combat should prevail over combat in some cases, or work best in combination with combat.
• The player controls (at least) dozens of ships simultaneously. FO is not an arcade action space shooter where the player has control over a single, high customizable, fighter craft. The level of detail of the ships design system should reflect this distinction.
• The level or detail of player control of ships should minimize the need (or ability) to micromanage individual ships. Not requiring players to be concerned with single-ship facings or subsystem activation will eliminate a major potential source of the "clickfest" micromangement problem. Most interesting tactics can arise from the relative positions of groups of different kinds of ships, and do not depend on details such as the facing of an individual ship.
• Battles should not take excessively long to complete. A rough guesstimate is at most 5 or 10 minutes of combat (total) in one turn. Many turns may also have less combat than this, or none, likely depending on the degree of combat focus in a particular game.
• Strategic factors may exist in and out of battles that determine the value of a ship. A ship can be valuable to a player, even if it is not well-suited doing and receiving damage with other ships, if it has other advantages in or out of battles. These might include range or speed of movement on the galaxy map or in battle, undetectability on the map or in battle, or effects on other game systems such as empire or planet productivity.

Weapon Types

Combat balance is organized primarily around different types of weapon delivery systems: Point Defense (PD), Short Range (SR), Long Range (LR), and Fighters.

• SR is short range, direct-fire weaponry that is good against ships, but bad against fighters.
• PD is short range, direct-fire weaponry that is good against fighters and incoming LR, but bad against ships.
• LR is long range, indirect-fire weaponry that is good against ships, but bad against fighters.
• Fighters move independently at long range from the ship that launches them to attack ships or other fighters. Fighters are divided into Interceptors (good against other Fighters), and Bombers (good against Ships).

The details of ship design, such as how many types of weapons ships may have are undecided.

Weapon Ranges

The following are tentative and preliminary values, to be used for intial engine design and content creation, and are sure to need balancing and tweaking later:

• Ships move about 5 AU per combat turn
• Short Range (SR) ships can fire at targets within 5 AU
• Point Defence (PD) ships can shoot about 3 AU
• Fighters can shoot about 3 AU
• Long Range (LR) ships shoot about 15 AU

Reasons and Consequences

• SR ships can't shoot further than they can travel in one turn, giving a reasonable meaning for "short range".
• PD range should similar or smaller than SR range. This way, PD ships can't protect SR ships from LR missiles or fighters by sitting behind the SR. Rather, the PD has to be out front of its SR, giving the PD more time to shoot at LR missles as they go by (towards the SR). This leaves the PD vulnerable to attacking SR (since the friendly SR is behind the friendly PD).
• PD shouldn't have to chase after fighters due to its range being too small, and fighters shouldn't be able to fly around PD too easily, or else PD might be too difficult to use.
• Keeping fighter range and PD range roughly equal should ensure fighters can't shoot past PD to hit something behind the PD, but that fighters can get fairly close to the PD, and can shoot back at it without too much difficulty.
• LR range should be more than two turns travel (or twice SR range), but not much larger than this so that the LR needs to be kept within a reasonable distance of their targets to keep them vulnerable to counterattacks.

Ship Designs

Ship designs consist of a hull, and the parts placed in that hull's slots. Both the hull itself, and the parts placed in it may affect a ship's characteristics in-game.

Hulls

A hull is the base on which a ship is built. Engines are part of the hull and are not separately selectable, so hull definitions include engine-related properties.

• Each hull is visually distinct from other hulls.
• Hulls set base or default levels to various ship meters and/or non-metered ship properties. These may include:
  • Speed on galaxy map
  • Speed on battle map
  • Fuel capacity and regeneration rate
  • "Health" or "Structural Strength"
  • Stealthiness and penalties to stealth while moving

Size

• Hulls will be labelled with a "size" that is of some significance strategically or in balancing. Sizes are tenatively: Small, Medium, Large, or Huge.
• Basic characteristics of a ship should be clear from just its size, regardless of the details of its design or its specific hull
• Hulls of a particular size tend to have some common characteristics and uses. The various hulls will be balanced so that all sizes (and all hulls within each size) are useful and an optimal fleet will have a variety of the available sizes, doing different strategic roles within the fleet.
• Ship size will likely have some relevance to tactical balance. Ships of different size may be differently useful for different jobs in battles, and may be differently useful overall in battles, offset by cost or non-battle considerations.

Parts

• Parts are the means by which players customize ship designs and make them into functional ships.
• Parts include things such as weapons, defenses, stealth enhancements, detection enhancements, extra fuel storage, colony pods, troop pods, and various galaxy-map effects-projecting special mission equipment.
• Parts can have effects that alter ship properties, both statically and depending on what the ship is doing.
  • Weapon parts might reduce stealth while firing
  • As many static functions of parts as possible should be implemented through effects

Slots

• Hulls have a set number, layout (and possibly sizes) of slots into which parts may be placed to make a ship design.
• Slots are either internal or external.
  • Some parts may be restricted to only internal, or only external slots.

Justification

Linking hull sizes indirectly to roles via non-role-specific size-dependent characteristics of the hulls of a particular size is a part-way solution between fully generic hulls with no role-association, and fully specialized hulls, which are each intended for use only on a single role.

There will be several different (sized) hulls on which ships can be designed, which are distinctive in that they are better or worse in ways that affect how well they do various roles, but can be used for roles including ones they aren't particularly well-suited. Different-sized hulls are also visually distinct and will have obvious associated characteristics, which should be easy to describe, discern and understand for players, rather than fully role-independent generic hulls which have no association to particular roles. In this system, it's not as easy to see what a ship is or can do as it would be if there were easy-to-see roles inherent in the ship's form or appearance, but it's better than having no information such as might occur with fully generic hulls.

Stealth and Detection

Basics

Within Battles

• Stealth is the ability of a Ship or Fighter to avoid Detection.
• Detection is the ability of a Ship or Fighter to determine the presence of, locate, and observe details about enemy Ships or Fighters.
• Spotters detect enemy Ships or Fighters at distance, allowing friendly Ships or Fighters to target enemies within their weapons range that they cannot themselves detect.
• Fighters and Ships can both act as Spotters.

On the Galaxy map

• Stealth is the ability of a ship or other game object (planet, system, building...?) to avoid Detection.
• Detection is the ability of a game object to detect other game objects, revealing the presence and details of the detected object to the owner of the detecting object.

General Principles

• Stealth and Detection are an integral part of the combat system. They are not merely a delay or distraction before the "real battle" begins, but are themselves fun and interesting.
• Stealth should not be the dominant consideration in all battles, particularly at the start of the game. In particular, battles should not often involve mostly hide-and-seek in a system, trying to located enemy ships to fight.
• It should be difficult to produce ships that are so stealthy as to be undetectable by similar-strength enemies, regardless of distance between them. It should be especially difficult to produce ships that are undetectable while firing weapons.
• Advancing technology renders previously stealthy ships, or very good detectors, less useful. A ship that is totally undetectable with one set of detection equipment become easily detectable with better detector equipment. Similarly, if a ship design can be easily detected, a more advanced version with better stealth equipment would be much harder, and possibly impossible to detect.

Mechanics

Ships and other objects in a battle have two relevant meters: Stealth and Detection. Detection indicates the base detection radius of an object during a battle; this is the maximum distance away at which it can detect a minimally stealthy ship. Stealth indicates the ability of an object to avoid detection, reducing the actual range at which it can be detected by other objects. Both these values are standard meters, ranging in value from 0 to 100.

Ship parts give bonuses or penalties to these meters to influence the detection ability or stealthiness of a ship. Other objects have other sources of bonuses or penalties, from techs, buildings, or other sources.

The following assumes a system of battle map coordinates where planets are about 100 units of distance apart.

To determine if a detector can detect a target, the target's stealth is subtracted from the detector's range, and the result is compared to the distance between them. If the distance is less than 10*(detector_detection - target_stealth), then the target is seen by the detector. If the distance is larger, then the target is not seen (by that detector; another detector might see it).

If (detector_detection - target_stealth) is less than 0, ie. stealth is greater than detection ability, then the detector can never see the targer, regardless of their distance of separation.

For example, if a detector ship has a detection meter of 30, it can see target objects up to 300 battle map distance units away, depending on the target's stealth. (And unless the target has a stealth of 0, in which case the target can be see anywhere on the map). If a target object has stealth 10, the detector ship can see the target object if it is 200 battle map distance units away or less. If the target object has a stealth of 40, the detector ship can never see the target object, no matter how close or far apart they are.

The factor of 10 scaling difference between meter values and battle map distance is used because the range of meter values (0 to 100) and the battle map distance units (1000 unit system radius and 100 units between planet orbits) were decided upon independently and a scaling factor is needed to make things work reasonably.

The stealth and detection meters of an object may vary from battle turn to battle turn. In particular, whether a ship is moving, or in particular, firing its weapons, should significantly influence its stealth level. Ships that are completely stealthy when not moving or shooting may becomes easily visibile when they fire weapons, due to increase penalties to stealth from weapons ship parts on the turn (and turns immediately after) firing.

A special case also occurs if a target has a stealth of 0. In this case, no calculation about distance between target and detector is done. Rather, any object can see any target object in a battle if the target has a stealth of 0, regardless of distance between them.

Most ships will have stealth 0, at least at the start of the game. Most celestial objects in battles, such as plants or stars, will have stealth levels of 0, so can always be seen by players in a system battle.

Detection meter boosts will be given much sooner and more readily and cheaply and earlier in the game / tech tree than stealth meter boosts. This makes is difficult for ships to be too stealthy to be detected by similar-strength enemies.

Planets in Combat

Planets appear in combat and take part in battles, and interact with ships over the course of a turn on the galaxy map. There are two main purposes to planets' offensive and defensive capabilities:

• Planets should not generally be completely defenseless, because it should not be necessary for players to keep a small defensive fleet at every system they control, in order to prevent their planets from being attacked and their colonies destroyed.

• Planets should be able to protect themselves against moderate to large enemy space fleets for several turns without being overwhelmed. This allows time for reinforcements or defensive response fleets to arrive in an invaded system. It could allow blockades to occur if attacking fleets are powerful enough to control system space, but not strong enough to capture or destroy planets immediately or at all. It may also have some use in making ground troops more useful, as well as other non-ship-weapon types of alternative warfare (biological, influence-based, or spy-dependent).

However, planets should not be invulnerable to enemy space fleets, particularly if those space fleets are quite large and powerful, or are specially equipped with planet-destroying or planet-capturing equipment.

To meet these goals, planets have two meters: Orbitals and Shields.

Orbitals

Orbitals are satellites that give a planet offensive capabilties.

Orbitals are tracked with a planet orbital meter. The current orbital meter value indicates the total strength of orbitals that a planet has, and the max meter values indicates the max level of orbital strength the planet can maintain. Like other meters, the current orbital value grows towards the max value over time, with a rate dependent on factor such as the planet's construction meter. It takes some time for a planet to fully develop its orbital constellation, or to recover from losing some of its orbitals during a battle.

Planet orbitals' attacking range should be fairly short, so that defended planets of multiple empires can coexist in the same system without attacking eachother.

Shields

Planetary shields are extremely strong defensive weapons that can protect a planet for several game turns, and render it nearly invulnerable to damage during a space battle.

Shields are tracked with a planet shield meter. The current shield meter indicates the "power" or "health" of the planet's shields, and the max meter value indicates the max shield strength the planet can maintain. Shields regenerate over time, like other meters.

While a shield is in place, a planet's surface is protected from orbital bombardment by fleets of enemy ships. The planet's building and meter levels are unaffected by enemy fleets in a system while the planet's shield is functioning. However, non-fleet warfare, such as dropping ground troops or using biological or psychological/sociological attacks can penetrate a shield. These attacks can destroy a planet's defense or infrastructure even if the shield is up, necessitating having protection against them even if a planet is shielded.

Shields can be damaged by enemy fleets in their system, however a relatively large and powerful fleet is required to do this. Fleets have a shield damage rating, which is the amount of damage they do to each enemy planetary shield in their system each turn. If this rating is higher than a given shield's regeneration rate, the shield is depleted each turn, until it is disabled. If the fleet's shield damage rating is less than a shield's regeneration rate, the fleet cannot damage or full prevent regeneration of the shield.

Some ship parts or weapons may be specially designed to weaken enemy planetary shields more effectively than other weapons.

Exactly what determines a fleet's or ship's planetary shield damage rating is not yet determined. Likely it will depend primarily on the strengths of weapons on the ships. Certain weapon types (LR, SR, bombers) may be more important for shield-damaging than others (PD, interceptors). There may also be special ship parts that don't act as standard weapons during battles, but which give ships a powerful anti-shield effect.

Consumables

Consumables include ship fuel, missiles, and fighters. Keeping track of the amounts of these a ship or fleet has can promote strategically interesting decisions and reduce imbalances or other undesirable game "features" or strategies.

Fleet Supply System

Consumables are generally important for the operation of a ship or fleet, so there must be a way to replenish, or resupply, a ship that needs more.

The supply system should conform to several goals:

• The mechanics of the supply system should be clear and easily understood by players.
• The player mainly interacts with discrete in-game objects like ships, fleets, buildings, etc. Abstracted sliders or numbers entered to pick how many supply ships to have in an empire, or how much money / production to spend on supply, or how many abstracted, unseen "privateers" to hire are not fun, engaging or easy to understand regarding their direct effect on the actual in-game objects.
• If resupply costs anything, that cost should not vary rapidly from turn-to-turn, or due to immediate state of an empire's fleets. This could cause large, unpredictable variations in the amount of PP consumed by the supply system, which would make planning and allotment of available PP to queued production projects difficult.
• Supply should be interruptable by other players, in order to provide ways to fight large supply-hungry attack fleets without a similar defensive large fleet. Smaller fleets of cheaper, faster supply-route cutting craft can position themselves behind the attack fleet to cut its access to supplies and cause it to weaken over time.
• Supply routes need to be long enough to allow battles to occur reasonably far from an empire's home territory, but not so long that securing supply routes is trivial, or battles can occur anywhere in the galaxy. Empire shape and cohesion should matter.
  • Range at which supply can be delivered should vary with tech over the course of a game. At the start of the game, supply should be limited and local only, but near the end of the game, it should be much easier to provide supplies much further away.
• Sources of supply shouldn't be trivial to set up. In particular, if it is possible to plant a trivial colony anywhere and be instantly supplied near that system, it becomes too easy to get supply far from one's own empire, and distant-supply considerations are circumvented.

Mechanics

• Ships starting a turn in a system can be resupplied on that turn if the system is or has a supply route to a supply source
• Resupply replenishes fuel, missiles or fighters.
• For a system to have a supply route to it:
  • The System must have an unobstructed path to/from a supply source, which is within the range of that supply source.
    • Sources are friendly (currently just same-player owned) game objects with Supply Range meters equal or greater than 1.
    • The range of a source is indicated by the value of its Supply Range meter. Meter value is rounded down to determine range in starlane jumps; a value of 2.5 means that the source can supply ships up to two systems away, where the counting includes the source system. That is: supply can be sent to the source system, and systems one starlane jump away.
      • Supply Range meter value depends indirectly on various factors such as techs, buildings, construction meters, etc. which all interact with effects to set meter's value.

• Rate of resupply for each consumable may need be limited for balance purposes.
  • For v0.4, supply rate will start as infinite for any supply source. That is, any source can instantly fully resupply any friendly ship to which it has an unobstructed supply route.
  • If supply rate is limited in future:
    • Each supply source will have a maximum amount of supplies it can give to each ship it has a route to supply. A source can supply any number of ships, but can only provide each individual ship with a limited number of supplies each turn.
    • Individual ships receive supplies only from the single source that can give the most supplies that turn. Multiple sources cannot supply the same ship on a single turn.
    • Factors that might limit rate of supply by a source include:
      • Length of the supply route from source to sink
      • Techs, Buildings, other sources of effects
    • Even if remote supply (where sink is not located in the same system as the source) is limited as above, a source can fully and instantly resupply any ships that are in the same system as it.

• If displayed to the player, a Rate of resupply presented as an abolsute number, eg. "1 fuel per turn", and not as a ratio, eg. "40% supply rate"

• For (ships in) a system to be supplyable by a source, there must be an unobstructed path between the source and sink, subject to the range limit of the source. Obstructions include:
  • Systems containing hostile armed enemy fleets.
  • Highly developed enemy colonies - undeveloped but minimally colonized worlds do not block supply.
  • Unexplored systems (by the empire sending supplies).

• More than one empire may be able to get supply to a particular system, even if they are hostile towards eachother, as long as there are no obstructions to either getting supply to that system.
• "Pirates" or other supply disruption events can occur, which just prevent supply routes from passing through a system until they are resolved - these function just like any other blocking of a system. This may or may not actually involve hostile ships being spawned to cause the disruption.

Fuel

It is undesirable to be able to fly any ship arbitrarily far across the galaxy. Limits on the distance ships can travel away from the systems their empire controls would prevent this, and some concept of ship fuel is an intuitive way to do this.

The fuel system should conform to several goals:

• It should not be possible for micromangement-intensive strategies to use or abuse the supply system to a player's benefit. If this is possible, it becomes necessary to play an optimal game.
• It is better to abstract something than to make it too complicated to manually control while claiming automation can replace player-performed micromangement.
• Ships should never be stuck immobile on a starlane due to lack of fuel. If a ship is left immobile, it should be in a system.
• Ships should rarely be completely stuck immobile due to lack of fuel. There should be some way to eventually move ships that are presently unfueled, in some very restricted way. This should not mean that it is possible to ignore the supply system's intended limits on range, however.
• Hard range limits are inelegant and disliked. In this system, ships would be not allowed to travel more than a certain range from colonized friendly systems, but could travel any distance within that range.
• Fuel is intended to limit range, but not movement within the allowed range. Consequently, fuel shouldn't be a major consideration when ships are moving in close range of an empire's colonies.
• When there is enough fuel available, or when ships are close to a friendly empire's colonies, the player shouldn't have to do anything extra with the interface to move ships around due to the presence of the fuel system.
• Ship range and ship speed are separate values, and it should be possible to have combinations of either extreme of both, such as fast-long, fast-short, slow-long and slow-short range ships. Ship speed should thus not be determined by fuel.
• It should be simple and easy to see how far a ship can travel with its available fuel. The most intuitive units of fuel to present to players is some measure of distance travelled, not abstract "gallons" or "kilotons" or similar.

Mechanics

• Most ships consume fuel to travel along most starlanes.
  • As a special case, a starlane jump between two systems controlled by the jumping ship's owner does not consume any fuel. It should not be necessary to stop your ships for a turn at the outer edges of your empire to refuel after jumpting between internal systems. Any path that takes ships to their destination via jumps between friendly planets can avoid this annoyance by not consuming fuel on such jumps.
• Amount of fuel is measured in the number of starlane jumps that a ship can make. A ship might have "4 jumps worth of fuel" or just "4 jumps".
  • A starlane jump is the process of travelling along a single starlane between two systems.
  • When making a jump that consumes fuel, ships generally consume 1 unit or "1 jump" of fuel per starlane jump. Fuel is consumed to start the jump, and no additional fuel is consumed during the jump, even if it takes several turns to travel along the starlane.
  • Fractional units of fuel may be possible, though jumping always requires and consumes a single unit of fuel.
• The game should support all of the following, some or all of which may actually be used, depending on future balance decisions:
  • Ships that can jump if they have fuel, but cannot move along starlanes when they have less than one jump's worth of fuel.
  • Ships that can jump without using fuel.
    • These would likely be late-game, higher tech, expensive ships, or ships that are specially designed and very limited in other functionality, in order to balance their unfuelled travel.
  • Ships that jump at a fast max speed if they have fuel, but which can also jump at a slower speed if they do not have any fuel.
    • If ships can travel without fuel, this unfuelled speed is very slow. It is impractical to ignore fuel and attempt to travel arbitrarily far without it. Rather, unfuelled travel would just be present to prevent ships from being permanently stuck a bit past where they could travel with fuel.
• Ships have a fuel capacity, which is the maximum amount of fuel they can hold.
• Ships generally cannot share fuel with other ships
  • If ships can share fuel with any other ship, abuses become possible that circumvent the supply system, and encourage micromangement
• Ships can replenish fuel using the supply system
• Ships may be able to spontaneously generate more fuel for themselves. This likely only occurs when ships remain idle in a system for a full turn. Combat may or may not prevent fuel generation. Arbitrary conditions, including whether or not a ship is moving on a given turn, should be possible to use to determine if a ship generates any fuel that turn.
• There may be fuel-generating ships that cause other ships near them to regenerate more fuel (or equivalently, generate and give fuel to other ships near them). These ships do not store fuel to be transported around the galaxy map however; they can only transfer fuel to another ship on the same turn the fuel is generated.

Ammo

• Keeping track of the available ammo for weapons on a ship prevents "scoot and shoot" tactics abuse, where a ship can enter a system, fire several long-range missiles and do some damage to a target, then retreat before it can be counterattacked, and then regenerate full ammo to do the same thing the next turn.
• Ammo is most important to keep track of for long-range offensive weapons that can attack independently of ship movement, such as fighters or missiles. It may be possible to allow short range direct-fire weapons or primarily defensive weapons to function indefinitely without requiring consumables for them to function.
• Allowing ammo to be consumed makes it possible to cut off a large fleet or powerful ship from resupply, then wear it down by wasting its ammo over several turns. This motivates keeping supply lanes open and makes it possible to use strategies involving ships that are less effective in direct battles, but which can cut supply lines to win.

Mechanics

• Ammo is shared between all ships in a fleet
  • When fleets merge, their ammo is put into a common pool for the combined fleet.
  • When a fleet is split, its ammo is split in some appropriate manner between the new fleets.
  • When entering a battle, ammo of a fleet is spread amongst the ships in the battle in some appropriate manner
• Tenatively, the following types of ammo are tracked:
  • Missiles
  • Fighters
• There may or may not be finer distinctions made between specific types of missiles or fighters that a fleet has. This is to be determined later.
• Ammo is shared in a fleet, whereas fuel is not.
  • If fuel could be shared, a series of ships could be used to shuttle fuel to ships outside the resully range. Refuelling a ship in the manner would allow that ship to travel further away from planets where it can be supplied than it otherwise "should" be able to, which is clearly an abuse of the system an a potential motivation to do so.
  • Ammo can also be shuttled to fleets in a similar manner, but doing so does not let the player do something with a ship or fleet that is significantly different from what they could otherwise do. If a ship can fly to a location, it can fly there without using up any ammo. Being able to shuttle ammo to fleets by sending ships to meet the fleet does not so significantly change what the fleet or its ships are able to do.

I don't get the fundamental difference between the abuse implied by fuel sharing and the lack of abuse in ammo sharing situations. It seems to me that either both or neither should be considered micromanage-y. In particular, I don't understand what it meant by "since it is not as likely to need to be restricted by considerations such as what the travel range of a ship should be". Geoff, could you clarify? --Zach

Modified to clarify. Is that sufficient? Geoff the Medio 06:04, 14 January 2009 (EST)

Building Ships

• Ships are ordered on the production screen. The design of the ship to build is chosen, and then enqueued. The ship is built when it's project is funded on the queue, in order of queue sequence.
• The build location of a ship is specified when the ship is ordered.

• Ships can only be built at shipyards.
• Additional restriction on build location may exist, depending on the design of the ship. Certain parts or the hull might have restrictions. The build location of a ship must be a valid build location for the hull and all parts.

• The total cost and minimum build time of a ship is a function of the ship's design.
  • The total cost of a ship is the sum of the costs of its hull and all the parts in the design
  • The minimum number of turns to build the ship is the sum of the minimum turns to build the hull and all the parts.
    • In general, hulls will have large minimum build time and small to medium costs, and parts will have zero or small additional build times, but collectively contribute most of the cost of a ship.
  • The maximum PP that can be spent on building a ship each turn is the total cost divided by the minimum build time of the ship.

Shipyards

Shipyards are buildings, or combinations of buildings, that allow ships to be built in the system where a yard is located, by the player that controls the yard. They are expensive, relatively rare, and strategically important.

• Ships, like buildings, are assigned a build location when they are enqueued.
  • Requiring ships to be built at specialized facilities makes the placement of these facilities strategically important.
  • There is a tradeoff between distance from the front lines, and the vulnerability of the shipyard.
  • Newly founded colonies immediately adjacent to the front lines cannot immediately start producing lots of ships, or at least lots of high-tech ships. This allows lines of supply and distance to the front to remain strategically important.
    • The signifiance of a tech limit increases with time during a game.

• Shipyard limits are upgradable by building an addon to the shipyard.
  • Shipyards have "tech levels" that determine the ship hulls and ship parts that they can build. A shipyard must have a sufficiently high level to build hulls or parts of that level or below; higher-level ship hulls or parts can't be built until the shipyard level is increased.
  • "tech levels" may not be literally called that. Various hulls or parts may require particular addons, without a separate "tech level" rating being assigned to either.
  • Shipyards may have a limit on the PP per turn that they can spend. This limit would be increased by improving the level of the shipyard.
  • Making shipyards need upgrades makes new shipyards less useful than long-term established yards. This increases the strategic importance of well-developed yards, making them important targets for combat, and their location in space strategically relevant to supply lines and distance to location of combat.
  • If shipyards were not upgradable, then all shipyards would be equal, and a newly-created shipyard on the border of an empire would be able to build unlimited numbers of the newest ships an empire could produce, which would likely be imbalancing.
  • There is a possible strategic tradeoff between having many redundant cheaper shipyards, or fewer upgraded shipyards that would be devastating to lose.

• Ships can repair, slowly, away from shipyards, but can repair much faster at a shipyard.
  • Ships may have a slow natural repair rate in the field if left immobile and out of combat, and in supply range for a turn.
  • There may be ship parts that allow a ship to speed the field repair rate of other ships.

• Shipyards and ships under construction appear in battles in the appropriate system. These can be targetted and destroyed, providing a strategically important target in battles that can be attacked without destroying all enemy ships in the system.

• Shipyards can be built in system with colonized planets. Additional restrictions may be added, including:
  • Shipyards may need a planet in the system where they are built of sufficinetly high development level. This may mean construction meter, or production output or population.
  • Shipyards may require the system where they are being built to be supply-connected to the rest of the empire.

• Shipyards should take a moderate amount of time to initial build. Each stage of upgrade should also take a moderate amount of time. Building a new fully-upgraded shipyards during the middle or end game should take a long time.

Ship Upgrades / Part Refinement

• Ships can be upgraded by researching refinements to their parts. When a refinement is researched, all parts on existing ships of type that were refined instantly gain refined stats / features / function / properties.
  • Any ship owned by a player who has researched a refinement gain the refinement's effects. Other players owning the same ship would not see the effects of a refinement unless they research it themself. A ship with refined parts that transfers ownership to another player who doesn't have the refinement researched will function with unrefined parts for the new owner.
• There is no way to change the design of a ship after it is built. The only way to "upgrade" a ship is by researching refinements to its parts.
  • After v0.4, we might add upgradeable parts, which can be replaced with another part to upgrade a ship, but this is not considered necessary for v0.4.
• There might be other factors besides just knowing a refinement tech that alter the function of a part for an empire.

Ship Roles

The concept of "ship role" may be built into the UI or AI, but not directly or explicitly into the ship design system as ship hulls or sizes that are used only for a specific role.

In particular, some indication of the role of a ship, as a summary of its design, may be generated and displayed to players and/or used by AI to determine how a ship "should" be used tactically or considered strategically.

What exactly constitutes a "role" is unclear, but may be strongly linked to weapon type or other parts used (or used primarily, or emphasized), tactics or strategies a ship is suited-for, range or supply limitations, etc.

Battle Balance Tactical Goals

The mechanics of combat should encourage and support interesting tactical outcomes. Battles should not dissolve into an amorphous tagle of ships. Rather, appropriate grouping and relative placement of ships should be a significant factor in determining victory between similar-strength forces.

• Ships are vulerable to LR if the LR-launching ships can see their target. Tatical use of spotters, stealth and detection are important for this.
• PD is best placed between a ship launching LR ordinance and the LR's target, not beside or behind. PD is more effective at protecting other ships than protecting itself from LR.
• Non-SR ships are very vulnerable to SR if it gets into range to attack them. A barrier of defensive SR is useful to protect other ships from enemy SR.

Additional tactical goals may be added. The above list is not meant to be a complete list of valid tactics in-game, but rather is a list of possible tactics to encourage instead of a chaotic melee-like jumble of ships.

Battle Map Layout

• The battle map is centred on the system's star
• Planets are located around the star, at random positions or at positions determined by some algorithm, possibly moving turn-to-turn
• Starlane endpoints are a medium-sized area of space - not a point, but not a very large region. An entire fleet should fit into the starlane endpoint area. Endpoints are oval or curved-oval in shape. There are gaps between endpoints of different starlanes.
  • Endpoints are located in a ring of space surround the rest of the system. The circle is thin relative to its diameter, but has some finite thickness.
  • Ships can only enter or exit a system via a starlane endpoint on the map
    • Ships can exit from a system during battle at any starlane entry point in the system, regardless of whether or which entry point the ship started at. This allows so-called "blockade running", where ships try to get past a hostile force in a system to get to the systems beyond. It has been suggested that this is not a good strategy to allow, as it compromises the chock-point function of a system and would promote uninteresting battles where the only purpose is to move ships between starlane exit/entry points in a straight line and hope the ships aren't killed. If this is found to be a bad feature in the game in testing, it may be removed or modified to only allow ships that arrive in a system during turn to exit via a starlane exit/entry point if they entered via that same entry/exit point at the start of a battle.
• Around planets and stars there is a ring of space, of thickness about equal to a planet diamater, which is considered to be the orbital space of the planet (or star). Ships in this space are "in orbit" of the planet, and can interact with the planet in ways ships futher away can't, and may have other tactical effects applied to them.

Pre-Battle Deployment

• Prior to battle, players arrange their forces as they would like them to appear at the start of the battle. Players deploy their forces without knowledge of other players' deployment choices; all players deploy simultaneously.
  • In future, allied players may be allowed to observed their allies' deployment while deploying their own fleets.

• Players entering a system at the start of a battle via a starlane deploy their ships within the starlane endpoint on the map.

• Players with fleets already in a system are able to deploy their fleets anywhere in the system, except for within starlane endpoints, and inside planets or stars. (In orbit of a planet or star is allowed.)

• Players are not allowed to see other players' deployments being done, even in some cases where it could be argued that it would make sense to do so, because if two players were able to observe eachother's deployments while doing their own deployment, a stalemate in which neither player is willing to deploy until seeing the other's deployment might arise.

• For v0.4, all ships that get to a system during a turn are placed and appear at the start of the battle.
  • In future, if necessary or desirable, fleet can appear during a battle after a delay proportional to the time during a turn at which they arrive. This would be dependent on how far the fleet was from the system at the start of the turn and how far it had to travel to get to the system. time = distance / speed

• In future, requested deployments may not correspond exactly to actual deployment at the start of a battle. Particularly for attackers entering a system at the start of a battle, ships may not arrive in the correct place or all together.

Exiting Battle

• Battles end if all ships in the battle are allied / mutually non-hostile.

• Ships may exit battle by being destroyed, or by leaving on a starlane.

• Ships leaving on a starlane must be within the starlane's endpoint area on the map. Ships can then be ordered to leave the system along the lane. Leaving does not occur instantly, but requires the ship to remain in the starlane endpoint for several turns. The exact number of turns may vary from ship to ship or empire to empire, depending on the hull or parts of the ship and their level of refinement. Ships are vulnerable to attack, and can attack back while in the endpoint attempting to leave the system.

Combat Objectives

Contested tactical objectives are generally achieved or resolved on the battle map. For example, invading a planet or transiting through an enemy-occupied system, from one starlane entrance to another, requires resolution on the battle map if there is an opposing fleet that would seek to prevent or interfere with these activities.

Possible combat objectvies include:

• Destroying enemy ships
• Invading or evacuating a planet (attackers provide cover for transport/assault ships or else perform orbital bombardment; defenders either engage attackers or provide cover for evacuation ships)
• Transit (attackers attempt to get from point A to point B; defenders interdict attackers or else cause attrition)
• Reconaissance (maneuvering a stealth ship past sector defenses/scanners to drop or retrieve an agent)
• Surgical Strike (targeting a specific installation either in the system or planetside)

Battle Pace, Timing and Orders

The combat engine will be hybrid real-time and turn-based. Individual turns will play out in real time, but player input, through orders, will only take effect once per turn. Orders may be given at any time (paused or not) and are queued to be processed in subsequent turns. During turns, between the times when orders take effect, the player(s) have no ability to alter the outcome of game events (other than orders given before the start of the present turn). Player(s) may request a pause at any time, but pauses only occur and the ends of turns. Current thinking is that a turn should be somewhere between 3 and 5 seconds. (Example: Knights of the Old Republic)

This system is chosen over a traditional RTS system because those generally turn into a clickfest, or a contest of who can more quickly and effectively manipulate one stack of numbers against the opponent's stack of numbers (Example: Empires at War). Conversely, a TBS system can be too slow and make be unable to capture any real sense of tactics (Example: Master of Orion 2).

Battle Math

The main reason for the following battle math system was simplicity. Various more-complicated systems were considered, but anything more than two or three numbers to track ship damage is too much data to track internally for the engine, and will often be more information than players can usefully take in during a battle. Separately tracking damage to individual ship parts in particular is not practical or necessary for v0.4 or likely for v1.0.

However there should still be some effect on ship systems before the seemingly perfect condition ship explodes when the last fraction damage if could absorb is dealt. Rather, ship performance should degrade as it is damaged.

Defining various threshold-related effects would likely require writing a lot more in ship part definitions, and would means writing the code to interpret those definitions and store the information and dole it out in various situations. This is a lot of extra work for coders and part design and balancing. Instead, a simpler system is used with continuous degrading of ship performance with damage to the ship.

Meters and Damage

Ships have two meters that track damage: Health and Shield.

If a ship is attacked, the attack does some amount of damage to the ship, which is subtracted from the current shield meter. If damage exceeds the sheild meter, the difference between the shield meter and the amount of damage done to the ship is then subtracted from the ship's current health meter.

Damage to ship shields has no direct effect on the performance of the ship. Reduced shield meters are simply reduced for the remainder of the turn.

Damage to ship health reduces in-battle ship properties such as ship weapon power, stealth, speed and detection in proportion to the amount of lost health. For example, if a ship is at 50% health, its beam weapons may 50% of full damage potential per turn, it may move at 50% speed, and may have 50% reduced stealth and detection ratings, or may launch fighters or missiles at half speed. Exact details of this are to be determined, but the point is that damage should affect a ship before the actual destruction of the ship.

Ship Design and Meters

Ship health and shield maximum values are determined from a ship's design. Specifically, the hull and the ship's part can modify the ship's health and shield max meter values.

Shields generally are only increased by specific shield parts. Ships without shield parts or some other source of shields at the start of a battle have a max shield meter of 0.

Health generally is increased somewhat by a ship's hull, so all ships have a max health meter above 0 from the effects of their hull. Other parts can also increase a ship's health, and armour parts significantly increase a ship's health max meter.

Repair

Ship shield current meters are set to their max value at the start of each main game turn.

Ship health current meters may or may not increase between game turns:

• Ships located in a shipyard's system are fully repaired (current health set to max health) at the start of each turn, except on turns in which the ships engaged in battle.
• Ships located within the fleet resupply network of their empire are slightly repaired by having their current health meter increased by some to-be-determined small amount each turn.
• Ships located outside their fleet resupply network do not repair between turns.

Note: Whether a ship arriving at a system with a shipyard is repaired on the first turn that a player would see the ship as being located in the system is unspecified now (ie. it is undefined in this section when the "start" of a turn is). In future, ships may be required to spend a full turn in a system to be repaired: the ship would need be in the same system for two consecutive turn updates to the ship's owner.

Weapons

Damage and Launch Rate

Direct-fire ship weapons and fighter attacks have a rating in damage per battle round, or damage per shot (to be determined from implemenation). This rating is determined at the start of battle, likely by effects or other factors that are not relevent in the battle itself (beyond the rating they produce), and may be reduced by damage to the ship.

Damage rating determines how much damage the weapon does when it attacks another object in battle (such as another ship).

Other than proportional reduction in direct-fire weapon damage due to reducection in an attacking ship's health meter, a weapon's damage rating does not change during battle. Distance to target or the type of target being attacked does not change the damage rating of a weapon.

Missiles have a fixed damage rating for targets they hit. There is no need for a damage "rate" for missiles that hit only once, on one round.

Fighter attacks may be rated per hit or per round, depending on implementation preference.

Indirect-fire ship weapons have a rating in the number of missiels or fighters that can be launched from a ship each battle round. This rating is determined at the start of battle, similarly to direct-fire weapon damage, and may be reduced by damage to the ship.

Range and Targetting

A weapon can target objects in battle that are within the weapon's range, and which the player controlling the ship on which the weapon is located can detect the potential target.

All weapons have a range rating that is determined at the start of battle, like the damage rating of the weapon. However, damage to a ship does not change the range of its weapons. This simplifies the UI and AI of targetting for groups of ships with the same weapon but potentially different health levels.

Every direct-fire (beam) weapon that fires at an object that it can target hits the target. There is no chance to hit or accuracy calculation.

Missiles may be targetted at objects within range of the ship that launches the missles. Once launched, missiles will move towards their target, even if either or both the missile or target move out of the range from the ship in which missiles can be launched at the target. Unless a target can outrun (move away faster than the missile can move) or the missile is shot down, or the target is destroyed or can no-longer be detected by thie missile-launching player, the missile will eventually hit its target. If a missile's target is destroyed, the missile disappears without detonation. If a missile's target becomes invisible due to moving out of detection range, the missile moves towards the target's last known position, and then holds position at that location. Missiles may or may not be retargettable; the player may have the ability to select an already launched-missile and order it to attack another ship that is within the range of the ship that launched the missile.

Fighters may be ordered like ships, and operate independently of the ship that launched them. Any ship that the fighter's player can detect can be targetted by that player's fighters, regardless of distance between the launching ship and the target, or the between the fighters and the target. Effectively, fighters have unlimited range.

Battle User Interface

• For v0.4, the smallest unit controllable by the player is a single ship. We will revisit for v0.5 the issue of whether or not ships should be able to (or always be) grouped with like vessels (and we will define what a 'like vessel' is).

• Orders must not be too detailed, but also not too generic. It is necessary to strike a balance that hits the sweet spot, so that interface and feed back are simple, but not too simple to be interesting and fun.

• Details of a ship's design are not represented on the 3D model of the hull. Instead, symbolic icons in the UI or textual indicators will convey this information.

• Ship shield and health should be indicated in the GUI with a colour-coded indicator based on thresholds of health / integrity / damage. This can be a separate indicator, or incorporated into a health number or bar by colour-coding.

Planet Resource Distribution

The planet resource distribution system is the means by which planets exchange (some of the) resources they produce, allowing planetary specialization in one resource while the others are provided by other planets. The planet resource system uses distribution routes that are functionally very similar fleet supply route, except that they are between planets, instead of from a planet to a fleet. Planet resource distribution routes are typically shorter than fleet supply routes, but within their maximum range, the same rules determine what systems through which planet resources can be distributed as which determine systems that fleet supply can travel through.

• The resources Food, Minerals and Industry are affected by planet resource distribution limitations. Trade and Research are sent directly to the empire stockpile regardless of whether there is a physical supply connection between the producing planet and the empire stockpile location.

• Planets can send supplies to and from other planets within their distribution distance.
  • If planet A's distribution range reaches planet B, but planet B's distribution range doesn't reach A, A and B can still exchange resources both ways.
  • If planet A and planet B are both out of eachother's distribution range, but planet C is within range of both A and B, then planets A and B can exchange resources.
• The distribution range of a planet is determined from the planet's construction meter. The number of starlane jumps away that a planet can send resources is equal to the planet's construction meter divided by 20, rounded down. For construction meter values:
  • 0 to less than 20: no supply range.
  • 20 to less than 40: one starlane jumps
  • 40 to less than 60: two starlane jumps
  • 60 to less than 80: three starlane jumps
  • 80 to less than 100: four starlane jumps
  • 100: five starlane jumps.
• It is expected that additonal increases in the construction meter will become harder to get with time, so getting a planet up to 20 construction and one resorouce distribution starlane jump will be much easier than getting the planet to 40, which is easier than getting to 60, etc.

• Any unspent stockpilable resources on a given turn from any planet that has a distribution connection (one step or multi-step) to their empire's resource stockpile planet, are sent to empire's stockpile.
  • Any resources in an empire's stockpile are available for use an export from the stockpile planet as if produced there that turn.
  • Any resources not used on a planet or group of planets that do not have a distribution connection to the resource stockpile planet are lost that turn. There is only one empire stockpile.
  • The stockpile planet is by default the capitol, but can be moved, either by the player picking a new planet, or perhaps by producing a building that designates the stockpile location.

• No planet can transfer resources any other planet if the path to do so passes by a blockaded system. This includes transfers within a system that is itself blockaded.

• Planets in blockaded systems may produce less trade by some to-be-determined mechanism.

• Blockades happen when a system contains a fleet or fleets that meet following requirements:
  • The fleets(s) are all owned by empires with diplomatic status that allows blockades against the empire being blockaded. If an empire has an armed fleet in a system, the empire is not blockaded in that system.
  • The fleet(s) contain ships that have offensive weapons.
  • The fleets(s) contain ships that have sufficient detection ability to see the resource distribution ships of the empire to be blockaded. Empires with appropriate techs that make their resource distribution ships hard to detect (stealthy) cannot be blockaded by empires that have poor detection technology.

• Cheap hulls shouldn't have fast in-system drives. This prevents a single weakly armed ship from staying in a system and running away from battles without leaving the system. Being able to avoid battles like this would mean a player would have to keep a defensive armed ship in a system at all times to prevent it being blockaded.

• Having blockades allows a system to be indirectly attacked by isolation from its empire. This prevents excessive turtling strategies, and makes empire shape and distance important strategically.

• There should be a diplomatic option to blockade resources individually. A probably use is blockading minerals or industry, but allowing food through for "humanitarian" reasons.

Health, Food Distribution and Population Growth

• When a planet has insufficient food, it shouldn't immediately starve to as few people as the amount of available food. If this were to occur, it would take only a single turn blockade to almost completely wipe out the population of a planet that imported almost all of its food.
• Instead, a planet's health should get increasingly large penalties turn by turn. This will eliminate growth, and then cause the population to start dropping after health falls below 20 (the break-even no growth point).
• The growth, food interaction with growth, and food distribution and consumption formulas need to be simplified. It's too difficult to understand where food is going and why right now. Also, currently planets that are maxed out in population still get up to twice their population in food, even though they don't need the extra food beacuse they can't grow.

Planet Focus

The player can assign a Primary Focus on every colonized planet, which determines the resource that the planet in question focuses on producing. The values of the Target Resource Meters are modified by Focus settings.