I think the main reason you don't tend to find games like this is like you say, maths. Computers are only so fast. I think a game like this might need to purely be written in C++ rather than C# or java. Btw, C# isn't derived from C, it technically doesn't fit under the C umbrella like you said. I have seen people saying its a nice mix of C and java before though, but I think .net or mono (or the JVM for that matter) might impact the speed of execution too much and lag your game, it looks like there might be alot going on there.

As for a renderer, Ogre3d is for C++ is very good and pretty quick, the only thing faster would probably be writing your own openGL or directx renderer. Irrlicht is also a good C++ renderer, don't know how good it is compared to ogre.

Physics you have a few choices, ODE, newton and bullet are the only ones free to use commercially that I can think of. I'm not really sure if any will do what you want them to do, you can always use parts of them and then write your own code to supplement.

For scripting it is possible to embed python or lua (lua is a little lighter weight) into C++ programs but of course there is a huge speed penalty over hardcoding or using DLL's.


I think the main issue is the sheer size (litterally, as well as the amount of effort) of this project. I advise you to have a look at the so called "Space Kraken" in the kerbal space program. The sheer magnitude of velocities and forces experienced can lead to all sorts of overflow bugs. Scaling down the universe so each ship appearing to be lets say 50 meters long is infact only 1 meter and scaling all other relevant factors aswell may be a good idea. Also N-Body physics (simultaneous gravity from all objects in game at once as would be realistic) is a HUGE impactor of speed. Going back to kerbal again it uses spheres of influence and only the strongest gravity effect takes hold (the spheres are hard coded too). This makes a few procedures impossible unfortuneately (like a stable figure of 8 orbit) but your going to fkill you computer trying multiple bodies. A viable solution may actually be the 2 strongest spheres instead.

Peripheral support won't really add any overhead, nice thing to add (are you thinking basic Xbox gamepads or the whole way upto flight sim control deck things)

Ogre3D looks pretty neat, but how good is the wounding? I want to smash a lot of stuff and I know good particle effects are more or less par the course nowadays, but wounding is still a little rare.

As ogre is graphics only (and I think it also offers limited sound and input abilities but from what I hear these aren't as good as using openAL or whatever instead)
It supports particles without issues, I think for wounding you can probably deform the model file and get ogre to draw the now deformed version. Should be possible.

Full disclosure: I spent 9 years writing space simulation games for one of the market leaders in the genre.


First of all, space games are hardly any more math intensive than anything else. In fact, done correctly, they can be far less computationally bound, because they by nature take place in a sparse environment. This makes physics, for instance, much simpler to do in an efficient way, provided you don't want ultra-realistic gravitation between arbitrary numbers of bodies. (I.e. you can get away with one or two gravitational influences per environment, but anything past that is going to be a nightmare due to the Newtonian n-body problem. Numerical stability of your integrator will go to crap in a heartbeat.)

I point to games like IWAR which did realistic physics and really cool energy weapons back in the mid/late-'90s. Think about how much hardware has advanced since then, and tell me that any modern desktop is going to be compute-bound in a space game ;-)



Secondly, the big challenge of doing a space game today is predominantly dealing with scale. Astronomical scales are hard to handle with traditional mathematics available in CPUs (i.e. either floating-point or fixed point). Get used to dealing with hierarchical coordinate systems and the mind-bending reality of having different objects exist in different coordinate spaces even within the same physical area.

Third, don't underestimate the artistic side. The big expense of the space games I worked on was far more on the art creation side than on the programming side. Making a space game that looks good is a lot harder than it sounds, but incredibly rewarding. If you're looking to capture the "ooh wow" audience at all (as opposed to the guys who would play a space sim if all it consisted of was a radar screen and a few gauges) then you'll need fantastic artwork. Recruit some good people to handle this and you'll be in good shape.


Considering you already have a solid background in mathematics and physics, I doubt six-degree-of-freedom geometry is going to give you any substantial trouble. Look out for the basic pitfalls (gimbal lock, coordinate transforms, imprecision, and overflow/underflow) and you'll be fine.


The last bit of advice I'll give you is to follow a slow-growth roadmap. As an engineer you should already be familiar with the dangers of tackling a project more complex than you're prepared to complete. Organic growth is a better and safer alternative, and if you ever get truly "stuck" you can always make heavy-handed changes in your direction or technique as appropriate.

- You're going to have to build your own graphics engine if you want realism. Period. No commercial or free engine on the planet is up to the task of dealing with the scale and intricacy of this, believe me.

- Sad to say it, but C++ is probably your best bet for a language. Whether you go Direct3D or OpenGL is entirely up to you.

- Start with a simple renderer. Just throw some textured triangles on the screen.

- Now add movement: add the ability to "fly" around your textured object in 6DOF.

- Get some artwork in there ASAP. Nothing is as motivating as seeing things that look cool.

- You'll want some kind of simple UI now; something to keep track of relative positions of objects, directional headings, etc. Even if it's just text overlays on the screen. Resist the urge to be excessively fancy.

- Now that you can move around and keep track of where you are, start introducing other elements: moving objects besides yourself, gravity, physics, etc. Pick a physics engine and integrate it with your renderer.

- This is a fantastic time to start implementing your ray guns and such, since it'll add more fun and motivation.

- Now integrate a scripting system (I like Lua) and build some simple AI for your enemies. Point and shoot should be sufficient.

- You should by this point have a solid tech demo and possibly a pretty visually impressive miniature game. From there, it's up to you to design a solid finished product, but you'll have enough of the basics in place to do a decent job of realizing your dream.


Finally, don't ever be afraid to scrap a large part of your code and redo it in light of lessons learned. There are a lot of things that are best discovered on your own by doing them the hard way, so it'll likely happen more than once that you find out that you could be more efficient or elegant or whatever by rewriting some code. This is not a sin. Think of it like designing a circuit and then discovering that you can halve its heat output by rejiggering a couple of traces and pulling out a resistor, or whatever (sorry, electrical engineering ain't my strong suit!).


Best of luck, and keep us updated - as you can probably discern from my career note at the beginning of the post, I have a soft spot for space games :-)