It appears to me that biomes are currently just randomly distributed, or something close. I don't see any realistic pattern to them like there is in the real world. Doing such a thing wouldn't be that difficult. I've actually been working on a world generator for a little while, and by now the results look really convincing. You can see here for details: http://code.google.com/p/worldgen/
Specifically, this is how some of the techniques I've learned could be implemented in Minecraft, as well as some flaws in adaptation.
-Temperature: My algorithm has two parts as of now: an ambient temperature and an altitude-based temperature. The altitude-based temperature would be easy to implement, just make temperature subtract a value that is a function of height. The ambient temperature is a little harder, as my original model is made for a spherical planet, not an infinite plane. What I think would work, though, is similar. Randomly distributed throughout the map are "poles" that would function similarly to the north and south poles in real life: they are generally the coldest locations, and temperature increases as you move away from them. What would work for Minecraft is setting ambient temperature to a function of the distance from the nearest pole. That way, you have arctic regions, temperate regions, and equatorial regions, all evenly distributed.
-Rainfall: Rainfall has two parts: a latitude modifier and a rain shadow modifier. On Earth, rainfall is largely dependent on latitude. Rainfall is highest closest to the equator and sixty degrees north and south of it. It is the lowest at the poles and thirty degrees away from the equator. Using the same poles from the temperature, an ambient rainfall could just as easily be established. The other half is rain shadow: for this I have a novel algorithm: take any point. Then, project two lines outward from that point one towards and one against the wind, extending upward with a slope inversely proportional to wind speed. If at any point a line passes underground, it gets a value based on the maximum difference between the line's position and the surface. Then, you subtract the line against the wind's value from the line with the wind's, and add the result to rainfall.
-Biomes: For my program, I needed a very algorithmic way to determine biomes. I found the Holdridge Classification Scheme (http://en.wikipedia.org/wiki/Holdridge_life_zones), which does just that. With rainfall and temperature, biome is determined. This is rather straightforward, and for simplicity, several biomes could be mapped to one set of generation parameters.
Unfortunately, there are a few obstacles in implementing this system in Minecraft. Three, to be precise. They are as follows:
-Height: One problem in Minecraft is that the maximum height of a mountain is little more than a hundred meters, and the average is much less. In reality, there are hills bigger than that, and mountains can reach several kilometers. This difference would severely detriment the effectiveness of altitude-based temperature and rain shadow, seeing as hills aren't too high up and don't divert rainfall. Increasing this, though, would likely be bad on the filesize, as chunks would become implausibly high. Also, players would easily become overwhelmed by the scale, barely being able to get anywhere easily, and having buildings seem much less impressive.
-Generation: Another problem with my algorithms is that they take a long time to calculate out. In a realtime generation scenario, this could be too slow. Maybe if the calculations were performed at a lower resolution it would go faster. Additionally, these algorithms usually expect the whole world to be generated at once, but this could be worked around.
-Incompleteness: This one is the easiest problem to fix, and it is that my algorithms aren't complete, so they currently are inaccurate, leaving out a lot of effectors. This may not be a problem in a fantasy game, but it bugs me. They could, though, be modified to correct this in time.
That's my input on this biome situation, from my couple years' experience doing a similar project. I hope not everybody responds to it with TL;DR. VDOgamez out.
Rollback Post to RevisionRollBack
I like making tools for Minecraft. Here are a few of the ones that I have made so far:
MazeGen (Version 1.0) --- An automatic maze generation tool ModelGen (Version 1.0) --- A 3D model import tool
I think you should wait til he does more than 'barely starts them and puts them in the game' before you judge how they're distributed. I really doubt their current implementation is going to be similar to how they will look when finished. He already plans to introduce several different factors that he just simply hasn't been able to get to, in relation to biome mapping.
Interesting read though!
I like your concepts.
I think they may be a bit pre-emptive though.
another problem I noticed was that it would be extremely difficult to implement different poles in a world that's constantly being generated. You would have to have something figure out where the poles are going to be before you could generate any sort of biome in the map (which means you would have to generate a very large chunk with several spaced out poles and the biomes around them before you could make any progress)
but regardless of the problems, what you have is freaking awesome. I seriously hope notch sees this topic
Your approach is very interesting! However, I don't think it will work for Minecraft, simply because (as actionjamesman said) you'd have to generate poles beyond the map to know what's going on where you are.
another problem I noticed was that it would be extremely difficult to implement different poles in a world that's constantly being generated. You would have to have something figure out where the poles are going to be before you could generate any sort of biome in the map (which means you would have to generate a very large chunk with several spaced out poles and the biomes around them before you could make any progress)
but regardless of the problems, what you have is freaking awesome. I seriously hope notch sees this topic
not true at all, a spherical object with pre-determined ungenerated chunks of equal size on the surface could define two randomized poles upon new game start and simply just generate the world terrain as you discover it, which would just eventually loop around if you walked far enough. If everything has a very subtle curve to it, also, it would give the game a horizon and make draw distance easier to pull off in far renders, too.
You don't' need to generate the world to have poles, you only need to determine which chunk on the sphere you start on, and where the magnetic poles are (which wouldn't necessarily correlate with geographic north, so they could be unrelated to the direction te sun and moon move)
Specifically, this is how some of the techniques I've learned could be implemented in Minecraft, as well as some flaws in adaptation.
-Temperature: My algorithm has two parts as of now: an ambient temperature and an altitude-based temperature. The altitude-based temperature would be easy to implement, just make temperature subtract a value that is a function of height. The ambient temperature is a little harder, as my original model is made for a spherical planet, not an infinite plane. What I think would work, though, is similar. Randomly distributed throughout the map are "poles" that would function similarly to the north and south poles in real life: they are generally the coldest locations, and temperature increases as you move away from them. What would work for Minecraft is setting ambient temperature to a function of the distance from the nearest pole. That way, you have arctic regions, temperate regions, and equatorial regions, all evenly distributed.
-Rainfall: Rainfall has two parts: a latitude modifier and a rain shadow modifier. On Earth, rainfall is largely dependent on latitude. Rainfall is highest closest to the equator and sixty degrees north and south of it. It is the lowest at the poles and thirty degrees away from the equator. Using the same poles from the temperature, an ambient rainfall could just as easily be established. The other half is rain shadow: for this I have a novel algorithm: take any point. Then, project two lines outward from that point one towards and one against the wind, extending upward with a slope inversely proportional to wind speed. If at any point a line passes underground, it gets a value based on the maximum difference between the line's position and the surface. Then, you subtract the line against the wind's value from the line with the wind's, and add the result to rainfall.
-Biomes: For my program, I needed a very algorithmic way to determine biomes. I found the Holdridge Classification Scheme (http://en.wikipedia.org/wiki/Holdridge_life_zones), which does just that. With rainfall and temperature, biome is determined. This is rather straightforward, and for simplicity, several biomes could be mapped to one set of generation parameters.
Unfortunately, there are a few obstacles in implementing this system in Minecraft. Three, to be precise. They are as follows:
-Height: One problem in Minecraft is that the maximum height of a mountain is little more than a hundred meters, and the average is much less. In reality, there are hills bigger than that, and mountains can reach several kilometers. This difference would severely detriment the effectiveness of altitude-based temperature and rain shadow, seeing as hills aren't too high up and don't divert rainfall. Increasing this, though, would likely be bad on the filesize, as chunks would become implausibly high. Also, players would easily become overwhelmed by the scale, barely being able to get anywhere easily, and having buildings seem much less impressive.
-Generation: Another problem with my algorithms is that they take a long time to calculate out. In a realtime generation scenario, this could be too slow. Maybe if the calculations were performed at a lower resolution it would go faster. Additionally, these algorithms usually expect the whole world to be generated at once, but this could be worked around.
-Incompleteness: This one is the easiest problem to fix, and it is that my algorithms aren't complete, so they currently are inaccurate, leaving out a lot of effectors. This may not be a problem in a fantasy game, but it bugs me. They could, though, be modified to correct this in time.
That's my input on this biome situation, from my couple years' experience doing a similar project. I hope not everybody responds to it with TL;DR. VDOgamez out.
MazeGen (Version 1.0) --- An automatic maze generation tool
ModelGen (Version 1.0) --- A 3D model import tool
Interesting read though!
I like your concepts.
I think they may be a bit pre-emptive though.
http://notch.tumblr.com/post/123343045/my-vision-for-survival (follow this link if you need proof)
but regardless of the problems, what you have is freaking awesome. I seriously hope notch sees this topic
not true at all, a spherical object with pre-determined ungenerated chunks of equal size on the surface could define two randomized poles upon new game start and simply just generate the world terrain as you discover it, which would just eventually loop around if you walked far enough. If everything has a very subtle curve to it, also, it would give the game a horizon and make draw distance easier to pull off in far renders, too.
You don't' need to generate the world to have poles, you only need to determine which chunk on the sphere you start on, and where the magnetic poles are (which wouldn't necessarily correlate with geographic north, so they could be unrelated to the direction te sun and moon move)
http://notch.tumblr.com/post/123343045/my-vision-for-survival (follow this link if you need proof)