Ship design definition

The definition of a ship design is the list of ship parts which are needed for the construction of a specific type of ship. Such a definition includes a hull, at least one engine, and it may include an arbitrary amount of other ship parts (generators, weapons, defences and any other kind of stuff).

Three constraints on valid ship designs exist:

• the total energy consumed by the various parts must be lower than or equal to the amount of energy generated by included generators,
• the total space consumed by the various parts multiplied by a “miniaturisation factor” (and empire-wide production) must be lower than or equal to the space provided by the ship’s hull,
• the ship must have a non-zero normal space thrust.

Predefined ship designs

The game includes a set of predefined ship designs. A predefined ship design is a ship design definition associated with a name and description from the internationalisation system. Since all predefined ship designs are considered to be valid, the minimal miniaturisation factor for a predefined ship design can be computed directly from the list of parts.

Empire ship designs

An empire ship design is a ship design definition identified by a name and associated with an empire. It includes a free text description, as well as a flag that indicates whether the design has been declared as being obsolete. Empire ship designs may only be deleted if no ship is actually using the design. Their names or descriptions may be changed at any time, however the design definition itself may not be modified if there are ships using the design.

Ships

A ship is identified by an arbitrary sequence number. It is based on an empire ship design. It may be given a name for identification purposes. In addition, a ship possesses hit points which must be lower than or equal to the amount of maximal hit points defined by its design, and experience points, acquired when the ship participates in battles. Ships also include a status information which indicates whether they are available, being deployed after construction, being redeployed after movements or mode switches, being redirected, undergoing repairs, being refitted or decommissioned, and a penalty which indicates the time required for a ship in any non-available status to be available again.

Fleets

A fleet is identified by an arbitrary sequence number. It consists of at least one ship (all ships in a fleet must use designs belonging to the same empire, as this determines the fleet’s ownership). It may have a name for identification purposes. A fleet has an attack strategy and a defence strategy, as well as tactics settings (target selection criterion and target selection mode). The game update identifier at which each strategy was last changed as well as the game update identifier corresponding to the latest tactics adjustment are stored, to prevent players from constantly switching these values.

A fleet may be orbiting a planet. In this case, all fleets belonging to the same empire have a mode, which is either attack or defence. The game update identifier at which the last mode change occurred is stored, to prevent players from switching from attack to defence and vice-versa too rapidly.

Fleets that are not orbiting planets are moving fleets. Such a fleet has a planet of origin; however, this information is insufficient, as fleets may be redirected at any time. A fleet’s actual origin is either an in-system location (which consists in a planet and a distance indication, that last part being positive if the origin was in the direction of the star, negative if it was in the direction of outer space, or zero if the fleet’s movement originated from the planet itself) or an outer space location (a set of x and y coordinates expressed as real numbers, since the redirection may occur at any point when moving in outer space). The time elapsed since the last movement order is required to estimate the fleet’s current actual location. Finally, the requested fleet mode on arrival is included.

Before I start, two important precisions are necessary. First, while there is actual ground combat (which is quite different from previous versions), players have no direct influence over it – everything is based on fleet strategies, and there are no actual ground units. Second, this ground combat system is definitely not the final version, it will be rewritten for M3 when the “real” planet management system is added.

Origins of ground armies

Ground armies come from 3 different sources.

• The planet itself provides a ground army, whose size depend on the planet’s population and happiness at the beginning of the battle.
• Buildings may provide ground armies.
• All ships (both defensive and offensive) may carry ground army drop pods.

Advantage index

The advantage index is a value between 0 and 1 that determines which side has the advantage. It is initially slightly in favour of defensive armies. However, it is affected by ships and buildings on both sides. Each ship increases the advantage for its side by a value that is determined by its fleet’s strategy; of course, buildings provide a fixed, pre-defined advantage increase for the defenders. The closer the value is to 0.5, the less clear the ground situation is – casualties will be high on both sides. If the value gets close to 0, then the attackers gain the advantage and they can inflict massive damage without suffering too much in return. Of course, the situation is reversed if the value is close to 1.

Dropping and extracting armies

Ships carrying armies will drop or extract their armies depending on this advantage index and on a setting that is determined by the fleet’s strategy. For example, in the current simulations, attacking fleets drop their armies below 0.55 while defending fleets drop theirs above .3 (they will therefore defend as long as the situation isn’t too desperate). Of course, this does not apply to armies provided by the planet itself or by buildings, which will always be present on the planet’s surface.

Damage

Damage to ground armies is partially determined by the advantage index. It is also strongly affected by the armies’ size: a very small army will probably lose against a much bigger one, even if the advantage index is totally in its favour – while it will inflict quite a lot of damage to the big army and not lose much at each battle update, it will end up dead eventually.

In the case of ground armies provided by ships and building, any damage to the army will translate back to its “container”, and vice-versa (any damage to the ship or building will reduce the size of the army).

Conquest

A planet is conquered when defending ground armies have been killed. The major consequence of this is that it is now entirely possible to conquer a planet while the battle is still being fought in orbit. I am still hesitating about what to do when this happens regarding the status of fleets – the best thing being to make it a setting.

Next time…

Unless you have questions or suggestions, which you should post as comments, the next post will not appear for quite a while. It will be about the battle computation’s implementation or about the database’s structure in M2, whichever comes first…

Target selection

The first actual combat step is the selection of targets. Each weapon on a ship or building may select a different target; while this may at first look like it makes no sense (and in the case of e.g. fighters, it is quite true), it is extremely important for bigger ships – if weapons fire was concentrated on a single ship, most of it would be wasted.

Target selection needs to be executed when a weapon has no target, when its target has been destroyed or when a mode switched occurred and the previous target should no longer be fired upon. In addition, depending on the fleet’s current strategy, there is a probability of spontaneously changing targets (for planet-based weapons, this probability is fixed to a relatively low value – 5% in the latest tests, but it may change a lot before the milestone’s release). If there is no need for a new target, then the target selection step is skipped.

At this point, all potential targets are examined. A weight is assigned to each target depending on the fleet’s (or planet’s) tactics settings:

• size-based selection, giving priority to either smaller, bigger or similarly-sized ships (buildings are considered to be medium sized),
• selection based on weapon power, giving priority to either more powerful, less powerful or similarly powerful ships or buildings,
• selection based on countermeasures, giving priority to either the most armoured ships, the least armoured ships, or similarly defended ships (buildings are never armoured in this version).

If the weapon is on an attacking ship, the weight of each target is then modified depending on the fleet’s attack strategy. This includes giving more or less weight to military ground structures and civilian ground structures.

Finally, a target is selected at random, with higher-weight potential targets being more likely to be selected than lower-weight targets.

Weapons firing

Once their target has been selected, weapons that are ready to fire will do so. The probability of success, and therefore various data such as the weapon’s damage or the probability of interception, depend on a set of variables.

• The probability of firing accurately is computed from the weapon’s accuracy, modified by the ship’s experience (buildings do not get experience points).
• The target’s manoeuvrability, modified by its experience, is used by the target to try and escape the shot. Of course, since buildings do not move, they do not escape shots.
• An “advantage” index is then computed, based on: the hit points of both the target and the weapon’s platform, the manoeuvrability of the weapon’s platform, and a modifier that depends on the relative strategies of the fleets (planets do not have a strategy, so the aim modifier of planets versus attack fleets and vice-versa are part of the attack strategy itself).

A bit of randomisation is then introduced, and a success index is computed. This index may indicate that the shot missed, or that it would hit but could be intercepted, or that it will hit. If the shot is successful, the damage it would inflict is then computed. It is based on the weapon’s base damage, and modified by the shot’s success index. It may be increased or damped depending on the fleets’ relative strategies. In addition, really successful shots will be considered “critical”, which will double their damage (the exact multiplier for critical shots may still change).

Interception

It is possible for a fleet’s ships to intercept shots aimed at other fleets, or at the planet if they are defending. When a shot is intercepted, the ship that intercepted it will take the damage instead of the intended target. Strategies which include a high interception probability may for example be used to provide cover for other, more powerful ships.

The probability of a ship intercepting a shot is determined by the fleet’s strategy, by various modifiers (current ship “health”, experience, manoeuvrability), by the amount of shots aimed at the fleet itself (a ship busy trying to escape shots is less likely to intercept a shot aimed at someone else) and of course by how successful the attack was. A ship may only intercept a single shot at each minute.

A note on strategies

As this post shows, strategies define a lot of modifiers applied to ships and planets during combat. A limited number of attack and defence strategies will be provided. Each strategy will have strong points, while being weaker on others. Strategy combinations are important too, as a strategy may be very efficient against another but very weak against a third. In addition, strategies are also involved in the ground combat computation; more details about that will be provided in the next post.

There are two major computations performed by the battle system. First, space combat is computed. Once this part is over, and provided there are still attacking ships in orbit, computations regarding ground combat are performed. Once these two main chunks have been computed, experience points are attributed.

This posts attempts to explain what the various steps of each computation are and how they work, generally speaking.

This flowchart shows the essential steps of the battle computations. Exit conditions and various internal steps have been omitted for clarity.

Space combat

The first step of space combat is fleet updates. When attacking fleets first start a battle or when fleets join an ongoing battle, they suffer “time dilation” which causes them to be less efficient for some time. This time dilation effect must be decreased over time.

Once fleets’ time dilation strengths have been updated, ships need to undergo various systematic updates: ships that can repair themselves will regain hit points, countermeasures will recover from previous damage absorption, and weapons will charge or cool down. If no weapons are ready to fire, then the space combat computation is over.

If there are weapons ready to fire, the first step is target selection. If a weapon already has a target, there’s a chance it might still select another target – this depends on a fleet’s strategy (for planet-based weapon platforms, there is a fixed, very small probability of target change). If such a change needs to occur, or if the weapon had no target for some other reason, it will seek a target based on the fleet’s (or the planet’s) tactics – basically, it can select targets by size, weaponry or defences, with different priorities. An attacking fleet’s strategy will determine whether the weapon may target the planet’s infrastructure.

Once weapons have selected their targets, they may fire. A computation is performed to determine whether the weapon actually hits, whether the shot may be intercepted and which amount of damage it would cause on a “naked” ship from various variables such as the ship’s experience, current hit points, manoeuvrability… When a weapon fires, there’s also a small chance of a critical hit, which cannot be intercepted and deals twice as much damage.

Depending on strategy settings, some ships may try to intercept shots aimed at other fleets or at the planet. Such an interception depends on how successful the aim was, and on various other factors such as how many hits the intercepting fleet might sustain. A successful intercept will cause the ship that intercepted the shot to take the damage – which is particularly useful to defend planets. No ship can intercept two shots in a single battle update, however.

Once the destination of all shots have been computed, the corresponding damage is inflicted to ships and buildings. Ships may have countermeasures which can sometimes absorb part or totality of the damage. Of course, should a ship or building reach 0 hit points, it is destroyed. In addition, any ships or buildings that provide ground armies will have their army strength reduced accordingly.

Ground combat

Once space combat has been resolved, and provided there are any attacking ships left, the computation of ground combat begins.

First, the ground defence advantage is computed. It is determined by the amount and type of ships supporting ground troupes, by the amount and type of military buildings, and by the population’s happiness.

The support that fleets provide for ground armies may vary depending on a fleet’s current strategy. Fleet strategy also determines whether ships that carry armies should drop the troupes to the planet’s surface or attempt to extract them.

Once the system knows which armies are on the planet, providing there are both attacking and defending armies, ground combat is computed. The damage dealt by either side is mostly determined by the advantage value, although their respective sizes has an influence. Finally, damage is applied to armies (and to the corresponding ships or buildings).

Assigning experience points

After all actual fighting has been computed, experience points are given to ships (buildings will have no XP in milestone 2, but that might change later). The amount of experience points granted to a ship is determined by the damage it inflicted to other ships, by the shots it intercepted, and by the damage the ground armies it carries inflicted.

Next time…

… I will explain the mechanics of space combat more precisely, and how it is affected by fleet tactics and strategies.

In order to make sure that the fleet-related information is complete, the most crucial component is the battle system. It affects a few things on planets, and has far-reaching consequences on the whole ship design and fleet management system.

The most basic types of information handled by the battle system are the definitions of weapons and their countermeasures. The basic principle – three types of weapons vs. three types of countermeasures – has been described many times. This time I needed to come up with the details.

Weapons

In addition to their types, weapons will have four characteristics.

• Base damage is the “standard” amount of damage a weapon deals when it hits. Depending on circumstances, the actual damage may be different.
• Accuracy describes the probability that, in a perfectly neutral environment, the weapon actually hits what it is aimed at.
• Charge time and Cool-down time are delays that occur before and after the weapon is fired.

It is easy to compute the average damage inflicted by a weapon at each tick. This allows weapons of the same level, but of different types, to be relatively different in behaviour without sacrificing game balancing.

For example, one could imagine a beam weapon that fires once every two ticks, with a base damage of 5 and an accuracy of 80%. This weapon would inflict, on average, 2 points of damage every minute. It is easy to create a mass driver with similar results; such a weapon would fire once every 4 minutes, inflicting a base damage of 20 with an accuracy of 40%.

In battles, each weapon fires independently. Weapons on the same ship may have different targets – while this makes no real sense for fighters, it prevents really big ships from concentrating their fire on a potentially much weaker target.

Countermeasures

Just like weapons, countermeasures have a few more characteristics in addition to their type.

• Maximal absorption is the maximal amount of damage that can be absorbed by a countermeasure before it becomes inefficient.
• Efficiency describes the probability that a countermeasure intercepts damage.
• Absorption recovery is the amount of absorption points recovered at each tick after damage absorption.

Balancing for countermeasures is a little more tricky than it is for weapons. I chose to use a (totally artificial) value corresponding to the efficiency multiplied by the amount of minutes a countermeasure would be efficient for if it was absorbing half its maximal capacity at each minute:

Efficiency * Maximal absorption / ( Maximal absorption * 0.5 – Absorption recovery )

Obviously, this means that the recovery should always be lower than half the maximal absorption…

In battles, all countermeasures of the same type act as one single countermeasure on a ship, with an weighted average used as the efficiency and sums for both the maximal absorption and the recovery.

Balancing weapons and countermeasures

No countermeasure can prevent damage indefinitely unless its recovery rate is higher than the damage being inflicted. While this might happen when pitting e.g. a very big ship against a single fighter, it makes it relatively easy to balance weapons and countermeasures of the same level – a weapon’s average damage should be slightly higher than its respective countermeasure’s recovery rate.

Next time…

I am still working on the battle system at the moment. My next post will be about fleet tactics and strategies, as this has been (is?) a major headache.

It is therefore necessary to write rules regarding the method used to travel from one location to another, and the distance it corresponds to. In order to do that, the different modes available have to be clearly defined, and the geography of the universe must be described more precisely than the vague definition we posted here earlier.

There are two different methods an object may use while traveling through the universe.

• An object can be flying through normal space, in which case it will not be affected too much by gravity wells, but will on the other hand be slowed down by e.g. asteroid belts or Oort clouds. In addition, interstellar travel, while possible in normal space, is extremely slow.
• An object can be traveling in Hyperspace, which allows relatively fast interstellar travel. However, Hyperspace is heavily affected by gravity wells; as a consequence, it is a highly inefficient way of moving inside a stellar system, although it allows bypassing asteroid belts and Oort clouds.

The next thing we need is a notion of “distance”. In this case, we do not really need to define that distance in terms of real-world units (nor do we want to); what we need is a numeric value which can then be used to compute e.g. travel times.

Obviously, the actual distance between two locations is always the same; this distance is specifically fixed for each possible type of location. However, depending on whether an object is moving through normal space or Hyperspace, different multipliers will apply.

For example, adjacent systems are always 1000 distance units away from each other, but a x10 multiplier applies when traveling through normal space.

While the example above is very simple, multipliers are actually much more complicated than that. Many objects can affect the multipliers: nebulae, black holes, location in a stellar system, etc. What’s worse, the two multipliers (Hyperspace and normal space) are not affected in the same way by a given object; the typical example is the Hyperspace multiplier in a stellar system, which gets higher the closer you get to the star, and which is not applied to normal space travel at all.

In order to define both the “base” distances and the multipliers, defining the structure of every possible “geographic” object is necessary. The next posts in these series will therefore describe the structure of solar systems, the structure of “special” objects such as nebulae and supergates, and the rules that will govern interstellar travel. The final post in this series will combine all of these elements.

There are two main types of hulls. Standard, mechanical hulls are the most basic option, while it is possible later in the game to create biological ships if the proper technologies have been researched. Biological ships, while leaving slightly less internal space available, are more robust and possess natural regenerative properties; they also include a basic power generation unit.

In addition, it is possible to categorise ship hulls according to their size. Indeed ship hulls come in all sizes and shapes. The size of a ship hull determines how the ship will be used.

Ships using tiny hulls are appropriate as scouts, or later in the game, when miniaturisation has been perfected, as small fighters. Tiny hulls imply a high maneuverability but a low firepower and protection.

Small hulls make very good fighters. While still being highly maneuverable, they can support many more components than tiny hulls and are usually somewhat more robust. The default fighter design is based on a small hull.

Medium hulls are useful to make ground troops carriers, or high-power fighters. They are much less maneuverable by default than their smaller counterparts, but are clearly more robust.

Big hulls are appropriate for high-powered local defenses, or basic hyperspace-capable carrier crafts. They are about as maneuverable as a fridge, tho. However, they can take a beating before blowing up.

Huge hulls make excellent capital ships. Their size allows them to be outfitted with lots of weapons as well as hangar bays for smaller ships. While having a very low maneuverability, they are very robust.

Enormous hulls are, well, enormous. Whatever one might want to put inside a ship, it’s likely that this type of hull can handle it. However, their maneuverability is low, and while this is amply compensated by their great robustness, they will require a crew to fly.

Gigantic hulls are almost as big as possible. They are capable of carrying loads of equipment and are highly robust. They require a crew and are not quite maneuverable.

Colossal hulls are the biggest hulls available. Even gigantic hulls are small compared to these mastodons. Their maneuverability is as low as it gets, and they require a crew. But on the other hand, these can really be made into flying fortresses that can take as much of a pounding as an entire fleet of smaller ships.

The list of hulls players can use has been divided between mechanical and biological hulls. Both lists are ordered by size.

The first one deals with mechanical hulls.

The second list regroups biological hulls. None of these ships have direct equivalents in Beta 5, and none are available by default.

The first set of hangar bays is designed for mechanical ships. The various categories of hangar bays have different sizes, allowing to carry more or less smaller ships.

The second set is designed for biological ships. Their biological nature makes them all extensible, allowing them to store more ships than their mechanical counterparts.

Biological generators are generators based on biological reactions. They are of course only compatible with biological hulls.

Zero-point generators rely on advanced knowledge of the universe’s underlying structure. They are based on advanced concepts and considered to be compatible with both mechanical and biological ships.

In this first post we introduce the mechanical generators – which are of course specific to mechanical ships. A second, later post will present the other generator types.

Passive generators are generators that collect energy from external sources and convert it.

Nuclear generators are generators based on nuclear reactions. They are the most basis power source and the first level of nuclear generators is the one available to all players at the beginning of the game.

Anti-matter generators are based on matter / anti-matter reactions.