There’s a bad pun in the title.
Do I win?
So, the last couple of weeks I’ve been working on some stuff. Mostly, I’ve been re-implementing some of the features into the game, like the pebbles, the flowers and some other stuff. But that’s not why I’m here today.
After a LOT of struggling, I finally managed to implement proper biomes and biome generation into the game. To make this work, a really nice friend of mine called TTFTCUTS, who wrote a really cool terrain generation mod for Minecraft, helped me a lot. Let me give you a quick rundown of biomes, how they work and how they’re implemented.
In the image above, you can see a desert to the left, a grasslands biome to the right, and a bit of an underground biome below (the stone bits sticking up). Basically, in the game, every biome has a certain weight to it that determines how frequent it is. For example, the grassland biome has a weight of 1000, while the desert only has a weight of 300, making it a lot rarer.
Additionally, every biome has a minimum and maximum y coordinate that it can generate at. So for example, the sky biome (which just generates emptyness) has a minimum height of about 50, while the underground biome’s maximum height is about -20.
Biomes are implemented in a way that I can honestly not quite explain fully (because it was a lot of trial and error and CUTS showing me his code), but basically: Every biome tries to generate in a sort of blob formation, and every blob has a “center point”. From that center point the biome is determined, which means that biomes can “leak” above and below their min and max y coordinates, but still stay in their general area. The actual biome to generate at a position (out of the list of possible biomes for that position) is then determined based on its weight. Here’s a little peek at the (inaccessible, closed source!) code of the biome generation.
During creation of biomes, I’ve had a lot of problems. This is honestly one of the most funny things about stuff like this: How much can actually go wrong. Here’s a little gallery of screenshots showing what all didn’t really work out.
Now for some more nerdy stuff: Culling. Culling is basically a way to make stuff that isn’t actually visible on screen not render, which saves a lot of resources meaning the game will run much better. This is usually a common thing in 3d games, but in Rock Bottom, tiles are culled when they’re off screen making them not render. That’s pretty simple.
For the longest time, I’ve rendered every visible chunk by running two for loops, one for each coordinate. That would make everything in the inner loop run 32*32 times. Which is a lot. Inside that loop, I’d then determine if the position is actually on screen, and only render the tile there if it was. But still, I’d be running through the loop 32*32 times every time which was a huge waste of resources.
Now, instead of doing that, I only run the loop over tile positions that I know beforehand will be on screen.
That code probably doesn’t mean that much out of context, but it’s the new culling algorythm for every chunk that’s visible (which is also determined beforehand in a different algorythm). As you can see, the for loop now only runs over a certain part of the chunk instead of the whole one.
The actual reason I’ve been telling you all this stuff about culling, though, is that I wanted to show a really cool gif that shows what happens if I exaggerate the culling (by making the limit of which tiles should be rendered one tile smaller). This is what it looks like then:
So there you go. That’s a bit of the stuff I’ve been doing the last couple of days.
As always, I hope you enjoyed this blog post. If there’s anything you wanna say, don’t hesitate to use the comment section down below or join the Discord linked on the front page!
Thanks for reading! <3