I've been trying to brainstorm better ways to develop a biome system. I've been pouring through some of the source code from other projects to get some inspiration, and have implemented a registry system similar to the one used in Minecraft. This is to try and make a scalable solution to accessing and storing different data, particularly as JSON files. Right now though, I'm only looking at biomes.

To generate the biome right now, I have a dual layer perlin noise map, simulating temperature and precipitation and determining the biome on a hard coded table set to different biomes, simply represented by a tile. This, however, is not particularly scalable nor easy to adjust, but I think I've got a better way to do it.

By using a registry and biome builder,  I can register associations between biome IDs in code and JSON files containing the necessary metadata to produce versatile biomes. This can include measurements for temperature and precipitation, but also the species of flora and fauna living there, the weather patterns across seasons, the effects it may have on the player, etc.

I'd like to give some versatility to the biomes as well, so no two forest biomes have identical settings, adding an extra level of uniqueness to the players world, but this raises an issue with procedural generation, in that beyond the generation of the seed, nothing is truly random unless it's saved. And to generate and save the biome settings as an entire biome sort of implies generating it as a whole and saving that data. I plan to save the data regardless at some point, but the only way I can think to create a consistent biome generation with pseudo-random variables without clear differentiation between chunks would be to generate new chunks with consideration to neighbouring chunks and tiles. I plan to experiment with this, but I worry it might be a little too computationally taxing for my liking.

---

I've spent a lot of time pouring over other peoples code, picking bits apart and writing it as my own. A lot of the Minecraft registry system has gradually been repurposed but at this point, it's so convoluted that it's really not worth imitating. So I'm starting from the ground up, using some of what I've learned, to try and build a streamlined and scalable solution to expand biome generation and combine registry with a sort of save system. Right now the pipeline looks like this:

This is a very basic overview, and I'd like to make it a little more dynamic than this, since this would mean that the only biomes that can spawn are hard coded JSONs, whereas I'd like to produce more naturalistic and spontaneous solutions to this, but I'll have to give that some more thought.

---

I'm also planning to have a fully coded texture system, rather than manually assigning textures to scriptable objects like I currently am. Although this is pretty standard practice in Unity, eventually I'd like to move away from Unity to a custom engine (as ambitious as that may be), and I'd like to have as little dependency as possible.

Surprisingly though, one of the harder parts of this has been figuring out a legible file structure! I've always worked on smaller projects where you can kind of get away with having just a scripts folder and maybe a player folder within it if you're feeling nasty. But alas, this is proving to be an ever growing project and, for the sake of growth, figuring out a file system and naming convention can only save me time in the long run.

---

As always the code is available on github, but otherwise that's all for now. Until next time, take care.