Making a Space Flight Sim!
Members - Reputation: 120
Posted 24 June 2012 - 11:08 PM
I'm an electrical engineer, particularly one of those who codes more than most. I have a good grasp on C, which basically means I can code in anything inside that umbrella--C#, C++ and my Java is excellent because of the lots of android programming I do as a hobby. I know a little python and perl and a few assembly languages. Another of my hobbies is producing music/DJing, so I have all that mess more or less sorted out in terms of equipment and software. I know a crapload of physics too, especially electromagnetic stuff (obviously). I have all the Autodesk stuff I need for making models and texturing. As far as my actual game programming experience goes, I made a thing in flash a million years ago and used some of the weaker game creation suites (like RPG maker) for some quick jokes.
I drew up some sketches and some theoretical models for some sweet propulsion and weapon systems, I'm more or less ready to go. As far as my research shows, I need this major stuff:
-a lot of scripting
-peripherals! (like joy pads)
-or alternatively a complete game engine that has everything I need.
Something like this (http://www.shatters.net/celestia/documentation.html) captures the fundamentals of what I want to do: realistic space travel, including the modelling of distant objects, orbits, gravity etc. A lot of different engine/renderer combinations look alluring, but I'm not sure which direction to go in because of the nature of the type of combat I'm thinking about incorporating. I want to use a lot of directed energy weapons and have realistic EM wave propagation and assorted effects, which means a lot of vectors with complex calculations everywhere all the time.
In plain English, I need something really fast and really flexible that can have a lot of math shoved into it.
I have a few friends working me on this too, so don't refrain from advice that points me down a labor intensive route. At this point, I want some opinions on what tools I should use. From there, I'll do a warm-up project to familiarize myself with the workflow then take on the big one.
Members - Reputation: 1054
Posted 25 June 2012 - 04:12 AM
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)
Members - Reputation: 120
Posted 25 June 2012 - 06:36 AM
"Space Kraken" brings up the issue of PhysX--I think it looks good because it has soft-body dynamics as well (if I'm not mistaking it with something else). I think I agree with you on the C++ though--it's pretty much as close as you can get to workhorse C while keeping objects (let's act like objective C doesn't exist because I hate it). 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.
Members - Reputation: 107
Posted 25 June 2012 - 09:30 AM
s33d, you may want to take note of a freeware called Orbiter. (http://orbit.medphys.ucl.ac.uk/index.html)
While I'm certain that what you're talking about is going to be different, a lot of the concepts may be the same. More importantly, while Orbiter is not open source, he does keep an active API for programmers, which may give you some ideas on some tricks for your physics.
Also, since Orbiter is a non-open source hobby, a lot of fan devs have been looking at trying their own hand at their version. You might be able to find some people with similar ideas or who have also attempted these issues here: http://www.orbiter-forum.com/
Either way, good luck. As mentioned before, there is a lot of physics and math to take into account. If you can simplify things, that might be better.
Members - Reputation: 1054
Posted 25 June 2012 - 12:38 PM
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)
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.
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.
Moderators - Reputation: 18054
Posted 25 June 2012 - 01:27 PM
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 :-)
[Work - ArenaNet] [Epoch Language] [Scribblings] [Journal - peek into my shattered mind]
Members - Reputation: 120
Posted 26 June 2012 - 10:49 AM