03-24-2012, 11:58 PM
Generating a world:
===================
First of all, what is the world? What parts can it be split into? Can those parts be changed independently of each other?
- Terrain height
- Ores
- Biome
- Structures (caves, trees, villages, ...)
- Terrain composition (waterlevel height, 3 dirt on top of stone, beaches near waterlevel, ...)
- Small foliage (tall grass, mushrooms, ...)
Changing algorithm for any of the above part results in a different world, but the change doesn't require propagation into other parts. A part may depend on other part being calculated first (terrain height on biome, structures on terrain height), but the dependency is purely value-centric, not algorithm-centric. So why not make them interchangeable for the users? Suggested dependencies:
Terrain height -> Biome
Terrain composition -> Terrain height & Biome
Structures -> Terrain height
Small foliage -> Terrain height
Biome
Current generator only has one fixed constant biome. A newer implementation could change that into whatever biome distribution we want - distorted-voronoi like the original MC, settable constant biome or even checkerboard biomes.
Technically, the biome generator has to generate an array of 16x16 biome enumerations for each chunk.
Terrain height
Current generator doesn't take biomes into consideration and generates height only based on the internal noise function. A newer implementation can use several noise functions, one for each biome, and interpolate between them based on biome data provided by the Biome generator.
Terrain composition
This one is questionable. Who should be responsible for the basic terrain composition, such as the amount of dirt on top of stone, the waterlevel etc.? I think there should be a terrain compositing component. The basic one, working as the current version, just makes the top three layers dirt, fills water up to waterlevel and adds beaches near the water. An essential modification is to be used with biomes - desert biome needs sand terrain and swamp biome needs clay pools, etc.
Structures
Generated things that are larger than a single block need to be able to be calculated again (for the neighboring chunks) and may be cached. Currently there is no such thing in MCS and we really need one, at least for the trees. Having the structures generate in the same step as the rest of the chunk will allow us to provide full chunk data immediately after generating and lighting data in a 1-delayed level. Currently this 1-delayed level is used for trees, which would mean lighting would be available on 2-delayed level, which is too much strain (needs to check 5x5 areas of 5x5 chunks after each chunk is generated).
Small foliage
Currently small foliage is generated all over the terrain, which is not really acceptable. Things should be more rare and should adhere to their rules (mushrooms in the dark etc.). Biomes could also modify parameters such as the probability for each element's spawning.
Ores
Current generation of ores is satisfactory, but could benefit from some slight Biome dependency - for example a bit more coal in the swamp biome etc. If we ever make springs a part of ore generation, then this is even more important, since biomes could affect the number of springs both underground and overground.
How to generate...
==================
... Original MCServer terrain:
- use a constant biome ("plains" are used currently for the MapChunk packets)
- use the terrain height using builtin cNoise
- use trees and 3D-noise caves for structures, nothing else
- small foliage everywhere on the terrain
... Flat terrain (WG-flat-like):
- use a constant biome
- use a constant terrain height
- no structures, no trees
... MineCraft-like terrain:
- distorted-voronoi biomes, with another distorted-voronoi ocean selector
- terrain height dependent on biomes, interpolating
- trees, worm-nest-caves and possibly other structures
- small foliage dependent on biome and (direct) lighting conditions - maybe even 1-delayed for the correct lighting
===================
First of all, what is the world? What parts can it be split into? Can those parts be changed independently of each other?
- Terrain height
- Ores
- Biome
- Structures (caves, trees, villages, ...)
- Terrain composition (waterlevel height, 3 dirt on top of stone, beaches near waterlevel, ...)
- Small foliage (tall grass, mushrooms, ...)
Changing algorithm for any of the above part results in a different world, but the change doesn't require propagation into other parts. A part may depend on other part being calculated first (terrain height on biome, structures on terrain height), but the dependency is purely value-centric, not algorithm-centric. So why not make them interchangeable for the users? Suggested dependencies:
Terrain height -> Biome
Terrain composition -> Terrain height & Biome
Structures -> Terrain height
Small foliage -> Terrain height
Biome
Current generator only has one fixed constant biome. A newer implementation could change that into whatever biome distribution we want - distorted-voronoi like the original MC, settable constant biome or even checkerboard biomes.
Technically, the biome generator has to generate an array of 16x16 biome enumerations for each chunk.
Terrain height
Current generator doesn't take biomes into consideration and generates height only based on the internal noise function. A newer implementation can use several noise functions, one for each biome, and interpolate between them based on biome data provided by the Biome generator.
Terrain composition
This one is questionable. Who should be responsible for the basic terrain composition, such as the amount of dirt on top of stone, the waterlevel etc.? I think there should be a terrain compositing component. The basic one, working as the current version, just makes the top three layers dirt, fills water up to waterlevel and adds beaches near the water. An essential modification is to be used with biomes - desert biome needs sand terrain and swamp biome needs clay pools, etc.
Structures
Generated things that are larger than a single block need to be able to be calculated again (for the neighboring chunks) and may be cached. Currently there is no such thing in MCS and we really need one, at least for the trees. Having the structures generate in the same step as the rest of the chunk will allow us to provide full chunk data immediately after generating and lighting data in a 1-delayed level. Currently this 1-delayed level is used for trees, which would mean lighting would be available on 2-delayed level, which is too much strain (needs to check 5x5 areas of 5x5 chunks after each chunk is generated).
Small foliage
Currently small foliage is generated all over the terrain, which is not really acceptable. Things should be more rare and should adhere to their rules (mushrooms in the dark etc.). Biomes could also modify parameters such as the probability for each element's spawning.
Ores
Current generation of ores is satisfactory, but could benefit from some slight Biome dependency - for example a bit more coal in the swamp biome etc. If we ever make springs a part of ore generation, then this is even more important, since biomes could affect the number of springs both underground and overground.
How to generate...
==================
... Original MCServer terrain:
- use a constant biome ("plains" are used currently for the MapChunk packets)
- use the terrain height using builtin cNoise
- use trees and 3D-noise caves for structures, nothing else
- small foliage everywhere on the terrain
... Flat terrain (WG-flat-like):
- use a constant biome
- use a constant terrain height
- no structures, no trees
... MineCraft-like terrain:
- distorted-voronoi biomes, with another distorted-voronoi ocean selector
- terrain height dependent on biomes, interpolating
- trees, worm-nest-caves and possibly other structures
- small foliage dependent on biome and (direct) lighting conditions - maybe even 1-delayed for the correct lighting