
Star System Generation
----------------------

One of the interesting things you'll find about Sysmap is its
ability to randomly generate star systems on the fly (F1). Rest
assured, this is meant as a feature, not a bug. Nonetheless, it may
make you wonder, "Just how the heck did he come up with this?" The
answer, in a nutshell, is "not easily."

Sysmap started out a few years ago as part of another SF-RPG
project which I'd been working on at the time (a project which I
still hope to get back to, incidentally). Because I originally
intended to release the program within a completely different
software package under the aegis of an original homebrew RPG
system/background, I didn't want to use an off-the-shelf star
system generation scheme. So I poked around, here and there,
looking for the essentials of what I thought was really necessary.
I wanted a system that was simplistic in a way, easy to follow and
with very few rules, yet I also wanted a certain degree of accuracy
(perhaps believability is a better word). And, of course, I wanted
it to answer the basic questions (What is this star system like?
What sort of planets does it contain?).

I started out by looking at MegaTraveller, GURPS:Space, Space
Master, 2300AD, and even at a system of planetary classification in
the front of "Worlds of the Federation", not an RPG supplement, per
se, though it could certainly serve as one for the Star Trek RPG.
I also took a long look at the preliminary version of the 3rd
Gliese Catalog of Near Stars (1991) and posed various questions to
people on one of the astronomy newsgroups as well as holding
intensive discussions with a few netizens who were interested in
SF-RPGs in general and creating a new one in specific. With each
step, I got closer to synthesizing my own half-baked intuitions
regarding how things work up there in space.

As I got further along in my understanding of astronomy, I began to
recognize that my own ideas were most probably erroneous (and most
probably would always be erroneous). After all, the science is in
a constant state of flux as new discoveries are being made,
toppling the theories of old, as it were. I soon realized that the
main problem with writing a program that randomly generates star
system information is that there are simply an awful lot of
unknowns. This shouldn't be surprising. It's sort of hard to form
a science of planetary formation based on only one well-observed
star system (our own). Until we actually visit other star systems
and see what's out there, we won't really know the range of what's
possible or what's even likely, and so the entire discipline will
likely remain shrouded for a very long time in unproven conjectures
and theories, all of which are bound to vary.

I'll give you a brief example of this regarding what I consider to
be a rather salient question of astronomy. Just how common are
"habitable" planets? If you play Traveller, and take what it says
as gospel, you'll probably come away with the impression that
habitable planets are quite common, usually one per star system or
something to that effect. But is this really an accurate
assessment?

Pro-Argument: Of course it is. Most planets have water in them
somewhere (usually as vapor in the atmosphere or as ice crystals in
the soil), and every star has a biozone (the zone at which the
water resides in a liquid form). Hence, any planet in the biozone
will likely have liquid water, and after you have that, all you
need is time, a certain abundance of elements, a little lightning
thrown in to make things interesting, and soon enough life will
spontaneously arise. Evidence seems to point to carbon-based,
water-solvent, oxygen breathers (animals) coupled with carbon-
based, water-solvent, carbon-dioxide breathers (plants) being the
most likely to survive the rigors of evolution, producing a stable
ecosphere and a perfectly habitable planet.

Con-Argument: Hold your horses, buddy! First of all, we have a few
extra things to consider. For instance, who's to say there's going
to be any planets to begin with? Many star systems are binaries or
trinaries (they contain multiple stars instead of just one). The
tidal forces generated by such a pairing would tend to disrupt the
process of planetary formation. Can you say asteroids? I knew you
could! Also, even assuming you've got planets, remember that most
stars out there are of the red main-sequence variety (MV). These
stars are so dim that it seems likely that any world in the star's
biozone (the region that can support liquid water), would have to
be so close to the star as to be tidally locked (one side always
facing the star, the other side always facing away). Would such a
planet be unable to retain its atmosphere over the several million
years of its formation? And even if it could hold it's gas, so to
speak, who's to say that people could actually live there, one side
boiling and the other frozen in perpetual night? Couple this with
the fact that the biozone is such a narrow region of any star's
planetary system, and that in order for a world to support (our
sort of life) life, it must not only reside in the biozone, but it
must have all sorts of other things going for it. An overblown
greenhouse effect would spoil such a planet. Lack of water could
also be disastrous. There are so many different things that can go
wrong. If life itself were to fail to spontaneously arrive at the
appointed hour in the planet's history, then would-be explorers
would have an awful hard time breathing the air. Remember, oxygen
is a by-product of (plant) life. There are so many possibilities,
so many sorts of worlds that can arise, and the conditions
necessary to support our form of life are so constraining that
habitable planets will, by sheer statistics, be very few and very
far between.

I could go on and on, but why bother? You see my point. It's a big
messy question. My goal, in this program, was to simplify it and at
the same time to provide a way for you, the user, to adjust the
built in assumptions to _your_ liking. So let's look at these
assumptions.

First, Sysmap looks in the galdata\sysmap directory. There, it
checks out the contents of three data files: system.dat, stars.dat,
and planets.dat. Think of these files as "assumption" files. They
contain most of the information Sysmap uses to randomly generate
star systems.

Step 1: system.dat

When Sysmap loads this file, it's asking the questions: What are
the chances of single vs double systems and how many stars will the
hub of each system have? Time for a little explanation. Our own
solar system is a single system with one star. Not all star systems
are like this. Many star systems actually contain a "far
companion", a star that is gravitationally locked to the primary
but which revolves around it at a very great distance. Such a star
may have its own complete host of planets and for all intents and
purposes should be treated as a completely unique star system. In
Sysmap's terminology, such star system pairs are called "double
systems". Now what about single, double, and triple stars? Well,
every star system has a "hub". Sometimes there's just one star
here, as in the case of our own solar system, however, quite often
there are two or even three stars in very close proximity. In
Sysmap's terminology, such pairings are called double or triple
stars.

The system.dat file gives the probabilities of each scenario. The
file should look like this:

# Star System / General Nature
#
# double systems involve two star systems in gravitational lock
# each of the primaries is a far companion to the other
single system: 80%
double system: 20%
# for each star system there are 1-3 stars at the hub
single star: 75%
double star: 20%
triple star: 05%

If you feel that single stars should be less common and double
stars more common, just edit the system.dat file with your favorite
text editor.

Step 2: stars.dat

After Sysmap knows how many stars are present, it tries to generate
those stars. To do this, it looks at stars.dat, which may have up
to sixty star entries. Here's a section of stars.dat just to help
you get familiar with the file format:

#Description             |   Shares   Mass  Planets 1st Bio CS
GA: Yellow Supergiant    |       0    12      3d6+3   8  13 OB
GB: Yellow Supergiant    |       0    10      3d6+2   6  11 OA
G2: Yellow Large Giant   |       0     6      3d6+1   3   9 O9
G3: Yellow Giant         |      13     2.7      3d6   2   8 O8
G4: Yellow Subgiant      |      52     1.8    3d6-1   1   6 O7
G5: Yellow Main Sequence |     389     1.1    3d6-2   1   3 O6
G6: Yellow Subdwarf      |       3     0.8    2d6+1   1   2 O5
DW: White Dwarf          |     162     0.8      3d6   4   0 H1
DB: Black Dwarf          |       0     0.8      3d6   4   0 I1

What's going on here is that each star type has a number of
"shares" associated with it. These are shares of probability. To
get an idea of how this works, imagine a raffle drawing. Every
person buys some number of tickets. Each ticket is a share. Put all
the tickets into a hat and randomly pick one. That one is the
winner. That's how probability shares work. As you can see from
this chart, G5 (GV, the category of star in which our own Sun
resides), is much more likely to result than other stars of the
Yellow "G" class. In fact, some stars on the chart have zero shares
of probability. Create as many star systems as you like, these
stars will never pop up. Of course, you may not like this
assumption. To change it, just edit stars.dat.

The Mass column should be self-explanatory. Each star's mass is
expressed in solar masses. The biggest star of a multi-star hub is
assumed to be the "primary", and it is from this star that other
statistics are determined, like the number of planets that the star
system will have, where the 1st orbit will reside, and where the
biozone orbit resides. Why can't the 1st orbit simply be the 1st
orbit? Because some stars are so hot that any planets which are too
close will be vaporized. Take the case of a "GA" (GIa) Yellow
Supergiant. In theory, the star can have up to 21 planets (assuming
maximum rolls on 3d6+3). In reality, however, the 1st seven of
those planets will be vapor. The planets in orbits 8-12 will be
considered to be "inner zone" worlds, probably all hot as hell. The
planet in the 13th orbit will be a "biozone" world with the
possibility of supporting a teaming ecosystem. Orbits 14-21 are
considered to be "outer zone" worlds, get ready to freeze your nuts
off. Is all this realistic? Well, it depends on who you talk to. If
you're one of those folks who feel that supergiants can't have
planetary systems whatsoever, change "3d6+3" to "0". If you feel
that the biozone should be in the 12th orbit instead of the 13th,
change that. The whole point to this is that you can change
whatever you like.

The last column on this chart is labeled "CS". Does not stand for
computer science. It stands for "color code" and "size radius".
Remember, the stars have to be displayed on the star system map
screen. I figured you might want to have some control over what
color is used and how much monitor estate they take up.
Incidentally, these are the color codes that the program
recognizes:

    A  Black    E  Red       I  Dark Grey     M  Light Red
    B  Blue     F  Magenta   J  Light Blue    N  Light Magenta
    C  Green    G  Brown     K  Light Green   O  Light Yellow
    D  Cyan     H  White     L  Light Cyan    P  Bright White

One note about the white and black dwarfs. As you may already know,
white and black dwarfs are stars that have gone through their
entire life cycle, experienced the red-giant stage, and basically
burned the living hell out of all the inner planets (vaporizing the
closest of them, most likely). Does the program account for this? 
You betcha, but the thing is that it's right in the code (can't be
changed from the data files). For those who are curious about the
difference between white and black dwarfs, my take is that the
black ones are a lot older (takes a long time for a star to lose
its glow, even a dead one). I put zero shares on these guys on the
possibly erroneous assumption that the galaxy was too young for
them to even exist. Your milage may vary, so adjust this if you
like.

One last thing I should mention. The program treats the four
subdwarfs currently in stars.dat (F6,G6,K6,M6) as 1st generation
stars. All other stars are treated as later generation (recycled).
What does this mean? Well, 1st generation stars are unique in that
they and their planetary systems are composed solely of hydrogen.
Hence, only gas giants can form, and these will be colorless, a
sort of milky white, and ghostlike against the black of space.
These stars are so rare that I decided to write the program such
that they are never seen in pairs, and if they show up in a later
generation star system, they will have the eccentric orbit typical
of a captured body.

Step 3: planets.dat

Here's the planets.dat file. The "#" entry is just a symbol
corresponding to a world of a given class (Gas Giants are Class C).
"S" is the size (radius) on the system map display. "C" is the
color code. Inner, Biozone, and Outer once again deal with shares
of probability. Note that Garden Worlds (Class M) can exist in the
biozone but nowhere else. Moons, of course, is the number of moons
that a world of the given class will have. If an empty (Class 0)
world is rolled, that simply means that the orbit is unoccupied.

# S C Description         Inner  Biozone  Outer  Moons
A 5 O Solar Companion       1       1       1     2d6
B 4 M DI: Brown Dwarf       -       -       -     2d6
C 4 M Gas Giant             1       1      10     2d6
D 2 E Magma Ball            6       -       -     d2-1
E 3 E Primordial            3       2       -     d4-1
F 0 I Asteroid Belt         2       3       4     0
G 1 I Planetoid             2       2       2     0
H 3 H Vacuum Ball           2       2       2     d4-1
I 2 H Snow Ball             -       -       2     d3-1
J 3 H Ice Planet            -       -       2     d4-1
K 3 E Shallow World         2       2       2     d4-1
L 3 G Barren World          -       2       2     d4-1
M 3 L Garden World          -       2       -     d4-1
N 3 J Water World           -       2       -     d4-1
O 3 G Desert World          -       2       -     d4-1
P 3 G Marginal World        -       2       -     d4-1
Q 3 C Belch Ball            2       2       2     d4-1
R 3 K Greenhouse            3       2       -     d4-1
S 3 N Exotic                -       2       -     d4-1
T 3 N Liquid World          -       2       1     d4-1
U 3 H Gas Core              -       -       -     2d6
Z 3 N Special               -       1       -     d4-1
0 3 A Empty                 4       6       8     0

As usual, you can adjust all this stuff to your liking. You can
even add worlds. My suggestion is that if you add any worlds, add
them toward the end of the file rather than toward the beginning.
In any case, don't put anything above Class U (Gas Cores) or it'll
foul things up when it comes to calculating what happens with
White/Black Dwarfs. Incidentally, although Gas Cores have no shares
to them in any of the zones, they can still occur in the generation
process whenever a white or black dwarf is present at the star
system hub. You can have up to thirty different classes of worlds.
Currently there are twenty-three (Empty is included), so that
leaves seven that you can add to this file. If you require more,
I can expand the variable dimensions to accomidate.

Keep in mind that Solar Companions (including Brown Dwarfs) are
mid-range companion stars, not so close that they are in the hub,
but not so far away that they can be considered far companions. I
did not program any feature to account for the gravitational
disturbance upon the formation of other planetary bodies which
would, no doubt, be caused by these stars, except to ensure that
these stars are themselves no larger than their primary. Neither
was the gravitational influence of Gas Giants upon neighboring
worlds incorporated into the code. There is so much controversy
in the field of planet formation that I figured it would be better
to just allow the user to massage the star system data until she
or he is happy with it.

Good luck using Sysmap, and if you have any specific questions or
ideas for the software's improvement, please write.

jimv@empirenet.com

