Plaintext
Aurora C# unofficial manual
Written by Steve Walmsley and organized by Aurora C# forum community
September 13, 2020
1
Contents
I Introduction 4
1 What is Aurora C# 4
2 About this document 4
II Diplomacy 5
3 Basic Framework 5
3.1 Diplomacy module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Basic diplomacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Intrusion into NPR territory 6
5 Claiming systems from NPRs 7
6 NPR vs. NPR claims 9
7 Restrictions on NPR claims 10
8 Independence 10
9 Banned bodies 11
10 Diplomatic ships 11
III Star System Design 13
11 Modifying stars 13
12 Adding stars 15
13 Modifying system bodies 16
14 Deleting stars and system bodies 17
15 Adding planets, comets and asteroid belts 18
16 Adding moons and Lagrange points 19
17 Deleting asteroids and Lagrange points 20
IV Weapons 21
18 Missiles 21
18.1 Missile updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
18.2 Missile engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
18.3 Missile launcher changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
18.4 Box launcher reloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
18.5 Missile thermal detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
18.6 Magazine design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
19 Guns 24
19.1 Meson update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
19.2 Turret update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
19.3 Beam weapon recharge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
19.4 Weapon failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2
19.5 Plasma carronades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
19.6 Particle lance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
20 Point defence 26
21 Ordnance transfer mechanics 26
22 Ordnance transfer orders 27
23 Automated weapon assignment 27
24 Atmoshpere and energy weapons 27
25 Planetary bombardment 27
V Ground Forces 28
26 Unit design 28
27 Formation templates 31
3
Part I
Introduction
1 What is Aurora C#
Aurora C# is turn based 4X1 computer game made solely by one man: Steve Walmsley as a hobby project
in spare time. It’s modern version of it’s predecessor „Aurora 4X” called sometimes „Aurora VB6” from Visual
Basic 6 - language it was written in. Aurora C# is writen in... C# more modern programming language which
resulted in dramatic increse of performance.
Aurora C# is free game distributed thru forum under address http://aurora2.pentarch.org/ where you can
find more information about game and ask qestions about mechanics to more experienced players and the
developer himself.
2 About this document
This document wasn’t be possible without Steve Walmsley who wrote devlogs during game developement
and forum community, especially user named Demonides who gave idea and started consolidation of information
scattered around forum.
This document is based on his and others work. Thank you! You can find original topic here: C# Aurora
Changes List v1.12 / Table of Contents
This document and it’s source in LATEXis distributed under Creative Commons Attribution-NonCommercial
4.0 International Public License. You can help improve it on GitHub or Aurora official forum. Newest versions of
this document in PDF format are availble on https://github.com/Pawel82S/Aurora-C-Sharp-manual/releases
1 4X - eXplore, eXpand, eXploit, eXterminate
4
Part II
Diplomacy
3 Basic Framework
Original post can be found here.
3.1 Diplomacy module
The Diplomacy Module is new for C# Aurora and replaces Diplomatic Teams. It also affects communication
attempts. The module is 30 HS, costs 300 BP and requires 50 crew. The minerals required are Corbomite,
Mercassium and Vendarite. It is a starting technology in both TN and conventional starts.
3.2 Communication
For communication checks to take place both sides must have ships and/or populations in the same system
and both sides must be able to detect the other. Communication checks will only take place if both sides have a
status of „Attempting Communication”. In other words, you can’t translate their language if they refuse to talk
to you. Diplomacy cannot take place until full communication is established. Alien races may take exception
to your presence in this situation, based on a number of factors will be covered in a future post.
For communication attempts, the highest Communication bonus of any commander of a ship with a Diplo-
macy module in one or more of the contact systems will boost any positive results achieved through the
communication process (which is otherwise the same as VB6). If no Diplomacy module is present in any of the
contact systems or the commander has no communication bonus, any positive gains toward full communication
are halved.
3.3 Basic diplomacy
Basic diplomacy follows similar principles to VB6 Aurora. Actions by each side generate positive or negative
diplomatic points. As the total of diplomatic points goes above or below certain thresholds, high level treaties
(trade, sharing of data, etc.) are put in place and the general level of cooperation changes (hostile, neutral,
friendly, allied).
The primary method of generating diplomatic points is via the Diplomacy module. The module must be
located in a system where the target alien race has ships and/or populations and both sides must be able to
detect the other. Diplomacy can only take place when full communication has been established. The highest
Diplomacy bonus of any commander of a qualifying ship is used. The number of points generated per year is
as follows:
T argetRacialXenophobia
DiplomacyP oints = (DiplomacyBonus ∗ 4 + 1) ∗ 100 ∗ (1 − )
100
For example, an officer with 20% Diplomacy trying to influence an alien race with Xenophobia of 40 would
have the following calculation: (0.2 ∗ 4 + 1) ∗ 100 ∗ 0.6 = 108 Points.
If there is contact but no Diplomacy module in a contact system or the commander has no Diplomacy bonus,
then no points are generated from this process (although other factors may generate points - covered in a future
post).
If there is no contact at all, even via civilian ships, then Diplomacy Points will move toward zero, from either
direction. The annual rate of change is the Xenophobia of the viewing race when the starting point is positive
and 100 – Xenophobia when the starting point is negative. For example, the view of a race with 25 Xenophobia
will only fall 25 points when the starting point is positive but will rise by 75 points when the starting point is
negative. Low Xenophobia races are quicker to forgive transgressions and vice versa.
Existing treaties or diplomatic statuses will improve relationships over time. Different treaties have a base
influence that is measured in diplomatic points per year multiplied by 1 − RacialXenophobia
100 . For example, a trade
treaty has a base influence of 100 diplomatic points per year. If two races have respective Racial Xenophobia
of 30 and 60, then while a treaty is in place the view of the first race will improve by 70 diplomatic points per
year while the view of the second ace will improve by 40. It takes longer to build trust with higher Xenophobia
races.
Trade, Geological and Gravitational treaties all have a base influence of 100. A research treaty has a base
influence of 200. A diplomatic status of friendly has a base influence of 100, while a diplomatic status of allied
has a base influence of 200.
5
Positive and Negative diplomatic points will be gained through other events, many of which will be defined
in future posts. An example of a negative impact is combat. Negative diplomatic points are suffered due to
damage inflicted by an alien race using the following rules:
Each point of damage from a hit that only damages shields: 0.1
Each point of damage from a hit that causes armour damage but not internal: 0.25
Each point of damage from a hit that causes internal damage: 1.0
Each point of space-based damage to populations, ground forces or shipyards: 1.0
Each ton of ground forces destroyed in ground-based combat: 0.01
If diplomatic relations are above the hostile level (-100), then even a single point of damage through combat
will reduce relations to that point. However a period of mutual non-interaction following a small clash will
probably return the diplomatic status to neutral. For example, if communications are established you may
ask a survey ship to leave your system (mechanics in a future post). If that didn’t work or you did not have
communication, you can slightly damage that ship. An unarmed ship would retreat from hostile aliens and the
immediate impact would be the alien race treating you as hostile. However, with no further combat in the short
term, the status would soon return to a wary neutrality. Future communication and diplomacy would still be
an option. Larger wars are harder to resolve but peace treaties will be covered in a future post.
4 Intrusion into NPR territory
Original post can be found here.
In each construction phase, each NPR will determine a value for each known system. In order of ascend-
ing importance, the values are: Alien Controlled, Neutral, Claimed, Secondary, Primary, Core, Capital. The
value is calculated on a number of different factors, including existing population and installations, whether it
is a logistics node, mining potential, terraforming potential and proximity to other important systems. Neutral
is the default state for a system in which the NPR has no current interest, while Alien Controlled is a system
which the NPR acknowledges is in the territory of another race as a result of accepting a claim from that race
(see section 5).
If you have forces or a population in a system that has at least Secondary value to an NPR, you are detected
and you are currently viewed as neutral or friendly, the NPR will issue a warning which will appear as an
event. This will still happen even if you haven’t detected any NPR forces. You will be notified which fleet or
population received the message. If communication has not been established, you will receive notification of an
„unintelligible communication of unknown origin”. If you have established communication, the text will reflect
the severity of the situation.
This communication can be as mild as a suggestion that your forces leave in the near future and as strong as
demanding you depart immediately or be fired upon. There are five levels of severity for messages and the one
chosen by the NPR primarily depends on the ’Threat Level’ (see below), although it may also issue a stronger
warning at lower threat levels if the NPR believes that war will soon follow without a player withdrawal.
The threat level is based on three factors; the NPR’s estimate of the value of the system, any status modifiers
due to the existing diplomatic relations and the Xenophobia of the NPR. This is calculated as follows:
RacialXenophobia
T hreatLevel = BaseT hreatLevel ∗ StatusM odif ier ∗ )
100
Base Threat Level
Secondary 2.5
Primary 5
Core 10
Capital 20
Status Modifiers:
Friendly Status = 0.5
Neutral with Diplomatic Points >= 1
Neutral with Diplomatic Points < 0 = 2
In addition to the messages, the threat levels generate a negative impact on diplomatic relations. The
penalty in diplomatic points for intrusion into NPR territory is based on the Threat Level above plus the ships
and population that the NPR can detect. The calculation for the annual point penalty is as follows:
p
DP P 2 = T otalDetectedShipT onnage + T otalDetectedP opulationEM Signature ∗ 10 ∗ T hreatLevel
2 DPP - Diplomatic Point Penalty
6
Each construction phase, the diplomatic penalty applied is equal to the annual penalty multiplied by
ConstructionP haseLength
Y ear
Shipping Line vessels will be ignored for this purpose if a trade treaty is in force. NPRs will treat ships
without military engines that have not demonstrated any weapon capability as 10% of their normal tonnage.
If at least one ship is detected, the minimum rating for Detected Ship Tonnage will be 1000 tons. If at least
one population is detected, the minimum rating for Population EM Signature will be 100. NPRs deduct 10,000
tons from the tonnage of one Diplomatic Ship (see section 10) per system for threat purposes if that class type
has never fired weapons and the Diplomatic Ship is in a non-Core system. If the NPR only has one system, it
is not treated as core for this purpose.
This table shows the diplomatic point penalties for different ship tonnages in different value systems, as-
suming an NPR Xenophobia of 50. For populations, use EM Signature * 10 for ‘Tonnage’.
√ Annual Diplomacy Penalty Construction Phase Penalty
Tonnage Tonnage Secondary Primary Core Capital Secondary Primary Core Capital
1000 31.6 39.5 79.1 158.1 316.2 0.5 1.1 2.2 4.3
3000 54.8 68.5 136.9 273.9 547.7 0.9 1.9 3.8 7.5
10000 100.0 125.0 250.0 500.0 1000.0 1.7 3.4 6.8 13.7
30000 173.2 216.5 433.0 866.0 1732.1 3.0 5.9 11.9 23.7
100000 316.2 395.3 790.6 1581.1 3162.3 5.4 10.8 21.7 43.3
300000 547.7 684.7 1369.3 2738.6 5477.2 9.4 18.8 37.5 75.0
1000000 1000.0 1250.0 2500.0 5000.0 10000.0 17.1 34.2 68.5 137.0
The warning message is issued during the first construction phase after detection and repeated during each
subsequent construction phase where the violation still exists. Allied Races do not receive warnings as they can
freely enter the NPR territory. Hostile races do not receive warnings as they are attacked instead. Trading will
allow some exceptions to the rules above and I’ll cover that in a future post. I will also cover situations where
the NPR considers claiming a system with a large existing player population in the ’Alien Controlled’ update.
5 Claiming systems from NPRs
Original post can be found here.
In the same way that NPRs can warn players to leave a system, a player can warn an NPR. On the Intel-
ligence and Foreign Relations window, there is a tab for Known Systems for each NPR. You can select a system
and then set a ’Protection Status’ for the selected system in connection with the selected NPR. Alternatively,
you can set a protection status for the system on the galactic map and that status will be set for any alien race
when they are first detected in the system. The six statuses are shown below with their ‘Demand Number’ (0-5)
and their ‘Demand Strength’.
Protection Status
0 No Protection: 0
1 Suggest Leave: 1
2 Request Leave: 1.41
3 Request Leave Urgently: 1.73
4 Demand Leave: 2
5 Demand Leave with Threat: 2.24
If you set a status for a specific combination of system and NPR, then if that NPR is detected by you in
that system during a construction phase it will be informed of your demand unless it is already allied or hostile.
The impact of the message on the NPR decision to accept or reject your demand is shown by the ‘Demand
Strength’ in the list above, which is the square root of the ‘Demand Number’. A Request is 41% more likely to
work than a Suggestion, while a Demand with Threat is 2.24x more effective than a Suggestion. The Demand
Value represents the idea that, from the perspective of the NPR, the forcefulness of your language may represent
a willingness to use force.
While the strength of your demand plays a part in the NPR decision, it also has a significant effect on relations
with that NPR. So a higher demand might increase the chance the NPR will leave, but it also increases the
chance of starting a war. If you demand the NPR leaves a system it doesn’t care about you will cause fairly
minor damage, but you could have made a polite request and it may have left with hardly any impact on
relations. If you demand an NPR abandons what it regards as a primary system, that might work if you have
a significant military advantage and the NPR is aware of it, but it might also cause the NPR to open fire
immediately.
7
System Values
Neutral 1
Claimed 2
Secondary 3
Primary 4
Core 5
Capital 6
This relationship impact is equal to DemandN umber2 ∗ SystemV alue2 ∗ Xenophobia 50 . So a demand to leave
a primary system would have the impact of 256 ∗ Xenophobia
50 , while a request to leave a claimed system would
have an impact of only 16 ∗ Xenophobia
50 .
The demand will be rejected if the NPR has not detected populations of your race with a total EM signature
of 10 ∗ Xenophobia or more. The NPR will base this on actual populations, not currently detected populations,
as it is assumed you will provide the necessary evidence to back up your demand.
Otherwise, the demand will be accepted based on Demand Value plus the following additional factors:
Accessible System Value
For each system that would no longer be accessible if the claim was accepted, including the target system, a
alue2
value is assigned equal to SystemV
4 . For example, a Claimed system is worth 1, a Secondary system is worth
2.25, a Primary system is worth 4, etc. Each individual system value is calculated first and then the results are
summed.
Military Advantage
This assessment depends on the total size of your military forces that have been detected by the NPR during the
last five years in comparison to its own (with an assumption of some as-yet-unseen forces) and its assessment of
relative technology based on its observation of your ships. I don’t want to go into too much detail on the Player
Military Advantage, but if the NPR believes the racial balance of forces is equal, Player Military Advantage
will be equal to 1. For the NPR to believe you have an advantage, it will need to see some firepower. This is
based on total known forces, not local known forces, so generating a high Military Advantage number is difficult
unless you show off a large portion of your forces. You won’t be able to simply send in a survey ship and ask
the NPR to move out
Population Factor
This is equal to: s
T otalEM Signatureof P layerP opulationsinSystem
T otalEM Signatureof N P RP opulationsinSystem
However, this factor can never be higher than the fourth root of T otalEM Signatureof P layerP
100
opulationsinSystem
.
For example, if the player had 1000 EM Signature and the NPR has 200 EM Signature, the factor would be
1.78 (because the fourth root of (1000/100) is lower than 1000/200. This is to limit the advantage when the
p
populations are relatively small or the NPR has no populations. Population Factor is the best ’peaceful option’
as demonstrating a large population is much more likely to achieve a decision in your favour.
Resistance
(Xenophobia + M ilitancy + Determination)
150
If the NPR has low militancy, low determination and low xenophobia, it will be much easier to push around,
and vice versa. This is difficult to assess because it is an unknown factor.
If
M ilitaryAdvantage ∗ DemandV alue ∗ P opulationF actor > AccessibleSystemV alue ∗ Resistance
the NPR will accept the claim.
For example, if the NPR has militancy, determination and xenophobia all at 50, then the value to overcome
for a Secondary system is 2.25. If there are no populations and you use ‘Demand Leave’ which is worth 2x,
you will need a Military Advantage greater than 1.125. Making this demand will cause a negative relationship
impact of 42 ∗ 32 ∗ (50/50) = 144. If you have a significant advantage in population in the system, then you
require a smaller military advantage or can use a lesser demand.
If the NPR rejects your demand to withdraw, the protection status for that system for that NPR is reset to
No Protection, so that further diplomatic penalties are not incurred. If you want to re-instate the demand (at
whatever level), it will generate a new penalty.
If the NPR decides it must withdraw based on its assessment of the situation, it will evacuate its ships and
transfer any colonies to your control. These will start at a status of Occupied. The system will be set to ’Alien
8
Controlled’ (Player controlled) from the perspective of the NPR and it will ignore the system when deploying
forces. This will change if conflict breaks out.
Note that the player vs NPR and NPR vs player functionality for claiming systems are a little different.
Both sides can send messages to each other and the types of messages are effectively the same. The difference
is the method of delivery and the potential reaction. This is because I wanted to give the player maximum
flexibility in Diplomacy, while still proving a structured approach for the NPR. For example, the player view
of the NPR in terms of diplomatic points does not drop if the NPR ignores demands to leave. The player can
decide whether it is necessary to go to war.
6 NPR vs. NPR claims
Original post can be found here.
NPR vs NPR Diplomacy works as a combination of NPR vs Players and Player vs NPR.
As described in section 4, when an NPR detects alien forces in a system that is claimed by the NPR, the
NPR will issue a warning. When the target is a player this appears as an event message as per section 4. When
the target is another NPR, the first NPR sets a protection status (in the same way as a player does in section
5 that corresponds to the same demand level as it would send to a player.
For example: An NPR detects an alien force in a system that it claims and decides this represent a threat
level of 12. If the alien is a player, the NPR will send a message to the player that will appear as an event.
The message will be on the lines of "We demand you leave" and that message will continue to be sent each
construction phase. If the target is another NPR (let’s call this NPR-B), then NPR-A will set a protection
status of ’Demand Leave’ instead.
Next phase (or in some cases later in the same phase), NPR-B will see the withdrawal demand from NPR-A,
just as it would see a similar demand from a player. It will react to that demand in exactly the same way except
for one crucial difference; NPR-B will not reduce the diplomatic points for NPR-A.
So why all the messing about with slightly different methods for Player vs NPR, NPR vs Player and NPR
vs NPR? Because NPRs, even though they are much smarter in C#, will still not have the human capability to
make intuitive estimates weighing the strategic benefit of claiming a system claim vs the potential downsides of
reduced diplomatic relations. This strategic deficit in AI vs human ability is handled by the different reactions
to claims.
• Player vs NPR: The NPR will generally react negatively to being asked to leave a system, as that is a
relatively easy to understand situation, and it can make a reasonable estimate of whether to abandon
that system. The player does not react negatively to the NPR refusing to leave in game mechanics terms
because the human player can make decisions himself about whether to treat the NPR differently. This
also means that continual messages can be sent to remind the player without diplomatic penalties in-game.
• NPR vs Player: The NPR will react negatively to player forces being in one of its systems, as that is also
a relatively easy to understand situation. The negative impact is based on the importance of the system
and the size of the player force. The player does not react negatively to the NPR asking him to leave in
game mechanics terms because the human player can make decisions himself about whether to leave or
treat the NPR differently.
• NPR vs NPR: NPR-A will react negatively to NPR-B forces being in one of its systems, as that is also a
relatively easy to understand situation. The negative impact is based on the importance of the system and
the size of the NPR-B force. NPR-B will decide whether to leave the system but will not react negatively
to being asked to do so. This allows the protection level to be reset each time without negative impact
(so the NPR doesn’t have to consider the huge variety of factors on when to make a new demand). Also,
NPR-B may well regard the system as one of its own and will be making its own demand of NPR-A, in
which case it will react negatively to a refusal from NPR-A.
The difference is that the NPR is always faced with an immediate decision and does not have to consider
wider implications. The player has the ability to take those wider implications into consideration and is free
to make his own decisions on relationships. When NPRs do confront each other, either one will leave because
the system is not important or they will start making demands of each other, which takes care of the dual
negativity. I know it sounds complex, but I think it the best option to handle the different situations.
9
7 Restrictions on NPR claims
Original post can be found here.
There are several situations where NPRs will not make territorial claims:
• If the NPR and the alien race share a capital system, no claims will be made in the capital system or in
any adjacent system
• The NPR will not make claims against an alien race with whom it shares a Fixed Relationship due to a
Truce Countdown
• The NPR will ignore claims from an alien race with whom it shares a Fixed Relationship due to a Truce
Countdown and there will be no diplomatic penalty
• The NPR will not claim a system if there are alien populations with a total EM signature greater than
10% ∗ (Xenophobia/100) of its own capital’s EM signature and also greater than the total EM signatures
of any AI populations in that system. The existence of populations will be based on intelligence data
rather than current contacts.
The above is based on the concept that an AI is unlikely to claim a system where it knows there is a good
chance that claim will cause a war. Note that from the NPR perspective an ’alien race’ includes player races.
8 Independence
Original post can be found here.
In C#, you can declare a colony independent using a button on the Economics window. Colonies may also
become independent in other situations, such as a rebellion following high unrest. Independence is far more
complex than it first sounds, because the population will be under the control of a new race that is essentially
a copy of the original race. The process is as follows:
• The title of the new race will be based on the name of the newly-independent population.
• A new flag will be auto-selected and random naming themes chosen for classes, systems, etc.. Commander
name themes will remain the same as the original race.
• The ranks of the new race will copy the ranks of the original race.
• Any ground forces at the population will be transferred to the new race.
• It is possible that an NPR population can become independent, in which cases it will retain the same tech
but create a new design philosophy.
• The new race will start with an amount of wealth equal to total original race wealth * (independent pop
size / total original race pop size before independence), which will be transferred from the original race.
• The new race will start with a number of commanders equal to original race number of commanders ∗
(IndependentP opSize/T otalOriginal) race pop size before independence). These are new commanders
and not transferred from the original race.
• A top-level admin command will be created at the population.
The new race will gain the following knowledge from the original race:
• The same galactic map, including map labels.
• All geological and gravitational survey data.
• All tech systems.
• How to build all ship components and missiles.
• All class designs.
• All ground unit class designs.
• All ground formation templates.
10
• All intelligence data, including alien races, classes, ships, sensors, weapons, populations and ground forces.
• A complete set of intelligence information on the original race which will be set up as a new alien race,
with known systems, ships, etc.
• Control Race flags on galactic map.
• Protection Status settings for different combination of alien races and systems.
• Locations of ruins, anomalies, wrecks, etc..
• Event colours.
For manual independence, any naval forces will have to be transferred using the Transfer Fleet option. In
the case of a rebellion, some ships may be transferred automatically.
9 Banned bodies
Original post can be found here.
If a non-spoiler NPR has a relationship of neutral or higher with another race, it will generally avoid
approaching ’banned bodies’.
An NPR will decide for itself which bodies are banned, but in general these will include:
1. Bodies that have an alien race population of approximately ten million or more
2. Bodies that are moons of any bodies in (1)
3. Bodies that are moons and share the same parent body as any body in (1)
4. Bodies on which the NPR already has a population will be exempt from the above rules
NPRs will not create populations on banned bodies and will not attempt to conduct geological surveys on
those bodies. The NPR will not generate points of interest within a few million kilometres of banned bodies. It
is still possible that NPR ships will approach due to other considerations, such as moving between two points
unrelated to banned bodies, but in general this should prevent the VB6 situation of NPR battle fleets making
port visits to your home world.
The banned bodies list is updated at game launch and during each construction phase. Banned bodies do
not exist for populations of races with which the NPR has a hostile relationship. If there are two populations
on a planet, one of which is hostile to the NPR and one neutral, the body will not be banned.
For example, in the Space 1889 campaign, the Martians will generally avoid Venus, Earth, Luna, all the
moons of Jupiter and all the moons of Saturn. They will still survey the Trojan asteroids and they still may
pass close to the banned bodies when on an unrelated mission.
NOTE: I looked at various ways of applying this in reverse. The NPR would generate a list of important
planets and check for player race ships within a certain range, perhaps ten million kilometres. If they were
detected, that would trigger a response, even if the NPR would otherwise not object to the player being in the
system. The problem is that the player would have to be checking each ship path to ensure that didn’t happen.
I even added code to avoid this problem by only flagging player ships that remained within ten million in two
consecutive construction phases, but even that is not foolproof. Essentially, the player knows the NPRs is trying
to avoid his populations and will react to NPR movements accordingly, but understanding that is much more
difficult for the AI. In the end the game play benefit is outweighed by the considerable micro-management required
on the part of the player, or by the amount of code that would be needed to avoid accidentally passing through
restricted zones. In most situations, the player would want to avoid being detected anyway so this situation
would usually only be relevant where a truce countdown is in effect and the player and the NPR share the same
home system. The player can RP that situation if needed.
10 Diplomatic ships
Original post can be found here.
A Diplomatic ship is any ship equipped with a Diplomacy Module. These can be built by the player or by
NPRs.
11
Diplomacy Modules and therefore Diplomatic Ships are important for communication attempts and essential
for basic diplomacy (influencing an alien race to view your race more positively). See section 3 for more details.
When a Diplomatic Ship is involved in diplomacy or communication attempts, the opposing race will know
the origin of those messages. If the Diplomatic Ship is on opposing sensors, the identity of that ship will be
noted in an event for the opposing race and its parent class will be flagged as a diplomatic vessel. If diplomacy
is underway, the name of the Ambassador will also be passed to the opposing race.
If the Diplomatic Ship is not on opposing sensors, the location of the signal from that ship will be commu-
nicated to the opposing race. This may be a system body, a jump point or simply a point in space.
Any damage to NPR Diplomatic ships, regardless of whether the opposing race knows that status, will be
treated as triple damage for the purposes for affecting diplomatic relations. If a diplomatic ship is attacked
without an existing hostile relationship, the relationship will fall to -300 from the perspective of the owner of
the ship (rather than the normal -100 for attacking when not hostile).
12
Part III
Star System Design
11 Modifying stars
Original post can be found here.
C# Aurora allows you to manipulate star systems in SM Mode. While it would be difficult to design a
system during the original generation process, due to the complexities involved, you can now add or modify
stars and system bodies. This post covers modifying stars.
You click on a star in the System View and then click Change Star. The dialog below pops up and allows
you to select spectral class, orbital distance, bearing and parent star. Here is an example from my current test
Figure 1: Star Setup
campaign that changes the B component of Alpha Centauri from a K1-V star to an F0-V, which is much hotter.
The star will orbit more quickly due to the increased mass, plus all the planets orbiting the star are affected
by the increased mass and luminosity of the different star. Temperatures will change, along with potentially
hydrosphere type and atmospheric composition (as gases freeze out or boil). Oceans or ice sheets may convert
entirely to water vapour given a significant temperature rise. Planets may change their tide-locked status.
Figure 2: Star Setup Example 1
13
Figure 3: Star Setup Example 2
These two screenshots show the effect of moving the star further from the primary.
Figure 4: Engineering Example 1
14
Figure 5: Engineering Example 2
12 Adding stars
Original post can be found here.
Adding a new star is straightforward. You click Add New Star. The dialog below pops up and allows you
to select spectral class, orbital distance, bearing and parent star.
Figure 6: Adding Star
This screenshot shows the result of adding the above star to the Alpha Centauri system. New stars do not
have any planets or other system bodies. These are added separately and will be covered in a future post.
15
Figure 7: Adding Star Result
13 Modifying system bodies
Original post can be found here.
Modifying system bodies is a more complex process than stars due to the number of factors involved. There
are factors that are tied to each other, such as mass, radius, density and gravity, plus certain types of bodies
have different rules (planets vs moons, gas giants vs rocky worlds).
Therefore, the following factors can be changed; distance to parent body, diameter, density, hydro extent,
albedo, atmospheric composition and dominant terrain. The dominant terrain is restricted to those terrains
permitted by the other factors. Factors such as colony cost, gravity, temperature, atmospheric pressure, length
of year, maximum population, tidal lock status, atmospheric retention, time required to stabilise a Lagrange
point, etc. will all be derived from the factors that can be changed. For example, if you change the diameter or
density, the mass and gravity will automatically change. If you change the distance to parent, the temperature
and year will change and perhaps the tidal lock status. Finally, factors such as escape velocity, magnetic field,
etc. are not shown here because they have no current game play impact, even though escape velocity will change
as a result of modifications to density or diameter.
The basic type of system body (terrestrial, dwarf, etc.) cannot be changed, but it will be possible to delete
one system body and add a new one of the desired type. This is to ensure all system bodies follow the basic
rules of their type, even if they are later modified.
Below is the System Body Modification popup window. You can change the green fields in the top left, the
dominant terrain dropdown and can add and remove atmospheric gases by choosing a gas and the desired atm
(0 to remove). As you make each change, everything else updates.
16
Figure 8: System Body Modification
For example, here is what happens if the diameter is halved. Gravity, mass and max population all fall,
while the terraform rate vs Earth and the time to stablise a Lagrange point both increase.
Figure 9: System Body Modification Result
14 Deleting stars and system bodies
Original post can be found here.
Deletion of stars or system bodies is straightforward. Click on the target object and then click Delete Body
or Delete Star. You will be given two popup warnings and then the object will be deleted. Deleting a star will
remove any system bodies in orbit. Deleting a planet will remove any moons of that planet. Any populations
on affected system bodies will be deleted. Deleting the primary star is not possible.
When a star is deleted, any remaining stars will be renamed accordingly. For example, if you delete the B
component of a primary, the original C component will now become the B component. When a planet or moon
is deleted, the orbit numbers of the planets or moons will be adjusted accordingly.
For example, here are the before and after views of the Alpha Centauri-A system when the fourth planet is
deleted.
17
Figure 10: Deleting Stars And System Bodies
Figure 11: Deleting Stars And System Bodies 2
15 Adding planets, comets and asteroid belts
Original post can be found here.
18
Below is the form for adding all new system bodies except for additional moons. You choose a system body
from the drop down, which includes Terrestrial, Dwarf Planet, Gas Giant, Superjovian, Comet and Asteroid.
Each body type has a distance parameter plus one or more other additional options.
• For terrestrial and dwarf planets you have a toggle for automatic moon generation and can choose a
specific or random number of moons.
• For gas giants and superjovians, you have the above moon options plus similar options for Trojan asteroids
(on/off, random/specific).
• For comets, you choose the starting distance and maximum distance.
• For asteroid belts, you can choose a random or specific number of asteroids and the specific or random
width of the belt (how far an asteroid can be generated from the centre of the belt).
Once the planet parameters are selected, press OK and the new body or bodies will appear in the System
View. You can select them and use Modify Body to customise if desired.
The various zones shown at the top affect how Aurora determines parameters such as atmosphere, hydro-
sphere, mineral deposits, albedo, density, number of moons, total mass of asteroid belts and a variety of other
factors. There is far too much detail to list, but generally bodies in the life zone will have better conditions and
mineral deposits, followed in decreasing order by Inner, Outer and Extreme. These zones also exist in VB6.
Of course, those factors only affect initial generation so you can override that by directly modifying a body
post-creation.
Figure 12: Add Planet Example
16 Adding moons and Lagrange points
Original post can be found here.
Below is the form for adding moons to existing planets. During planet creation you can specify appropriate
moons to be created at the same time using standard moon generation based on the type of planet and is orbital
distance. This form, accessed via the Add Moons button, is for creating additional moons which do not have to
obey normal size restrictions. The form allows the addition of up to five moons (the drop-downs all start with
no moon) with type and distance specified. If more than five moons are needed, the form can be used multiple
times for the same parent planet.
After initial generation you can use Modify Body to specify additional detail if required.
The Add Lagrange button adds a Lagrange point to the currently selected body, even if it would not normally
qualify for one.
19
Figure 13: Add Moons Example
17 Deleting asteroids and Lagrange points
Original post can be found here.
Deleting individual asteroids can be done by using the Delete Body button. To delete an entire asteroid belt
or all the Trojan asteroids for a particular planet, click one of the asteroids in the belt or one of the Trojans
and click Delete Asteroids. There will be two warnings before all the affected asteroids are deleted.
Lagrange Points can be removed by selecting the parent system body and clicking Remove Lagrange.
Below is the final version of the System View in SM mode with all system engineering buttons present.
Figure 14: Deleting Lagrange Points
20
Part IV
Weapons
18 Missiles
18.1 Missile updates
Original post can be found here.
The following changes will be made to missiles in C# Aurora:
1. Missile Armour has been removed.
2. Laser warheads have been removed (I may add these back at some point in the future).
3. ECM is now a fixed 0.25 MSP for missiles. The ’Missile ECM’ tech line has been removed and if a missile
is equipped with ECM it will have the same ECM capability as the current racial ECM technology, The
missile design will maintain that ECM capability and will not be upgraded if the racial tech improves. For
each level of ECM, the missile will be 10% harder to hit with energy weapons and will reduce the lock of
missile fire controls by 10%. This can be negated by linking a similar level of ECCM to the point defence
fire controls.
4. Missiles can be equipped with ECCM, which is a fixed 0.25 MSP. The missile ECCM level will be equal
to the current racial ECCM tech. In C# Aurora, the ECCM of missile fire controls will only affect the
range at which the fire control can lock on. The ECCM of the missile itself will affect the chance of the
missile striking its target, if that target has active ECM.
5. Any missile sensor (active, thermal, EM or Geo) has to be a minimum of 0.25 MSP or it will have no
effect.
6. Missile series have been removed. Instead, there will be more detailed class loadout options.
These changes will make electronic warfare much more important for missile combat. Missiles with ECM will
become harder to shoot down and missiles without ECCM will have a reduced chance to hit targets equipped
with ECM. Anti-missile missiles will either be less effective, or larger, vs ECM-protected missiles, while anti-ship
missiles are likely to increase in size (and therefore reduce salvo sizes). Large volleys of size-1 missiles will be
less effective in a heavy EW environment and no longer have a huge advantage in launching speed (due to the
missile launcher changes).
18.2 Missile engines
Original post can be found here.
In C#, Missile Engines follow the same size-based fuel consumption rules as Ship Engines using the formula:
r
10
F uelConsumption =
EngineSizeinHS
The above increases the fuel consumption of missile engines based on size alone. However, VB6 also had a
flat x5 multiplier for the overall fuel consumption for missile engines as they were treated as a different engine
type than ship engines. As C# is aiming for consistency between ship and missile engines, this x5 multiplier
cannot remain as it was before. Removing the x5 multiplier entirely would cancel out the fuel consumption
increase resulting from the changes in the size-based fuel consumption calculation. As one of the objectives
of C# is a reduction in missile ranges, a new rule is required that increases fuel consumption but that is still
consistent with ship engines.
Therefore, the calculation for fuel consumption based on boosting engines will now include an additional
multiplier if the boost being used is higher than the maximum racial boost tech. Only missile engines have
the capability to use higher boosts than the racial maximum, so this still allows consistency between ship and
missile engines in the spectrum where they both operate. Once you move outside of the boost range possible for
ships, additional fuel consumption can be added without breaking consistency. This rule adds a linear multiplier
21
from 1x to 5x depending on the level of boost beyond the racial maximum. The formula is as follows:
if BoostU sed > M axBoostM ultiplierT ech then
BoostU sed − M axBoostM ultiplierT ech
HighBoostM odif ier = ∗4+1
M axBoostM ultiplierT ech
So if a race has Max Boost Tech of 2x, any missile with a Boost Level of 2x or less will use the standard
boost fuel modifier calculation of BoostLevel2.5 .
Above a Boost Level of 2x, the linear High Boost Modifier will come into effect, reaching a maximum of 5x
fuel consumption at 4x Boost Level.
Here is a comparison between VB6 and C# using MPD engines and an engine size of 1 MSP. The Max
Boost Tech for this race is 2x:
VB6 Missile Engine with 2x Boost
Engine Power: 1.6 Fuel Use Per Hour: 81.51 Litres
Fuel Consumption per Engine Power Hour: 50.944 Litres
Engine Size: 1 MSP Cost: 0.4
Thermal Signature: 1.6
Materials Required: 0.4x Gallicite
Development Cost for Project: 80RP
C# Missile Engine with 2x Boost Engine Power 1.60 Fuel Use Per Hour 76.8 Litres
Fuel Consumption per Engine Power Hour 48.0 Litres
Size 1.00 MSP (2.5 tons) Cost 0.80
Development Cost 80 RP
Materials Required
Gallicite 0.80
VB6 Missile Engine with 4x Boost
Engine Power: 3.2 Fuel Use Per Hour: 922.18 Litres
Fuel Consumption per Engine Power Hour: 288.182 Litres
Engine Size: 1 MSP Cost: 0.8
Thermal Signature: 3.2
Materials Required: 0.8x Gallicite
Development Cost for Project: 160RP
C# Missile Engine with 4x Boost
Engine Power 3.20 Fuel Use Per Hour 4344.5 Litres
Fuel Consumption per Engine Power Hour 1357.6 Litres
Size 1.00 MSP (2.5 tons) Cost 1.60
Development Cost 160 RP
Materials Required
Gallicite 1.60
18.3 Missile launcher changes
Original post can be found here.
Missile Launchers have undergone significant changes in C# Aurora.
1. Fractional-size launchers can be created. The minimum is still 1 HS but a launcher can now be 1.1 HS,
2.7 HS, etc.
2. The reduced-size launcher techs are all available immediately and do not need to be researched. This
means box launchers are available from the start. The progression for reduced size launchers has been
altered slightly:
22
0.75 HS 2x Reload
0.6 HS 5x Reload
0.4 HS 20x Reload
0.3 HS 100x Reload
0.15 HS 100x Reload (Box Launcher)3
If a box launcher containing a missile is damaged, the missile will explode. The chance of this happening
can be reduced by a new tech line. The first step reduces the explosion chance to 70% for 1000 RP and the
last step reduces to 5% for 120,000 RP. In addition, Box launchers can only be reloaded in a hangar, or at an
Ordnance Transfer Point (a Spaceport, Ordnance Transfer Station or Ordnance Transfer Hub). Reloading at
an Ordnance Transfer Point is 10x slower than in a hangar (similar to the penalty for maintenance facilities in
VB6 Aurora).
The base reload rate for all missile launchers is now:
√
M issileSize ∗ 30seconds ∗ ReducedSizeM odif ier
M issileReloadRate =
ReloadRateT ech
Assuming a race has reload rate tech of 3, a normal size 1 launcher will reload in 10 seconds, a size 4 will
reload in 20 seconds and a size 9 will reload in 30 seconds. This change will dramatically reduce reload times
for larger launchers.
The change for box launcher reload rate from x15 to x100 is not as dramatic as it seems for larger missiles
due to the new reduced reload times for larger missiles. However, it is still an significant increase from VB6. A
size 4 missile mounted on a box launcher will now take about 1h 40m to reload in a hangar and about 17 hours
for an ordnance transfer point. A size 6 is about 2 hours and 20 hours respectively.
These changes are intended to:
1. Reduce the disadvantage of larger missiles
2. Remove the realism issue of not having box launchers available at low tech yet make box launchers a more
difficult decision vs standard-type launchers
18.4 Box launcher reloading
Original post can be found here.
In VB6 Aurora, box launchers can be reloaded in a hangar or at maintenance facilities. For C# Aurora, box
launchers can only be reloaded in a hangar, or at an Ordnance Transfer Point (a Spaceport, Ordnance Transfer
Station or Ordnance Transfer Hub). Reloading at an Ordnance Transfer Point is 10x slower than in a hangar
(similar to the penalty for maintenance facilities in VB6 Aurora).
Because of the changes to maintenance facilities in C# Aurora, it will be a lot easier to forward deploy
facilities for full-size warships, both on planets and in space, which would increase the potential of box launchers
if they could still use those facilities to reload, especially given they are immediately available in C#. The
introduction of ordnance-specific facilities for C# provides a good alternative.
The existing changes post for Missile Launchers section 18.3 has been updated to take account of this new
rule.
18.5 Missile thermal detection
Original post can be found here.
In VB6 Aurora, the thermal detection of missiles is based on the following formula:
M issileSize Speed
T hermalSignatureV B6 = ∗
20 1000
I have no idea why I coded thermal detection for missiles to be based on size, although I am sure it seemed
like a good idea at the time :). For C# Aurora, missiles will use the same formula as ships for thermal signature:
CurrentSpeed
T hermalSignatureC# = M axEngineOutput ∗ ∗ T hermalReduction
M axSpeed
3 Note that reload for this was x15 in VB6
23
As missiles (for now anyway), don’t have thermal reduction or an option to travel below maximum speed,
their thermal signature is equal to the power of their engines. Combined with the changes to passive detection,
this means that missiles in C# Aurora will probably be detected by thermal sensors at much greater distances
than in VB6 Aurora.
18.6 Magazine design
Original post can be found here.
There are several changes to magazine design for C# Aurora.
• The ’ejection’ tech line has been replaced by the Magazine Neutralisation System. It is functionally
identical but in technobabble terms this is a system design to render missile warheads permanently inert
in the event of damage to the magazine.
• Magazines have a base HTK number equal to the square root of their size (rounded down). in VB6
Aurora, all magazines have a base HTK of 1, regardless of size. It is still possible to add extra HTK in
C# by sacrificing internal space.
• The explosion chance for a magazine is divided by the square root of its size. For example, if a size 1
magazine has a base explosion chance of 15%, the equivalent tech size 5 has an explosion chance of 6.71%,
the size 10 is 4.74% and the size 20 is 3.35%.
• If the ship has a Chief Engineer, any explosion chance (for magazines or engines) is reduced by his
Engineering Bonus. So a 5% explosion chance would be reduced to 3.5% by a Chief Engineer with an
Engineering bonus of 30%.
• When a magazine is hit, a proportion of the remaining ordnance will be destroyed (based on destroyed
magazine capacity / total ship magazine capacity). Any destroyed ordnance will explode with its full
warhead strength. In VB6, only ordnance beyond the remaining magazine capacity explodes and only at
20% strength.
In summary, magazine explosions in C# Aurora will be much rarer, especially for larger ships, but far more
devastating when they do occur.
19 Guns
19.1 Meson update
Original post can be found here.
Mesons have the following changes for C# Aurora:
1. Their cost is based on the same principles as a laser, so mesons will cost the same as an equivalent laser
of the same tech level.
2. Mesons penetrate shields as before but their ability to penetrate armour is now limited.
3. A new tech line exists, Meson Armour Retardation, which is the chance for each layer of armour to stop
the meson. This starts at 50%, then 40%, 32%, etc. finishing at 7% for TL 12
4. If armour does stop the meson, it scores 1 point of damage on the armour.
5. If the meson hits a damaged armour location, it only has to penetrate the remaining armour in that
location.
6. Mesons will destroy missiles without penalty, as missiles are no longer armoured in C# Aurora.
As with everything else, these changes are subject to play test.
24
19.2 Turret update
Original post can be found here.
A minor update. The benefits of multiple energy weapons in turrets have been doubled. A twin turret now
has a 20% reduction in crew vs two solo weapons and has a 10% reduction in gear size. A quad turret has a
40% reduction in crew vs four solo weapons and has a 20% reduction in gear size.
In addition, I found an error in the VB6 code for turret design that meant a turret needed four times more
armour than a ship of equivalent size. This has been corrected for C# Aurora, which means armoured turrets
are now much more viable.
19.3 Beam weapon recharge
Original post can be found here.
In VB6, if a power plant is damaged, it slows down the recharge rate of all weapons by a proportionate
amount.
In C# Aurora, power is allocated weapon by weapon until the available power is exhausted. This means
that some weapons may not be recharged, but the others will be recharged at the maximum rate. Weapons are
charged in order of ascending power requirement. Once a weapon is recharged, it will require no more power
and other weapons can begin the recharge process.
This should allocate power in the most effective way to keep a ship in the fight.
19.4 Weapon failure
Original post can be found here.
At the point when any weapon (energy-based or missile launcher) fires, there is a 1% chance the weapon
will suffer a failure. If sufficient maintenance supplies are available, the weapon will be instantly repaired and
will fire normally. If maintenance supplies are not available, the weapon will be damaged and unable to fire.
This is partially to simulate the stress of combat on weapon systems, but also as a balance to other rule
changes.
19.5 Plasma carronades
Original post can be found here.
1. The development cost of Plasma Carronade focal size has been halved. For example, a 30cm Carronade
is now 4000 RP.
2. The building cost of Carronades has also been halved.
These two changes should make Carronades more viable. A powerful and inexpensive weapon but very short-
ranged.
19.6 Particle lance
Original post can be found here.
This is a copy of a post in the VB6 7.2 Changes List. I didn’t release the updated VB6 version so this is
still a change from the released VB6 Aurora.
The Particle Lance is a large, potentially devastating weapon that is variant of the Particle Beam.
Once Particle Beam Range 200,000 km and Particle Beam Strength 6 have both been researched, the Particle
Lance can be researched for 30,000 RP. The Lance is a modification of the normal Particle Beam and is an
extra option in the design window.
The Particle Lance modification affects the Particle Beam in the following ways:
2x Damage
25
2x Size
2x HTK
2x Crew
2.5x Power Requirement
3x Cost
2x Development Cost
As well as the above modifications, which essentially creates a weapon twice as large, that recharges 2.5x
more slowly and costs 3x as much, the damage template of the Particle Lance is a single column of armour,
rather than the Particle Beam which has a template between that of missiles and lasers. The Particle Lance
retains the constant damage of the Particle Beam, creating a weapon that can penetrate enemy armour at
significant range.
Here are examples of similar tech level Particle Beam, Particle Lance and Laser.
Particle Beam
Beam Strength 6 Rate of Fire: 15 seconds Maximum Range: 240,000 km
Particle Beam Size: 8 HS Particle Beam HTK: 4
Power Requirement: 15 Power Recharge per 5 Secs: 5
Cost: 94 Crew: 24
Materials Required: 18.8x Duranium 18.8x Boronide 56.4x Corundium
Development Cost for Project: 2250RP
Particle Lance
Beam Strength 12 Rate of Fire: 38 seconds Maximum Range: 240,000 km
Particle Beam Size: 16 HS Particle Beam HTK: 8
Power Requirement: 38 Power Recharge per 5 Secs: 5
Cost: 282 Crew: 48
Lance Weapon
Materials Required: 56.4x Duranium 56.4x Boronide 169.2x Corundium
Development Cost for Project: 4500RP
25cm Far Ultraviolet Laser
Damage Output 16 Rate of Fire: 20 seconds Range Modifier: 5
Max Range 800,000 km Laser Size: 8 HS Laser HTK: 4
Power Requirement: 16 Power Recharge per 5 Secs: 5
Cost: 100 Crew: 24
Materials Required: 20x Duranium 20x Boronide 60x Corundium
Development Cost for Project: 1000RP
(laser will have 320,000 km range with equivalent tech level fire control)
Comparison of Damage Templates at 240,000 km
Particle Beam (6) 2, 3, 1
Particle Lance (12) 12
Laser (3) 3
Two Particle Beams or 25cm Lasers can be installed in the same hull space as the Particle Lance. The Lasers
are devastating at close range, the Particle Beams inflict more damage at long range (in terms of DPS), while
the Particle Lance penetrates much more armour at long range.
The Particle Lance is intended as a powerful anti-ship weapon that requires a large investment in a particular
tech line, lacks the flexibility of lasers or railguns and provides a different armour penetrating option to mesons,
although mesons are still superior against shields. Mainly though it is to boost the Particle Beam as a serious
weapon choice.
The Particle Lance is not tested under normal battle conditions yet so I may change it a little after play-
testing.
20 Point defence
Original post can be found
21 Ordnance transfer mechanics
Original post can be found
26
22 Ordnance transfer orders
Original post can be found
23 Automated weapon assignment
Original post can be found
24 Atmoshpere and energy weapons
Original post can be found
25 Planetary bombardment
Original post can be found
27
Part V
Ground Forces
26 Unit design
Original post can be found here.
Ground Forces and Ground Combat are undergoing a huge expansion in C#. The VB6 Ground Unit becomes
the Formation and the VB6 Ground Unit Type becomes the Formation Template. However, there are no longer
any fixed unit types or unit values. Instead, there is endless scope for Formations and Formation Templates,
based on a detailed design process at the Formation level and below. This will allow the simulation of ground
forces from many science fiction genres. As this is a long topic, I am going to break it into several posts each
covering a different topic.
The most granular level is the Ground Unit Class, which is an individual soldier or vehicle. One or more of
the same Ground Unit Class are grouped into Formation Elements, which in turn are grouped into Formations.
Formations remain intact for movement purposes, but combat involves each individual unit (each soldier or
vehicle). As individual units are now tracked for casualty purposes, readiness no longer exists. Morale is
tracked at the Formation Element level (which is a group of the same unit class), so the infantry in a Formation
may have a different morale than the anti-tank guns or artillery.
The process of design starts with the Ground Unit Class. Two important factors in this design process are
the Racial Armour Strength and Racial Weapon Strength, shown at the top of the Ground Forces window.
Racial Armour Strength is based on the strength of the highest racial armour technology. Conventional
Armour is 3, Duranium Armour is 5, et cetera. For this screenshot, the Commonwealth has researched Ceramic
Composite, which has a strength of 10.
Racial Weapon Strength is based on the highest tech level (TL) among Laser Focal Size, Railgun Type,
Meson Focal Size, Particle Beam Strength and Carronade Calibre. For example, 15cm Laser Focal Size is TL3
as it is the third tech of that type. Racial Weapon Strength is the value of armour at the same tech level. In
this case, the Commonwealth has researched 20cm Laser Focal Size, which is TL4. The fourth Armour Tech
is Ceramic Composite, which has a strength of 10, so the Racial Weapon Strength is 10. The reason for using
Armour as the basis of Weapon Strength is partly because that means Ground Armour and Ground Weaponry
are aligned, and partly because it is straightforward way to assign value based on very different weapons.
The Ground Unit Design tab of the new ground Forces window is shown below. First, a ’base type’ is chosen,
which is infantry, several sizes of vehicle, or static. Static in this sense is a weapon that is not self-mobile, such
as a towed anti-tank gun, towed artillery, et cetera. Static weapons remain in place when firing so they are
easier to hit than infantry or vehicles. Each base type has six main characteristics:
1. Size (in tons): Size is the basis for transport requirements and cost, although there are other modifiers to
cost (discussed below).
2. Hit Points: Unit hit points are compared to weapon damage during combat to determine the chance of de-
struction (the Damage Check). The chance of a weapon destroying a unit is (W eaponDamage/HitP oints)2 .
3. Slots: The number of component slots available for the base type.
4. To-Hit Modifier: Used to modify the chance of the unit being hit during combat (based on the mobility
of the unit). This only applies if the unit is not fortified.
5. Maximum Fortification: The maximum strength to which the unit can be fortified by construction factories
or construction units. The Chance to Hit for a firing unit is divided by the Fortification Level of the target
unit.
6. Maximum Self-Fortification: The maximum strength to which the unit can be fortified without construc-
tion factories or construction units.
The next section is Armour Type. The Armour of a unit is compared to the Armour-Penetration (AP) value
of a weapon. The chance to penetrate is equal to (AP/Armour)2 . For example, a weapon with AP 4 attacking
a unit with Armour 6 has a 45% chance to penetrate. The overall process for checking if a shot destroys a
target is Chance To-Hit, followed by Armour Penetration Check, followed by Damage Check. All three must
be successful to destroy the target. Each type of Armour has two values.
1. Base AR: The Base Armour Rating is multiplied by Unit Size (including components below) to determine
cost. So a unit with 6 armour would be 50% more expensive than the same unit with 4 armour.
28
2. Racial AR: Racial Armour Rating is the Base Armour Rating multiplied by the Racial Armour Strength
(shown at top of window).
Below the base type and armour is a large section showing Components. Infantry, static and light vehicles
all have one ’component slot’, vehicles and heavy vehicles have two slots, while super-heavy and ultra-heavy
vehicles have three and four slots respectively. Each slot can hold one component from the list and the same
component can be put into multiple slots. Certain components are only available with certain base types. For
example, the Super-Heavy Anti-Vehicle component can only be used by super-heavy and ultra-heavy vehicles.
The primary component is selected from the main table, while any additional components are selected from
the dropdown(s) below the main table. Each component has a name and an abbreviation and is rated in nine
different areas:
1. Size: The size in tons is added to the size of the base unit type.
2. Armour-Penetration (AP): If the component is a weapon, the chance to penetrate a target’s armour is
(AP/Armour)2 . The AP Rating is the underlying AP of the component (not shown), multiplied by the
Racial Weapon Strength.
3. Damage: If the component is a weapon, the chance to destroy a target after the armour has been penetrated
is (W eaponDamage/HitP oints)2 . The damage value is the underlying damage rating of the component
(not shown), multiplied by the Racial Weapon Strength.
4. Shots: The number of times a weapon will fire during each ground combat phase.
5. CIWS: ’Y’ indicates this component is a Close-in-Weapon-System, capable of defending the planet (on
which the unit is based) from missile attack. This CIWS will use the values in the CIWS section, which
will become visible when a CIWS component is selected. More on this in a later rules post.
6. STO: ’Y’ indicates this component is a Surface-To-Orbit energy weapon, capable of engaging ships in
space within weapon range of the planet on which the unit is based. The weapon type used for the STO
component can be selected in the section to the centre right, which will become visible when an STO
component is selected. More on this in a later rules post, although see the second screenshot.
7. HQ: The headquarters capacity of the component in tons. This is the total size of the formation (or for-
mation hierarchy) that can be effectively controlled by a commander based in a unit with this component.
To assign a commander to a formation, one of the units within that formation requires a headquarters
component. More details on command hierarchies will be provided in a future rules post.
8. FFD: ’Y’ indicates this component is a Forward Fire Direction (FFD) component. Forward Fire Direction
allows a front-line unit (more on that later) to direct the fire of bombardment units from a formation in
a support position, fighters on close air support missions, or ships in orbit. A later rules post will explain
this function.
9. Const. The construction value of the component in Construction Factory Equivalents (CFEs).
At the top-right of the window is the Capability section. One or more Capabilities can be selected for the
Unit Class. The Boarding Combat capability is required for a Unit to be able to board another ship. For all
other capabilities, the Chance to Hit is doubled in the environment specified. If a unit has multiple capabilities,
such as Mountain Warfare and Jungle Warfare on a world with a dominant terrain of Jungle Mountain, the
bonus is cumulative (i.e. 4x to-hit in this case). Each capability selected for a Unit will increase the cost by the
multiple specified. Some capabilities are only available for infantry units.
In the bottom right section, a summary of the unit is shown in a similar style to the Class Summary for
naval designs. When the sizes of all the units in a formation are aggregated, that is the transport requirement
for that formation in tons. Cost is in BP. When the costs of all the units in a formation are aggregated, that is
the build point requirement to construct the formation. Armour and Hit Points have been described previously.
Below that is a list of components, followed by the materials required for construction and the research cost to
develop the unit once designed.
29
Figure 15: Ground Forces Example 1
This screenshot shows a static unit with an STO component selected. The chosen weapon (which is any
non-turreted weapon developed for shipboard use) is selected on the right. Spinal Weapons can be selected for
ground use without penalty. The STO mount includes the weapon, a reactor of the exact size needed for the
recharge rate, an active sensor with range greater than the weapon range and a built-in beam fire control with
a 4x range modifier. The cost is equal to the static platform, the weapon, the reactor, the active sensor and
half the fire control. STO weapons have a 25% bonus to fire control range. The damage shows two numbers,
which is the damage at minimum and maximum range.
Figure 16: Ground Forces Example 2
30
27 Formation templates
Original post can be found here.
The screenshot below shows the Formation Templates tab of the Ground Forces window. Formation Tem-
plates are the equivalent of VB6 Ground Unit Types, although it might be easier to think of them as serving
the same function as Ship Classes. They are a detailed design that serves as a template for building Formations
based on that same design, which is the same relationship as Ship Classes to Ships.
This tab is split into two halves. On the left is a list of available Ground Unit Classes created using the
Unit Class Design tab (as explained in the previous rules post). All of these were created using TL4 technology,
with three exceptions. For comparison purposes, the Challenger 2 Main Battle Tank and the Warrior AFV were
created using Conventional, rather than Trans-Newtonian, technology, while the Challenger Base TN Upgrade
was the Challenger design with TL1 technology. It should be possible to simulate most modern army units with
the new C# Aurora ground combat, so you could theoretically be landing on an alien world with Abrams and
Bradleys or T-14 and T-15 Armatas. The ten columns for the Unit Class List are as follows:
1. Type: An abbreviation for the Base Type (infantry, Vehicle, Heavy Vehicle, etc.)
2. Name: The name assigned during Unit Class Design. This can be changed using the Rename Unit button.
3. Size: Transport size in tons.
4. Cost: Cost in Build Points.
5. Arm: The Armour Strength of the Unit. This is based on the armour available at the time of design and
is not upgraded when newer technology becomes available (as with ship designs).
6. HP: The Hit Points of the Unit. This is set at design time and does not change.
7. Components A to D: Abbreviations for each of the components included in the Unit Class. These are the
same abbreviations as used on the Components table in the Unit Class Design tab. As with armour and
hit points, any components use the technology available at the time of unit design. To see the detailed
view of the components, click on the Unit. The Unit Summary will be shown in the bottom section on
the left hand side.
As an example, the Leman Russ Battle Tank is a Heavy Vehicle of 104 tons, with 60 Armour and 60
Hit points, costing 12.48 BP. The components are Heavy Anti-Vehicle (HAV) and Heavy Crew-Served Anti-
Personnel (HCAP). Looking at the summary, the HAV has 1 shot per combat phase with Penetration 60 and
Damage 60, while the HCAP has 6 shots with Penetration 20 and Damage 10.
The right-hand half of the tab shows Formation Templates. A new Formation Template is created by
clicking the New button. In this case, four have already been created. Each Template comprises one or more
Template Elements, shown in the bottom right section Each Template Element has a specific number of specific
Ground Unit Class. For example, the Guard Armoured Regiment is currently selected, which has four template
elements: 60x Leman Russ Battle Tank, 1x Macharius Command Tank, 12x Hydra Flak Tank and 24x Hellhound
Anti-Infantry Tank.
Each template element has the following attributes:
1. Name: The Unit Class for this element.
2. Units: The number of units of that Unit Class in this element.
3. Size: The total size on tons of this element. For example, 60 Leman Russ Battle Tanks at 104 tons each
is 6,240 tons.
4. Cost: The total cost in Build Points for this element.
5. HP: The total aggregate hit points for the element.
6. HQ: The headquarters capacity of the elements Unit Class in tons. If there are multiple units in a template
element, only one is considered for the headquarters capacity. Any additional units are for redundancy.
The headquarters capacity is the total size of the formation (or formation hierarchy) that can be effectively
controlled by a commander based in a unit with this component. In the case of the Macharius Command
Tank, it has an HQ capacity of 10,000 tons.
31
7. FFD: The total number of Forward Fire Direction (FFD) components in the template element. Forward
Fire Direction allows a front-line unit to direct the fire of bombardment units from a formation in a
support position, fighters on close air support missions, or ships in orbit.
8. Const. The construction value of the element in Construction Factory Equivalents (CFEs).
9. CIWS: The number of Close-in-Weapon-System components in the template element, capable of defending
the planet (on which the unit is based) from missile attack.
10. STO: The number of Surface-To-Orbit energy weapon components in the template element. STOs are
capable of engaging ships in space within weapon range of the planet on which the unit is based.
The totals for each Template Element are added together to create the total for the Formation Template
as a whole, shown in the top right section. In the example shown, the Guard Armoured Regiment has a total
size of 8,942 tons, which is the combination of all four template elements. The Formation Template list has an
additional column for Rank. A default rank will be suggested by the program, although this can be overridden
by the player. This rank will be used by Automated Assignment process for any Formations built using this
Formation Template.
To add new Template Elements to a Formation Template, use the Add Units button in conjunction with
the adjacent text field to specify the number of units in the new element. This number can be subsequently
edited by selecting the element and clicking the Edit Amount button. Both Formation Templates and Element
Templates can be deleted using the appropriate buttons.
This screenshot shows the Macharius Command Tank on the left and the Brigade Headquarters formation
template on the right. The Macharius is a super-heavy vehicle, with two super-heavy anti-vehicle weapons and
an HQ4 component, which provides a headquarters capacity of 10,000 tons. This is a large and expensive vehicle
at 518 tons and 93.24 BP, but is well-protected as the loss of the HQ in a formation will result in the loss of
any commander bonuses (and maybe the commander himself).
Figure 17: Formation Templates Example 1
The Brigade Headquarters formation template includes two Guard Brigade Headquarters units, in case one
is destroyed, plus thirty-six large artillery pieces, twelve flak tanks and a company of Guardsman. Combat
involves three locations. Front-Line, Support or Rear-Echelon. Units in a Support position can only attack
using bombardment weapons, or defend themselves against air attack. This formation is intended to serve in the
Support location and is organising accordingly. However, it is possible for a Support Formation to temporarily
find itself moved into a Front-Line position, so the Guardsman Element will provide additional protection in
that case.
32
Figure 18: Formation Templates Example 2
33