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.

Will there be contribution credits in Beta 6?

Obviously, yes, or I would not be posting about them. However, they will not be used simply by viewing the pages as they were in Beta 5.

So what are Beta 6 contribution credits used for?

Generally speaking, there are two types of uses for contribution credits.

• They can be used to buy features. Once bought, such features stay linked to your account permanently.
• They can also be used to subscribe to some features. The subscription model uses some credits every day, with features being disabled if the account runs out of credit.

Can you name a few of these “features” you keep yapping about?

I can’t name all of them because, well, I don’t know them myself, but I can give you a few examples.

In the first category, you will have extra message storage or extra folders, extra slots for ship designs or build queue extensions.

In the second category, you’ll find stuff like disabling in-game ads, creating automatic filters on your messages, access to better planet management tools, and fleet automation (e.g. automatic retreat).

How do people get contribution credits in the first place?

…because obviously you won’t be rating Beta 6 planet pictures. Well, you’ll always have the option to pay for your contribution credits, through PayPal, although new options may be investigated. Bug reports will be another possible source of credits, but I will get back to these in a bit. Two new options will be added: voting on game-rating sites, and bringing new people to the game.

What about milestone releases?

Obviously, new features introduced by a milestone release will never be require contribution credits to be used. However, once a milestone release has been properly tested and the next one is introduced, some features may become subjected to the contribution credits system. Contribution credits will be carried over from a release to the next.

You said something about bug reports?

Oh, yeah, I did. Bug reports will be handled through a specific interface, allowing easy tracking and automated attribution of contribution credits, the amount of which will depend on the severity of the bugs.

Will Beta 5 contribution credits be carried over to Beta 6?

Not until Beta 5 is finally shut down, and they will not be transferred directly but rather after a conversion.

Will it be possible to trade credits?

No. The only thing this would cause is the emergence of a parallel economy.

Will people who don’t want to or can’t pay still be able to enjoy the game?

Voting on all rating sites as often as possible will allow non-paying players to get enough contribution credits to enable most of the game’s subscription-based features. They might have to sacrifice one such feature for a time if they want to activate one of the permanent ones, but they shouldn’t be too annoyed by the whole thing.

Stock market buildings

Of course, in order to use the stock market system, specific buildings have to be constructed. There are two categories of buildings that have an influence on the stock market system.

The first category contains the actual stock market buildings; only one such building can be constructed on each planet. The category contains four “levels”, each level providing higher benefits and lower risks.

In addition to the stock market itself, an economic simulator can be constructed (providing that one is available, of course); economic simulators are supercomputers which specialise in trying to predict the market’s tendencies, therefore anticipating problems and helping solve them. Like the stock market building, only one economic simulator might be built on each planet.

Regulating stock market usage

While the stock market’s output cannot be affected directly, players can control how it is used through two sets of laws. The exact names of these laws have not been determined yet, but the principles are described below.

One of the sets controls the nationalisation or privatisation of the planet’s industry. When the industry is nationalised, the state gets the full benefits from the factories’ production, but the stock market has no influence over these benefits. The higher the privatisation level, and the lower the direct benefits for the empire; however, since the stock market’s value affects the output, these benefits are sometimes heightened. With the lowest level of privatisation and the lowest level of stock market building, the benefits will range between 95% and 105% of what they would normally be; on the other side of the spectrum, the benefits will range from 89% to 135% of normal (the potential loss is higher, but it is more likely to increase the overall benefits). One last option remains – a law which can only be obtained by empires with the “Sneaky” alignment. This law allows the state to pretend the industry is controlled by the private sector, while actually owning it through a set of holdings and fake companies. In this case, the benefits will be between 96% and 145% of normal.

The second set of laws allows players to privatise their planets’ tax collection infrastructure. This will affect the planets’ base income, indexing it on the stock market.

Next time, on the LWB6 blog…

This post explained the basics of the stock market system – how it is enabled and how a player interacts with it. Next time, we’ll take a look at how it actually works.

Indeed, while players will get the final say about their fleets’ trajectories, some details remain to be explained. In addition, many other elements of the game use the travel rules (e.g. mining operations or trade); in these cases, the various computations are applied behind the scenes, without any intervention from the player.

Path optimisation

In the previous post we described optimal indirect routes as well as sub-optimal indirect routes; however, these routes only apply to interstellar travel. When trying to compute an optimal route between two areas, the game will also consider the trajectory’s endpoints. For example, when traveling from a stellar system to another, it may sometimes be worth staying in Hyperspace to avoid a particulary dense Oort cloud.

Travel time

While we have described trajectories in terms of abstract “distance units”, the actual time it takes a fleet to travel along a trajectory also depends on other factors.

• The slowest ship in a fleet determines the fleet’s actual speed.
• The speed of a ship depends on both its engines and its size; quite obviously, a capital ship outfitted with fighter engines will not be able to accelerate as fast as a fighter.
• Some ships may be outfitted with specific modules that can cause them to fly through nebulae or near black holes at optimal speeds.

Fleet trajectories

While the game’s interface will provide the player with automated trajectory selection tools, it will be possible to create arbitrary trajectories – deciding which sections to travel and whether they should be traveled in Hyperspace or normal space. While this is unnecessary under most circumstances, it is sometimes useful to create a more complex path, for example while planning an attack.

Supergate travel

Supergate travel was not described in this series of post; that is because it obeys specific rules which are not really a part of distance and trajectory computations. We will post more details about supergate travel in another post.

Automated uses of path computations

In addition to fleets, many elements in Beta 6 will need to use path computations: probes, remote mining operations, trading, population migration… In these cases it would be annoying to ask the player about the trajectory to use. Trajectories used by these elements will therefore be computed using the best known route.

Next time on the LWB6 blog …

This concludes our series about travel and distances. While it was quite boring and sometimes a bit technical, I think it was necessary to describe these various notions.

The next post will be about the stock market system, which can be used to increase an empire’s benefits while introducing a chance of economic depression.

Because of the structure of the universe in the new version, it is impossible to describe interstellar travel as simply as it was in Beta 5. It is impossible to fly through some of the map’s areas, while Beta 5 made sure that it was always possible to get from one point to another without passing through something that wasn’t reachable. In addition, the new version will allow players to use waypoints when determining a fleet’s trajectory; because that is possible, it is only logical that the game can propose optimal trajectories to the player. Finally, a lot of computations depend on the distance between two points – these computations should always use the best possible route.

As implied by the introduction above, there are at least two different modes which can be used when computing interstellar travel routes: direct paths (flying in a straight line) and indirect, optimal paths. However, players in Beta 6 will not always know the whole map of a layer; it would therefore be illogical for their fleets to use the optimal paths when they do not know these paths. This fact adds a third trajectory computation mode, which is the “best known route”. We will examine all 3 modes.

Direct paths

While direct paths seem easy (they are, after all, a straight line between two points) at first glance, it gets much more complicated than that due to the fact that the trajectory has to be split in order to know the distance traveled at each location. This computation is made necessary by the fact that different areas of the map have different multipliers (for example nebulae or areas near a black hole).

The graph below illustrates the problem:

On this graph, we can clearly see that the direct path between the two areas noted by a black spot intersects different areas (the cyan areas); however, it is also clear that the distance traveled in each area is different.

In order to solve this, we start by computing the raw Euclidean distance between the two points and multiplying it by 1000; this is the total length of the path. We then use a parametric representation of the line to compute transitions from an area to the next:

x( distance ) = X1 + distance * ( X2 - X1 ) / total_distance
y( distance ) = Y1 + distance * ( Y2 - Y1 ) / total_distance

The results are then rounded to integer values; while this causes a few errors (some paths end up being asymmetrical when they shouldn’t), the error is always 1 distance unit, which can safely be ignored at this scale.

In the case of the trajectory presented on the graph above, the resulting path is:

Applying this algorithm to our example results in the following list of transitions and distances:

• At (-1;2) : 625 distance units
• At (-1;1) : 208 distance units
• At (0;1) : 1042 distance units
• At (0;0) : 625 distance units
• At (1;0) : 625 distance units
• At (1;-1) : 1041 distance units
• At (2;-1) : 209 distance units
• At (2;-2) : 625 distance units

Indirect paths

In some cases, it is impossible to go from a point to another directly because of a black hole sitting in the middle of the trajectory. In other cases, the direct paths would take the ships through very slow areas of the map and there is a much more efficient trajectory that goes around these areas. However, the best path is not always known. Two different algorithms will be used for these two types of indirect trajectories.

The classic Djikstra algorithm will be used to compute optimal paths; since it is very slow, the optimal trajectories will be pre-computed when the layer is created, and partially re-computed in case the space-time drilling ability is used (which shouldn’t happen too often, hopefully). Using the pre-computed results, it is easy to determine whether a player has all of the data required to compute the optimal trajectory or if a sub-optimal indirect path has to be used.

Sub-optimal indirect paths are impossible to pre-compute, as it would require computing the set of indirect paths for each possible combination of known/unknown map areas. Therefore, the A* algorithm (classically used for pathfinding in real-time strategy games) will be used on a per-request basis.

The examples below show the difference between direct and optimal indirect paths. The image on the left is the direct path, which requires 41,565 distance units; the image on the right is the indirect path, “measuring” only 15,889 distance units.

Next time, on the LWB6 blog…

Now that we’ve seen the different parts needed for distance and trajectory computation, the only thing left is to explain how these different parts will be put together to actually compute distances and trajectories as required.

Black holes

Black holes are indeed special because of the fact that no ship can fly through a black hole. Not content with being obstacles on the map, black holes also influence space around them, causing very high multipliers to be applied to both normal space travel and Hyperspace travel within a radius of 4 (we’re talking about Euclidian distance here, see the picture below).

The multiplier generated by black holes applies to interstellar travel, of course, but it also applies to travel within the affected systems or nebulae. In order to avoid extremely high multipliers, black holes are not allowed to be less than 8 units away from each other; it is also impossible for a black hole to be located less than 4 units away from a supergate. These rules affect both the universe generator and the use of the space-time drilling ability.

Nebulae

Nebulae are possibly the simplest type of special objects.

First, they affect interstellar travel by causing a multiplier to be applied to all ships flying through the area, whether in normal space or in Hyperspace; this multiplier depends solely on a nebula’s opacity.

Second, nebulae have an internal structure; this structure is very simple, as it consists in only two areas where ships can be “parked”, the border and the core. These two zones are separated by empty areas. In both the nebula’s core and the empty area that is adjacent to the core, the nebula multiplier is doubled, as the density is much higher.

Supergates

The third type of special objects which can be found in all of the universe’s layers is the supergate. Space around supergates is divided into 5 areas, as indicated by the schema below:

The G area is the gate itself. Once the gate has been reached, fleets cannot be re-routed and have to reach the specified destination (or another destination if the gate screws up). The C area is just in front of the gate; ships leaving through the supergate will stop there before “jumping”, and ships arriving through the supergate will arrive in this area. The B, B’ and B” zones are “buffer” areas; an alliance controlling the gate can build gate bases at these locations. The A zone is the approach location for the supergate, with an additional “empty” area (the blue rectangle on the schema) separating it from outer space.

A ship cannot use Hyperspace travel in the direct vicinity of the supergate; therefore, ships coming from outer space will have to drop out of Hyperspace in the A zone, and ships arriving from the gate will only be able to enter Hyperspace past this zone. The reason behind this is that supergates should be strategic control points, where an alliance can block incoming hostile forces, or prevent them from moving on to another alliance-controlled layer.

The distance between the areas identified by letters is very small, and no multipliers apply. The area of empty space that lies at the exit point is much wider, but it can be traveled through in Hyperspace.

Next time, on the LWB6 blog…

The fourth and almost last chapter in this series of posts will examine interstellar travel, which is not as easy as it sounds…

Stellar systems have two “levels” of structure. First there is a general structure, common to all stellar systems; this level includes the Oort cloud and the locations of the various “orbits”. The second level is specific to what can be found at a given orbit: life-supporting planet, planetary remains, gas giant, asteroid belt or, well, nothingness.

General structure of stellar systems

As stated in the introduction, all stellar systems, regardless of their actual contents, share a similar structure. The graph below describes this structure:

The blue areas on the graph are empty zones; while it is impossible for a ship to stop in one of these areas, they must still be traveled through when navigating inside the stellar system. When coming from outer space, the first area that ships will enter is called the outskirts; while it is still outer space, it is considered a part of the system as only ships going somewhere inside the systems would enter it. The next area is the Oort cloud, which has a specific sub-structure, and some more empty space. After that, there are 5 areas called “orbit regions”, which contain two layers of empty space surrounding an area which may contain an object such as a planet or asteroid belt (the exception being the innermost orbit region, which only contains one area of empty space, since having an empty area in a direction in which you can’t travel anyway wouldn’t make much sense).

In terms of distances, the Oort cloud as well as empty areas have a “width” of 50 distance units, while an orbit has a total “width” of 20 units. Because of the stellar system’s gravity well, a Hyperspace multiplier applies for all in-system travel; this multiplier ranges from 10 on the outskirts to 145 in the innermost orbit.

The Oort cloud

A system’s Oort cloud is divided into 3 different areas. All of these areas are filled with various debris, albeit in different proportions. Of course, the cloud’s core – the middle area – is both wider and harder to navigate than the two others. Each Oort cloud has a specific density.

The density of the debris is low enough not to cause any additional perturbations on Hyperspace travel. However, normal space multipliers are applied: in the outer areas, this multiplier can be as high as 2, and it can reach 4 in the cloud’s core (the actual value of the multiplier depends on the cloud’s density).

Planetary bodies

Planetary bodies (life-supporting planets, gas giants and planetary remains) share a similar, relatively complex structure. The complexity of this structure is required for the game to handle ships being redirected in the vicinity of a planet. The graph below shows the various areas around a planetary body.

The A, B, A’ and B’ area are used to compute trajectories for ships passing by a planet. A and A’ are “approach vectors” – anything that has to go to the planet or just move by it will fly through these areas. B and B’ are only used for ships passing by. However, if the orbit being considered is the closest to the sun, only A is available as any ship going there is obviously headed for the planetary body’s orbit.

The O1, O2 and O3 regions are positions in orbit around the planetary body; ships can stay at these locations. However, the O2 and O3 areas are only available on actual planets; planetary remains and gas giants only have an O1 area.

Because it is possible for a fleet to change trajectory, it is possible to go from any of the A, B, A’ or B’ areas to the orbital area. Such transitions are only possible between areas. In addition, the “width” of these areas have been computed so that the path to O1 that passes through B or B’ is always longer than the direct path.

Depending on the type of planetary body, different modifiers apply; actual planets and planetary remains will not affect travel in normal space, and gas giants will actually give a 300% speed boost. In the case of Hyperspace travel, the planetary body’s gravity well will cause additional trouble, depending on the size of the planet.

Asteroid belts

The structure of asteroid belts is very similar to the one used for Oort clouds. An asteroid belt is composed of three areas: two outer areas of lower density, and the belt’s core, a smaller area with a much higher density (this area is where minerals are mined from).

The density of asteroid belts is too low to have an effect on Hyperspace travel. It does however impact normal space travel greatly, as the multiplier grows exponentially depending on the belt’s density.

Next time, on the LWB6 blog…

We’re going to talk about the structure of space near nebulae and supergates, which is both as important and as boring as this was…