PPG- Procedural Planet Generator

ExtraSolar wrote:

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.

Thats nice work.

ExtraSolar wrote:

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 first 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 need to keep track of more then just Oxygen Concentration and density (When it comes to Atmosphere) , we need to worry about CO^2 remember, the player is supposed to be able to play as a plant and therefore we will definitely need to keep track of CO^2. We also need to keep track of pressure. Of course both of these would be mostly static and we wouldn't have to worry about that when it comes to biome generation. (we might be able to do CO^2 by biome though if we want to say, make a place where plants will grow much better, and take into account the greenhouse effects in the industrial stage)

From a programming standpoint, CO^2 concentration should be easy to implement, pressure might be a different story entirely.

Pressure should be fairly easy- you just need to know how thick (meaning, how many miles around the planet it extends) the atmosphere is, and the average density (g/cm³) of the atmosphere. Then you can convert your distance above sea level into the pressure you feel from the atmosphere by knowing how much gas is weighing down on you. The same can be done for pressure under water, except it's even easier, since the seawater composition probably won't vary as much as atmospheric composition.

Also, if you could give me the yEd for that, that would be great. It looks brilliant.

untrustedlife wrote:

We need to keep track of more then just Oxygen Concentration and density (When it comes to Atmosphere) , we need to worry about CO^2 remember, the player is supposed to be able to play as a plant and therefore we will definitely need to keep track of CO^2. We also need to keep track of pressure. Of course both of these would be mostly static and we wouldn't have to worry about that when it comes to biome generation. (we might be able to do CO^2 by biome though if we want to say, make a place where plants will grow much better, and take into account the greenhouse effects in the industrial stage)

Since we'd be keeping track of the percentages of different gasses in the atmosphere with this model, as well as density, I imagine that figuring out the relative concentrations of each individual gas would be easy. I mostly focused on oxygen concentrations because they would play a big role in organism evolution. In addition to CO2, I suggest keeping track of water vapor as well.

Of note, [A Greenhouse] is the measure of what percentage of the atmosphere is composed of greenhouse gasses, such as CO2, Water Vapor, Methane, and just about any other molecule with 3+ atoms. The way it's set up now, though, it would only be calculated once at planet creation, but I suppose we could have it and a few other values be recalculated every now and again.

~sciocont wrote:

Pressure should be fairly easy- you just need to know how thick (meaning, how many miles around the planet it extends) the atmosphere is, and the average density (g/cm³) of the atmosphere. Then you can convert your distance above sea level into the pressure you feel from the atmosphere by knowing how much gas is weighing down on you. The same can be done for pressure under water, except it's even easier, since the seawater composition probably won't vary as much as atmospheric composition.

Also, if you could give me the yEd for that, that would be great. It looks brilliant.

Hmm. I might have to tweak some variables here. [A Density] measures pressure at whatever we're marking as sea-level (Or other zero-point.) I suppose we could use the composition to figure the actual density, but the main issue here is that the height of the atmosphere is left unspecified in my model. Time to add more variables, I suppose.

As for the yEd file, it looks like I can't add it as an attachment here. Should I just e-mail it to you?

Sure, you can email me. ikrone @wi.rr.com
If we have percent compositions, density should not be a problem to calculate. We may run into problems with stratification of the atmosphere though.

Sent.

Yeah, for the sake of simplicity, I modeled atmospheres as one homogenous unit. This will definitely be a problem if we want to have organisms above the troposphere/on gas giants. (Are we doing gas giant organisms? Because the habitability checks assume a terrestrial planet)

ExtraSolar wrote:

Sent.

Yeah, for the sake of simplicity, I modeled atmospheres as one homogenous unit. This will definitely be a problem if we want to have organisms above the troposphere/on gas giants. (Are we doing gas giant organisms? Because the habitability checks assume a terrestrial planet)

Gas giant planets were considered, but we won't focus on them until we have a stable terrestrial game. Could you write up a little key to the yEd chart explaining what some of the abbreviations are. and what red, green, and blue lines mean?

I've got a rough key to the side of the main graph, but I'll write it here too

S prefixes indicate star attributes
P prefixes indicate planet attributes
M prefixes indicate satellite attributes
PA is for Planetary Atmosphere
MA is for Satellite Atmosphere

Circular Nodes indicate values that are determined entirely by input from other values.
Rectangular Nodes indicate values that are determined semi-randomly with input from a RNG. In the Planet Editor, these values would likely be able to be tweaked by user input by manipulating the random input.
Nodes with a blue background are used in habitability checks,

Red lines indicate that one value puts a maximum cap on another.
Blue lines indicate that one value influences the other, but there is a random element involved.
Green lines indicate that one value directly dictates another, with no random element involved.

S Metal is Star Metallicity
S Lumin is Star Luminosity
P Number and M Number are the number of Planets/Belts around the star and number of Moons/Rings around the planet, respectively
Orbit T is Obit Time, or Year
Orbit E is Orbit Eccentricity
Orbit D is Orbit Distance
Comp stands for Composition
Dense stands for Density (Rather, pressure at sea-level)
Green stands for Greenhouse Gas Concentration
PM Mass Ratio is the ratio between the masses of the Planet and Satellite
M Tidal Flex is the measure of how much tidal flexing the satellite receives, as influenced by PM Mass Ratio and it's orbit eccentricity. High numbers will increase geological processes and the mean temperature of the body.
Rot T is Rotation Time, or Day
Rot A is Rotation Angle, or Axis Tilt
Rads stands for Radiation at Surface (We may get rid of this variable and it's Satellite equivalent if we don't want to model ionizing radiation)
Temp Mean is the mean temperature of the body
Temp Grade is the map of temperature variation over latitude over time

I'm pretty sure that's it. If you have any other questions, feel free to ask.

That's good. I just added a key under the main chart.

I've been putting some thought into what sort of stars we would want to represent, and what sort of presets we would want. I've done some work on this, but I wanted to post it up in case I missed something. My big question is whether we should include variable stars.

Let me show you the list so far:

Main Sequence (The vast majority of stars populating the galaxy, and hosts for almost all player-worlds)

O: An upper-range blue star, the hottest and largest of the main sequence, rare
OB: (not an actual class) A lower-range blue star, closer to the border between O and B
B: A blue-white star
A: A white star
F: A white-yellow star
G: A yellow star, much like our sun
K: An orange star
KM: (not an actual class) An upper-range red star, closer to the border between K and M, common. aka Red Dwarf
M: A lower-range red star, the coolest and smallest of the main sequence, common. aka Red Dwarf

Giants (Larger stars, typically evolved main sequence stars)

Standard Red: A typical Red Giant
Red Clump: A type of Red Giant notable for stable luminosity
Asymptotic Branch: A late-stage Red Giant
Standard Blue: A typical Blue Giant
Horizontal Branch: A late-stage Blue Giant
Blue Straggler: A high-mass blue star that has not evolved

Supergiants (Very large stars, the source of heavier elements, often unstable)

Blue: A typical Blue Supergiant
Red: A typical Red Supergiant, often evolved from a blue one

Hypergiants (Incredibly large stars, unstable, with fierce solar winds)

Blue: A typical Blue Hypergiant
Red: A typical Red Hypergiant, the largest stars in the galaxy

Other Stars (Exotic, Degenerate, and Pre/Post-fusion stars)

Wolf-Rayet: A large, very hot star that is rapidly losing mass
Hot White Dwarf: A White Dwarf on the hotter, brighter end of the spectrum, relatively young. The remains of a lower-mass star.
Cool White Dwarf: A White Dwarf on the cooler, dimmer end of the spectrum, relatively old. The remains of a lower-mass star.
Brown Dwarf: A failed star, too small to perform fusion.
Neutron Star: A hyper-dense object produced from the death of a high-mass star. Rotates quickly and has a strong magnetic field.
Black Hole: A hyper-dense object produced from the death of a very high-mass star, dense enough to prevent light escaping from its gravity well.
Quark Star: A mostly theoretical, hyper-dense object formed from a massive Neutron Star. Incredibly rare.
Protostar: A star in the process of formation, found inside certain nebulae.

(27 presets so far)

Quote :

(27 presets so far)

Try to keep the number of presets low. We can cut complexity by compressing main sequence stars into one group which ranges through the individual classes in mass, color, and luminosity. We'll most likely be playing around F, G, K, and M stars.

~sciocont wrote:

Quote :

(27 presets so far)

Try to keep the number of presets low. We can cut complexity by compressing main sequence stars into one group which ranges through the individual classes in mass, color, and luminosity. We'll most likely be playing around F, G, K, and M stars.

Hmm. Good idea. I was trying to strike a balance between variety and simplicity, but I think with a little work/math we could pull off compressing Main Sequence down to a function. We might even see better results from it, since they compose 90% of the stars in the galaxy. Honestly, we could pare down the Giant class to just red and blue, and simplify White Dwarfs to a function as well, leaving us with two functions and 12 presets. (11 if we cut Quark Stars)

ExtraSolar wrote:

~sciocont wrote:

Quote :

(27 presets so far)

Try to keep the number of presets low. We can cut complexity by compressing main sequence stars into one group which ranges through the individual classes in mass, color, and luminosity. We'll most likely be playing around F, G, K, and M stars.

Hmm. Good idea. I was trying to strike a balance between variety and simplicity, but I think with a little work/math we could pull off compressing Main Sequence down to a function. We might even see better results from it, since they compose 90% of the stars in the galaxy. Honestly, we could pare down the Giant class to just red and blue, and simplify White Dwarfs to a function as well, leaving us with two functions and 12 presets. (11 if we cut Quark Stars)

I would definitely advocate a function for all main-sequence stars, as well as dwarfs and giants. I don't really care about implementing quark stars, so do whatever you like with them.