Terrain Generation Data Structure

[olls]

As an alternative to looping over neighbouring slices while generating terrain to find features such as hill peaks or biomes:

As we only generate the slices in chunks anyway, we move that assumption into the gen_slices function, then we generate the features per chunk first and store them in a separate map. This way we can loop over the features within our reach, instead of the slices.

[olls]

This would also be helping to make the features more generic, helping with #12

[olls]

I have increased the usage of chunks, so they are used for generation. The next step is to actually generate the terrain by chunk, this way we should be able to collapse both the chunk slice loop, and all the feature slice loops into fewer (hopefully one) loops. This should improve generation times, and make it easier to generalise the generation.

[olls]

Planned operation for 'feature caching':

Store ~4* chunks worth of features in a cache-like structure. When generating new terrain, first get features for chunks in our range, if chunks are not in cache, generate the features, and put them in the cache (replacing the oldest chunk(s)).

* Might need to be related to player count? Or number of 'discovery bounds'?

[olls]

The multiplayer branch has noticeable pauses every time it generates a new chunk, whereas the master branch is very constant, this is probably because in the multiplayer branch, slices are generated chunk at a time, but master does it slice at a time. This is so the multiplayer can send whole chunks at a time to save bandwidth, but in order to make the game smooth in singleplayer, we need to make the terrain generation very fast. Or we could generate the terrain slice at a time in singleplayer, but chunk at a time in multiplayer, which could be messy...

[olls]

Other than fixing some bugs, the only thing left to do with this is to modularise it a bit.