[info] The Rules with the Orbits

The development and changes of the interface with the orbits continues its course, I cannot yet post a dev update with screenshots since I want the Orbits panel to be completed before it. I also working on the removal the 3D space units (replacing them by 2D ones) and of course of the useless 3D orbits.
I also removing the Action Menu (the one when you right clicking in the 3D view) by something more satisfying; a tree to browse directly all the orbital objects (including satellites) in the current planetary system and act on them (data access).

Meanwhile I fully completed the definitive version of the rules concerning how the orbits are managed in the game, and how space units on them are located. It’s not a critical step for this alpha 10 itself but is a vital one after it for many points of future gameplay.

I created a semi-abstracted and simplified model to simulate the space units on the orbits around planets and satellites. The objective is to provide some granularity, and being coherent if not realistic without giving headaches to the player. Don’t worry, it looks more complicated than it is, and most of the time the player can even don’t care about the details, as long as its space units are located on the orbits it wants them.
But in the future, certain part of the gameplay (orbital combat, communication / planetary survey satellites and so on…) will take this model into the account.

If you want to read more details about this model, than this TL;DR above, you can read the full excerpt from my main game design document in the box (examples uses the template for 26 regions, pictured below):

Orbits Rules

Since the surface is detailed into regions, rules must exists to modelize the relative position of a space unit in orbit of an orbital object.
The use of it can be multiple and open, two relevant examples; for communication satellites, or for an orbital offensive.

Any space unit in orbit is assigned to an Orbital Zone (OZ) which is either a row or a column of regions (or a full band of longitude or latitude).

The effective window of this OZ can be extended in geosynchronous orbit, depending of the surface template defined in the previous section.

How is set an OZ depends on which type of orbit a space unit is located on:

– in Low Orbit; the OZ can be either Equatorial (a full row of regions) or Polar (a full column of regions including the polar ones.
the indication in the game is defined as this: In Low Orbit [Equatorial – 70°North] Each equatorial row is noted in °North/South with a range from 0 to 90°
Each Polar column is noted in ° West/East with a range from 0 to 180°

In game term, the exact location on this orbit isn’t determined since in low orbit space units do one full orbital cycle in a relative short time.
For ex; a space unit in Low Earth Orbit (at about 850km) and 8.1km/s do its full cycle in about 96.2min, so in 24h such space unit orbits the Earth about 15 times. So instead to constantly update a position for no general but specific uses is a useless overhead and certainly another complicated data for the player to manage. Instead, each region has a Time Window (tWin) that will be used as a sort of coefficient / modifier when it is needed.

Since the surface is only a equirectangular projection of a planet or asteroid, orbiting up a latitude will link to orbiting down another latitude, and orbiting a longitude, especially for higer or lower rows, will not be a straight line since it isn’t realistic but instead will hop to an adjacent row and so it provides a simple model of inclined orbit around a planet or asteroid.
By rule abstraction. if the chosen longitude is a North one, only the first 50% of it will be covered, and the second portion of 50% will be covered above the regions the of longitude band below the chosen one. And it is the reverse for South longitudes.
Ex: if 0-35° south will be picked, the space unit will orbit above only the first 50% of regions (the 3 first region with an example with 26 regions in total) and the other 50% will be above the 3 last regions of the 0-35N (the longitude band directly above).

Two specific data for low earth orbit exists; tWinEquatorial and tWinPolar (by region of course)

one to indicate the time a space unit hover above a region, on an equatorial orbit, before passing to the next one, and one other to indicate the same kind of time, but for a polar orbit..
It isn’t the same because the number of regions in polar orbits can be different of the number of regions in equatorial orbits, and so it affect the time a space unit hover above them. Of course in the end it is the same time for a full cycle.

By default, when a mission for a space unit include that its destination is the low orbit of an orbital object, the nature and position of this orbit will be set randomely. By this abstraction, the player doesn’t have really to care about such detail when most of the time it isn’t relevant.
If it is relevant, as for example a satellite or the module of an orbital station must be set into a wanted orbit, it is of course possible to the player (and AI) to set a specific type of orbit and a specific range of longitude or latitude.

– in Geosynchronous Orbit; notation is the same as Low Orbit.

In game term, any space unit into such orbit will stay locked a focused latitude, and it will have an extended effectiveness to adjacent latitudes which is determined according to the surface template.
Ex: with a 26 regions template, like for Epsilon Eridani 2, if a space unit is locked toward the 60° East (4th column on the surface, starting from the left) latitude, it covers this latitude with 100% effectiveness (the poles only at 15%) and will cover the two adjacent columns to the left and right (60°W and 120°E) with 50% effectiveness.
his effectiveness will play as a coefficient/modifier for communications etc…

Of course, since the space units in geosynchronous orbits orbit around their orbital objects at the same speed than this one, there is no moving effect. The space units stay still and continues to cover the same zone.

Any space unit placed in such orbit can also have its location determined totally randomely or set by the player/AI.

In addition to these rules, any space unit can change its range of longitude/latitude, as long as it has reaction mass to do so. Also, any space unit in low orbit must maintain it over the time with their system of propulsion and it also cost them reaction mass.

If you have survived to my bad pseudo-technical English, you can live another day 🙂

That’s all for now, I will publish a Dev Update post when the Orbits panel is done and functional.

As usual thanks for your interest!

Scroll to Top