Updated: Dec 20, 2022
How i started with infinite terrain .. got it working.. but then back tracked to a fixed size sandpit. Why did i do that?
Polygon Planet is the story of an astronaut who crash lands on a mysterius planet and so naturally I wanted to develop the game terrain as a spherical planet rather than a flat terrain.
Out of the box, Unity's terrain editor is intended for manually creating a flat world terrain, and is great provided you are reasonably artistic and patient. Unity's gravity system also assumes a flat world. I didn't want to devote heaps of time to manually creating a terrain environment in this way since 1) that is primarily an artistic endeavour rather than programming approach and I wouldn't learn very much, and 2) I simply don't have the time to do a good job of it. Furthermore the terrain editing tools are not particularly suited to creating a low-poly terrain of a fixed mesh resolution.
So I turned to Sebastian Lague's fantastic Coding Adventures tutorials on youtube for Terraforming planets procedurally. https://www.youtube.com/watch?v=vTMEdHcKgM4 and also his other series for procedural generation of infinite flat-world landscape using Perlin noise.
This was exactly the kind of approach i had in mind and I got carried away with it and had a go and produced my first results which you can see in these videos:
My first go at procedurally generating a single terrain tile using Perlin noise.
My first go at stitching tiles together to form a landscape.
My first go at an infinite landscape where tiles are procedurally generated in realtime.
This was great fun and i learnt loads from it especially about constructing the mesh vertices and triangle arrays for the tiles and the issues at edges of tiles -- namely that where adjacent tiles are of different LOD then they do not precisely join (since one tile has more vertices than the other) and thus gaps are formed in the landscape which look really bad.
First i tried Sebastian's approach to solve this which was to increase the number of vertices to a fixed maximum at the perimeter edge of every tile. However this was even worse because it caused "ribbons" of high LOD highlighting the seams between tiles which was more noticeable than the original gaps.
I researched some more and found that the opposite approach is the solution - reduce the number of vertices along the perimeter of the detailed tile to match the number of vertices of its neighbour. This worked extremely well and I was all chuffed with myself!
Just because you can doesn't mean you should!
I had gotten so carried away with learning how to procedurally generate the terrain that I'd not properly thought about why i should generate it procedurally in real time!!
The more I thought about it the more I realized that I actually need the game terrain to be a limited sandboxed region in order to reduce the amount of work I have to do!! --An infinite terrain only really works for a game that is going to be like Minecraft where essentially it doesn't matter where in the terrain you are provided that you undertake certain activities and those activities are possible anywhere. That model doesn't fit Polygon Planet where location really matters because the npcs and the players and the scenery are to be highly interactive and esoteric/bespoke.
The other practical matter is performance - why on earth generate the terrain in real time if you don't have to?! ...So having realised this I decided to take what i had learnt and generate the terrain from the Perlin noise using the procedural method but then simply save the resulting tiles as a fixed terrain mesh that Unity can work with in the normal way. I also switched the render mode to Universal Render Pipeline so that I could add my own custom shader to give the terrain the low-poly look and colourise the terrain vertices by elevation.
My final landscape for the planet as a flat-world sandbox.
Sphere of flat-world?
The one remaining thought for me was that I had really wanted to create a planet rather than a flat-world terrain. The reason for this was that then the whole crash-landing arrival thru space and eventual departure could truly be modelled and animated as a single scene rather than faking it with cut scenes and stuff. It would also leave open the door for visiting another planet in the solar system for a sequel to the game!
However, using a sphere really complicates things because there is no simple mathematical projection from cartesian to spherical coordinates. First off you need to create a mesh of evenly distributed vertices or in other words a fairly even grid on the sphere and that is tricky given that most spherical meshes have uneven distribution of vertices with them heavily clustered at the poles and sparse at the equator. Or you go for a hex-ball or some other style of mesh to approximate the sphere. They all have pros and cons. Now consider pathfinding on a sphere compared to a flat-world? A* algorithm for a spherical surface?
No doubt it can be done and is probably very interesting but i decided it was too ambitious for me to undertake at this point given how much else I need to learn.