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…

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

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

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

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

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

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

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

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