
Back at the end of January I mentioned that I was starting work on programming a new game called One Small Step. Well, at last I have some screen shots to show off. Those will be down at the bottom. It's actually taken a huge amount of work to get to this point, and I thought I share some of the details with you (hopefully without boring anyone too much). This might get a little long.
Some of the difficulty has been in determining the equations used to calculate the exact position of a body in orbit at a given point in time. I actually ended up purchasing two text books to help me deal with this issue (although I expect the books to help solve other problems for this and future programs as well).
The first book is Fundamentals of Astrodynamics by Bate, Mueller, and White. It's an introduction to a variety of issues in Astrodynamics. It covers a lot of theory on a variety of topics (even including an interesting chapter on ballistic missiles). I got this because while most of this information is on the internet, it's hard to find stuff that doesn't jump straight from the easy stuff right into the super advanced stuff. This keeps the information at a more consistent level, and while some of the math takes some effort to understand, it's still at least vaguely approachable (though it would be waaaay easier if I hadn't forgotten all my college math).
The second book is Astronomical Algorithms by Meeus. It's a book that covers the practical instead of the theoretical aspects of solving a variety of astronomy related problems. There's great stuff in here that covers everything from calendar conversions (for things like Jewish or Arabic calendars) to a huge variety of other issues related to finding and displaying astronomical entities. It's nice and easy to follow, although doesn't cover anything theory, which means you might have some trouble if you need to expand a situation to be more generic.
Some of the difficulty has been in drawing an exact ellipse. At first I was using the drawing routines from the programming library that I using for my user-interface. Then I discovered that the line for the orbit wasn't exactly on the planet when zoomed in sufficiently far. That led me to discover that they're using an approximation to draw circles and ellipses. It's actually a very good approximation with an error probably on the order of 0.0001%... Normally good enough, but not in my case. Well, getting the ellipse draw was tricky, and required lots and lots of frustrating trial and error, even after I found a good algorithm online.
The end result can be seen in the screenshots below:

Here you can see a shot of the entire system out to Pluto (yes, yes, Pluto isn't a planet). One feature of note here is that the inner solar system and all the various moons exist, but are hidden, since at this zoom level they're too close to the planetary body that they are in orbit around.
Another interesting feature is the button labeled "+7 Days". Every time you click that, time advances 7 days and everything gets updated fairly quickly. For a system containing about 300 bodies, it takes about a third to a half second. As I proceed with the game I'll need to find ways to be tricky and get better performance, but that's good enough for now.
For the shot above, you'll note that I turned off the labels, icons, and orbit paths for Asteroids and Comets. That's because there are 100 randomly generated asteroids in the belt between Mars and Jupiter, and 125 randomly generated asteroids and comets beyond the orbit of Nepture. If I hadn't turned those features off, the display would look a bit... messy.

For this shot I've zoomed in a little bit so that you can see the inner planets, and turned on the icons and orbits for the asteroids and comets.
This is a good time to mention the controls for changing your view. You can use the scroll bars to move the view around, and the one at the top of the window to zoom in and out on the current point in the center of the screen. Or, you can zoom with the mouse wheel and drag the view around by clicking and dragging the mouse. Each time it needs to draw the screen, it takes about 0.1 to 0.2 seconds (or less, depending on the size of the window). While not completely smooth, this is definitely sufficient, and fairly impressive given what's taking place. Again, I may be able to improve performance here in the future.

Finally, I've zoomed in somewhat on Jupiter and its moons. I wasn't able to zoom in enough to allow you to see all the moons, and in fact, the larger, more famous ones are in too close to the center to be visible. Trust me though, they're there.
This brings up another point... I entered in information on all the planets and most of their moons. Each orbit has effectively been rotated so that everything lies in the same plane (everything is 2D, not 3D). Other than that, all of bodies represented should be at the correct locations for the start of year 2000 (a common checkpoint for astronomical data). Orbit shapes should all be accurate. Now, for performance reasons (and because it doesn't matter that much for my purposes), I'm not modeling gravitational peturbations that occur due to the influence of other bodies in the system. That means that accuracy will definitely drift the further you get from the year 2000. Still, it should be sufficiently accurate. Oh, and yes, it did take a while to enter the information, particularly since some of it was not represented in a form that I could use, and I had to manually add together two different numbers in order to get the correct value that I needed.
You'll also notice in the picture that the background is green instead of black. What's happening is that I'm currently drawing a solid green circle around every body to represent the sphere of influence of that body. You can actually see a bit of black in the lower right corner. That's the edge of Jupiter's sphere of influence. Essentially, this is the area within which a body is more influenced by Jupiter's gravity than the sun. Essentially an object isn't going to have a stable orbit around Jupiter unless it's within Jupiter's sphere of influence. This information also gets used with a technique called patched conics for altering the orbit of a body when it passes near to another body. This gives a reasonably accurate means for having objects like comets get their orbit modified if they pass too near Jupiter or something. It's also used when plotting the course a spacecraft takes when traveling between orbits around two different bodies. I haven't yet implemented that stuff yet, but it's coming sometime in the (relatively) near future.
Well, that's probably enough for now. At least there were pretty pictures! Hopefully next time will see the introduction of a way to select and view information about objects, and the implementation of parabolic and hyperbolic orbits. Those types of orbits indicate a body which has reached and surpassed escape velocity of the body around which it orbits. This opens up the possibility of additional asteroids and comets, and... spaceships!
Comments
Re: One Small Step - screenshots
Sweet!
Come a long way from drawing triangles (ships) and arrows (vectors) on pieces of paper huh?
=)
Seriously though, that's some very nice work man. Now about the far-reaching orbital differences due to the gravitational non-effect of smaller bodies. Is there an easy way that you could do a gross adjustment? Meaning, if you decided to use this system in a campaign set in about - lets just say - the year 3300 could you re-calculate the celestial body positions for that date, and then set everything in motion from that point, instead of the starting point being y2000 so they would technically be more accurate, but then for the more current stuff, the simpler calculating method wouldn't result in as much an error (for the stickler)? Or am I out in left field?
-- Kent
Re: One Small Step - screenshots
That's a perfectly valid question. I will not be making adjustments to the base orbits according to the starting time. What I will be doing is properly modifying the location of each body along their orbit according to the starting time. In otherwords, I will be assuming that the orbit parameters that I have are completely accurate and unchanging, and then correctly setting the location of each body appropriately for the starting time.
The reason for this is that it's hugely complicated, and I don't think I can get accurate values out that far because no one has calculated them. The data I'm using is considered accurate out to 2050, and even at that point should have errors of less than 1/6th of a degree at worst (and more like 1/60th of a degree in most cases). I have access to data that is considered "accurate" out to the year 3000, but it's an average of about half as accurate (or up to 20 times worse in some cases). Beyond that, I'm just not seeing any data, and I can't generate it myself because it tends to be generated based on observation, not calculation.
In addition, the eventual default starting date of the game will likely be sometime in the next couple decades anyway, and games won't tend to run longer than 100 years or so (most likely), so the current accuracy is probably sufficient.
However... You will actually be able to provide your own data file for game initialization, which means that if you can generate the "correct" starting values yourself, you can use them to get stuff set up.
Oh, and yes... a long way from triangles and arrows.
Re: One Small Step - screenshots
So - anything recently here? Ready to take that second small-step?
-- Kent
Re: One Small Step - screenshots
No progress recently, but I've actually been close the last two weekends to putting on some more work on this project, so it wouldn't surprise me if I got back to it sometime soon.
Re: One Small Step - screenshots
I was lost on most of that explanation but what you are doing looks really cool! I'm definitely impressed . . . I have NO idea how someone goes about making headway on such a vast project! I feel a bit like I do when my husband talks about what he does at work. Wow! The pictures help a lot so that I can visualize what you are accomplishing. Thanks for posting!
Re: One Small Step - screenshots
Wow, I reallly like this! Some good work here! You have accomplished quite a bit! It kinda makes me laugh about Sagan getting excited about "listening" to noise from outterspace and thinking that if he finds a pattern it might indicate there is intelligent life "out there." Didn't he already notice that "outer space" pretty much follows a pretty complicated pattern as it is--maybe there is life besides himself. I enjoyed reading this a whole lot even if it is beyond me!
Re: One Small Step - screenshots
Very impressive...hard to imagine working that ahrd at math just to have fun!
I'm curious...what is it about what you are wanting to accomplish that makes the precision you need beyond what most opthers need? You must be aiming at something above and beyond what is already out there.
Re: One Small Step - screenshots
The need for precision is a little funny in this case. In most real-world astronomy programs there is a great concern that the program accurately represent the real world (for obvious reasons). My needs are slightly different. There are two different kinds of accuracy I'm attempting to achieve.
First, the eventual target audience of this game is a small niche group of people that loves detail and simulations, loves playing complex games, and really likes space. That group of people is more likely than average to notice little details about a representation of space ("Hey, where's Halley's comet?"). So, I make a reasonable attempt to have the objects in my solar system be relatively close to reality. In addition, I may as well use real-world data, since I need those numbers anyway to have elliptical orbits represented. So, why not use the actual numbers.
However, the more you try to achieve results that perfectly match reality, the more complex the simulation needs to be. Given that I am writing a game that will be doing other things besides just modeling the solar system, I don't have the computing power to throw at this to make it ultra realistic. So, I have to make a cutoff at some point. That's why all the orbits are in the same plane instead of being truely 3D. It's also why my obits are all perfect and unchanging elllipses instead of being constantly perturbed by gravitational forces.
Secondly, I need pinpoint accuracy with regards to where an object is located in space, because the game is intended to include spaceships that fight each other. You could abstract those fights, but I'm interested in more of a simulation approach, and in order to make that interesting, I'm planning on having things happen in time slices that are a minute long. If your game handles things in time slices of a minute, then you need to know where exactly an object is from minute to minute. That requires fiarly high accuracy in your orbital simulation to avoid things like planets seeming to have an inconsistent movement rate.
Now sure, you could make the argument that there is no need for this kind of complexity. Just have circular orbits instead of eliptical ones. Or don't bother having planets/moons/asteroids move at all. But... this being a simulation-style game, part of the point is to find the fun and interesting features in playing a game in a setting that is highly realistic. Because fun is still important (fun is relative to the target audience), I may have to tweak things as I go along. For instance, it may end up being pretty pointless to have something on the order of 250 asteroids in a star system. So, I may throw out most of those and only show the 25 "most interesting" ones. We'll see. I'll have to play with that as things develop.
With regards to your comment about aiming at something above and beyond what is already out there... This is not exactly true. Lots of programs have a much higher fidelity. That is, they represent the real universe much more closely than I do. Most of those don't need the precision I do, because an astronomer really doesn't care about being off in location by a couple kilometers. In fact, many programs are oriented around an object's viewable location from Earth, and in that case it can be sufficient to be off by a fairly large amount and still be "close enough". Most games require high precision like I mentioned, because there is usually a need to "zoom in" and deal with interactions on a small time slice or at very close ranges. Most don't make as much an attempt as I am to accurately represent the real solar system. There are some exceptions though, such as Obiter, which is an extremely impressive space flight simulator.
Re: One Small Step - screenshots
Interesting.
Actually, it's the high precision I wondered about. I don't doubt that the accuracy is good - ie, fidelity - but as you obviously know, precision and accuracy aren't the same.
So, this will be a real-time (ie, not accelerated) scenaro, rather than an arcade (ie, accelerated time) scenario? Or, do you do long travel accelerated under the guise of hyperspace speeds, then real-time in the close-up kinds of things? We both know this game isn't for me since I rarely have the patience for real-time games. That's why real simulators aren't for me. I have enough trouble with flying coast to coast in real life let alone real-time trips in MS Flight Simulator, for example!
I'll take a teleporter any time to get from origin point A to point B where there's something of interest. I always said that if there wasn't good fishing at the end, it would be hard to justify the pain, time, and effort of backpacking! 
I assume you know all of the tricks in the book to save computing power, etc. Some things immediately came to mind regarding trade-offs, but I'm sure anything I can think of would be trivial and you've long since passed that level of thinking. I'd be interested in hearing some of the tricks you play to get there. Every so often when I'm playing a game, I see something and realize that it is a pretty slick way to save memory, run faster, shortcut limited bandwidth, etc. I find those kinds of things fascinating, even though I know I'd never have a need to use them myself.
Anyhow, thanks for the explanation. As I said, I'm very impressed. It's way over my head, and more ambitious than anything I'd try myself if I did have the technical background.
Re: One Small Step - screenshots
Actually, the game will be... sort of accelerated real-time, but sort of turn-based. Essentially, the computer will process things in a turn based fashion where each turn represents one miunte. But, things will run constantly until the system encounters a significant event of some kind or the user manually pauses things. While stuff is paused, the user can give orders and step things forward one turn (one minute) at a time.
Of course, I'm not entirely sure yet that things will calculate fast enough, so I may end up finding that I have to carry things out on a sliding time scale so that some turns take a minute, but some turns take longer (an hour or a day). I really hope I don't need to do that, because it can become really tricky to program, because you need to know when to shift time scales, and you need to be able to have tasks partially accumulate progress towards completion according to variable length "turns".
So, we'll have to wait and see exactly what we end up with.
And actually, I'm not typically really great at optimizing performance. But, it can usually be very difficult to optimize performance without seeing the code, since most optimizations deal with details, and those that don't require the code to be structured in a certain way from the ground-up.
Since the calculation of location for bodies in orbit is carried out as an iterative process where each iteration adds to accuracy, I actually want to put in a sliding scale so that the number of iterations is appropriate for the object. Objects in a closer orbit will require less accuracy than those further away, because the result of the calculations is an angle and a radius, which needs to be more accurate at longer ranges in order to obtain the required x,y coordinate accuracy. I've also got a couple things I'd like to try to speed up drawing performance.