A question of scale…

So, addressing the consistency of vessel sizes led to addressing space stations (naturally – ships need to dock), which has led looking at how I am portraying the volume of ‘local space’ you would be in when by a station, or other vessel, which has led to looking at how ‘local space’ maps to ‘planetary space’ – and so on up the hierarchy.

Regular viewers may recall that you can go anywhere in Dominium ‘space’… not just where I say you can, or where we’ve bothered to author a scene or some content. You can drop into deep space between star systems at your behest. You can fly between the satellites of a planet, into it’s ring system and then to the star, and back out to the furthest planetoid – as you choose.

To do this, we have a scene hierarchy which you can freely move about in – which brings interesting challenges for computing technology. I have broken ‘space’ up into a series of volumes which each increase in scale. Think of it as ‘granularity’. If you move 100km in local space (and yes, right now it’s scaled so you can ‘see’ 100km in local space, which will change!), you would then move 1 unit of ‘planetary space’ – which gives me a new scene in local space – and so on. When you travel between stars, you are not in ‘local space’ but ‘galactic space’ where 1 unit is a light year, giving you a new stellar scene to view.

So – when you fly to a planet, you are actually just flying to it’s location in ‘stellar’ space. Once there, you stop moving in stellar space and enter ‘planetary’ space. You then fly through ‘planetary’ space into the planetary system (with it’s satellites). When you fly to a space station around the planet, you move in ‘planetary’ space to the stations location and then stop – entering ‘local’ space where you can then fly to the station itself, no longer moving in ‘planetary’ space.


The crux of all this is – I have to balance all these various scene scales off against each other (by mapping each to the other) so that moving through local space results in a believable change in the planetary scene, moving through planetary space results in a believable change in the stellar scene, and so on. This is incredibly important, as some of the objects floating around Dominium are very large indeed (orbital rings have a circumference much larger than the world they are built around) and you have to be able to fly around them in a believable and above all seamless way. But don’t worry – you, the intrepid space pilot, will have no idea all this technical magubbery is going on. You will just say ‘fly from A to B’ or just turn your FTL drive on and then off when you like – and all this scene management will just happen.

This all leads me back to the galaxy generation algorithms – and changing how they work. Or rather, the units they work in. I chose the “Astronomical Unit” (149,597,871 kilometres) as the base line for mapping out star systems, planetary orbits, their radii, et al – it seemed a good yardstick to choose given that Earth is 1AU from our Sun.

Each scene can represent prominent objects from a lower scene, scaled appropriately. So, the stellar scene contains ‘planets’ – but scaled to the stellar scene’s units. At the moment a planets radius is represented in AU’s in the stellar scene, which means a very small number is being used. (Earth is therefore 0.00085 AU’s across.) Very small floating point numbers for processors are incredibly inaccurate. Remember, I’m not using the ‘double’ precision floating point type due to being cross-platform with mobile devices. This may very well change – by the time Dom gets released all mobile devices may be powerhouses of double precision number crunching! For now – the mobile FPU determines the precision I have to work in.

Now I need to rethink the database ‘base unit’ – it was only ever a ‘stop gap’ to get things rolling. I may change the stellar scene to a basis of 1 light-minute instead of 1AU. This increases the overall range of numbers from their current values by a factor of 8.5 (as Earth is roughly 8.5 light-minutes from Sol : 8.5m = 1 AU). It also increases the fidelity of the numbers being used for very small planets (giving a slight increase in accuracy). A minor (almost intangible) benefit, but one that gives me a consistent unit of distance to work with. This way I won’t have to write a load of conversion functions which can handle ‘1AU -> light-minute’ and so on. Trust me when I say that having a consistent ‘measure of space’ when building a galaxy and letting someone navigate it at leisure is very handy!

But it doesn’t stop there.

At the moment, planetary orbits (and satellites) are all ‘perfect circles’ – which isn’t the case in reality. They are typically elliptical, and sometimes wildly eccentric (Pluto). So I need to get them to have orbits which obey Kepler’s Laws. Even though the game will run in ‘real-time’ and you’ll rarely notice planetary orbital changes – they will be taking place, in real time. Play the game for a month and you may notice planets have moved along. Their orbiting moons (and non-geostationary space stations) will certainly have changed position.

In short – making things ‘consistent’ has ballooned into a mahoosive overhaul of the game universe which has long been postponed, and is much needed.

Now, where’s my calculator…


  • Facebook
  • Twitter
  • Myspace
  • Google Buzz
  • Reddit
  • Stumnleupon
  • Delicious
  • Digg
  • Technorati
Author: Mak View all posts by

Comments are closed.

Subscribe to The Dominium Observer Newsletter!