Work had started on the land generation engine some time ago using procedural generation (or procgen) to create the world of Omega Connection dynamically based on the player’s game play style. The initial work I started was based strictly around customizing each unlocked grid using the players statistics while creating an area of land that fit within the boundaries of the OC world itself. At the time I had no intention of delving further into the Generation Engine than to ensure the land created matched the player type that unlocked the region. That was the intention at least.
I had stopped working on the procgen land engine with the system outputting two BMP files to show me a basic idea of what it was creating. The first is a color coded map of the area types for a single 1000m X 1000m grid and a height map for that same grid. After a few sleepless nights this program was producing what I considered a success.
Below are four images depicting a few possible outputs for the Generation Engine. The color images are all terrain maps (brown = rock, yellow = sand, dark green = forest, green = grass, light green = scrub, light blue = marsh, blue = swamp) that are used to determine the basic land area, i.e. vast yellow areas might be desert while small yellow areas are just sandy spots. The black and white image is a height map (Omega Connection does not use height maps or clipmaps for displaying terrain, this image was for testing purposes only; more on that in a moment).
Aside from pure Chaos areas always looking like a random mess, each map generated has been completely unique. I actually forced it to run 1000 times in a row just to ensure the outputs all made sense and were all unique in their creation. I was not disappointed.
The next piece for the Generation Engine was to be water paths followed by towns and roadways, but in order to accomplish that the terrain needed a little more geometry than the simple height map that was being generated. Additionally, while the height maps might be useful for creating terrains at render time and to give a basic idea of elevations, they are not very visual for understanding what is really being created. I wanted to see these lands in 3D, crude form or not, and I wanted to be able to share a video fly through of these lands with everyone out there.
This is the point where things started to go sideways. Like many programmers out there I have vast stores of reusable code and classes which I had written once upon a time, most ready for immediate use. As almost all programmers know, it is always a bad idea to look through old code. Unfortunately, ALL programmers are like characters in 80s horror films, that is to say we WILL open the closet door…
After several weeks of redesigning almost all of my OpenGL classes and many of the shader programs, I finally returned to the Generation Engine. And then the worst thing that can happen to an indiedev happened to me (aside from opening the closet door): I had a conversation with myself. It went something like this…
Self: Hey Andrew, you know if we write quick OpenGL Tessellation shader and Geometry shader programs we can cut the number of vertices sent to the GPU dramatically and we can get the performance of clipmaps without giving up true 3D geometry.
Me: <crunch numbers on the calculator> Wow, you’re right! It would cut the data transfer down to almost 1/10th of what was planned and we were already going to use Tessellation to upscale the land vertices anyway. Great idea!
Self: Now all you have to do is rewrite the Generation Engine to output data in a format compatible with GL_PATCHES instead of triangles or triangle strips.
Me: I Hate You!
If you are an OpenGL programmer that conversation might make sense. For the rest of the world, it means I came up with a way to display far more detailed lands in Omega Connection without sacrificing game play speed. At the cost of my own sanity. All this because I wanted to make a video fly through for a land that was only meant as a quick test of dynamic player style. Funny how game development works.