Phase 1 World Generation

[DigitalLibrarian]

Phase 1 will not be finished product. It'll will still be a tech demo. But once it is over, then we can start talking about surface npcs and things. Phase 1 can be described as being similar to the map model that Minecraft uses.

• Endless terrain generation in all 6 directions
• Mixable/Composable generation strategies

A world generation profile will be built from a set of composable generation strategies, for example :

• "Adding a 3d vein of copper"
• "Adding a cave"
• "Adding a surface feature"
• "Adding Trees"

These strategies will likely begin life as action bar items, bound to the number pad. If they require special input, then dialogs will likely pop up (initially). Depending on where things go, the useful stuff will likely be pulled out into external editors. This UI description will only be to get something rolling. It does not represent any determination over future UI. We just need a way to build a world and interact with the systemic components that generate it

Once we have a rich set of strategies, then generating a world can be reduced to merely choosing how many of each strategy to employ.

The result will be a library of ways to create 3d chunks of "world" to tile an infinite minecraft world, and be rich enough to make them interesting to explore.

This will involve making ( and discovering that we need to make ) lots of tools to edit the various elements that make our "world".

Things that will need to be modeled and have configurable generators :

• Biomes
• Material veins (like ore veins but can be used with any material)
• Rivers, Lakes, Ponds, bodies of liquid material (low priority)
• Plants (these should be built from voxels)
• Caves and other below surface features
• Atmosphere (this is made of voxels as well)
• Clouds
• Vehicles
• Organisms

Assume that this structure is the single "world grid" that you see in DF or minecraft. All voxels in this world model are the same size, but non-terrain things can be made of variable voxel models - #21

[DigitalLibrarian]

Fanastic resource describing how perlin noise can decomposed into a set of "feature" specific functions. This is likely to be our goal for mixable/composable generator strategies.

http://freespace.virgin.net/hugo.elias/models/m_perlin.htm

[DigitalLibrarian]

Another algorithm called Simplex Noise is reported to have much of the same compos-ability features that make Perlin attractive, but it is reported as cheaper to calculate. This is worth looking into.

[DigitalLibrarian]

Simplex also reports to be isotropic, that is there are not direction-related artifacts.

[DigitalLibrarian]

Generalization of a lattice-based noise generator: http://www.codeproject.com/Articles/785084/A-generic-lattice-noise-algorithm-an-evolution-of

[DigitalLibrarian]

The basic paradigm that both algorithms use is this :

1. Start with a function that maps integers -> persistent random values

That is to say, there should be no correlation between inputs that are "close" but passing the same input should yield the same output and the output is always in the range (-1, 1)

You can take lots of functions that have this property and add them up (mixing).

1. To find a point between two integer inputs, use an interpolation technique, like lerp()

That's it. Now you have coherent noise that can be resolved down to any arbitrary resolution (within computational limits) and it allows mixing "feature generators".

• Add the ability to scale the interpolation range (maybe it goes between 2-4, instead of 2-3) as a parameter.

[DigitalLibrarian]

Such a system should be isolated enough to be able to be reused in lots of different applications. For instance, we can use this type of coherent noise to bend joints idle characters, given them some random, but sensible, idling animation. We might also use this generate textures that make sense procedurally, rather making them by hand.

[DigitalLibrarian]

Here's a discussion about importing real terrain data from google earth

https://forums.epicgames.com/threads/607176-Tutorial-Importing-Detailed-Terrain-from-Google-Earth

This would be a cool thing to do, if for no other reason to see how the system behaves with a data source other than perlin noise.