Archive for the ‘SpaceSim’ Category

Heightmaps and Force Fields

2013/02/23 Leave a comment

Work is proceeding on my space war game (SWG); it would be nice if I came up with a proper name for it but for now SWG shall suffice.  For the past couple of weeks I’ve been looking into missile mechanics and shield simulation.  For the missiles I simulate fuel load and consumption, albeit crudely, such that the missile has a limited flight time before tumbling into a fit of self-destructing acrobatics accompanied by a flash of yellow sparkles.

A work buddy suggested that I tackle force fields next and he had the good idea to use a ripple effect – the same sort of ripple effect you get when you drop a badger into a lake.  There is a very simple algorithm[1] that you can use to produce a variable heightmap for use in a water effect and thought this would be suitable for deforming my shields.

The Update method is called once per frame to update the simulation:

Here’s some shots of the ripple effect:



…and corresponding textured-mesh view:


Then of course I went to apply it to an ellipsoid and I was sort of stumped as to how to deformate a 3D object – something with no edges no less.  Realising I was a bit of a buffoon, the obvious answer was not to procedurally modify the mesh via a heightmap but rather use the heightmap as an input into a parallax shader where we can fiddle with the surface normals thus giving the illusion of heightened depth.  So I kept my code above for creating the heightmap but I just tossed the mesh modification.

I wanted my shader to be transparent so the alpha component is merely the heightmap value.


Here is a short video of the outcome.

[1] “2D Water”,

Categories: SpaceSim Tags: , ,

A Space Game in Unity3D

2013/02/10 Leave a comment

Having moved from XNA to Unity3D I thought I would have a play at making a simple space game.  I thought this would be a good exercise at procedural asteroid fields; AI; missile simulation and nebula effects whilst learning how to use Unity3D;

The following video shows my games work in progress from a few weekends in Unity.

Categories: SpaceSim Tags:

Autonomous Steering Update for Space Simulator

2012/11/07 3 comments

I recently added a behaviour for steering the ship towards a target destination; thrusting up to cruise speed; followed by a final deceleration step.  With a given velocity and breaking deceleration it’s reasonably easy to work at what point to start breaking.  This makes it nice to enter a point in orbit around a planet or perhaps a space station.

Next will be to work out an actual orbit based on either a given velocity or how far the orbit should be.  Fun days ahead!

Other updates include:

Though floating origin works rather well, the next problem is to scale the planets based on how far away they are.  “float”s don’t have the precision to otherwise model ranges of the distance from say the Sun to Jupiter and then to model Jupiter’s diameter.  It seems the solution is to treat things as continuous sub-scenes.  A topic for another day.

20121104 spacesim

Categories: SpaceSim Tags: ,

Space Simulator Screenshots

2012/10/23 Leave a comment

Here’s some spiffy pics of the simulator thus far:




The Earth with a nice atmosphere effect.  A quick implementation of atmospheric scattering


Categories: SpaceSim Tags: , , ,

Space Simulator Rewrite via Unity

2012/10/23 2 comments

I’ve switched to Unity 3D, both a game engine and game development environment for my humble Space Simulator hobby project.  Thus far I’m most impressed with the speed that Unity allows me to realise ideas and focus on what is more important – what the game is about. Far more sensible than spending time in other 3D APIs trying to implement a mini-map which may break in the next release of the API.

Unity’s asset and scene browsers allow you to organise your project logically and visually.  Setting up a scene is an absolute joy as opposed to attempting the same in code.   Files that have been created externally in say Blender, 3ds Max or Photoshop for example do not require subsequent import steps, Unity immediately displays changes.

Unity Pro also comes with some nice features such as:

  • Pro Image Effects including shadows; screen-space ambient occlusion (SSAO); bloom
  • Occlusion culling
  • Extended light-mapping (radiosity)
  • Deferred rendering with unlimited lights
  • HDR
  • A pretty dark-grey theme

I did feel guilty about the idea of using a tool such as this but that was quickly laid to rest.  For instance, we use nHibernate, StructureMap, Entity Framework, ASP.NET MVC and IDE’s such as Visual Studio and Xcode so the concept is not new.

Why re-invent the wheel?

Don’t Move Your Viewpoint–Move the Universe Instead

2010/12/28 10 comments

In my space simulator project I wanted to model the Solar System but sadly this led to a rather annoying limitation because of restrictions of single-precision floating point. Flying about near “Earth” and the moon seemed OK but flying to Jupiter proved another story. If I tried to place say Jupiter at a scaled-distance from my in-game “Sun”, flying my ship to the Jupiter region caused all sorts of floating point truncations which were very much visible in ship rotations – it all became quite “jumpy”.

After a bit of reading by posts from other devs in my predicament, it seemed that the best approach was not to move the in-game first-person camera based on ship motion but rather to always keep the camera at (0,0,0) and to move everything else instead! In other words – you don’t move, the Universe does. Reminds me of a Greg Bear novel. Winking smile

Also, it makes no sense at this stage to store everything in absolute coordinates when you are dealing with the very large.  I think that storing everything relative to it’s immediate stellar parent makes more sense.  e.g. planets to stars, moons to planets and so-on.  By using octrees I can partition objects relative to the node in which they live thus cutting down large values.  e.g. at least one of the Jupiter nodes should contain the planet and all its moons while other nodes just take into account the planet.

So with this in mind I:

  1. placed the scene origin (0,0,0)
  2. placed the sun at the origin
  3. distributed the planets and moons scaled down and relative to each octree node
  4. placed the camera at some nice location
  5. translate octree nodes based on the camera’s logical position (move the planets not the camera)
  6. when rendering, just draw those models in octree nodes that intersect with the view frustrum
  7. eventually this can lead to dynamic scene content streaming based on the contents of an octree node

Anyway here’s a video.  It’s a test video where the maximum viewable distance is shorter than normal hence the planets vanishing only to be replaced with “crosses” so as to indicate “not viewable”.  If an octree node is too far away it turns blue.

Categories: SpaceSim Tags: , ,

XNA Planet Custom Shader

2010/12/18 2 comments

Well I’ve been working on making my planet shaders to be something a bit more colourful.

Day and Night

First of all I wanted to map two diffuse textures that are alpha blended depending on whether the planet’s side is in the Sun’s shadow or not.  When it is you’ll see the city lights twinkle on.


Next I wanted to do some sort of atmospheric effect.  This was tricky and I’m still not absolutely happy with it – I think I need to read more on subsurface scattering.  Geometry-wise, it’s just a slightly larger sphere.  To shade it the atmospheric shell only renders when the surface normal is nearly perpendicular to the eye – in other words it only shades around the edges of the planet.  The dot product is raised to the 4th power or so to be used during the calculation for the alpha value.  The atmosphere is also emissive so as to illuminate when in shadow.

2010-12-18 vanquish planet atmosphere 1

2010-12-18 vanquish planet atmosphere 2

2010-12-18 vanquish planet atmosphere 3

2010-12-18 15-35 vanquish planet atmosphere

Categories: SpaceSim Tags: , , ,