So I have been thinking about this post for a while today and came up with some ideas, and now that I have finally had time to go back and read it thoroughly, I have found that many of the ideas I had come up with were already thought up by you. It’s safe to say that I agree with your ideas here as a result, but I still would like to provide my own perspective on them in hopes that it helps.
Patch Features and Data:
A big idea I had was the conversion of biomes like vents, tidepools, mountains, and rivers into a patch feature or “terrain data” as you put it instead of a patch itself. However, it seems you actually covered that yourself with the idea of “Child Points” Which seem to be indicators for this additional terrain feature.
My own take on this idea was that these features would be visually listed in the patch details for the player to identify, (Like a “Terrain Features” category among the atmospheric gasses and such.) while mechanically would act as a sort of generated terrain modifier similar to how a game like Minecraft handles smaller features such as ravines and lakes independently from biomes.
For example; A normal patch would generate it’s biome with no alterations. While a patch with a “cave” modifier would generate as normal, but then generate caves on top of that within the patch. As you can see it’s pretty much just like your own idea and I feel like it would work either way.
Plate Tectonics:
I am not very knowledgeable on this subject in reality, all I really know is that the earth’s crust is broken up into plates that like to flow around. Naturally when I thought about this, I was like “Aha! We just draw some shapes that will represent the plates and shift them around the planet!” and that’s about it.
To put it another way; My idea was that after the world is generated, the generator would then cut large regions of patches into sections that would be defined as plates. From there, these would be able to randomly move around as time went on. They wouldn’t do anything weird like overlapping or shrinking, as collision would just result in what would look like a merge to the player, but in truth would just be the plates touching each other until they move again.
I actually feel like Narotiza’s idea on this may be more functional and better thought out.
Patch Depth:
So this is one of the more complicated issues; How will we handle patches related to depth (Abyssopelagic, bathypelagic, etc)? In my personal opinion I think we should change how we handle them entirely in the macroscopic stage. Instead of trying to show the player all the depth zones within the sea, we could simply visually identify the max depth of a patch by the color. So shallow seas would be light blue, and deeper seas would be dark. This is because they would contain the same depth zones in the same order but just more or less of them. The conditions of each depth zone could be displayed much like the modifiers I described above. This basically turns depth related zones into a patch feature, rather than patches themselves, collectively turning all submerged patches into just fluid patches with individual values.
Edit: Rethinking this; I am unsure how we would handle population and adaptation, and navigation relating to these features. I suppose the mini-nodes style Narotiza suggested??
Movement between patches:
I feel like this is actually something we should bring up, as it’s an important question we should answer. (Have we answered this already? I don’t recall.)
Should players be able to move between patches within the gameplay, through the editor map overview, or both?
In my personal opinion, being able to do both would allow players to freely explore the world in a much more cohesive way, while at the same time enabling a sort of limited “fast travel” between editor sessions that could let the player navigate to new adjacent patches or to previous ones that contain the player’s population.
That’s all I have. Narotiza has put some excellent thought into this, and I suppose I pretty much agree with their ideas here. There is unfortunately little else I can provide without some insight on the technical requirements of these features.