Making of the Dream Game _ Orbital Dogfight

As an indie developer we are often faced with the question "is this a realistic plan to make a game or am I just wasting time?" I don't have the answer to this question (yet) so I am going forward with the only thing there is, blind ambition.

I love Kerbal Space Program. Sheeeit it taught me orbital mechanics (for turds) and convinced me that in the zombie apocalypses I can pilot a space vehicle to safety. I also love War Thunder, because I am a flight enthusiast and have a setup to fly in VR with Thustmaster HOTAS, not bragging, just saying I LOVE IT! So I was thinking... would it not be fun to have a VR dogfight game that took place in space and atmosphere? Not the only one either. "Wait wait wait," you might say "haven't you played..." YES I have.. and the best* so far in this genre is Elite Dangerous in VR with HOTAS (WOW.. barf so sick) BUT .... and this is a small butt. There are no orbital mechanics! There is some awesome space time sheet happening but nothing like Kerbal Space Program. Meh meh fun but I am thinking of something different. I want something less grindo more blasto, like War Thunder,  but with space. That is where this journey began. So I started with planets.

Ouch! If that wasn't the biggest kick in the head. I don't know if you have ever tried to tackle making a full scale planet before but it is tough. There are a few methods but the main is procedural generation, I did not go that route. Instead I opted to use the tools that I already knew. I'll tell you why that was a bad and good idea, but first some diagrams of the method I ended up using.

This first pic is just a conceptual drawing for unwrapping a quad sphere to its cube map format. As I understood it this method was the best for mapping out planets. But, instead of doing this procedurally I would manually build the planet using Rhino 5 and Grasshopper. This would allow me to customize its surface and generate LODs (level of detail) at any level of detail . Instead of using noise at various scales I used World Machine combined with Wilbur to generate the height maps that would be used as tiles in the scheme below.

Of course this method required that the seams in the tiles be addressed. I did this in Photoshop by transforming the position and rotation of the tiles so that each outside seam became an inside seam. This allowed me to blend the heights maps across seams, effectively eliminating them. Here is a visual of the transformation space for the cube map... basically makes it inside out.

The images are color coded for reference to see where the UVs are going.

By this time the height maps have been processed through Wilbur and World Machine. The process goes:  Wilbur is used first. I import a rough gray scale image as a primer into Wilbur and run erosion cycles on it till I am happy. The exported image is then fed into World Machine and setup for tiled output. World Machine adds the final landscape touches like coastal erosion and also generates textures for the associated height map output. These can be splat maps.

Here is the planet height map undergoing the transformation below it. It is returning to the standard cube map format after being made seamless.

Here is the Grasshopper script and an iteration of the planet it generates. By the time it was working properly I had also written a custom Rhino script to map UVs onto the generated meshes.

Here is the same planet rendered with no textures except a transparent blue on a separate mesh sphere representing the ocean. I thought " hey I'm getting close."

What I did not account for was the huge memory space these tiles and their associate textures would take up. There was some foreshadowing though. Let me pose a problem to you.

I have a planet with 24 tiles and 24 textures, how long does it take to apply 24 textures to 24 materials to 24 meshes? If you are fast about 30 seconds per...ahh only 12 minutes.. not bad.. but not for a sustained pace. Now lets take a Planet with 5 LODs. On the highest level LOD we would need to set 6x4x4x4x4x4 tiles.... 6,144 TILES! umm hmm math ahh 51.2 hours!!!!.... sheeit!! Game ender?

No. So I bit the bullet and starting learning things I did not know and eventually wrote some code. At the time I thought this was some hot stuff if you know what I mean.

using UnityEngine;


public class enMassTexturing : MonoBehaviour {
	
	public string m_filePath;
	
	private MeshRenderer[] m_gameObjects;
	private Object[] m_files;
	
	void Start(){
		m_files = Resources.LoadAll(m_filePath);
		m_gameObjects = GetComponentsInChildren<MeshRenderer>();
		Debug.Log("found: " + m_gameObjects.Length + "children MeshRenderes");
		Debug.Log("found: " + m_files.Length + "texture in folder");
		for(int i = 0; i < m_gameObjects.Length; i++)
		{
			Texture m_texture = (Texture)m_files[i];
			m_gameObjects[i].sharedMaterial.mainTexture = m_texture;
		}
	}
}

The script worked and processed all 6,144 tiles in under 30 minutes. It saved me from what was an ambition ending wall of time and I finally got the planet into Unity. This meant the dev cycle was possible in some way and could commence. This was great!

Jumping that little hurdle gave me more confidence to move forward but the file size limitation still loomed large and I wasn't anywhere near the level of detail desired (true planet like earth needs about 10-15 LODs). I knew these were game critical elements but without immediate answers the only option was to go forward. I decided this was okay and begin the next phase...flight. A few take away(s) first.

It is possible to create your own custom planet not using procedural code. The major drawbacks are file size and organization. I would not recommend this route unless your planets will be smaller or less realistic. However the major benefit to this method is customizability. By incorporating Wilbur and World Machine more realistic erosion patterns resulted compared to the procedural equivalent with tuned noise. Writing my own planetary shader is probably the next step..

FLIGHT

So at first it was easy. Unity 5 came with an Aeroplane prefab you could drop in your scene and fly with a keyboard. Total crap by any flight sim standards but it worked to get me started. The first issue one encounters in altering the code for planetary flight is that the Unity's gravity system considers UP to be the Y axis and this does not work for planetary flight. This may seem obvious but now UP needs to be the opposition direction of gravity's force, which is in a direct line from your mass center to the planet's center. So solving that... then... it starts to get harder. The methods in the flight controller rely on calculating the angle of pitch and so forth from a flat world (go flat earth idiots) but as we rotate around the planet pitch angle will depend on how we are oriented to the planet. So this must be accounted for. I would go into more detail now but I'll save it for the orbital elements section.

That's the post for now. The game is further along so this blog should be updated soon as I capture some more recent content. Thanks for reading. 

Moga