Difference between revisions of "0.4 Design Pad"

From FreeOrionWiki
Jump to: navigation, search
(facings not needed, minor edits)
(Shipyards)
Line 231: Line 231:
 
* 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.
 
* 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.  It is assumed that ammo will be less prone to micromangement abuse, and easier to balance to make this true, since it is not as likely to need to be restricted by considerations such as what the travel range of a ship should be.  This may need to be revisted, pending future balance observations.
 
* Ammo is shared in a fleet, whereas fuel is not.  It is assumed that ammo will be less prone to micromangement abuse, and easier to balance to make this true, since it is not as likely to need to be restricted by considerations such as what the travel range of a ship should be.  This may need to be revisted, pending future balance observations.
 +
 +
 +
==Shipyards==
 +
 +
Shipyards are buildings that allow ships to be built in the system where they are located, by the player that controls them.  They are expensive, relatively rare, and strategically important.
 +
 +
* Ships, like buildings, are assigned a build location when they are enqueued.
 +
* Shipyards have a rating that determines the types of ships they can produce.  This may be a hull size limit, or may be some other "tech level" type limit.
 +
* Shipyards may also be limited in the number of PP per turn that they can process.  Only this number of PP can be put towards ships being built at the shipyard each turn.
 +
* Shipyard limits are upgradable by building an addon to the shipyard.  This increases the size, tech level or amount of PP that can be spent.  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.
 +
* Shipyards likely have some importance for upgrading or repairing ships.  It may be only possible to do upgrades at shipyards, and repairs might go much faster, or only, at shipyards.  Details are to be determined.  If upgrades were possible without shipyards, then much of their strategic purpose would be lost, in that upgraded ships could be fielded by players far from their shipyard locations.
 +
* 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.
  
 
==Roles==
 
==Roles==

Revision as of 12:57, 6 September 2007

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.

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. A hull is essentially built around an engine, so the engine is a part of the hull and is not separately selectable, and various hulls include engine-type 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 battle map (fueled and unfueled)
    • Fuel capacity and regeneration rate
    • "Health" or "Structural Strength"
    • Speed on battle map
    • Stealthiness and penalties to stealth while moving

Size

  • Hulls will be labelled with a "size" (one of 4 to 6 options) that is of some significance strategically
  • Basic characteristics of a ship should be clear from just its size, regardless of the details of its design or shape
  • All hull sizes have different characteristics and different 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 roles.
  • 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 effects-projecting (in battle and on the map) 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 implimented 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.
    • External slots are more likely to be damaged by weapons fire hitting the ships.
    • Some parts may be restricted to only internal, or only external slots.
  • Slots may or may not (TBD) have a "size". If slots are sized, parts would also be sized, and would require an equal or larger sized slot to be placed.
    • If slots have a size, it may be possible to place multiple smaller parts into a single larger slot.

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 partciularly 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.

Having different slot sizes allows easier balancing and allows greater distinction between different ship shapes of the same size, by allowing a distinction between four small slots and one large slot that could hold four small parts. For example, "large" ships might have two "medium" internal slots, but only "huge" ships would have "large" slots that are required for some parts that it is desired to restrict only to "huge" ships.

By having multiple smaller parts in one larger slot, we can let a design have many parts, without letting the design have many different parts. By reducing the variety of parts in a single design, we simplify the battle UI.


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 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.

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 (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.

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.

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.

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.
  • 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
  • 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 transferred however; they can only transfer fuel on the same turn it 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. It may be possible to allow short range 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. It is assumed that ammo will be less prone to micromangement abuse, and easier to balance to make this true, since it is not as likely to need to be restricted by considerations such as what the travel range of a ship should be. This may need to be revisted, pending future balance observations.


Shipyards

Shipyards are buildings that allow ships to be built in the system where they are located, by the player that controls them. They are expensive, relatively rare, and strategically important.

  • Ships, like buildings, are assigned a build location when they are enqueued.
  • Shipyards have a rating that determines the types of ships they can produce. This may be a hull size limit, or may be some other "tech level" type limit.
  • Shipyards may also be limited in the number of PP per turn that they can process. Only this number of PP can be put towards ships being built at the shipyard each turn.
  • Shipyard limits are upgradable by building an addon to the shipyard. This increases the size, tech level or amount of PP that can be spent. 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.
  • Shipyards likely have some importance for upgrading or repairing ships. It may be only possible to do upgrades at shipyards, and repairs might go much faster, or only, at shipyards. Details are to be determined. If upgrades were possible without shipyards, then much of their strategic purpose would be lost, in that upgraded ships could be fielded by players far from their shipyard locations.
  • 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.

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.

Engine-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.

Pre-Battle Deployment

Prior to battle, players must deploy their forces as they would like them to appear at the start of the battle. Players may or may not have knowledge of other players' deployments while deploying their own forces opportunity to deploy their forces.

Defending players are generally able to see attacking players' deployment while the defending player deploys. In future, the extent to which players are made aware of eachother's pre-battle deployments will depend on technology and other factors, such as espionage, providing this information or hiding it from other players. Surprise attacks by forces already in a system (hidden or previously-allied) will also be treated differently than forces seen by the in-system defender to be entereing the system via starlane.

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 a) in the correct place, or b) all together, depending primarily on the attacker's technology.

Combat Objectives

Contested tactical objectives are generally achieved or resolved on the battle map. For example, invading a planet or traniting 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 exceptions (ie. uncontestable objectives) include defenders retreating, from a system they occupy, through any starlane(s) other than the one(s) through which attackers are arriving, or allowing attackers to avoid battle by retreating via the starlane on which they arrive in a system the same turn.

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)

Combat on the battle map ends when one side's forces are all removed from the field. If players' combat assets do not engage eachother in combat for some (yet-to-be-determined) number of turns, combat results in a draw. (Also yet to be determined: does a draw force the attacker to retreat? Might there be technology to allow a vessel to remain in enemy space without engaging for a few turns?)

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).

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.