Tuesday, 19 November 2013

The Quad Core Conundrum

A recent post on the private backers forum by Michael Brookes revealed what Frontier Developments regard as the minimum spec to run the Elite: Dangerous alpha build. It makes for interesting reading:
  • Direct X 11
  • Quad Core CPU ( 4 x 2Ghz is a reasonable minimum)
  • 2 GB System Ram (more is always better)
  • DX 10 hardware GPU (my reasonably low end machine has a GTX 285 with 2GB)
When asked if faster dual core processors will be able to cope, Michael said they would run the game but it would likely be unplayable. Some people are sceptical of this claim, even after reiteration from Michael and further explanation.
Michael made reference to multi-threading as the reason why 4 cores are required, but I think he was actually referring to multi-processing. The reason some people are sceptical is because of the way the most games have been developed in the past.

A computer game is basically a very tight loop, made up of reading user input, updating (AI, networking) and then rendering. Each one of those steps is dependent on the one proceeding it and so they can't be run in parallel (or there is very little gain in trying to do so). This has led to the practice of keeping everything in a single process (although I'm sure there are a few exceptions).

However, a space sim such as Elite: Dangerous may offer some unique opportunities to have some heavy tasks put in separate processes. A few examples spring to mind:

Galaxy Simulator / Procedural Code

OK, there probably isn't any need to simulate the entire galaxy but certainly a star system. If they're complex enough then there may be a significant amount of work involved which would benefit from being done separately. Don't forget, there are going to be procedurally generated textures and bitmaps required which may not be suited to being generated on a graphics card.


Keeping track of thousands of objects and particles (velocity, rotation, collision) may warrant a separate process which is then queried by the main process. I imagine handling the interactions and gravitational effects of planets, moons and belts made up of thousands of asteroids is not trivial. If the amount of physics work going on far exceeds the overhead of implementing it in a separate process then this could make a lot of sense.

Scripting Engine

If the user interface and some other features are done through a scripting engine such as LUA then there may be a real opportunity to keep it in a separate process and leave the main process worry about the tight-loop. In the future, if user scripting is supported, then dodgy user code may not impact the game so much.

Then again, perhaps this is all speculation and the alpha build will happily run on dual core processors. Remember, Michael is in a difficult position and doesn't want to make promises which then get broken. It may just be simpler to give out the spec of a machine he knows to work and then refuse to be drawn on lesser deviations.

EDIT: Thanks to Maxeren on the forums for pointing out the existence of fragment shaders in relation to procedurally generated textures on graphics cards. I have now changed it to reflect the fact that whatever method FD use it may not necessarily be implementable on graphics hardware.