Planet Terrain Resources and Discussion

[Narotiza]

I created this thread mostly so I could have a place to put a bunch of resources and loose concepts relevant to generating and manipulating a planet whose surface features are dynamic and define the patch map.

First of all, a few relevant threads:

• Planet Generation
  A thread mostly focused on computing realistic variables, such as habitable zones, light spectrums, atmospheric conditions, etc…
• Planetary Map Data Model
  This thread seems a lot closer to what I’m talking about here, and I considered posting there but @NickTheNick said I should make my own thread first; and we can always merge this thread later if we decide it’s better suited there.
  This thread has a lot of pretty technical discussion about how terrain data would be stored and manipulated, including a few ideas about how plate tectonics would work. I imagine the ideas here will be super useful so it’s worth a look through.
• Patch Map Design Discussion
  Most of the most recent concepts here were posted by me, in case you want to know my thoughts on the patch map (which began to include a global planet map)

Next here’s a bunnh of resources I found online about how other devs (mostly one dev actually) have approached the problem of building and dividing planet maps using points.

Resources

Red Blob Games:

• Polygonal Map Generation For Games
  A 2D map generator using voronoi, including rivers, biomes, and some fancy effects like coast distortion.
  
  
  
  • Polygon Map Generation demo
    (2010) A Flash demo of the map discussed in the above blog
    
  • Polygon map generator
    (2017) An HTML5 demo of a similar, but modified map generator(?)
    
    
• Alternatives to Voronoi diagrams
  An interesting alternative to voronoi which uses delaunay centroids instead of circumcenters, which looks a little bit prettier and organic, at the expense of relative size uniformity.
  
• Delaunay+Voronoi on a sphere
  A method of tiling a sphere with voronoi/a centroid-based voronoi alternative. Has a demo where you can customize a bunch of parameters and see the results.
  
  
  • Procedural map generation on a sphere
    A continuation, using the same system as before. Divides the planet into tectonic plates with random movement, then determines the terrain by the interactions between plate boundaries. Doesn’t discuss anything about actual plate movement though. Also has a demo!
    
    
• Mapgen4
  A map creator allowing you to paint in different features
  
  
  • Blogs on mapgen4

Other

• SotE: Tectonics
  A fairly non-technical overview of Songs of the Eons’ plate tectonics system. Has a lot of different examples of features created by different interactions between plates though.
  
  
• Worlds and their geography — particracy
  A voronoi sphere map for a geopolitical strategy game. terrain generated with a random heightmap
  
  
• Experilous: Procedural Planet Generation
  Generating a planet map with a subdivided icosahedron, divided into plates with random motion and rotation, terrain based off of plate boundaries
  
  
• Tectonic Explorer
  A really helpful little tool that lets you divide a planet into plates (up to 5, and you can only use presets for these divisions sadly), draw in some continents, determine each plate’s force vector, and then watch the process of plate tectonics in real time. Uses a hexagonal grid, but each plate is its own grid that moves independently of the others, creating and destroying cells when needed.
  I only found this partway through writing this post, but perhaps a system like this could also be used for tectonics? Figuring out adjacencies between plates could be tough though.
  
  

Now onto my ideas, which… currently aren’t much, but they’re a starting point I guess.

I used the Delaunay+Voronoi on a sphere demo with relatively high jitter, and then filled in a bunch of cells with biomes. Note that this can lead to some weird stuff happening, such as the very long and oddly-shaped coast to the right.

I’ve thought about this sort of thing before, and one of my worries was that concave or unusually-shaped patches (such as rivers or mountain chains) wouldn’t be able to exist, and any variation in the spacing of these points (such as greater distance between patches in the ocean) could lead to the whole thing looking weird, like this.

However, the points on the planet don’t necessarily have to be patches, but instead just terrain data; then, same or similar points could be grouped into patches. For instance, the C-shaped group of mountainous points would become a single, C-shaped mountain range patch, and wide areas of points in the ocean with little to no variation would, again, become individual patches.

So, generating a planet could be done by making a bunch of points all around the planet, spaced fairly evenly apart, then dividing the planet up into plates and using those to help generate the terrain, determining what the conditions of each point are like. Things like rivers and, depending on the scale, mountain ranges, could be represented as lines going along the edges of the voronoi cells. Smaller features such as vents, tidepools and lakes could be represented by sub-points, parented to the point of the cell they’re in?

Note that these points aren’t guaranteed to always be in their parent cell, especially if the origin point is getting closer to another origin, changing the boundaries of the cell.

Plate tectonics is probably going to be the hardest part, however using groups points to represent patches (and bigger groups of points to represent tectonic plates) means that the actual terrain of the world can be moved around without having to worry about keeping track of where patches go and such.
Compare this to using a planet with a static grid that changes the patches or “colors” in its cells over time, where you’d have to keep track of where everything is moving to. Movement would be sudden and stuttery as plates move through the cells, and there’s potentially the worry of patches going weird directions or merging into the same cell.

I’m not sure if I can really add much useful information to this part I’m afraid, since I’m not sure I can really wrap my head around how all the tectonic plates move at once on a planet, but I can try to give some vague ideas I guess.

Plates subducting would cause parts of one plate to eventually be destroyed, which could be represented by the points/cells getting destroyed as they’re subducted, or perhaps merged with nearby, unsubducted terrain as they get too small.

Terrain changing would simply be the roughness/height of different cells changing, still retaining any life present on it. (though said life may have trouble surviving or want to relocate)

---

Finally I also wanna think about how this information will be shown to the player.

Here’s an image from the patch map design discussion, which is a bit outdated (notice the hexagonal+pentagonal tiling, and the unexplained perfect terrain underneath) but in general I still do think it might not be wise to continue pursuing a node-based patch map based on large, underlying planet terrain like this, and instead try simply using a globe heavily obscured by a fog of war, with many aesthetic details hidden if possible, too.
Patches could be selected by hovering over and clicking it on the globe. For oceanic patches which are stacked on top of each other, a vertical beam could be cast from the mouse straight down to the center of the planet, creating a 1D cross section of all the water (and floor) patches.

(note: i haven’t really thought about water patches with the voronoi planet. Would there just be water cells above subaquatic terrain cells, identical in shape, then adjacent ones of the same height could get combined into patches? figuring out where certain water depths start could be tricky too. Maybe check the lowest depth of a cell? (since they can have roughness) and if a water depth starts above that point then that cell has a water area of that depth.)

Here would be a cross section, each “rectangle”/column representing a differently-shaped cell on the voronoi map. The columns of water above each of these cells shows which water depths each one has (note which ones are and aren’t grayed out)

---

It’s really late and that’s all I’ve got for now I think, so please feel free to post your own thoughts on this! I know a lot of my ideas are really too distant for any meaningful implementation in the short term, so apologies if I should have been using my time more reliably.

[Buckly]

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.