One of the classes I'm taking this semester is a relatively low-level astronomy course, and while we were talking about the gravitational force's effect on its satellites, the professor pointed something out that I had never thought of before. I'm sure you're all pretty familiar with the equation for gravity, where 'G' is the universal constant and 'g' is the resulting force:

g = G(m₁m₂) / d²

You're also probably aware of the formula for the relation between force, mass, and acceleration:

f = m • a

What I had never before considered was what happens when you put the two together to find the true acceleration from a gravitational pull.

G(m₁m₂) / d² = m₂a
(Gm₁m₂) / (d²m₂) = a
Gm₁ / d² = a

If the horrible formatting didn't confuse you, you'll see that the mass of the satellite gets cancelled out from the gravity equation, and therefore any two satellites, no matter the mass, will have the same orbit around a star.

When I realized that I had overlooked this and that my admittedly very innacurate astronomical simulation was even more innacurate than I'd thought it was, I decided to do some reworking. Once I had taken the mass of the planet out of the orbital calculations, ramped up the gravitational constant in my program, and adjusted the initial speed for each new orbit to match the old ones, there's basically no difference. However, some of the planets in my program now orbit faster than they used to, and some orbit slower, because it's a little bit more scientifically accurate than it was before, and I'm pretty happy with that. This also opens the door to some more fun ways to play with the orbits - I've already added two planets with very different masses and overlapping orbits that I know will absolutely never collide with each other, but that make for some really interesting navigational and economical possibilities.

Another thing that we discussed in my astronomy class has to do with the location of the star inside its satellites' elliptical orbits and how it will always be on one of the foci of the ellipse. This little fact caught hold of my curiosity, and so I wrote a lot more code than you'd think was necessary (or at least, more than I had expected) to calculate the location of the foci for each of the orbits in my game and compare them to the location of the star. Unsurprisingly, math is very consistent and even my mediocre physics simulation places the star anywhere from a lower bound of less than one pixel to an upper bound of about six pixels away from one of the foci. Considering that most of the orbits are at least a thousand pixels wide, I think this is pretty awesome!

Anyway, I know that this isn't much by way of progress, but I've had fun coming back to this project with some actual science and thought it was worth sharing. Hopefully I can keep going and come back soon with some more progress.

Basically, I haven't done anything. I've only spent about an hour programming over the last two weeks as I settle into my new school schedule. I definitely want to find some regular programming time before too long, but I still may not do much for another week or two.

Oh well. At least I got in that last really big update on the old thread, so I don't feel too bad about a few slower weeks. Hope your guys' projects are going well!

Chances are that there's going to be some more problems related to the route system for me to solve, but barring any major distractions, my plan for this week is to work on being able to select convoys apart from when they're docked on a planet (which doesn't include convoys that are waiting on that planet until they launch again). Without this, once a convoy is assigned a route it can never be selected again, so it's an important feature but shouldn't be all that major of a task, which sounds perfect for this week.

In a sentence, this game is (going to be) an interstellar trade simulator. The player will manage ships, create trading routes, and more to earn money and grow even bigger. I have a lot of ideas for cool features, but I'm trying not to get ahead and myself (and, realistically, I kind of doubt that I'll ever get far enough to start implementing more than the relative basics, but fingers crossed!).

All of my progress so far can be found here.

Goal

Spend a minimum of two hours over at least four days every week programming.

Achievements

Carry-Over Achievements

½KLOC: Your game reaches 500 lines of code. You're off to a great start!
1KLOC: Your game reaches 1000 lines of source code. Making progress! Excellent!
2KLOC: Your game reaches 2000 lines of source code. Keep it up!
Hang it on the Fridge: You create at least one piece of art (sound, texture, model, sprite, etc.) for your project.
Artistic: You create four pieces of art for your game.
Widget Factory: Add a UI of some sort to your game, with buttons, sliders, check boxes, etc.
Heads Up: Add a Head-up Display or other UI overlay to your game.
It's Just Temporary: You put in artwork in your game that you claim is temporary, until you or your friend can provide you with better art.

I've also already spent seventy-eight hours and twenty-four minutes working on this game, but for the most part I'll start counting from zero again. I may make note of when my overall time reaches big milestones like one-hundred hours, though.

New Achievements