UWP Star System Types
Since WorldGen is vaguely based on Traveller, it was always going to be possible to generate star systems from UWP format data. Since I want to allow exploration of the less well chartered parts of the universe for my Deepnight Revelation campaign, I’ve now added in support for parsing SEC data and creating star systems from that. It’s not as pretty or usable as TravellerMap, but it does provide more detailed information, and allows me to limit what can be seen by players according to how deeply systems have been surveyed.
The main topic of this post though is looking at the different star system types. Though the basic UWP only describes a single world, the extended sector data does allow for multiple stars in the system, like this:
Petre 0210 B696478-A Ni Pa 210 Im F4 V Dimple 0305 D200201-8 S Lo Va 500 Im G1 V M1 V Benidorm 0402 E546400-8 Ni Pa 120 Im G2 V Carian 0408 B300459-B N Ni Va 924 Im M0 V M7 V
Which means I needed to flesh out the binary and triple star system handling. There’s probably some quad star systems in the data somewhere, but currently WorldGen only supports up to three stars per system.
Each star system in WorldGen has a system type associated with it, which is basically a description of the number of stars and their general layout.
Single Star Systems
These are the simplest, since there is a single star at the centre, with a planetary system surrounding it. Not much needs to be said about this, except they are the most likely type to have Oort Clouds.
Since all the defined planets orbit the single star, they will have the largest singular planetary systems. If there are multiple asteroid belts, one of them is also likely to be a kuiper belt on the edges of the system.
If they have a small dwarf star, then there is a likelihood of that star suffering from extensive solar flares, but the chance of jump instabilities in the system is low.
Binary Star Systems
These have two stars in them, and there are several ‘layouts’ available, which define how far apart the stars are and how their orbit each other. Generally, if there are two planetary systems, then the planets will be split equally between them, with any ‘odd’ planets going to the primary.
If the companion is a white dwarf star, then there is a greater bias towards more planets being around the primary star.
The main world is always considered to be around the primary star, which is generally the largest.
A close binary is the simplest type of binary, which it looks much like a single star system except that it has two stars at the centre. The stars orbit well within 1 AU of each other, normally within 10 million kilometres, with both orbiting a common centre of gravity.
There is a single planetary system that orbits the two stars. The combined energy output of the two stars is used to calculate the temperature of each world. Since the planets are significantly further from the stars than the stars own orbital distance, the temperature can be considered constant enough to not need to worry about climatic variations.
Worlds probably have ‘warm’ days and ‘cool’ days though, depending on the exact position of the two stars.
These systems have a high incidence of causing jump instabilities in the system, which doubles the diameter of jump masks. They can also suffer from dangerous solar flares, as the two stars interfere with each other.
Such systems will also have two overlapping jump masks, one from each star.
A conjoined binary is much the same as a close binary, except the atmospheres of the two stars are actually touching. These are very rare. Expect a very high chance of solar flares.
Medium binaries are probably the most complicated type. There are two stars, one of which orbits the other at a distance of tens of AU, normally more than 10 AU and less than 100 AU. Unlike a close binary, there are potentially two planetary systems, each orbiting one of the stars. They are the rarest type of binary.
The two planetary systems will be small, since they are generally within 20% of the distance between the two stars for stability reasons. Planets in both systems will be affected by the energy from the other star, leading to quite extreme winters and summers.
As far as jump dynamics goes, they can be complicated because the jump shadows of one star can sometimes obscure the other’s planetary system. This can put a planet in a jump shadow for a sizeable portion of their orbit for several years, and causing serious disruptions to trade.
Such medium binary systems are often close enough such that it’s practical to move from one planetary system to another without using a jump drive. A 2g thrust ship can cross a 50AU gap in a couple of weeks, so if there is traffic between the two stars then their may be a flow of in-system vessels.
Oort clouds around medium binary stars are quite rare, though possible.
One feature of WorldGen is that I can calculate the current positions of the planets and stars in a system for any given (in-game) date, so in theory I could bring the complications of worrying about jump shadows into the game when players are planning their navigation. Basically, in Traveller you can’t jump within or through 100 diameters of a planetary or stellar object (personally I prefer this based on mass, and WorldGen has the option to do either, but I’m using diameters for this game). The Jump Mask is everything with 100 diameters of an object, so you have to jump to as close as you can, and then fly the rest of the way. For large stars, it can mean not being able to jump directly to planets in the inner system (for Sol, this distance is just under 1 AU, putting Mercury and Venus within Sol’s jump mask).
Since you can’t jump through these areas either, it means the region behind a star or planet is in shadow, and you can’t jump directly to a point there. If the star system you want to jump to is ‘behind’ your local star, then you need to fly out to a point to the side of the local star before jumping, potentially adding several days to a journey.
So it’s an extra layer of complication which might be interesting in some circumstances, or could get annoying. So I could bring this in as a common feature that needs to be planned around, or I could simplify and ignore it except in situations where it might be dramatically important. It might be more interesting in a campaign where players are keeping to a local region, then some systems could get a reputation of being ‘a pain in the arse’ to fly into as it a bit of background flavour.
Far Binaries are like medium binaries but further out, with 100s or 1,000s of AU between the two stars. This basically means that the two planetary systems don’t interact with each other, and the companion star will be little more than a bright star rather than obviously a ‘sun’. It does mean that travel between the two planetary systems often requires jump drives since doing so without jump is often impractical (though may be possible in emergencies).
Though the overlap of jump shadows can also happen with far binaries, it is much rarer than with medium binaries since the stars are so much further out, and so spend far less of their time within the shadow of each other.
Far binaries never have Oort Clouds (I’m sure this will be contradicted at some point, when we discover an Oort Cloud around the Centauri system, but I currently like it as a differentiator).
Triple Star Systems
Triple star systems, as the name suggests, consist of three stars, each potentially with its own planetary system. Currently, only one type of triple system is supported, which is treated in the same way as a Far Binary. There is a primary star, with two companions which orbit it at 100s and 1,000s of AU. More complicate arrangements (such as a close pair, with a far companion) may be added later.
About half the planets are around the primary star, with the rest split between the other two, with preference for ‘odd’ planets going to the primary or secondary. If the system has four gas giants, then two will be around the primary, and one each around the secondary and tertiary stars.
Tertiary star systems don’t have Oort Clouds, since the gravitational instability of the system don’t permit such a cloud to remain stable. Given the distance between the stars though, the three have little affect on each other, and Jump travel is really needed to get from one to another.
Note that it’s probably (definitely?) more realistic to have these systems orbiting a common centre of gravity, but given how slow their orbits are, it doesn’t make much difference in-game exactly how they’re orbiting, and it keeps things simple to treat the primary star as the central point.
So far I’ve generated 14 sectors along the Great Rift, which includes 1,798 star systems, 18,576 planets with a further 37,668 moons.
The total population of these sectors is 2 trillion, 123 billion, 830 million, 942 thousand and 679.
Of those, 471 are far binaries, 159 close binaries, 56 medium binaries and 50 are triple systems.
Most of these sectors are relatively sparsely populated, but I wanted to get them done first to make sure everything works before moving onto the more densely populated sectors. It did take all night to generate them (including surface maps for all the worlds and moons) on my rather slow desktop (the database and web server is running on a Raspberry Pi 4, but the hard work of creation can be done from the client), so I don’t want to have to redo things too many times.