Design GSoC Project: Biome-based world generator and Earth-like world

Vizaxo

New Member
Contributor
TLDR: For GSoC, I propose to implement a world generator which moves most of the generation from the global world generator to the individual biomes (I've done a prototype of it here). Then I'll use this to implement a number of biomes, to provide an Earth-like world generator with distinct regions of terrain.

Hey everyone,

I've been working away at my GSoC proposal: I'm planning a project based on Noise-based generation of distinguishable terrain features (#943). So far I've figured out a rough plan for the project, and have implemented a prototype world generator which shows some of the concepts I am thinking about. I would like to get some feedback on the idea, both from the perspective of a GSoC project (e.g. whether the scope is right), and from the perspective of it as a game feature.

The prototype is on my GitHub; it is explained below, and I tried to document most of the code to show what it is doing.

The project would have two main components: first implementing an updated world generation system, and then using that to build a world generator. The world generator would provide many different biomes to give a world that feels like it could exist in real life (though on a smaller scale, and slightly more blocky).


Updated world generator
The updated world generator is based on the principle that the biomes should control what is generated in them, rather than them being set based on the existing world that has been generated. It would still use a global generator to calculate a general heightmap, which will determine the approximate location of oceans, mountains, and the stuff in between, but then the biomes take over and can modify the world however they like.

This means that, for example, plains and deserts can be made to be roughly flat, hills can be a bit more bumpy, and mountains can be as big as they like.

For anyone who is interested in the class-level architecture, here is the basic plan (though it is still very flexible at this stage):
- The WorldGenerator acts as normal, with FacetProviders and Rasterizers applied
- The global heightmap is calculated with a SurfaceHeightFacet as usual
- A BiomeFacet is added, which calculates the most appropriate Biome for each column
- Each Biome then calculates an updated height for each column, and updates the global heightmap with this information
- At the rasterisation stage, the Biome rasterises the world one column at a time (rather than one chunk at a time, so that biomes can have smooth borders, rather than being aligned to chunk borders)*
- The rasteriser also tells the chunk which biome each block is in, so the rest of the game can use this information

*Alternatively, the system could just generate dummy chunks where only the blocks within the biome are affected, which are then copied into the main chunks. This would allow the Biome to always rasterise as if it was doing a whole chunk at a time, so the rasterisation process would be very similar to the current process.

This is quite a flexible system, as it still uses the current facet/rasterizer system, so should be compatible with other modules that add world generation. It also can be extended, such as to add another layer of biomes by adding another BiomeFacetProvider, which controls the underground biomes. These underground biomes control all of the generation under the surface, such as generating different rock types and affecting generation of ore, caves, and other underground features. This would allow surface biomes to only focus on the surface, and then underground biomes can be added completely independently (or in a way which is linked to the surface biomes, such as certain rock types being more common under mountains).

This whole system still follows the modular philosophy of the game, allowing any part to be changed or added to. One such extension could be an implementation of Advanced and dynamic geology based on plate tectonics (#141). This could be implemented by using the tectonic plate-based heightmap as the base heightmap, adding surface biomes as usual, and then adding multiple layers of underground biomes to control underground generation.

One of the main issues to be solved is making the biomes interact smoothly at the boundries. There are several ways this could be done, such as having a step after the biome heightmap calculations that interpolates at the edges of biomes, or allowing the biomes themselves to know where the edges are, and make sure they are smooth at those points. There are advantages and disadvantages to each method, so more research and testing would need to be done before a decicion is made.

Another thing to work out is how the biome locations will be determined. This will probably involve generating a few more layers of data such as temperature, humidity, rainfall, etc., which can also be affected by the heightmap (such as high-rainfall areas near oceans). From there, the BiomeFacet can work out the most suitable biome for each column, and the continuous nature of the data should mostly keep the biomes in large clusters (though some other checks, such as making sure each biome area is a suitable minimum size, can be done).

My prototype implements most of the basics, and I quickly made 2 biomes to show it in action (mountains and plains). They are currently only generated on either side of the x=0 line to show the side-by-side generation provided by the biomes, but it shows how the BiomeFacet controls placement of biomes, and that most of the world generation is handled by the biomes themselves. The attached screenshot shows the mountains on the right, and the plains on the left.


Earth-like world
The second part of this project would be to use the generator detailed above to implement biomes that represent some of the most iconic terrains on Earth. The basic biomes I would implement would be grasslands/plains, ocean, desert, mountain, and hills. As all of the world generation code is stored in the biome classes, inheritance can be utilised to great extent. The heightmap generators can be reduced down to oceanic, flat, and mountainous (with adjustable parameters, for example to control the height variation), with each of the biomes extending the appropriate heightmap generator and rasterising the chunk as appropriate (some of them could even share a parent for this too, as grasslands and hills would look similar, just with a different heightmap generator).

Forests and bodies of water (rivers/lakes) can be implemented as biomes that inherit from an appropriate parent (such as allowing for different types of forest/lake on plains to the types found in the mountains), or just an extra decorator on top of the biome system. Forests would mainly require adding trees and vegetation to the existing landscape. Lakes and rivers are more tricky because they modify the landscape, and have stricter requirements on where they can occur (such as a lake needing a big flat area), so they would require more research, planning, and testing.

Another interesting challenge would be to generate some terrain with overlaps and overhangs, which are not created by the standard heightmap-based approaches. Fortunately, this system makes it easy to use a standard heightmap-based approach for most of the terrain, and add only modify biomes that need it, such as mountains.


Thanks for reading; please leave any feedback below! At this stage I'm still open to big changes, but I think this is a fairly solid foundation for the project.

Terasology-170323221015-1920x1080.jpg
 
Last edited:

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Nice work! Very cool to see a functional prototype like that :)

It sounds a bit like you've hit an interesting mix of the Distinct World Gen item and part of the Sector / World Gen Phases item (do check out its thread if you haven't already - but then I bet I probably already shared that on IRC?)

For your biome concept we actually have space in the block data to track biome not only per block column but per block period - so you could work entirely different biomes up in a sky island layer and down below in a cave layer. Hmm. We've already talked about all this on IRC, haven't we :D Back when Vel0city appeared too with more world gen stuff, like the Realistic Terrain Generation MC mod thing.

Did I link you to the ancient http://forum.terasology.org/threads/store-biome-per-block.1082 thread yet?

Readding overhangs would be hugely appreciated. I miss them dearly from the legacy Perlin days!

Also: moving this thread to the Suggestions forum since it feels like it would fit a little better there.
 

Vizaxo

New Member
Contributor
Nice work! Very cool to see a functional prototype like that :)

It sounds a bit like you've hit an interesting mix of the Distinct World Gen item and part of the Sector / World Gen Phases item (do check out its thread if you haven't already - but then I bet I probably already shared that on IRC?)
Thanks for the feedback :) I did read the sectors thread yesterday, but it seemed to focus more on the game simulation, rather than the world generation, so I thought it would be a bit too much to implement both this world generation and sectors in one project. However, on re-reading it with a clear mind, I can see a lot of great possibilities for it. I think tying biomes to the sector, rather than to the blocks, would be a definite possibility. All of the blocks would have access to the biome data, but without each one needing to store it, which also means you can stuff a lot more data into the biomes without worrying about performance too much. I think that makes a lot more sense conceptually too, as 99% of blocks will have the same biome as their neighbours/others in the chunk. It could also mean that biomes can be more fluid and less well-defined (like in the real world), and make interpolation between them, for both generation and colouring/spawning, etc. much easier (as the data for nearby biomes is easy to access, rather than having to address nearby individual blocks/chunks).

Though I think biomes is possibly not the best name for this, or at least it could be split up into a few different distinct but connected features. The actual definition of biome is related to the plants/animals that form in it, which is determined by climate, terrain, etc. I think sectors would certainly allow this, by separating the simulation/generation of terrain and climate, then using that data to determine biomes. The terrain and climate could be related, possibly in some sort of feedback loop (i.e. a heightmap determines general terrain -> that terrain helps determine the climate (changing based on mounains, oecans, etc.) -> climate information further shapes the terrain (erosion, humidity) -> etc.). From that, biomes could be set, which determine the flora/fauna in an area, represented in-game by different spawning of entities, generation of plants/trees, and changing the colour/other properties of blocks, such as the land being sand vs. grass vs. dirt vs. clay (which could in-turn be done by just having a "land" block, that gets its properties from the biome, and is rasterized into sand/dirt/clay etc. when it is broken, with the possibility of re-integrating back into the environment when placed back).

I also like the fact that the sectors don't need the chunks to be loaded, so things like climate simulations can continue when the player is away. At the sector level, you could even dynamically allocate the load on the servers, such as by pre-calculating data for lots of sectors during periods when the player-count is low, so that the server doesn't have to worry about calculating it at peak times, and can just use the pre-calculated data (unless, of course, a player sets off a nuke that irradiates miles of climate. But maybe they should be punished with a bit of lag in that case :p).

This would also keep a lot of the data around after generation-time, allowing for seasonal weather, the player affecting the climate (blowing up mountains, setting off nukes, using magic for terraforming, etc.), and biomes adjusting based on these changes (i.e. nuking an area would have a huge impact on the wildlife, but some species could still thrive). It could also add effects to the player, such as heat exhaustion or radiation sickness of various degrees, when they are exposed to certain environments.

The sector could even store information and do calculations for things like the tectonic plates (presumably just at generation-time, but allowing earthquakes and volcanoes to result during the game would be really cool), which can then influence the initial terrain generation, and all of the climate/biome data can be calculated on top of that.

I think the possibilities for rivers and lakes will also be fantastic with sectors, as you can tie it to terrain generation (both ways, allowing for rivers to cause erosion, glacier-carved valleys to be simulated, etc.), and to the climate system. You could have a realistic water cycle influenced by player actions, or let the players change the course of rivers, or make dams to generate electricity and help irrigate areas to make them suitable for farming (I just watched a great Vlogbrothers video on the topic, yesterday).


I hadn't seen it before, but I've just read it through. Sectors seem to provide all of the advantages mentioned in that thread, but without the performance concerns of having to store all of that data, and interpolation would be much easier with biomes stored on a sector level, rather than per-block.


For your biome concept we actually have space in the block data to track biome not only per block column but per block period - so you could work entirely different biomes up in a sky island layer and down below in a cave layer. Hmm. We've already talked about all this on IRC, haven't we :D Back when Vel0city appeared too with more world gen stuff, like the Realistic Terrain Generation MC mod thing.

[...]

Readding overhangs would be hugely appreciated. I miss them dearly from the legacy Perlin days!
Yeah, we talked about it, and I think I might have mentioned my ideas for layered biomes (sky layers for floating islands, surfaces, underground rock seams/layers, etc.), which would then be passed to the blocks at rasterization time. I think sectors would be a much more elegant solution, and would mean that you aren't restricted to a global set of discrete layers. You could even do crazy stuff like making floating islands that slowly move across the sky (because you keep all of their information in the sector), or shifting rock layers according to earthquakes/tectonic plate movement. Not having to rely on heightmap layers also opens up great possibilities for different types of terrain that isn't simulated well by heightmaps, such as overhangs :D


This project would involve adding sectors to the engine, but a lot of it can be modularized, and just attached to the sectors in the same way that the facets and rasterizers are connected to the world generator at the moment (but some of it could be tied into the engine, if features such as the climate or generation wanted to be, but I imagine most of it would be better off in a framework-style module that other modules can expand on).

I know you said you liked walls of text, but I'm sorry for everyone who doesn't, or if this one was a bit too rambly :p This is pretty much me just thinking out loud to my keyboard, and getting very excited at the possibilities while doing so. I don't think I'd have time to actually make the Earth-like generator during the summer if I implement sectors, but I'd love to focus on the underlying architecture, and expand the possibilities for modules to come in and extend it. I think it's time for a lot more thinking, and a reorganization of my project :)
 

Skaldarnar

Development Lead
Contributor
Art
World
SpecOps
Wall of text are just a lot to read :p Lots of good stuff in here, I'm now looking forward to reading your actual proposal. The world prototype looks already promising, and it is good to see you already got your hands on the code base!

I think you are right in saying that, in order to generate a unique world with distinguishable features, we need better support for biomes or the like. Drawing the connection between biomes and sectors seems natural as it can simplify the handling of biomes, landmarks, and terrain features. Having sectors properly implement would then enable more advanced simulation in the game world - a neat side effect :)

I'm afraid that rivers (and erosion, ...) would still require chunks to be generated in some way. Otherwise, rasterizing the high-level sector concept later on may result in rivers "popping up" out of nowhere or messing up with already generated parts of the world. We had a pretty detailed discussion about this topic with the guy from VoxelFarm and a bunch of people interested in procedural generation, pretty complex topic.
 
Top