Geo Realism: Discussion on a new SDK based map generator

@primem0ver

Some resources appear in approprate geological areas such as Sulphur and Obsidian can be spawned after volcanoes go away. And volcanoes can spawn from such resources too.

Actually volcanoes don't spawn from resources. They spawn from plume hot spots, divergent margins, and from subduction, all of which will produce volcanoes in the plate tectonic simulator. That is one of the main points of all this. To put volcanoes where we would find them in the real world :)
 
Yes... for the most part. However, your post here has gotten me thinking about the month to month precipitation. My original plan was to just use average precipitation per annum. However, that may be inadequate. I don't think that per month is necessary but per season might be useful. Especially since season types are part of the xml schema.
I think at least summer and winter should be a separate consideration to capture mongoose precipitation patterns properly (that is what the Perfect World 3 map script does btw, it generates separate temperature maps for summer and winter and then calculates humidity and precipitation starting from the sea).
 
However, your post here has gotten me thinking about the month to month precipitation. My original plan was to just use average precipitation per annum. However, that may be inadequate. I don't think that per month is necessary but per season might be useful. Especially since season types are part of the xml schema.

If you want to use the Köppen system, you definitely need to calculate monthly precipitation, because a fair number of the climate types under Köppen are determined by percipitation during the driest month and / or wettest month. For instance, one of the thresholds for Tropical Rainforest (Af) is that every month has a precipitation of more than 6 cm. Maritime temperate climates (Cf) are determined by the driest month having more than 3 cm precipitation. Summer-dry Mediterranean climates (Cs) are determined by the driest summer month having less than 3 cm precipitation and three times less precipitation than the wettest winter month. And so on.

To use Köppen, calculating monthly precipitation is a must, I'm afraid. That, and monthly mean temperature.

Actually I appreciate the offer. I would like to take you up on it as well. Sometimes I don't like getting down with minutia of detail because I like fitting it all together into the big picture. So since you are interested in this sort of thing, perhaps you can research the "seasonal" thresholds and fill them into the XML files once I get the format ironed out (for this new addition).

Yes, I'll gladly help with thresholds in the XML tables and the like.
 
To use Köppen, calculating monthly precipitation is a must, I'm afraid. That, and monthly mean temperature.

I don't necessarily agree. Going through the simulation 12 times per re-calculation is going to take a LOT of time considering that the engine will probably be doing a climate "reset" every 50 or so million years of geologic history. (with a total of 20 times = 1 billion years). Of course this is ideal but not likely. It will probably be once every 100 million years.

I think doing four calculations will work fine and we can improvise by adding season length times to the SeasonsInfo file. That way we know how long each season is for a given climate. The average season is 3 months long. That can change for certain types of seasons but tropical rainforests basically have 1 12 month season. So a tropical rainforest must have in excess of 72 cm (6 x 12) which is very close to what I put anyway.
 
I don't necessarily agree. Going through the simulation 12 times per re-calculation is going to take a LOT of time considering that the engine will probably be doing a climate "reset" every 50 or so million years of geologic history. (with a total of 20 times = 1 billion years). Of course this is ideal but not likely. It will probably be once every 100 million years.

Would it be possible to have the engine run on a rougher scale for the geologic history, and then on a more detailed, 12 months per year scale for the last cycle to determine the climate during actual gameplay?
 
Would it be possible to have the engine run on a rougher scale for the geologic history, and then on a more detailed, 12 months per year scale for the last cycle to determine the climate during actual gameplay?

Hmm. Interesting question. I suppose it could be. What would need to happen though is that we would need to define a min and max for each month (thats a LOT of xml), then expand the seasonsInfo xml file schema to allow for defining which months belong to a season for each SeasonsType. That is a lot of work!

For the engine to run in the beginning it can simply talley the months involved in the season and run the simulation once for each season. Then, later it can run the simulation for months individually.

I'm not sure I like it though. It is a big tradeoff for something that can be reasonably simulated anyway. I think that would take too much time between turns when it does run. Of course...then again it will only happen once every 20 thousand years or so...
 
@Laskaris

I will have to do some thinking. There may be an easier approach.

First we can define seasons by using temperature as a criteria. For example, summer is defined as having a temperature above 50 degrees. We can also add wet and dry.

Then we can run a single simulation for climate during peak season months and using that data, calculate the season profile for each plot depending on temperature.

In order to be defined as a certain climate, they must fit a certain season profile.

That way we can accurately define climates without using too much processing time (since seasonal calculations can determine approximate monthly temperatures based on peak air moisture and latitude).
 
What would need to happen though is that we would need to define a min and max for each month (thats a LOT of xml), then expand the seasonsInfo xml file schema to allow for defining which months belong to a season for each SeasonsType. That is a lot of work!

Like I said, I'm willing to help with the work. Given the hours and hours of research I have poured into my Earth maps, I am not really deterred by that.

I admit that I am not very clear yet on how you plan your engine to work, though. So, you plan on modelling the climate all the way through geological history? You mentioned 1 billion years. What is the purpose of this? To gather info for resource placement?

Initially, I assumed that the tectonic plate motion simulator and geomorphology calculator would be one part of the engine, determining the layout of the continents and the bedrock, basically. I assumed that, then, climate modelling would come into play, and that you would run it only over a few thousand years or so until the climate model has stabilized.

I am also not clear on what the purpose of the seasons is. Is a season supposed to be a time unit in the climate calculator? Why not take 1 month, or 3 months, as a time unit instead? That way, you would not have to deal with messy converstions of months into seasons, or determining which month belongs to which season.

Mind you, this isn't criticism of what you are doing. I'm just trying to understand the exact workings so we can get on the same page! I suppose it will become clearer to me once you show more previews.
 
So, you plan on modelling the climate all the way through geological history? You mentioned 1 billion years. What is the purpose of this? To gather info for resource placement?

Bonus placement, feature placement, and geomorphology (placement of different types of geography such as mountains, volcanoes, volcanic deposits, etc...) will be based on the engine running a history. Oil is the easiest example to show how beneficial the history will be.

Oil requires two things (out of three, the third being required):

  1. A vast collection of microorganisms (both photosynthesizing and non photosynthesizing) that settle (creates a deposit) somewhere. OR
  2. A large collection of plant and animal biomatter EITHER of which go through decomposing and minor metamorphic processes AND
  3. A low to zero permeable bedrock deposited directly above that traps the deposit in an environment where it can experience metamorphosing agents without escape.

A geologic history simulation will determine where these occur and where oil traps will most likely be found.

Another example is the Appalachian mountains in the US and the Kjolen Mountains (more commonly known as the Caledonian mountains) in Scandanavia and Britian. These used to be part of the same mountain chain even though the Atlantic ocean separates them. Both of these mountain chains are important parts of geology and shape both our biomes and our land, not to mention history. Yet they are not the results of any modern plate collisions. They are due to a collision that occurred before Pangea existed. Actually it was the collision/merging of two super-continents that created both the single mountain chain (the Caledonian orogeny) and the Pangean supercontinent. When Pangea separated due to a new plate division (spreading center) this mountain chain became separated into the Kjolen Mts on the northeastern side of the split (Europe and Asia) and the Appalacheans in North America.

From this we can see that mountains will be more realistic and more plentiful if we simulate a geologic history.

Initially, I assumed that the tectonic plate motion simulator and geomorphology calculator would be one part of the engine, determining the layout of the continents and the bedrock, basically. I assumed that, then, climate modelling would come into play, and that you would run it only over a few thousand years or so until the climate model has stabilized.

You have the basic idea. Except that climate doesn't need to stabilize. The processes that change climate occur on a much quicker scale that the processes that change continent morphology and location so these changes never destabilize climate. Only volcanic activity that results from plate tectonics can destabilize climate. So I will only run the climate engine once after each geologic calculation (or perhaps once for each season/month).

I am also not clear on what the purpose of the seasons is. Is a season supposed to be a time unit in the climate calculator? Why not take 1 month, or 3 months, as a time unit instead? That way, you would not have to deal with messy converstions of months into seasons, or determining which month belongs to which season.

Mind you, this isn't criticism of what you are doing. I'm just trying to understand the exact workings so we can get on the same page! I suppose it will become clearer to me once you show more previews.

The SeasonsInfos were originally a way to keep track of seasonal variation between moisture and to fit the number of seasons into the Climate calculations. Now it seems we will be using them for more.

I will spell everything out once the XML files are completed and have been posted. The XML is the easiest way to conjure up the details and have more things become set in "stone." It is a way to plan out the way things will work as some details I didn't consider always come to light. Maybe you didn't notice this but the basic approach is explained in the first post of this thread. There have been some minor changes since that post but as I said, more can come and I will explain more detail when they are more firm
 
Thank you for the explanation. I did read the first post of the thread, which explains the basic approach, but no details yet.

So, am I right in assuming that every 50 million years or so of geologic history, the engine is going to calculate the climate? Basically, you are going to take a "sample" at this one point in time, and extrapolate the climate for the entire period from it? Then, fast forward 50 million years of geologic history, and you take another climate "sample" (which will be different from before, given that the position and shape of the continents has changed, new mountains may have been pushed up etc.), and apply it to that period? Is this how it will work?

I must say, simulating a climate history across geological time periods is an incredibly ambitious task. In the real world, there are alternating phases of "Greenhouse Earth" and "Icehouse Earth", the exact causes of which are still little understood and under much debate in the scientific community. Do you plan on including "Greenhouse Earth" and "Icehouse Earth" phases? It would be incredibly complicated.
 
Thank you for the explanation. I did read the first post of the thread, which explains the basic approach, but no details yet.

So, am I right in assuming that every 50 million years or so of geologic history, the engine is going to calculate the climate? Basically, you are going to take a "sample" at this one point in time, and extrapolate the climate for the entire period from it? Then, fast forward 50 million years of geologic history, and you take another climate "sample" (which will be different from before, given that the position and shape of the continents has changed, new mountains may have been pushed up etc.), and apply it to that period? Is this how it will work?

Yup, that's the general idea.

I must say, simulating a climate history across geological time periods is an incredibly ambitious task. In the real world, there are alternating phases of "Greenhouse Earth" and "Icehouse Earth", the exact causes of which are still little understood and under much debate in the scientific community. Do you plan on including "Greenhouse Earth" and "Icehouse Earth" phases? It would be incredibly complicated.

Well considering that I will probably not simulate the two different "earths" for the geologic history it isn't that big of a deal (until we get to game time). The climate engine will be a LOT less complicated than the geologic engine. Especially because as I have been thinking about it, I have realized that I do not need to simulate air mass movement as a whole from the oceans. I have simplified the algorithm considerably.

Basically I will make a list of all beach plots and mid continent plots. These plots will already have a wind direction, wind speed, relative humidity, and temperature initiated based on global winds, nearby geography types, and latitude. They will also have a calculated amount of water in the air. So I simply move the air from that plot to the next plot in the direction of the global winds. Calculate the change in elevation, the rise (or fall) in humidity, and any thing over 100% is reduced to 100% with the excess being converted to precipitation. Next plot please... (and so forth) until we intersect another air mass.

I will be using a queue structure to do the calculations so we do one piece of the air mass at a time.

A final precipitation value will also consider the "air mass frequency." I will consider the size of the body of water, the wind speed, and possibly one or two other variables to come up with a "number of air masses per season" type of calculation (frequency). This will lead to the final rainfall statistics for the plot.

Then, for each plot the climate will be determined based on temp statistics*, season length, humidity statistics*, latitude, direction of nearest coast, and rainfall statistics* (did I miss anything?)

Finally, the plot vegetation will be calculated and assigned and bonuses generated based on statistics found in the VegetationInfos file.

All that is easy compared to the plate tectonic engine which will involve considerably more physics and geometry math.

As far as ice versus greenhouse? I may add that for calculations during the game. But not for the historical part of it. The reason is because it doesn't really matter much for the game. Climates are much more fleeting than geology. I suppose I could randomize an "ice earth" occurrence during the whole effect by lowering temperatures globally every now and then. Still... it wont effect much since climates can change overnight in geologic terms. The only potential affect could be hidden bedrock layers and their potential to create different bonuses.

*statistics refers to the calculated values for each of the four seasons.
 
Thanks again, I'm getting a much clearer picture now.

The climate engine will be a LOT less complicated than the geologic engine.

I could be wrong, but I'm getting the impression that you have a bigger interest in geology than me, while I have a somewhat bigger interest in the climate generation. It's not like the other field doesn't interest us at all, but there seems to be a slightly different emphasis. We could complement each other well.

Basically I will make a list of all beach plots and mid continent plots. These plots will already have a wind direction, wind speed, relative humidity, and temperature initiated based on global winds, nearby geography types, and latitude. They will also have a calculated amount of water in the air. So I simply move the air from that plot to the next plot in the direction of the global winds. Calculate the change in elevation, the rise (or fall) in humidity, and any thing over 100% is reduced to 100% with the excess being converted to precipitation. Next plot please... (and so forth) until we intersect another air mass.

I will be using a queue structure to do the calculations so we do one piece of the air mass at a time.

A final precipitation value will also consider the "air mass frequency." I will consider the size of the body of water, the wind speed, and possibly one or two other variables to come up with a "number of air masses per season" type of calculation (frequency). This will lead to the final rainfall statistics for the plot.

Sounds okay. We will see how well it works in practice, and then we can tweak it. The goal is that it should generate accurate results, in broad terms, on an Earth map. That should be the yardstick, as you wrote earlier.

What is crucial, in my view, is that calculations for the airflow are done for different times of the year as well.

Then, for each plot the climate will be determined based on temp statistics*, season length, humidity statistics*, latitude, direction of nearest coast, and rainfall statistics* (did I miss anything?)

I have done some thinking about this, and I believe that, actually, you can determine climate a lot easier. That is, at least you don't need as many factors as the ones you mentioned.

Frankly, "season length" and the whole messing around with different seasons of different lengths strikes me as unncessarily complicated. I would just leave it out. You also don't need "direction of nearest coast" or "humidity statistics" to determine climate. All you really need is temperature and rainfall for different times of the year, and you have the climate type - that is how Köppen does it.

Here is how I would do it, just as an idea, and to illustrate how it could work:

- You calculate the mean temperature of a square, as a result of latitude, elevation above sea level, time of year (angle of sunlight) and airmass flow. Temperature according to latitude, elevation and time of year is a very straightforward calculation. Factoring in the airmasses, the hot and cold winds, is a bit more complicated, but you have the airmass calculator / simulator for this.

- Similarly, you calculate the precipitation that a square gets. This is also largely a result of the airmass calculator / simulator.

- You do these temperature and precipitation calculations for different points of the year. This is the crucial part - otherwise, the Köppen system can't really be applied. Ideally, temperature and precipitation should be calculated for every month of the year, which would mean 12 calculations. I believe dividing the year into four phases and doing only four calculations would be adequate, though. To do this, we don't need to mess around with "seasons" per se, nevermind seasons of different length in different places. We just divide the year into four phases of three months each, straightforward.

- The third thing you need to know (in addition to temperature and precipitation) is whether a plot is on the northern or on the southern hemisphere, so that you know whether a certain month (or 3-month phase) belongs to the "summer" time or the "winter" time.

- Once you have the mean temperature and precipitation for the 12 months (or four 3-month phases), the climate type can be determined in a pretty straightforward way, like Köppen does it. For instance: if the mean temperature of the coldest month is 18° C, the square has a Tropical (A) climate. If, in addition to that, the precipitation of the driest month is more than 60 mm, it has a Tropical Rainforest (Af) climate. If it has some dry months, it has a Savannah climate (Aw). Et cetera. Or, if the hottest month has a mean temperature of more than 10° C, and the coldest month a mean temperature between 0° C and 18° C, we are talking about a Temperate (C) climate. Furthermore, the precipitation values determines whether it is dry summer (Cs), dry winter (Cw) or fully wet oceanic (Cf). And so on.

- You can take a look at the way the different Köppen climate types are determined in Table 1 of this essay. It gives the general idea. Simpler equations would also work well enough, I think - I'll come up with something.

As far as ice versus greenhouse? I may add that for calculations during the game. But not for the historical part of it. The reason is because it doesn't really matter much for the game. Climates are much more fleeting than geology. I suppose I could randomize an "ice earth" occurrence during the whole effect by lowering temperatures globally every now and then. Still... it wont effect much since climates can change overnight in geologic terms. The only potential affect could be hidden bedrock layers and their potential to create different bonuses.

I think a "Greenhouse Earth" and "Icehouse Earth" simulation for the geological stages would really be overdoing it. My point was the opposite: do we really need to model climate for the geological timespans at all? If you don't take all the massive climate changes, greenhouse phases, icehouse phases etc. into consideration, it is not a very accurate simulation. But if you do, it gets incredibly complicated.

Maybe it would be a better idea to simulate the geological climate, insofar as it is relevant for resource placement (coal and oil), in a much, much rougher fashion?
 
I think a "Greenhouse Earth" and "Icehouse Earth" simulation for the geological stages would really be overdoing it. My point was the opposite: do we really need to model climate for the geological timespans at all? If you don't take all the massive climate changes, greenhouse phases, icehouse phases etc. into consideration, it is not a very accurate simulation. But if you do, it gets incredibly complicated.

Maybe it would be a better idea to simulate the geological climate, insofar as it is relevant for resource placement (coal and oil), in a much, much rougher fashion?
I'd like to add a few observations to this conversation, if I may...

1: if the map takes various snapshots of geologic history and climate history then it would be neat to save those snapshots and potentially use them in the future of our development for a multi-map method of representing time travel adding real estate to the game via portals to distant history.

2: if we don't include the icehouse ages etc... how will we work in the desired adjustments of ice ages striking and receding throughout the span of the early human history we'd like to express during the game? It sounds as if these setup methods could be extended to continue operating throughout play!
 
I'd like to add a few observations to this conversation, if I may...

1: if the map takes various snapshots of geologic history and climate history then it would be neat to save those snapshots and potentially use them in the future of our development for a multi-map method of representing time travel adding real estate to the game via portals to distant history.

2: if we don't include the icehouse ages etc... how will we work in the desired adjustments of ice ages striking and receding throughout the span of the early human history we'd like to express during the game? It sounds as if these setup methods could be extended to continue operating throughout play!

I know this might open a can of worms and hot debate but...

1. I don't believe in time travel for several reasons. I know not all physicists negate this possibility but their are reasons they should. The gravitational constant is one of them. If time travel is possible then the gravitational constant is subject to change... which would violate the idea that it is constant (I wrote a short story about getting around this problem but... in the end it is only one of the reasons I don't believe.). So besides the problem with making an already complicated mod more complicated... I don't like the idea of "time" real estate at all.

However, that doesn't mean the time snapshots shouldn't be saved for future use. If for no other reason, I like the educational value of it... a window into each world's past.

2. I thought this is what Laskaris was suggesting it for... apparently not.
 
I know this might open a can of worms and hot debate but...

1. I don't believe in time travel for several reasons. I know not all physicists negate this possibility but their are reasons they should. The gravitational constant is one of them. If time travel is possible then the gravitational constant is subject to change... which would violate the idea that it is constant (I wrote a short story about getting around this problem but... in the end it is only one of the reasons I don't believe.). So besides the problem with making an already complicated mod more complicated... I don't like the idea of "time" real estate at all.

However, that doesn't mean the time snapshots shouldn't be saved for future use. If for no other reason, I like the educational value of it... a window into each world's past.

2. I thought this is what Laskaris was suggesting it for... apparently not.

I can understand objections to Time Travel on theoretical ground such as this BUT it should be noteworthy that its a tech that already exists on our future tree...

2. It appeared that Laskaris was trying to say such models were unnecessary and I was trying to make a point that not only would they be necessary for establishing the process in creating the map up to now, but could also be extended to continue taking place during the play frame of the game as well. In short, I was supporting your assertion that they'd be necessary.
 
Thanks again, I'm getting a much clearer picture now.

I could be wrong, but I'm getting the impression that you have a bigger interest in geology than me, while I have a somewhat bigger interest in the climate generation. It's not like the other field doesn't interest us at all, but there seems to be a slightly different emphasis. We could complement each other well.

I'm not sure if I agree with that assessment or not. I have a keen interest in both climate and the "creation myth" from the perspective of science (i.e. the science version of the story). A lot of that has to do with how the Earth's physical structure came to be how it is. So I suppose that is the big geology part at play here. However, the fact is that geophysical simulation is by nature much more complicated than climate systems. We understand most of what there is to know about climate in terms of factors involved. When it comes to tectonics, we know a basic mechanism and most of the structures involved. Yet we still don't know where some of the plate boundaries are... we just have good guesses. Modeling the exact movement of plates is still something we are trying to fully grasp.


You also don't need "direction of nearest coast" or "humidity statistics" to determine climate. All you really need is temperature and rainfall for different times of the year, and you have the climate type - that is how Köppen does it.

While theoretically this is probably true (because ultimately it depends on raw data), the reality is that direction of the nearest coast will make climate calculations more simple. The question here is whether it is an east or west coast because gyres play a HUGE role in climate. Knowing whether the closest east-west coast is east or west (warm or cold current respectively) will tell us much about which climates are even possible on a plot.

We can factor in this information as a shortcut to get a more precise model about the 12 month humidity and rainfall patterns.


Ideally, temperature and precipitation should be calculated for every month of the year, which would mean 12 calculations. I believe dividing the year into four phases and doing only four calculations would be adequate, though. To do this, we don't need to mess around with "seasons" per se, nevermind seasons of different length in different places. We just divide the year into four phases of three months each, straightforward.

I believe that temperature can be projected for 12 months if we know max, min, and the more in between points, the better. The same with humidity. While "seasons" may seem arbitrary, they are part of how climates are described to real people and this should be part of our model if for no other reason than to describe the climate of an area. I also believe it can help us shortcut a few calculations.


The third thing you need to know (in addition to temperature and precipitation) is whether a plot is on the northern or on the southern hemisphere, so that you know whether a certain month (or 3-month phase) belongs to the "summer" time or the "winter" time.

This makes no difference when it comes to climate calculations and will not be factored in. We will define "winter" as the coldest part of the year and summer as the hottest. It doesn't have anything to do with the numbers. The same climates that exist in the northern hemisphere exist in the northern hemisphere as well (or at least would if the land masses were mirror images). Because summers of both hemispheres are 6 months offset from each other has no bearing on conditions that make them what they are.


Maybe it would be a better idea to simulate the geological climate, insofar as it is relevant for resource placement (coal and oil), in a much, much rougher fashion?

This is the reason for the "historical" climate. Otherwise it wouldn't be necessary. So we might just do a rudimentary run of climate for the past and one final big one in the present. (Maybe we can even do a 12 month run for it).
 
2: if we don't include the icehouse ages etc... how will we work in the desired adjustments of ice ages striking and receding throughout the span of the early human history we'd like to express during the game? It sounds as if these setup methods could be extended to continue operating throughout play!

Just as an additional clarification: what I referred to above as an "Icehouse Earth" stage is not the same thing as what we commony call an "ice age".

What I called an "Icehouse Earth" is a period of time where continental ice sheets are present, as opposed to a "Greenhouse Earth" stage where no such ice sheets are present and the worldwide climate is much hotter than today (think the age of the dinosaurs). Today, we live during an "Icehouse Earth" phase. These icehouse / greenhouse phases last for very long times, many million years at a time.

The colder phase we live in today, what I called the icehouse phase, is again divided into glacial periods (what we commonly call an "ice age", with extensive glaciation of the higher latitudes), and warmer interglacials (i.e. today). These glacials and interlglacials alternate at a much higher frequency. They usually last less than 1 million years.

There is debate over what causes the long "icehouse" and "greenhouse" stages. One theory is that there is a lot of tectonic and thus volcanic activity during the greenhouse stages, which releases high levels of greenhouse gases into the atmosphere and heats the climate up. Once the volcanic activity subsides and the greenhouse gases decline, the climate cools down again and becomes "icehouse". But, like I said, there is debate about this and the whole process is still very poorly understood.

The alternation between glacial ("ice ages") and integlacial phases, on the other hand, are very probably down to astronomic factors - changes in the tilt of the Earth's axis and the Earth's orbital eccentricity.

Changes between "Greenhouse Earths" and "Icehouse Earth" would be very difficult to simulate, I think, because you would have to mess around with significant changes in the atmospheric composition, the building up and declining of greenhouse gases, and so forth. There is a lot of uncertainty about this.

Glacials and interglacials should be somewhat easier, because the changes in the tilt of the Earth's axis, or the orbital eccentricity, are a somewhat more straightforward process in terms of the mathematics involved. It is also much more recent history, so we have more reliable data on it.
 
While theoretically this is probably true (because ultimately it depends on raw data), the reality is that direction of the nearest coast will make climate calculations more simple. The question here is whether it is an east or west coast because gyres play a HUGE role in climate. Knowing whether the closest east-west coast is east or west (warm or cold current respectively) will tell us much about which climates are even possible on a plot.

I see your point. On the other hand, ocean gyres aren't as straightforward as "east coast = warm, west coast = cold", as I'm sure you know. There are warm and cold gyres on either side, depending on the latitude they come from and the continental shape. So other factors need to be taken into account as well.

Have you thought about doing an actual simulation of the ocean currents? Since we would only deal with the surface currents (no deep sea stuff), it might be a fairly straightforward affair. But it would add some work, obviously.

I believe that temperature can be projected for 12 months if we know max, min, and the more in between points, the better. The same with humidity.

I don't think projection would work with min and max only. With some more in-between points, it might.

While "seasons" may seem arbitrary, they are part of how climates are described to real people and this should be part of our model if for no other reason than to describe the climate of an area. I also believe it can help us shortcut a few calculations.

I agree that we should make the results of the model accessible to people. Whether seasons have to be part of the actual calculations is another question, though. If they can help as a shortcut, great.

This makes no difference when it comes to climate calculations and will not be factored in. We will define "winter" as the coldest part of the year and summer as the hottest.

True, that is an easier way to do it.

So we might just do a rudimentary run of climate for the past and one final big one in the present. (Maybe we can even do a 12 month run for it).

I think that would be the best way to do it. And a 12 month run for the final, as-accurate-as-possible climate would be awesome.

I'll get to work on exact criteria for the climate zones, so we can discuss them and I can put them in when we get to that stage.
 
There is debate over what causes the long "icehouse" and "greenhouse" stages. One theory is that there is a lot of tectonic and thus volcanic activity during the greenhouse stages, which releases high levels of greenhouse gases into the atmosphere and heats the climate up. Once the volcanic activity subsides and the greenhouse gases decline, the climate cools down again and becomes "icehouse". But, like I said, there is debate about this and the whole process is still very poorly understood.
One significant effect is tectonic plate movement and its effect on ocean currents. The amount of ice on Antarctica could only reach its present level because of the Antarctic Circumpolar Current, which isolates it from the warmer regions.
 
Just from a playability and enjoyment standpoint, I hope the amount of desert and otherwise poor/useless terrain is hopefully reduced from that generated by the perfect world 2f map.
 
Back
Top Bottom