Hey there! As mentioned last time, we’ve continued working on the terrain generation and rendering. This took quite a hard setback when we realized a visual limitation and had to implement some radical changes.
We’re not talking about the new Mario Maker here, but instead of our own terrain! Our team discussed the visualization of terrain, cells, and microbes and we realized that microbes need to “crawl”/”slide” on the floor of the terrain to make sense to the player in the environment.
Here comes the problem:
For now, we only had vertical walls. So, how exactly do microbes get up there? If we make them crawl up, they would be able to climb all mountains, rendering them useless. If we block them, they can’t change elevation at all.
So we now have slopes in the terrain. To be exact, whenever there is only a height difference of one tile, we automatically make it a slope! These can then be used by microbes to go up and down. Height differences of 2 or higher are vertical walls and block microbes.
Turns out, Slopes make everything a lot more complicated…
The most complicated part of rendering the terrain is the baking of the mesh. What does this exactly mean?
A mesh is (simply speaking) a collection of points in the world (called vertices) and triangles connecting them. Each triangle is then rendered by the graphics card and many, many of them make up what you see of the world.
In addition to that, a mesh can also have UVs (which define how textures are displayed), normals (which control the light reflection), and more. Finally, you apply materials, which define how the mesh should look like. Textures, light interaction, color, and so on.
Generating all of this data in as little time as possible is quite hard. Simply generating all information for all thousands of voxels is gonna end badly. Instead, we only create the data that actually could be visible. Sides that are covered up by another voxel don’t need to be shown. Additionally, we slice the terrain up in chunks and each chunk into columns. This way we can calculate multiple voxels at the same time.
Every time we change the terrain, for example with a terraformer, we need to recalculate the mesh. Due to chunking, we only need to recalculate the chunk containing the change. This reduces the time taken for continuous changes to the terrain during the game.
To get interesting random terrains, better than the quick’n’dirty and one we already have, we started to rework it, properly!
This time, we looked at how games such as Minecraft do their terrain generation, which seems to work pretty well. (Of course, our maps are not going to be anywhere near that in the first versions.
Similar to them, we are now using Biomes, which we’re going to distribute on the map with the help of two values, Humidity and Height Variation, which make sense for
We’re using two overlapped Perlin Noises to represent both the Humidity and the Height Variation value. At the same time, each Biome has an ideal Humidity and Height Variation value set, and we’re using the Biome with the smallest difference at said position. Furthermore, every Biome can overwrite some values, to make both flat and mountainous terrain possible.
In the next step, we’re blending the borders between Biomes to make fluent transitions possible, as you can see in the screenshot above.
After that, we’re going to decorate it, however, we’re still unsure what we want to have for our game, so we’re going to keep it simple for now. As our map doesn’t represent nature or another planet, we have to come up with some alternative Biomes that fit our setting.
Currently, there’s a problem regarding the distribution of the biomes along those axes, thanks to the nature of Perlin noise (similar to a normal distribution). This problem, however, should be solvable with a little bit more research!
So, we’ll be finishing up the terrain generation and rendering hopefully next week and then move on to creating assets and making the game playable once again.
See ya next week with more updates!