PPG- Procedural Planet Generator

There is no "try". The ONLY factors affecting gravitational attraction are distance and mass. Greater distance, less pull. Less mass, less pull.

As to the actual discussion:
We don't know a ton about the distribution of elements within the galaxy, and the simpler we make the game, the better. If you're also wondering about the solar system's accretion disc, It really doesn't matter where we place gas giants and rocky planets, because they can conceivably move anywhere after formation, and even be shot out of the system entirely, since gravitational systems composing of more than two bodies become highly chaotic.

~sciocont wrote:

There is no "try". The ONLY factors affecting gravitational attraction are distance and mass. Greater distance, less pull. Less mass, less pull.

As to the actual discussion:
We don't know a ton about the distribution of elements within the galaxy, and the simpler we make the game, the better. If you're also wondering about the solar system's accretion disc, It really doesn't matter where we place gas giants and rocky planets, because they can conceivably move anywhere after formation, and even be shot out of the system entirely, since gravitational systems composing of more than two bodies become highly chaotic.

Yes, there is a try. The further, the more potential energy. I am probably far enough away from you to send you through the core of the Earth and vice versa. The two reasons this does not happen is A) the Electomagnetic Force, and B) the fact that our masses are negligible. A planet and a star are separated by empty space, meaning no electromagnetism. and yes, they are big. But they are far apart, so this does not cause a problem in a stable orbit. However, the distance factor doesn't stop the potential energy from making a distant planet stronger. But closer ones exert more force. So this equals out. Therefore Hot Jupiters are not favored by observation. If not by observation, then what? The answer: These are much more common than gas giants as distant as ours.
I bet you were by the end.
As to the not-so-actual discussion: Good idea.

You seem to be talking about Gravitational Potential (Energy), and the GPE of a distant planet cannot be calculated without detailed knowledge of the planet and star, and certainly cannot be measured with a telescope, and so does not affect observation.


(Actual Discussion)
Your idea makes sense, but Scio is right, we don't really have enough evidence to support the theory and it is better to keep it simpler. I think gameplay would be preferable with an even distribution of resources, too. I think we should go for random planet locations in a system, too.

The Uteen wrote:

You seem to be talking about Gravitational Potential (Energy), and the GPE of a distant planet cannot be calculated without detailed knowledge of the planet and star, and certainly cannot be measured with a telescope, and so does not affect observation.


(Actual Discussion)
Your idea makes sense, but Scio is right, we don't really have enough evidence to support the theory and it is better to keep it simpler. I think gameplay would be preferable with an even distribution of resources, too. I think we should go for random planet locations in a system, too.

I don't mean YOU CALCULATING THE GPE, I mean THE GPE CALCULATING YOU. I'm saying GPE effects wobble.
(As I said, NOT actual discussion)
Sure, it would make it easier.

Deathbite42 wrote:

The Uteen wrote:

You seem to be talking about Gravitational Potential (Energy), and the GPE of a distant planet cannot be calculated without detailed knowledge of the planet and star, and certainly cannot be measured with a telescope, and so does not affect observation.


(Actual Discussion)
Your idea makes sense, but Scio is right, we don't really have enough evidence to support the theory and it is better to keep it simpler. I think gameplay would be preferable with an even distribution of resources, too. I think we should go for random planet locations in a system, too.

I don't mean YOU CALCULATING THE GPE, I mean THE GPE CALCULATING YOU. I'm saying GPE effects wobble.
(As I said, NOT actual discussion)
Sure, it would make it easier.

The PE doesn't effect the actual amount of energy exerted. The Kinetic energy is what matters, that's what's measured..

PE is called "potential" energy because it is POTENTIAL for kinetic. Why else would it be called that?

Deathbite42 wrote:

PE is called "potential" energy because it is POTENTIAL for kinetic. Why else would it be called that?

Look, you're failing to understand the basic physics. The equation explains everything going on. There is no extra energy exerted because the planets are father away from each other. The gravitational energy decreases as the inverse square of the distance. that's the end of the story. Force ONLY weakens with distance, and it does so in a regular exponential fashion.

~sciocont wrote:

Deathbite42 wrote:

PE is called "potential" energy because it is POTENTIAL for kinetic. Why else would it be called that?

Look, you're failing to understand the basic physics. The equation explains everything going on. There is no extra energy exerted because the planets are father away from each other. The gravitational energy decreases as the inverse square of the distance. that's the end of the story. Force ONLY weakens with distance, and it does so in a regular exponential fashion.

So if it was 1 away, it would have 1 force. But if it were 2, it would become 1/4. I know. But it appears you have completely ignored my PE.

Deathbite42 wrote:

~sciocont wrote:

Deathbite42 wrote:

PE is called "potential" energy because it is POTENTIAL for kinetic. Why else would it be called that?

Look, you're failing to understand the basic physics. The equation explains everything going on. There is no extra energy exerted because the planets are father away from each other. The gravitational energy decreases as the inverse square of the distance. that's the end of the story. Force ONLY weakens with distance, and it does so in a regular exponential fashion.

So if it was 1 away, it would have 1 force. But if it were 2, it would become 1/4. I know. But it appears you have completely ignored my PE.

Potential energy does not affect the force of gravity or anything else. It's basically an imaginary thing made up to explain where the energy goes when you lift something up.

Then it comes back when it falls.

Well, I sort of hate going against what's already been established, especially being a newbie like me, but let me humbly present a system for generating star systems, both for player starting worlds and populating the galaxy. All variables are denoted by [brackets,] with variables that are direct influences on organisms being bolded and variables that must be within a certain limit for life to evolve being underlined.

Wall of text incoming...

It all starts with creating the star, namely generating it's [Stellar Mass], [Stellar Luminosity], and [Stellar Metalicity]. In order to conform to what we've observed of stars in our universe, [Stellar Mass] and [Stellar Luminosity] will be drawn from presets, including Main Sequence stars, Giants, Super-Giants, Dwarfs, and a few exotic options to spice things up (I'm estimating maybe 25 profiles.) We could also include information in these presets to help determine the color of any photosynthetic life on orbiting planets.

[Stellar Metalicity] is roughly a measure of the percentage of heavy metals present when the system was forming. This is used to select how many planets/asteroid belts the system contains, as well as puts a cap on their maximum [Planetary Mass.] It will also influence both [Planet Composition] and [Atmosphere Composition,] with higher [Stellar Metalicity] leading to more options when generating compositions.

[Luminosity] determines how much energy the star is putting out. This, along with [Orbit Distance] is a major factor in deciding both [Planet Radiation] and [Planet Mean Temperature]

[Stellar Mass] is used with [Planetary Mass] and [Orbit Distance] to calculate [Orbit Time].

From here, we begin generating Planets and Belts. [Orbit Distance] for each is generated first, with no two Planets allowed to be less than 0.2 AU apart. (Belt minimum distance calculations incoming.) Once orbits have been designated, [Planetary Mass] is then generated for each planet in the system, using [Stellar Metallicity] to determine a cap. Finally, we use [Stellar Metalicity] once more to generate [Planet Composition.] The first check for habitability is made here, against [Planetary Mass,] as any planet that is too small will be unable to continue geologic processes for very long, which are responsible for recycling various compounds and helping sustain/build the atmosphere. (Note, a second check might also be performed here for the presence of Carbon, but is not necessary if we decide to allow other water-based biochemistries, if there are any (Never my strong suit))

[Orbit Distance] is used in calculating [Orbit Time] as well as determining [Planet Radiation] and [Planet Mean Temperature.]

[Planetary Mass], along with [Orbit Distance] is used to place a hard cap on [Atmosphere Density.] It is a factor in orbit calculations It is also, of course, used to determine [Gravity] and the size of the planet in gameplay terms.

[Planet Composition] gives rough percentages of elements in the planet's crust, for use in generating mineral [Resources] later in the game. It also plays a role in determining [Liquid Water.] The process for this involves a weighted list of potential elements/compounds, which is then randomly selected from to build the makeup. (This needs a bit of polishing)

Next, orbit mechanics are finalized by generating [Orbit Eccentricity] and calculating [Orbit Time] by using [Stellar Mass], [Planetary Mass], and [Orbit Distance.] Another check takes place here, limiting the Eccentricity of orbits, as a more oval-shaped orbit will not only cause wild temperature variations, but is more likely to be involved in a planetary collision with any orbits it nears.

[Orbit Eccentricity] is a measure of how round vs oval a planet's orbit is. It is used in calculating [Temperature Gradient] over the course of the year due to changing distance from the star.

[Orbit Time] is a measure of the planet's year.

The next step is to generate [Planet Rotation Time] and [Planet Rotation Angle] randomly, but perhaps weighted slightly towards "Normal" to prevent a universe full of Uranus-lookalikes.

[Planet Rotation Time] is a measure of day length and is used in calculating [Temperature Gradient] over the course of a day.

[Planet Rotation Angle] is a measure of axis tilt and is used in calculating [Temperature Gradient] over the course of a year due to seasonal changes, along with [Latitude.]

Then, we generate the planet's atmosphere. From [Stellar Metallicity,] we generate [Atmosphere Composition]. Using [Planetary Mass], [Orbit Distance,] and [Atmosphere Composition,] we place a hard cap on [Atmosphere Density]. Using these two in conjunction, we then calculate [Atmospheric Albedo] and [Atmosphere Greenhouse.] A third check involving [Atmosphere Density] is performed, as one needs a certain level of atmospheric pressure to keep water in it's liquid form, as well as give enough for organisms to breathe. (Note, a check for Oxygen might also be performed here, if we're not allowing alternatives)

[Atmosphere Composition] gives percentages of various gasses that make up the atmosphere. It is generated similarly to [Planet Composition,] and is used in calculating [Atmospheric Albedo] and [Atmosphere Greenhouse,] as well as helping determine [Liquid Water.] Finally, it helps put a cap on [Atmosphere Density]

[Atmosphere Density] is the atmospheric pressure at whatever our zero-point is as far as elevation goes. It is used in calculating [Atmospheric Albedo] and [Atmosphere Greenhouse,] as well as helping determine [Liquid Water.]

[Atmospheric Albedo] gives a rough percentage of how much stellar radiation is reflected back on average. It is used in calculating [Planet Mean Temperature] and reducing the effects of [Orbit Eccentricity] and [Planet Rotation Angle] on [Temperature Gradient.] It is also involved in calculating [Planet Radiation]

[Atmosphere Greenhouse] measures the amount of greenhouse gasses present in the atmosphere. This has an effect on [Planet Mean Temperature] and limits the degree of change in [Temperature Gradient] over a day-night cycle.

Finally, we generate surface conditions. [Stellar Luminosity], [Orbit Distance] and [Atmospheric Albedo] are all used to both calculate [Planet Mean Temperature] and [Planet Radiation.] The possibility of [Liquid Water] is then determined by [Atmosphere Density] and [Planet Mean Temperature] (as water boils at different temperatures at different atmospheric densities) as well as looking at [Atmosphere Composition] and [Planet Composition] for the possibility of it even being there at all. The final check for habitability is performed here. If there is no [Liquid Water,] the planet can not possibly host native life.

[Planet Mean Temperature] is the measure of the baseline surface temperature of the planet. It is used as a starting point for calculating the [Temperature Gradient]

[Planet Radiation] is the measure of how much ionizing radiation reaches the planet's surface.

[Liquid Water,] the big one, measures what percentage of the planet's surface is covered by ocean.

The last and most complex step is to generate the planet's [Temperature Gradient] over the course of one day, then over the course of one year, utilizing input from [Planet Rotation Time] and [Atmosphere Greenhouse] for the former and [Planet Rotation Angle], [Orbit Eccentricity,] and [Atmosphere Albedo] for the latter. Both use [Planet Mean Temperature] as a starting point, and utilize Latitude into their calculations. Essentially, we wind up with two three-dimensional graphs: Temperature per day over Time over Latitude and how (Temperature per day over Time) changes over Time over Latitude. I assume we'd calculate the former during the equinox. The resulting graphs are then used to determine [Biomes] much the same way as on this thread https://thrivegame.canadaboard.net/t858-biomes-the-final-definition

Um, here, have a chart for the whole process

Spoiler:

The main reasons I like this is that we can potentially generate an entire system using only numbers, with no need for presets, allowing for a diverse galaxy. In addition, we can easily determine if the planet is suitable for a player homeworld using a few checks along the way.

The main issues here are:

1) Stuff gets really complex once we start using this for multi-star systems, especially the orbit calculations and, by extension, temperature calculations. There are a couple of ways we can kind of gloss over these, mainly by lumping the stars together so that they're calculated as a whole (with combined masses and luminosities) instead of separately. However, this only really works when the stars orbit each other relatively closely. Long story short, multi-star systems are a total Belgium when it comes to orbit calculations. We may have to resort to presets here.

2) No hard math yet, but I've identified relationships and which of these calculations are hard functions and which involve some amount of RNG influence. The latter would be able to be directly tweaked by the player in the Planet Editor. Units for such things as planetary days and years are also up in the air.

3) This has absolutely nothing to do with creating the actual terrain of the planet, so Ocean Level/Biome generation may run into some problems.

4) How element percentages are generated for planets and atmospheres could probably use a lot of work. I have no idea how processor intensive the weighted list method is, which leads me to my final potential issue.

5) I really have no idea if this would be easier or harder to implement compared to Sciocont's original idea, and ultimately this is the major decider here.

[/walloftext]

Nice post. Quite long too.

For arbital stuff and all of related variables, i think i have an easier way of calculating them. And it will work for any amount of stars, and even for player-made solar systems. What we can do is run the solar system through a simulation, with gravity and all that stuff, and start storing the radiation recieved at every chunk of the planets that we care about. Then, once enough time has passed on the simulation (i'm thinking on something from 100 to 1000 years long). Then, if the planets are still in place (didnt bump into other planet and the star formation didnt break), we calculate the temperature for each chunk of the planet.

This acomplises a few things at the same time:
-Calculates the daily temperature variation
-Calculates the seasonal temperature variation
-Makes sure nothing stupid hapens with them (like the same face of the planet facing the star all the time)
-Makes sure the system is stable

Once the calculations are done, we store the results so we dont have to simulate again.

Edit: I've done some quick calculations, and a 1000 years calculation, on a system with 20 objects, runing on a single 2GHz processor will take at most 30s. Probably this is way over the real need. The problem i see is storing the actual energy values, which could take a very big chunk of memory space.

Honestly, the only things concerning star energy we need to store beyond basic Luminosity (which is a preset) are the final values for Radiation Levels and the temperature maps, which we need anyway from what I understand of biome assignment. If the large numbers involved are a worry, all I have to say is that we can select our units here. We can just set it to, say, multiples of Sol (Which is honestly what I was planning for star masses anyway)

I do really like your idea of running an actual gravity simulation. I know I cut a lot of corners on the orbital mechanics, and we'd have to fudge some things to ensure a stable system with the way I have it set up. I was mostly worried about taking up computing resources, but, again, I'm not a programmer.

My sugestion only calculates the energy recieved by the planet. That is, it's temperature. It's not about the star or it's energy level. The problem i was speaking about is storing all the info untill we do the calculation and we can delete the data. That would be:
-We store a radiation map for the first frame on our simulation.
-We move the simulation a frame forwards
-We store a second radiation map
...

Each radiation map requires a tiny amount of space on memory, but if we store one for each frame, for 1000 years, the total size gets huge.

Units shouldn't be much of a problem. Computers are good at that kind of stuff. We could store star's mass in picograms and it would be fine still.

Ah, I see what you mean. Hmm...

Perhaps we run a quick gravity simulation to make sure things are somewhat stable, then use some of whatever it spits out as a starting point for the calculation I described. Hopefully, we can do this all with two functions (total of 10 variables involved if we pare it down, including variables involved in determining variables within the function itself) without needing to gather a bunch of separate data points. It won't be 100% accurate, but I'm hoping it will cut down on unneeded data, since we need at least some of that orbital data for space exploration anyway.

Another way we could do it is have temperature be a function of distance from the star, sort of a simplified "Goldilocks Zone" sort of thing, with dimmer stars having the range closer and brighter stars having it farther out. Just have one zero-point on this gradient defined for each star preset, and we can use a simple function to extrapolate out energy received at each distance. For weird eccentric orbits, we can just use the midpoint between nearest and farthest approach.

At the end of the day, though, the atmosphere of the planet plays a pretty big role in both average temperature and how wildly it swings is varying conditions. It needs to be brought in somehow, but finding an efficient way to do so will probably take some noodling out.

I'm thinking about dropping radiation levels, too. Now that I think about it, I have no real idea how we'd put that into gameplay terms. I don't think we're simulating the long term effects of ionizing radiation on organisms.

Well, by radiation i was only meaning sunlight recieved. Is there anything other we need?

I'll write down the variables that affect sunlight recieved at different areas of the planet, in case someone cames with an idea on how to simplify calculations.

Variables
E_star - Total energy output from the star
r - Distance from the star to the area. It is close enough to the current radius of the planet's orbit that we can use that.
φ - Angle between the line that joins the planet and the star's centers and the normal vector (perpendicular) to the area being calculated.

E_recieved = E_star/(4*π*r²)*cos(φ)

That is assuming the area is perfectly plane, which is not, but close enough. Also, any negative value means the sun doesent hit the surface (night), and the resoult should be set to 0 instead.

E_star is a value that comes from the star's mass and luminosity. It shouldn't change at any point (unless we simulate stars aging).
r comes solely from the eccentricity of the planet, and the time of the year (position on the orbit). It stacks with seasons, but on earth its effects are not too noticiable (summer on the south pole is about half a degree celsius higher, and winter is half a degree lower). It could also meet up with spring and autum on a different orbital setting. On planets with a higher eccentricity, it could make one of the two poles too extreme.
φ is the hardest one to calculate. For it, you need the orbital inclination plus the time of the year. That will change seasons. You also need the latitude. That will make the equator be hotter. And you need time of day too. That will mark daily changes.

That will only be true for planets orbiting a single star. That leaves out any multi-star system and life-bearing moons, althrough some adaptations can be made so the calculations on that cases are not too bad. Tell me if i missed something.

Anyway, i think i have an idea on how to do the solve the problem with the data storing. I'm thinking on storing only the highest and lowest temperatures, plus the overall temperature, to make up biomes. I'll post more if i get some thoughts on it.

Hi there,

That was a really good explanation of your idea ExtraSolar. As a programmer, it was clear to read and all along I tried to figure how that could be applied in code.

I think it is a neat and realistic way to implement it. My suggestion would be to simplify all the planets generation(i.e simulation of planet physic over a long period seems overkill IMO, it's a huge amount of work for something barely noticeable). Some basic rules coupled with randomization would give good results for much less work.

I would concentrate on making the actual planet as realistic as possible. Ideas of temperature related to radiation of the star and eccentricity of the orbit are really cool and aren't THAT much work to implement. They should be calculated on a per-use base(or daily) instead of calculating 100 years ahead which I saw suggested somewhere else.

I'm really interested in everything space related and I've done spacecraft control software during 3 internship. You guys will probably seem me around this thread quite a bit:D

Well, the calculations for the temperature and stuff only need to be done once, to put the biomes on place, then we can just assume solar income dont change too much. That is, precalculate the biomes once and forget about it. If we need to have the amount of light coming in to an area during gameplay, it is really easy to calculate.

Alright, I figured temperature would be an important parameter on a daily basis.

A planet with an extreme eccentricity would have huge temperature gradient over the time of a year and some change over the course of a day. That would definitely impact the creature living there.

This is a detail at this point and we'll see as implementation goes I guess.

About planets with extremely eccentric orbits...

I think I have a solution. We would have two variables : Tmax and Tmin. Tmax would be measured when the planet is at the shortest distance from it's star[s] and Tmin is when it's the most distant. Than we would have another variable: By how much the temperature changes per a certain distance upon getting closer/more distant from the star. That variable would be equal to
Tc=(Tmax-Tmin)/HO. HO is the half of the planets orbit (in 10k km's).

Than instead of measuring the temperature every single day, we would just change the temperature by Tc every time it crosses the required distance.

[quote="ExtraSolar"Large amounts of greatness.[/quote]
First, let me thank you for taking the time to write up such an excellently stated, thought-out, and formatted post. It's really heartening to see new members show up and immediately assume such an excellent level of professionalism and enthusiasm.
You may be interested in this thread, which contains a few very important equations for climate which seregon and I have worked out.
I think the framework you've provided here is excellent, and I'd like to collaborate with you more on it, refining it and plugging in equations for the arrows on your flowchart (I realize that your flowchart was made in a few minutes for explanation's sake, and i'm really happy it's there, since it's a great visual aid- However, you may want to look into yEd or something similar, since it vastly improves workflow and the end product. I'm currently using it to chart organ evolution). It seems to me the best way to start the task would be to create a table for all of the values you've just defined, so they can be quickly looked up by both humans and the computer. This will also help when writing equations, as we can use row-column shorthand for values instead of just writing them out.

Tarpy wrote:

About planets with extremely eccentric orbits...

I think I have a solution. We would have two variables : Tmax and Tmin. Tmax would be measured when the planet is at the shortest distance from it's star[s] and Tmin is when it's the most distant. Than we would have another variable: By how much the temperature changes per a certain distance upon getting closer/more distant from the star. That variable would be equal to
Tc=(Tmax-Tmin)/HO. HO is the half of the planets orbit (in 10k km's).

Than instead of measuring the temperature every single day, we would just change the temperature by Tc every time it crosses the required distance.

This is a good idea, but I think the exact application is a bit different. What we need to apply this to is light, not temperature, since light is what produces the temperature initially. We can take max and min distances and turn them into max and min light levels (by distance), but the relationship of levels in between them is going to be a bit complex because of the nature of the elliptical orbit. I'm going to do a bit of calculus and get back to you.

Wow, thanks for all the kind words, everyone! Also, thanks for the link to yEd, Sciocont. MSPaint isn't exactly prime diagram-making material.

Daniferrito wrote:

That will only be true for planets orbiting a single star. That leaves out any multi-star system and life-bearing moons, althrough some adaptations can be made so the calculations on that cases are not too bad.

I now realize that I forgot to take habitable moons into account as well. Heck, I forgot ring/satellite generation altogether. Whoops. I figure we can just use the planet/belt generation process, but shrink the orbit distances and put a cap on how large the bodies can be. We'll probably use the mass of the host planet to help determine how many satellites roughly to generate, with more massive planets more likely to have more satellites due to having larger spheres of influence.

As far as getting by that minimum mass check for habitability, we could probably make an exemption for satellites around a sufficiently massive planet, since tidal forces would keep geological processes going far longer than the satellite's mass indicates. Or we could get rid of that check altogether, since it's implied in the minimum atmosphere check. If the body is too small to hold onto minimum atmosphere, it's probably too small for geological processes to continue for long enough for life to evolve. Granted, distance from the star also plays a part, thanks to the effect of solar wind, but if you're close enough for that to make a big difference, you've got bigger problems.

RodGame wrote:

Alright, I figured temperature would be an important parameter on a daily basis.

A planet with an extreme eccentricity would have huge temperature gradient over the time of a year and some change over the course of a day. That would definitely impact the creature living there.

This is a detail at this point and we'll see as implementation goes I guess.

You've hit my thinking right on the nose here. As far as I'm concerned, the four major environmental stresses on an organism are Gravity, Atmosphere Density (including oxygen concentrations), Water Availability, and Temperature. The first two are pretty much global, barring extreme elevations for the latter, while the second two would definitely change wildly from biome to biome. From what I can tell, water would be determined by the biome, but I'm unsure at this point whether temperature maps would be used beyond determining biomes. Would the generated temperature map be used to determine temperature during actual gameplay, or would we simplify it to just be determined by the biome you're in? At the end of the day, they'd probably look pretty similar from the player's perspective, but, again, I don't know which of the two would be easier on the programmers/CPU.

On that note, for places that have wild swings in temperature over the course of the year, would we just create a biome that is characterized by wild swings in temperature, or would we stick to more Earth-like biomes and have the actual biome assignment to the area change over time? I'm guessing the former, but it might be a bit hard to conceptualize.

~sciocont wrote:

It seems to me the best way to start the task would be to create a table for all of the values you've just defined, so they can be quickly looked up by both humans and the computer. This will also help when writing equations, as we can use row-column shorthand for values instead of just writing them out.

I do have an Excel file with some basics worked out, but it was mostly just helping me keep my inputs and outputs straight and designating whether there would be any randomness included in a given function. I'm not exactly sure what format you'd want the table, though, both file type and actual layout.

We're going to define biomes partially by seasonality, so temperature swings will be important.
Any kind of table, really. Perhaps you could just write down all of the variable names and I'll try to make a fairly organized table from them.
Satellites are quite important, but lots of their variables will be determined by their planet. The problem with satellites is that their additional rotation creates a bit of a headache when dealing with light, since they'll pass behind the shadow of their planet, creating an extra day/night cycle apart from the one caused by their axial rotation, and their seasonal cycles will be much faster, since their tilt now changes orientation to the stellar plane as it orbits their planet, not as the planet orbits the star, so long as their rotation around the planet is faster than their stellar year.

Alright. After much deliberation (and figuring out yEd,) I've produced a better graph of the planet generation process, this time also including values for satellites, marked with an M prefix.

Warning, large image:

Spoiler:

I also have the original yEd file for anyone who wants it.