GameDev Diary – SpaceLife #5

Planet Hacking – scaling objects based on distance

Continuing my experiments into creating large planets, I came across this post where people are simulating large scales by resizing objects based on the distance away from it. I couldn’t get the code in this post to work because I’m still moving the camera and not the world – But I created my own implementation based on the theory, using the downscaled 3d skybox containing the distantCamera and distantSun.

Scale based on distance.png

If you haven’t noticed already, there’s a glaring error with my maths –

  • as you get closer to the object the scale isn’t linear. At a starting distance of 40, if we are 20 units from the planet, it’s scale is multiplied by 40/20 =2, but if we only go 10 closer, we are 40/10 = 4. Are we really twice as close? If we are 2 meters away, the planet is 20 times bigger, and one meter away we are 40 times bigger. That’s not right!
  • Even if the maths were right, we are doubling up distance movements – by scaling AND moving objects. The edge of the object has moved towards or away from us in addition to the movement.

If we want to move around planets, we have to be able to move the camera (or world) around us, so I have to ask the question to myself, why am I concerned with scaling objects by distance? What problem am I solving?

The problem lies that within the mini-skybox, all planets have been downscaled, and when we move around, we need them to be scaled up at runtime. This has two advantages – one we can arrange our solar system with ease (you can’t easily move items that are huge, or even fit them into the scene), and we give the perception that moving 1/100000 unit feels like moving 1 unit. So, back to the drawing board on the maths – trying to take into account a linear progression but also the scale of the camera movement…

I’ve worked out what was wrong with the maths, but there’s another problem – Even if I solve the scale  issue – Unity just can’t handle it. If I want really large planets, drawing really large objects isn’t the way forward. If I have a scale of 1.6m and a distance of 800,400 and a camera far clipping plane of 1000, I can see the planet, but it flickers really badly. Obviously I’m not the first person to try and tackle this problem, and it looks solvable if you know what you’re doing. I currently do not!

The most interesting posts I’ve found so far on this subject are here:

And this awesome video

Either this will inspire or destroy me!



Gamedev Diary – SpaceLife #4

Planet hacking – multiple distant cameras

Ok – attempt 1 – multiple cameras that allow distant objects to be rendered. To overcome Z buffer accuracy…

  • I added more cameras as children of the main camera.
  • I added a layer called ‘distant’ – this allows only distant objects to appear in this layer, making the culling mask ‘distant’ (not shown below).
  • I changed the depth order so that the cameras would render farthest first
  • I changed the most distant camera to contain the skybox
  • I altered the near and far clipping planes.
  • I received an ugly error flooding my console (didn’t stop the program though) when exceeding the far clipping plane value 1e+07


I made the sun super huge:


I’m not particularly a fan of errors and warnings in my programs.  This approach has worked – but it’s not entirely satisfactory. I also wonder how many cameras should I add, where does it stop?

Thoughts so far on this approach:

  1. Unity soon complained about the values I entered (just warnings).
  2. When I  approach the sun, it looked massive, yay, but very rough meshes.
  3. When approaching them, my ship coordinates are far from 0,0,0 – which allegedly will cause madness with the physics calculations (if I were to hit an asteroid etc).
  4. Any layered effects you put on the object tend to be very fiddly and don’t show up (e.g. scaled down transparent spheres/particle effects), and they might look ridiculous at close range – I’ll have to do some more playing around to see if those can be worked around. Multiple LODs? Maybe switch meshes/objects out as they transition to closer cameras?

I’m going to shelve this idea for now and play with another….

Planet Hacking – The scaled down universe

For this experiment I just moved my planet and sun to a point way out of the scene, and re-parented them under a new game object. I then added a camera with a normal viewing distance, and placed solar bodies apart scaled down to 1/100,000,000th (one millionth) of their sizes.


The final trick is to add a LateUpdate() function onto my camera and tie in the distant universe camera as a public property of my main camera:


This worked great!


You can see my spaceship moved a huge distance (11 million units) and my camera in the mini universe only moved 11 units. However, as you can see – I’m now getting warnings that my spaceship is too far away. Another issue presents itself – when I get close to the sun, it doesn’t appear big any more. It is only 20 units wide – and it looks 20 units wide close up.  I’ve scaled the distance, but not the size.  Should I scale the size whilst moving? it all seems perverse. Maybe have bounding colliders that allow me to reposition the sun further away but at a bigger scale?

Back to the drawing board!

I think it’s time to find out how others achieve this – rolling my own is starting to get frustrating!

Its fun trying though.



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


Gamedev Diary – SpaceLife #2

Well, that was five minutes well spent!

In the last post, I mentioned moving the ship’s physics code into the BaseShipProperties class (I think it’ll better called ShipController, don’t you?), and it’s liberating! I’ve made the main input handler smaller – a good thing, because I think we’ll be adding more to it. This allows us to easily use the same ShipController as an AI bot, sending it thrust, roll, pitch instructions without replicating the movement and intertial dampner calculations. Also, I don’t care to know what the max speed is in the camera controller, that’s upto the ship, so I don’t Clamp() it here.

Improved camera controller

Whilst I was testing my scene, I thought I’d have a look at the stats tab, and wow, 30 draw calls (aka SetPass)? I narrowed this down to the OnGui() function which had all my scene buttons in it created by GUI.Button(). Removing the buttons reduced the draw calls to 9. Much better. #oneToWatch. The funny side of this is that I had noticed juddering, so I looked into the draw calls to see if something strange was happening. Then I noticed the GUIText() culprit, but even then the program was juddering. WHY?

Well, I was running another windows 10 hyper-v session in the background that I’d forgot about. This dell laptop is amazing with its NVIDIA GeForce GTX 960M, but I should give Unity a fighting chance!

As you may notice below – I’ve found some cool font to show in HUD, maybe it’s temporary, but maybe not! It’s pretty nice. Let’s hope meters per second is enough. Or do you like miles per hour? I guess it depends if my ancestors have pillaged your country or not.


Particle article…

Oh my, particles are fiddly beasts aren’t they? My first outing with the particle system, and I think I only achieved this by copying the standard Asset for the aircraft jets, and tweaked it a little. I think I need to spend a good few hours watching tutorials and playing around to get effects combined that produce something lovely, I’ve managed this so far – next step to make the length adjust with the speed (madness in space, it makes no sense!). The question is, should I add jets for rotation, pitch and reverse thrust? Maybe overkill.


Hmm.. The choices you have – does the jet size relate to how much you’re trying to accelerate or thrust? That would certainly be the case in the real world of space physics. But it doesn’t work so well in games. It will mean that if we are going our top speed  we will have no jet. So, maybe we’ll do a bit of both. The jet should depict how hard we are trying, and as we reach our target speed, we settle down to a size proportionate to our speed. – I’ll give that a go and see! Oh the fun!



Gamedev Diary – SpaceLife

After creating the TapPhrase game, I regret not keeping  a running diary of events, discoveries, mistakes and milestones.

So this time I’m going to try and run some quick blogs charting the progress of the game I’m making at the moment called SpaceLife.

My biggest woe at the moment is that I don’t actually know what I am creating, other than I’m doing it because it’s fun.

I’ve always wanted to create a space-epic like Elite, X2, Galaxy On Fire, EVE, Starwars Galaxies. I would be happy with something that did even 50% of those. I’ve always had a fascination with space games, and in particularly hauling goods across the galaxy. Yes I’m weird.

I have so many ideas of what this game could be, from the basics (exploration, mining, pirate hunting, and hauling) through to Space->Planet transitions, proper exploration, surface mining, Farmville in space, tower defence.

My more left-field idea is that you are actually a Space Unicorn, whose trying to create rainbows through space. Or, you work for a bunch of Space Unicorns that require magical carrots in order to bend space for large corporations to transfer goods and governments to wage war (like the Navigators in Dune).

The tragedy is procrastination – thus, I’m just playing with spaceships at the moment.

I’ve got a few spaceships, nebulas, skyboxes and planets that I’m just getting the control mechanisms right for.

My main work yesterday was to construct camera positions around a spaceship using cameras to get the picture right, and then disable them before running the game. When the game starts up, we enable the forward facing camera, and when the user presses 1,2,3,4 we Slerp within two seconds to the location and rotation of the camera positions. It kinda works, and is good enough for now. I’ve made a nice scene which serves as my play-area in Unity to experiment with ships and planets without having any performance issues with lots of scene objects. Here’s  a sideways screenshot.

Thanks to the brilliant contributors in Unity’s asset store, I’ve not had to create a single model yet. This has accelerated my enthusiasm, so I can concentrate on the structural coding and logic (which there is very little yet).


What you see here is a small ship, probably an escape pod or ‘safe zone transport for one’, I doubt it would serve much more than that given its dimensions.

I’ve created a basic script called Base Ship Properties, which simply exposes a number of public variables that a main controller can interact with. It also defines the camera positions available. This allows me to apply this component, set some values and re-make prefabs for different ships and tweak their base properties.


I haven’t yet decided if this Base Ship Properties will include basic functions for movement which are called by the main input loop – i.e. instead of having code manipulating transforms in the MainCamera’s PlayerController script, that it simply told the ship how much movement is being input – then the ship script should know how to handle the input itself. The last thing I want is a complex main control script, but also I don’t want Input.GetAxis/GetkeyCode style code anywhere else other than the main loop. – this will be a job for later.

Plauyer Controller.png

If you’re interested in how I get the cameras to move at the moment, here’s some code. TargetCamera is set up when the user presses a key to be one of the ships cameras, we then try and move our transform (the camera) over a fixed 2 seconds to the target camera position and location:

Plauyer Controller

What’s next?

Before I move code around, I want to try adding jets to the ship where its rear nozzles are, and make them proportionate to the speed. Then I’ll work out how to make it nice and generic, so that Prefabs can just add the scripts and drag in game objects as placeholders for those thrusters, and maybe assign a tag to them to identify if they are forward/roll/pitch (as required).

One thing I should mention – This isn’t realistic space simulation.

  • angular drag is on to kill some of the speed when turning.
  • I have a max-speed per ship, once we achieve that speed we do not go any faster, unlike in space. Most space games do this, because it’s no fun trying to stop with infinite acceleration!
  • I apply inertial dampening to the ship when banking/turning – so that the player can feel like they are getting the affects of air resistance, and that they don’t feel they are going backwards too long when they’ve flipped 180′.















MacBook Pro blank screen and no keyboard illumination

This morning I woke up to a ghastly sight – my beloved MacBook pro opened but with a blank screen.

An external display didn’t even register at the time (but did eventually).

To cut a long story short I did the following, using instructions from this site:

  • Held the power off button to force power off, turned it on, several times, whilst trying different dance moves and monastic chants, invoking demons, you name it – no luck.
  • Tried to reset the SMC, using the hidden sleep functionality – no response.
  • Tried to reset the SMC using the keyboard shortcuts – no response.
  • Reset the PRAM – I got a chime from the MacBook – yay.. I must have fixed it, NOPE.

Disheartened with the lack of screen, I decided to plug the external display in again, and see if that’s changed.

BINGO – I had a progress bar. But it was stuck at 25% and still no main display!  (so one of the above DID do something).

I then found Safe Mode (SHIFT+POWER ON), could get me beyond the progress bar stall (  – but still no main display, and the drawing speed was very slow – probably because graphics drivers aren’t fully loaded or something.

The  other problem I now had is that the external display wouldn’t show the Apple Bar at the top, so making it hard to access sleep etc.

I solved this latest conundrum by adjusting the TV’s own controls to fit the input source to the screen, rather than taking a 16:9 aspect. (Something I’ve not had to do in the last two years!).

I was then about to try resetting the SMC again, but found this Apple article Just following the initial steps exactly (Sleep, Wake, Shutdown, Restart) fixed the problem. And then after changing the display settings I could finally get on with my Unity 3d Project!



 ** UPDATE **

My fix lasted for two days, then the screen really didn’t want to work.

After taking it to the Leeds Apple Store, they simply took the MacBook apart, reset the SMC again, disconnected the battery and reconnected it as well as “Reseated the graphics card cable”. It’s fixed again – for now.

Thanks Apple for not charging me for your time though – many would.


Radiation Diary – Visualizing data

Having a few hours spare on a Sunday evening, I decided to try and visualize the rather dull radiation levels recorded from last weekend. I know how to live right?

Ever the outcome focused individual, I decided I wanted to produce a heat-map of the flight. I’ve never done this before, but with a little Googling I worked out it should be possible with Google Maps and JavaScript.

I’m no JavaScript expert, and without intelligent auto-complete or type-safety this was going to be a little more hacking than development. I stumbled across, a free on-line development environment, but it still lacked auto-complete. I probably should have tried Visual Studio, but with CodePen and Google’s API documentation, I began the hackery.

Before I got too into the code, I decided to visualize the problem and input data. What did I have? Check this picture out, it should say it all.



To produce


See the code, and press Run. Add the Satellite imagery to see the runways properly.


How to load files?

Luckily with a copy and paste from Stack Overflow, I’ve got myself some asynchronous ajax request using JQuery.

How to process a CSV file?

Yet again, Googling revealed Jquery-csv. Bingo!

How to convert the date from the CSV into a JavaScript date?

A little more complicated, I had to hack the separate components of the string because it wasn’t a format JavaScript liked. There may have been something in JQuery that could have helped. I didn’t check.

– How to work with JavaScript objects, arrays, blah blah?

Years of experience of many languages and good Google skills. Yet again, I probably didn’t use all the JQuery I could.

– How to combine the radiation data in minutes, to GPS coordinates in seconds?

I didn’t think too hard about this, I merely iterated around each GPS coordinate and found what radiation existed in the same minute and added a weighted blip on the map.  However, that does mean that what you really see as heat is the clumping together of readings as the aircraft slows down or banks. Zoom in and the heat goes. I’ll need to experiment more to get that right – but the basics are there.

– What’s with the markers?

The KML file import provided all the markers, but I couldn’t find a way of deleting or manipulating them to show interesting peaks of radiation. So I’ve just left them for now as I didn’t really care, the 80-20% rule and all that.