In the original version of When Pigs Fly, actually building a working airplane was pretty difficult. As a result, the map could be pretty small without worrying about running out of room to fly. As I improved the flight model, added better parts, and people generally got better at the game, the map quickly became too small. People were building planes fast enough to cross the map in under a minute. Eventually I replaced the map with a much larger one. This alleviated the problem a bit (it now takes 10 minutes or so to fly across the map in an average speed plane), but it didn't completely solve it.
Ever since that first map, I've been trying to decide what my solution is going to be. I've thought about making the world wrap around, so when you fly off one end of the map, you warp to the other side. I've thought about replacing the 'flat' map with a globe, so that you can actually fly around the world. Today, though, I wanted to experiment with endless terrains.
How it works
The terrain in When Pigs Fly has always been generated at runtime (using my WIP low poly terrain generator). But since I always use the same seed, the terrain is always the same and is static once generated. My terrain generator works by building a flat grid of triangles, then setting the height and color of each vertex based on a height map (procedurally generated or otherwise).
This morning, I replaced the height map with a very simple perlin noise implementation. I also added some code to the terrain system that monitors the position of the player. When the player moves past a certain distance, the terrain is recalculated with a new offset to remain under the player. Here is an exaggerated example.
Why this isn't a good solution
Terrains in when pigs fly are low-poly and vertex colored. The nature of this system means that when the terrain is recalculated, if the x and z values of a vertex aren't exactly the same, its height and color will change. I did a few things to fix this problem, but it still isn't perfect. I could do more to make sure the terrain respawns on an exact grid, but that still wouldn't fix the next problem.
The entire terrain mesh is regenerated every time, meaning that I am wasting resources rebuilding parts of a mesh that already exist. In my small scale tests this wasn't a huge problem, but I imagine it would become an issue in game.
What I'll probably end up doing
I think it would be better to generate new "chunks" of terrain as the player nears the edge of the map, and delete them as they get far away. This way there would be no time wasted generating things that already exist. It would also solve the issue with exactly matching vertices. It should be pretty easy to implement this system, as the current terrain is already split into chunks to stay under Unity's maximum mesh size. I think draw distance is really important in flying games, so I also want to experiment with an LOD system so that the terrain truly stretches to the horizon.