Gamedev Diary – SpaceLife #3

In thrust we trust

I think I’ve got a solution to the thrusting issues (ooer). 100% thrust looks nice, and at 100% speed you get the same rewarding jet so you know you’re travelling fast. Yes – I know, in real space you would keep accelerating if that were the case.   And when you’re going 50% of your max speed, you get a half-jet etc. The trouble is when you’re trying to recover from a sudden 180 flip or harsh pitching, you don’t get any indication of extra effort being put in to correct your course. Now you do! There’s  an extra flare of thrust for ‘inertial dampening/correction’. However, these wacky calculations caused some issues when trying to manually increase or decrease the thrust, the effect was that the jet immediately altered which looked poor. So I introduced another calculation just for when the user manually alters the thrust – lerping from the current size/length values to the target values over time.

See the comparison below of 100% thrust and 100% with recovery thrust:


I’ve got a bit of code tidying to do but other than that I’m happy for now – there’s always room for improvement, but things like planets and space-stations, mining ships and the usual space-fare are calling me. And yes – a nice dashboard/cockpit wouldn’t go amiss.

Size is important

Ok, so now I’m trying to put planets in the scene. You may have already seen a screenshot where I placed a big yellow sun and smaller planet in the scene. It was all fake – you could run up to that planet in no time, and it’d be the size of a rock. That’s not what we want. Unfortunately Unity (and many games) have some issues when trying to represent far away objects.

  1. If you try and encompass far away objects in your main camera, you can end up drawing a lot of objects you might never be able to see (slow)
  2. A large viewing area (near and far clipping plane) leads to errors in the drawing pipeline because the Z (depth) buffer can’t calculate the correct order easily.
  3. As distances move far away from (0,0,0) physics calculations can go screwey.
  4. The accuracy of objects can only be represented by up to 7 significant figures. Thus you can model small items successfully, but really large items start to loose a few meters, kilometres or more depending on how big they are. (Let’s not forget the earth is 149,000,000,000 meters away from the sun, and the sun is 1,392,000,000 meters wide. So I may just get away with it – as I don’t really need physics in play for those planets, but I might want to get near them, which puts me way off the (0,0,0) origin.

Obviously Suns can be seen from very far away. If we extended our camera’s range, it would have to be huge. Not really feasible. Time to look for solutions.

Looking around the forums I discovered a few tricks which I’m going to try out:

  1. Combining cameas: Set up your main camera to render 0.3 to 1000, and then two more cameras which render 1000 to 10,000,000 and 10,000,000 to 100,000,000,000. I can see how this solves the Z buffer issue, but might not solve drawing too many objects without a bit of help.
  2. Combining cameras: Keep your main camera as is, but have a scaled down solar system somewhere out of sight from your main scene area that contained your distant objects, vastly reduced down in scale. You would then use the LateUpdate() of your main camera to keep rotation in check, but movement would be scaled by your ‘mini galaxy scale factor’. Thus you’d still edge towards these planets but very slowly. You would also configure the mini-galaxy to have the skybox, and to draw first by configuring it’s depth setting to less than that of the main camera. I’m also not sure how sheer size will factor into this unless we can narrow the camera frustrum to make items look massive?
  3. Additionally, instead of moving your player around a universe, where physics might get dodgy as you move away from the center, move your universe around the player keeping them at 0,0,0 (sounds hard).
  4. I had another thought which was to ‘occasionally’ do step 3, e.g. when my ship hits +-1000 in any axis, move all root game objects + or – 1000, and the player. Effectively zoning the map such that we never stray too far and physics can work effectively. However, I imagine that any code which is attempting to reach a specific world-coordinate will have some amusing ‘hyperspeed’ experiences. Best not to prematurely optimize.

So, my next step is to try some of these methods out and report back. I could take the easy route out and just deny allowing players to get within close proximity to planets and insist on using space-stations to Segway between space and ground. If it was good enough for Starwars Galaxies, it’s good enough for me. But ideally I’d love for players to go seamlessly from space to ground, if their ship was suitable. #lifegoal



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s